Call its functions
Server Objects run on ck-exec.
A client never changes a Server Object's values. It calls one of the Server Functions its definition lists, and the server decides. The examples use the village beacon's FeedBeacon function, which takes an Oil amount and answers with the oil the beacon now holds. Every node here needs a Server Object; see Get a Server Object.
The Call node
Call FeedBeacon has an execution pin and a pin for each input on the left. On the right it has Then, On Success and On Failed, then a pin for each output. It is a latent node, so it goes in an event graph. On Success or On Failed runs, one of them and only once, when the server answers.
Outcome and Reason are shown on the node, after the function's outputs. Retryable, Code and Timeout are in the node's advanced area: click the small arrow at the bottom of the node to show them. Timeout is an input, explained in Give up sooner. Code is an output that only a Game Kit starter fills, with its refusal code, such as full; it is None for every other type. A pin you have already wired stays visible when the area is collapsed.
- On Success runs with the outputs set. Wire them straight from their pins.
- On Failed runs with Outcome, Reason, Retryable and Code. Outcome is one of the call outcomes. A call the server refuses by a rule in the asset, such as Callable By, arrives as Denied with the reason to show, and a call inside a Cooldown as Denied with Retryable true; see What a refused player sees. A call to a server, or a type, that is switched off or paused arrives as Paused with Retryable true, so a Switch on Outcome has a Paused pin: try again later or show a paused message. A Game Kit starter's refusal for a reason of the game's, such as a full match, arrives as Refused with its Code, so the Switch has a Refused pin too. A call made after the player's access ended, or still waiting when it did, arrives as Access Ended, not retryable, so the Switch has an Access Ended pin too: show Reason and send the player back to sign in; see When access ends. A call that times out says in Reason whether the server's own limit or the connection gave up; see Timeout.
- An input you leave alone sends its default from the asset.
- An input that does not fit its type, such as -1 for a
uint32or 70,000 for anint16, sends nothing: On Failed runs as a Bad Request and Reason names the input.
The beacon's oil changes on the server, not on the client when the call succeeds. On Oil Changed shows the new amount to every player watching, the way it does in C++. Call reports what the server answered; use On Changed to show the state.
When Members From is This Object, the built-in functions Join, Leave, Add Member, Remove Member, Make Leader and Set Open for Joining are offered as Call nodes too.
A busy server is retried for you, up to three tries, and nothing else is; see What the SDK retries.
Feed the beacon
When the player walks into the beacon, feed it ten units of oil:
- Add Call FeedBeacon (CSO_VillageBeacon) and wire the overlap event, Event ActorBeginOverlap, into its execution pin.
- Set its Oil input to 10.
- Under On Success, use its Oil output, the oil the server says the beacon now holds. Under On Failed, show Reason, or try again later when Retryable is true; show both with the arrow at the bottom of the node first. The figure prints the oil, and the reason, with a Print String each.
Pan a Blueprint figure with the right mouse button. Press Copy nodes, then Ctrl+V in your own event graph.
The call needs no Target: it uses the beacon's own component.
Give up sooner
A call waits for the answer as long as the project's Server Object Call Timeout allows, 20 seconds unless you changed it; see Project settings. The advanced Timeout pin of a Call node, typed or generic, is a limit of its own for that one call, in seconds. It is counted from the call, retries and waiting to send included. It can only shorten the wait: a value above the project's timeout changes nothing, and 0, the default, leaves only the project's. When the function has an input named Timeout of its own, the typed Call node labels its limit pin Call Timeout so the two do not clash; otherwise the pin is Timeout. A graph saved with either label keeps its links.
When it runs out, On Failed runs with Outcome Timeout and Retryable false, and Reason reads, for a Timeout of 5, "No answer within 5 seconds; FeedBeacon may still have run on the server". The server is not told to stop, so the call may still take effect, and an answer that arrives later is not reported. Watch the beacon's oil with On Oil Changed before you feed it again.
Ping the platform
Ping Server Objects is a latent node under Crowdy SDK > Server Objects. It asks the platform for an answer over the connection the Server Objects already hold and measures how long it took:
- On Success runs with Round Trip Ms, how long the platform took to answer.
- On Failed runs with Reason.
The node is the async action UCrowdyServerPingAction, and both of its pins are the delegate FCrowdyServerPingDone.
It never opens a connection. With no Server Object connection open, such as before the first Server Object is used, it fails at once with "No Server Object connection is open". The platform answers at most 60 pings every 10 seconds on a connection and drops the rest without a word, so the SDK refuses more than that itself, failing with "Too many pings: the platform answers at most 60 every 10 seconds". Ping on a timer of a second or more, not every frame.
By name
The generic Call Server Function under Server Objects has a Function dropdown that lists every function of every asset, for when you would rather pick than type. Its pins are laid out like a Call node's, with Outcome and Reason shown and Retryable and Code in the advanced area. The nodes below work by name and by type instead, for a graph that calls whichever function it is told to.
Feed the beacon by name
- Call Get Server Object on the component. Drag the result into Is Valid first: it is None until the object joins.
- From the Server Object, call Make Inputs with Function set to
FeedBeacon. It returns the function's Inputs with their default values. It has execution pins: wire it in before Set Server Value, and pass its result to both of the next two nodes. - Call Set Server Value with those Inputs, Name
Oiland Value10. It changes the Inputs you pass in and returns true, or false when there is no Input by that name or the type differs. - Call Call Server Function with the Server Object, Function
FeedBeaconand those Inputs. - Under On Success, call Get Server Value on Outputs with Name
Oilto read the oil the server says the beacon now holds. Under On Failed, show Reason, or try again later when Retryable is true.
The figure is steps 1 to 4 only: it has no trigger event, no Is Valid and nothing on On Success or On Failed, and it reads the Server Object from a component variable named Beacon. Add your own trigger and the Is Valid, and wire step 5.
Call Server Function here is the one with no Function dropdown, found under Crowdy SDK > Server Objects; it takes a Server Object and Inputs. It is latent like the typed one, and its On Success and On Failed behave the same. Both are the delegate FCrowdyServerCallDone, which carries Outputs, Outcome, Reason, Retryable and Code; a C++ handler bound to them takes all five, see Bind the Blueprint call in C++.
Make Inputs returns a function's Inputs with their default values, and is empty when the function takes none.
Two things to know about the by-name nodes:
- Set Server Value and Get Server Value work by name and by type. A misspelled name or a wrong type gives false, not an error, so branch on the result while you are wiring a graph. The typed nodes have no such failure: a wrong name or type does not compile.
- For a function with no Inputs, leave the Inputs pin of the untyped Call Server Function empty.
Related
- Call its functions, from C++: the same rules, from C++, and what the SDK retries
- Hear its messages: the previous page
- Call a Server Function Library: the next page, the Call node of a type with no instance
- Pins for every type: which pin each input and output gets
- Use the Game Kit starters: the Refused outcome and its Code
- Troubleshooting: every outcome, and the refusals from your server code
- Access, members and timers: what a refused player sees
- Tip jar: your first Server Object: Call Tip, click by click
- Shared boss fight: Call Hit with a cooldown and a value range