Windows client on linux server, odd behaviour

[Tankbuster 1733]

Guys,

 

Not exactly sure if this is the right place - does this forum cover Linux dedi server issues?

 

Anyway, my mission runs just fine on a Windows server with Windows clients. But a couple of guys run a Linux dedicated server and they report the mission doesn't work properly. As I don't have access to their box, I can't be completely sure what's going on, but I do have a relatively verbose RPT to look over.

 

First off, it seems the waitUntil command doesn't work quite right in initServer.sqf.

_handle2 = [] execVM "server\missionsetup.sqf";
waitUntil {scriptDone _handle2};

Works fine on Windows dedi, but on Linux, the waitUntil never releases. (yes, missionsetup does complete, I've observed that)

 

I changed it to

_handle2 = [] execVM "server\missionsetup.sqf";
waitUntil {missionrunning};

Where missionrunning is a publicvariable set by missionsetup.sqf and it works fine on both servers.

 

So, the above notwithstanding, is there anything special I need to be aware of when authoring a mission that will be run on a Linux dedi?

[jonekone 1]

Maybe post this to

Quote

ARMA 3 - SERVERS & ADMINISTRATION

 

[Fluit 13]

Hey Tankbuster, did you ever resolve this issue?

I have the same problem with DEP on a Linux server. You are using DEP in your mission too, so I recon you ran into the same problem?

I know that directory separators are different for Windows (\) and Linux (/), but I would expect the game engine to handle this.

[Tankbuster 1733]

Hi mate. I'm following your ticket on github and was about to chip in.

A Linux server had a similar problem and it was related to scripts not handling the script handle reliably.

As I said above,the only way I could unbreak this was for the called script to set a global variable flag on completion and have the calling script wait for that.

[Fluit 13]

Ok cheers mate. Hopefully they will fix this, but in the mean time I guess the global variable is the way to go.

Thanks!

[Tankbuster 1733]

2 hours ago, Fluit said:

Ok cheers mate. Hopefully they will fix this, but in the mean time I guess the global variable is the way to go.

Thanks!

Note this was something from 3 and a bit years ago and although the user who reported it is still active, I don't know if he still plays the mission and uses a Linux server. It ma have been fixed meantime too. Don't know. 🙂

PS and OT, while you're here.. are you likely to be doing dep_worldname data for Cam Lao Nam?

[travhimself 10]

I've been seeing this issue for several years, and it's still present as of today (July 2021). Frustrating, but I'm glad it's not only me!

 

I am running first-party DLC only. No other addons.

 

Here was my original setup:

_get_locations = [] execVM "init\server\get-locations.sqf";
waitUntil { scriptDone _get_locations; };
diag_log "WR_SYS: INIT: ...get locations done.";

_setup_game_objects = [] execVM "init\server\setup-game-objects.sqf";
waitUntil { scriptDone _setup_game_objects; };
diag_log "WR_SYS: INIT: ...setup game objects done.";

 

The first three lines would run fine. The second script (setup-game-objects.sqf) would run, and all its contents would be executed, but the scriptDone statement would never resolve.

• If setup-game-objects.sqf file were totally empty, it WOULD resolve. (Adding back a single line of code to the file, even a comment, would break it again.)
• If I removed the first three lines and ran setup-game-objects.sqf on its own, it WOULD resolve.
• If I flipped the order of the scripts, BOTH scripts WOULD resolve.

 

With these findings -- and judging by the variable name in the original post ("_handle2") -- this issue seems to happen when you try to execute multiple scripts (with waitUntil scriptDone) one after the other. But there must be some other nuance I'm not seeing.