Hosted vs Dedicated Server

[JohnKalo 657]

Recently two of our missions faced bug reports coming exclusively from Dedicated servers. Everything worked as intented in MP Hosted servers but not on Dedicated ones. The two issues that came up were these:

 

1.] Mission: Panochori Cleanup

 

Description: Players start the mission by being in a helicopter that transfers them to the insertion location.

Dedicated Bug: JIP players fell of the chopper and ended up airborn.

Fix (Thanks to the person that detected the bug): Used  this moveInCargo tran1; in the init of every playable unit that was in the helicopter.

 

2.] Mission: Eco Terrorists

 

Description: Players meet the Governor (AI Unit) who is then grouped with a particular player.

Dedicated Bug: AI unit has a disable "PATH"; that would not be enabled. The trigger that enabled the AI unit's path also grouped the unit to the player. The grouping worked but not the enableAI "PATH"; command.

Fix (Thanks to the person that detected the bug): Added a script and an addAction command and also changed disable/enable "PATH"; to disable/enable "MOVE";

 

So what I would like to know is why these issues occured. Knowing such a thing would be really helpful since we will not let them repeat themselves.

Is the dedicated and MP server that different? Are there specific procedures to avoid such bugs?

[Belbo 462]

Let's start with the basics:

The main difference between a dedicated server and a hosted game is that there's no player on the dedicated server. That means that the player command always returns nil on the dedicated server. player moveInCargo tran1 on the dedicated server will not work.

Every client on the dedicated server is a JIP client.

In addition to that the locality of arguments and effects have to be considered when using a command. enableAI has global effect but uses local arguments, as you can see from the biki: https://community.bistudio.com/wiki/enableAI

That in itself should probably not be a problem if executed after the grouping (which changes the locality of the AI unit to the player's client). But from the evidence given I'd say that this exactly seemed to be the problem. The join command takes global arguments, but enableAI doesn't. So probably you executed both commands on the server - and hence the AI unit wasn't local to it after the grouping. addAction only executes the code local to the caller - if the AI is local to the client already (after grouping) the client can achieve an effect by executing enableAI.

 

That's what I'd expect the reasons for these specific problems to be.

 

But let me elaborate on the differences between hosted games and dedicated servers a bit more with a couple of hints:

- Don't use init lines. Not ever (unless you specifically know why you have to use the initline - it has very, very, very, very, very limited use. Basically it's only viable for sp scenarios. I have yet to find anything reasonable for the init line to do aside from setGroupId). The init line of an object is executed on every client and server as soon as a client joins the game (which, as we now know is for every client on a dedicated server). That means that "this moveInCargo tran1" with 8 players on a dedicated server will be executed 9 times at the begin of the mission - and again everytime a client joins later, rejoins or whatever. "this addItemCargoGlobal ["Weapon",1]" in the initline of an ammobox will add 9 weapons in that scenario. That's not what we want, if we want just one weapon in there.

You should always use the right Event Scripts with their initialization order in mind to make your mission as mp compatible as possible. Every piece of code that only concerns the player should go into the initPlayerLocal.sqf, everything that only concerns the server should go into the initServer.sqf.

If you put a

waitUntil {player == player && time > 1};

player moveInCargo tran1;

in your initPlayerLocal.sqf the player will be moved into tran1 once at mission start and not later again and again and again.

addAction commands belong in the initPlayerLocal.sqf as well - there's nothing the dedicated server can do with addAction.

waitUntil {player == player}; in your init.sqf on the other hand will break the mission on the dedicated server, as player is always null on the dedicated server - code following that will not be executed by the server.

Using the init.sqf you should get yourself acquainted with all the different isServer, hasInterface, isDedicated and local checks. If you want a command or script to be executed both on the player's client and the server you should put it in the init.sqf but be aware that some commands only take local arguments or only have local effect.

 

- Consider the locality of triggers.

Triggers execute their code always local to the computer on which the conditions of the trigger are fulfilled. A "vehicle player in thisList" trigger can never be executed on a dedicated server - you'd have to use something like "{isPlayer _x} count thisList > 0". So make sure the triggers that have to execute global commands are only ever local to the server - and their conditions can be fulfilled on the server. And on the other hand you have to make sure that the triggers that execute code for the player only execute this code locally. "vehicle player in thisList"-triggers will execute their code once for every client's player unit that steps into the trigger.

 

- The good thing about scripting your mission to be dedicated server compatible is: Apart from the playableUnits vs. switchableUnits debacle (which is easily solved), you can play every mission that is ds compatible as a single player or hosted multiplayer scenario as well. It doesn't work the other way round. So make sure your mission is ds compatible if you want it to work either way.

[JohnKalo 657]

For starters thanks for spending so much time so as to explain what is going on.

 

Now as it seems dedicated servers are more complicating than expected. I am not sure it is worth spending workhours in order to make missions dedicated servers compatible when there aren't so many mission playable slots. It would be better to spend those hours so as to make more MP Hosted compatible missions. Nevertheless I will keep these in mind and try to make  our missions playable in dedicated servers when possible.

 

Oh and the fixes were witnessed to work so hopefully they will be workable.

 

 

 

[pierremgi 4890]

1 hour ago, helicopterenthusiast said:

 

Now as it seems dedicated servers are more complicating than expected... It would be better to spend those hours so as to make more MP Hosted compatible missions.

 

 

If you write for MP, there is not so much difference between dedi and hosted server. If you pay attention for what must be run on server (spawning AI units for example), and what should be on player PC (custom loadout...) you will never fail once on hosted. As Belbo said, if you catch the syntax for dedi, you can run safely on hosted (dedi + one client).

On the other hand, you can have the feeling to cope with MP requirements, writing for hosted, then have plenty of disappointments with the "hosted" player, for a bunch of unforeseen situations.

That doesn't mean to create a dedicated server each time you want to test your MP mission. That's a "lot of" work, even with BI tools.

Last point: When you play on a dedi, the AI units/edited objects belong to the server, except for some cases explained here. That means a dedicated PC runs their codes, letting all Players' CPU free of them and focusing on what belong to player. In better words, an hosted server has to manage the AIs + one player, degrading the fluidity of the game on heavy scenario.

 

[JohnKalo 657]

Quote

On the other hand, you can have the feeling to cope with MP requirements, writing for hosted, then have plenty of disappointments with the "hosted" player, for a bunch of unforeseen situations.

Our missions are tested multiple times so that is how we avoid any bugs on any mp hosted server.

 

Quote

Last point: When you play on a dedi, the AI units/edited objects belong to the server, except for some cases explained here. That means a dedicated PC runs their codes, letting all Players' CPU free of them and focusing on what belong to player. In better words, an hosted server has to manage the AIs + one player, degrading the fluidity of the game on heavy scenario.

Yep, that is why using the best speced pc for the host is advised.

 

And a question about addAction   .... objects that have addaction commands which activate scripts which are needed for the tasks to continue  ..... do those have a dedicated compatability issue?

 

If I get it correctly I have to use initPlayerLocal for loadouts or for when positioning the player somewhere at the start of the mission. Audios are always in the description.

Where are intros activated? In the init.sqf or in the initPlayerLocal.sqf?

What about the initServer.sqf. An example of when it is needed to be used please?

[pierremgi 4890]

5 hours ago, helicopterenthusiast said:

And a question about addAction   .... objects that have addaction commands which activate scripts which are needed for the tasks to continue  ..... do those have a dedicated compatability issue?

 

If I get it correctly I have to use initPlayerLocal for loadouts or for when positioning the player somewhere at the start of the mission. Audios are always in the description.

Where are intros activated? In the init.sqf or in the initPlayerLocal.sqf?

What about the initServer.sqf. An example of when it is needed to be used please?

 

AddAction can be difficult to work. As you know player addAction has no sense on a dedi server because there is no player. You need also to code again about respawn.

But addAction on object can lead also to errors. A good example of what could be an undetected error on hosted:

try to addaction a little push on a boat stuck on the beach to make it floating again. (you want this action available on each boat). Say, you want to use setVelocity to push the boat. The boat belongs to server. Your hosted player also. Seems to work fine when you test it... until you launch another PC to test a second player's action (remote). Now, the addAction is here but the second player can't fire the code because the boat is on server and the player somewhere else. Jump into the boat, disembark, the addAction seems to work. (workaround with remoteExec).

 

Yes initPlayerLocal is the best place to script something like loadouts. Last but not least, you don't have to ask: player still exists! so you can use player command without check.

 

Intro? I don't know. It's another "layer" like outro. I never use that. There is no player here!

 

initServer is fine for all events you have to script (as I said spawning units/ vehicles and so on). For example, you want to add a toolKit on each spawned vehicle. You just have to be on server for that. The global command does the job and you don't get a toolkit per player.

 

 

 

 

 

[JohnKalo 657]

OK thanks. I am starting to get into the Dedicated Server logic.

Need work since I got to convince myself that players do not really exist but that's all about practice.

If I ever need help about this issue I'll use this thread again.

 

 

 

 

[JohnKalo 657]

We have had another issue regarding a Dedicated server. This time Waypoints were activated when they shouldn't! 

 

Mission: Samaris Scrutinization

 

Details:

1.] AI units have waypoints to get in choppers and trucks.

2.] The following AI units' waypoints are SEARCH and DESTROY waypoints.

3.] The folowing vehicles' waypoint is a MOVE waypoint that is blocked by a trigger condition.

4.] The following vehicles' waypoints are TRANSPORT UNLOAD waypoints.

 

Differences:

[Hosted MP] AI units get in the vehicles. Afterwards, following the trigger activation the vehicles start moving and transport the units when and where they should. The AI units then follow their waypoints.

[DEDICATED] AI units get in the vehicles, disembark and move towards the SEARCH and DESTROY waypoint without the vehicles.

 

Result:

A mess regarding Dedicated Server gameplay.

 

[pierremgi 4890]

What is the trigger condition,

What role play the players in this cinematic?

[JohnKalo 657]

The trigger condition is a simple BLUEFOR Present condition.

Update: It is not a Dedicated exclusive issue. As it seems the guys providing the feedback have the same result even in the editor. Really strange since I tested the mission again and the AI units remain in their vehicles no matter what. Only when the trigger condition is met do they move. Maybe it is one of the mods they use?

 

In any case, I will place a condition for the AI units too if they are moving in some players and release a v1.1 mission version.

REALLY AWKWARD!

[opusfmspol 282]

Are you using editor "GET IN" synched with "LOAD" waypoints to have the units board the aircraft and trucks?  Rather than mods the culprit could be a known issue that synchronized "GET IN" and "LOAD" waypoints have in multiplayer.  Hosted MP and DS need scripting effort to make them work.

 

Instance of Arma:
Launch of an arma exe.  SP and Hosted MP are one instance of Arma launched, as both server and player/host.  DS is a separate instance of Arma.  A machine can have two instances running at one time, with DS launched and MP launched to join as a player.  Launching DS creates one instance, launching MP to play creates another instance.  DS testing gives best results when using two machines with three instances (DS/Player & player), it can give answers to questions raised where locality might be tied to a machine rather than an Arma instance, the DS/Player being JIP on server machine, and the other player being a true remote JIP.

 

Synchronized "GET IN" and "LOAD" waypoints Placed in Editor:
- In SP it works because server and player are the same instance of Arma running.
- In Hosted MP it works for host, but not for JIP.  Server is same instance as the host, but JIP is a separate instance of Arma running.
- On DS, it works when AI leaders have both the "GET IN" and "LOAD" waypoints.  It fails when either leader is a player.

 

Regarding certain waypoints probably being hard-coded in their function with the 'unitReady' command (which doesn't broadcast), there was discussion already:

 

 

Since then I've done more testing.  And where I had thought that the vehicle with the "LOAD" waypoint must be created by the same instance of Arma as the leader having the "GET IN" waypoint, I'm now questioning if that's really the case or if which instance of Arma reads waypoint conditions is the critical factor.  I found that only the instance of Arma for a group leader is checking his group's waypoint condition.  No other instance checks the waypoint condition.  If the leader is AI, only server instance checks the condition (even when players are subordinate in the group).  If the leader is player, only that player's instance of Arma is checking waypoint condition.  And in SP and Hosted MP, player/host is the server instance.  But all instances will execute the waypoint expression once condition becomes true for the leader doing the check.

 

The 'unitReady' command doesn't broadcast between instances, which is a real problem to overcome where only waypoint group leaders check waypoint condition and synched waypoints may have it hardcoded to their function.  The synchronized function of the waypoints would fail where the two leaders are not in the same instance of Arma.

 

(Final note: my platform is A2/OA Combined Ops, but as the linked discussions above showed, not much appears changed with this waypoint  behavior in A3.  To test waypoints for the instances of Arma, I inserted diag_logs into waypoint conditions and expressions, then checked to see which instances were reporting to the .rpt log.  Was surprised to find only the group leader instance reporting the waypoint condition check.)

[JohnKalo 657]

Thanks for spending so much time for replying but I do not have LOAD waypoints. The groups that have only got AI units have GET IN and SEARCH AND DESTROY waypoints and the vehicles have MOVE and TRANSPORT UNLOAD waypoints. The vehicles' MOVE waypoints have the condition. Besides the units reported to disobey waypoints are the groups and not the vehicles.

 

In any case, this post might have blocked other possible bugs in future missions     

[opusfmspol 282]

44 minutes ago, helicopterenthusiast said:

.... the vehicles have MOVE and TRANSPORT UNLOAD waypoints.   .... the units reported to disobey waypoints are the groups and not the vehicles.

 

And that jogs my memory, thx for that: It appears TRANSPORTUNLOAD also has similar issue.
https://community.bistudio.com/wiki/Waypoint_types#Transport_Unload

 

It may be that the single waypoint is hardcoded with checks for both groups, causing the fail.  Running looped currentCommand checks on leaders and the units could affirm.  Whenever a unit reaches unitReady status, the empty string ("") gets returned.  But as found, it only gives accurate return to the local instance, and returns true to all others, making the others jump the gun.  It seems a unitReady check might be getting made on the truck before a "GET OUT" command is made to the cargo team.

[JohnKalo 657]

Quote

The group will move to the waypoint (spatial or object), where any units from other groups who are in cargo spaces of the original group's vehicles will disembark. On a dedicated server, this waypoint does not work if the commander of the group being transported in the back of the vehicle is human. It will only work with A.I.

There are no human players and the vehicles are trucks so still there should not be an issue. Besides there has only been one bug report and while testing in MP everything worked perfectly