forums.smartfoxserver.com

I need to run headless unity server in a large mmoroom. My understanding is this unity instance will login to sfs as a client, from there I can do whatever i want.
The problem is I need it to controll mmoitems. But since this unity is just like another user, it has AOI, and will only know about mmoitems near it.

How do I get around this? AOI is needed for all other players, just not the headless server.

Hi,
you can use the the client API to connect from the Unity headless to SFS2X but you will need a more complex interaction.
In particular you need to talk to the Extension directly (via Ext calls) so that you can have access to the totality of the Room data, not just what a regular client is able to access.

Via Extension calls you can grab any data and bypass the limitations of the client API.

Cheers

Cool, can you tell me how to get the headless client to bypass AOI? thx!

I mean all my clients already connected through custom EXT. But they only receive things in the AOI. if this headless server connects to an EXT, he still will only receive things in the AOI, because other clients send position/var updates only to the AOI. It's not up to my headless client's EXT to receive what is not sent. So perhaps there's something I don't understand.

You're still relying on the Client API though, which is what Lapo said to not do.

So let's say you have a mob that needs spawning - the headless needs to know about this NPC. On the SFS server, you spawn the mob as normal, you can then trigger a "OnMobSpawn" extension response, which contains data about the new mob that's spawned. This "Extension Response" is received outside of the normal AOI information.

Your headless can then process this information and act accordingly. Your clients will still only receive AOI updates.

I'm curious though, why would you need to use a headless instance when SFS is there to handle the workload directly? The Client API is supposed connect directly to SFS from your Unity client is it not? Are you trying to only connect a single client (in this case, the Unity headless server) to SFS rather than the players themselves?

Thanks for writing. Quick version: How do I intercept the updating of player vars and force this information to the headless client?


The game has many clients connected, the players. They receive oai updates. Everything works good. The server handles everything including cheat detection, transactions, etc... But I need one single headless unity client to deal with cheating or things only unity knows, e.g. physics, landscape. Also, currently npc logic is controlled by clients, the server selects certain clients to control them, but I want to rewrite this so that the headless unity client will do this. In order to do this, this unity headless client, which is referred to the headless server, but in reality is just a client of sfs, needs to know all the info of mmoitem and other clients outside of aoi.

With that said, can you show me kindly some code example of how I would achieve what you described? The headless basically needs to receive all player data updates, and all mmoitem updates in order to validate all the important things that sfs cannot, e.g. physics related things, landscape, anything that is already in unity that I'd rather not duplicate, replicate, in Java.

So low level, if i dont receive info the way a normal client does, then how is my headless client going to know playerXYZ on the other corner of the map is moving, and his data. E.g. if he now equipped a sword instead of a gun, that's all done by player variable update, and that happens automatically by updating the player vars, same as setting mmoitem vars, when I set those vars, the server sends it to the clients in respective aoi, how do I intercept the updating of client var and force this information to the headless client?

Bumping it incase the support team missed it.

Sorry we can't provide specific code examples for your use case, as it's beyond the scope of our support. What we can do is suggest how something could be implemented.
As mentioned before in order for the headless server to know about the internal state of SFS2X there must be constant communication between the two. Since they are supposed to run side by side the communications should take place in a local private network, with very low latency.

The basic principle to use when building something like you have described is to query the SF2X state every time you need to make a "decision" for a specific player or NPC. In other words when running the headless logic you can send a request to SFS2X (via Extension call) and obtain the data that is needed, perform the necessary logic and update clients if required.

how is my headless client going to know playerXYZ on the other corner of the map is moving, and his data

You can poll SFS2X at a constant rate (or on demand) and obtain the updated players' state.

Cheers

Can I write something on my current extension so all client sent data is relayed to my headless client? Then my headless client and know all it needs, even animation

The problem is, there's much more to it than location. e.g. a player taps attack, jump, etc.. these need to be pushed, not pulled. So it would be good if the clients who send messages, will be able to relay all the messages already sent, to the super-client.

Lapo wrote:Sorry we can't provide specific code examples for your use case, as it's beyond the scope of our support. What we can do is suggest how something could be implemented.
As mentioned before in order for the headless server to know about the internal state of SFS2X there must be constant communication between the two. Since they are supposed to run side by side the communications should take place in a local private network, with very low latency.

The basic principle to use when building something like you have described is to query the SF2X state every time you need to make a "decision" for a specific player or NPC. In other words when running the headless logic you can send a request to SFS2X (via Extension call) and obtain the data that is needed, perform the necessary logic and update clients if required.

how is my headless client going to know playerXYZ on the other corner of the map is moving, and his data

You can poll SFS2X at a constant rate (or on demand) and obtain the updated players' state.

Cheers

Having a headless unity "super-client" defeats the purpose of using SFS in the first place...
Youre better of importing the terrain data into SFS and writing your own collision resolver in pure java, ofcourse thats a lot of work and pretty cimplicated but if you want to make a server authoritive MMO its really the only option, if you run a headless unity server running a unity instance you will need a much more expensive hardware server, theres other networking solutions that require a unity instance to be ran on the server but they arent made for mmos, rather for client hosted minigames or lan games with up to say 10 or 20 players.

No it doesn't defeat the purpose of smartfox. Players to Player communication is still leveraging all the MMO AOI stuff. This is only needed for the server controlled part of game world that relies on knowledge only Unity has. The rest still work as is.

SFS doesnt do "player to players" comms though... that would be a peer to peer networking solution which is very unorthodox. The way it works is always player to server to player, the server being authoritative if you want to be able to implement anti cheat.