Jump to content

Recommended Posts

Thought I would share an intense run in with an Apache. In my experience playing the mission on the lowest settings, there is like a 5% chance a gunship will be called in. So when this Apache started attacking, I had no idea what it was. Thought it was the IFV that was called out but the rounds quickly became apparent that it was something else. Good thing he didn't use rockets or missiles....but he might have used rockets..cant really tell. We survived the attack and Escaped Esseker. And yes we were screaming like girls during the attack. We thought it was over.

 

View the clip here:

https://streamable.com/z1vzi

Share this post


Link to post
Share on other sites

There's a lot of info in these 48 pages, but unfortunately I can't find a fix to one of my favorite missions

 

My problem

I very recently created my own linux dedicated server and when I try to play escape I spawn with full standard loadout, next to the same rock every time, with no prison anywhere around me.  I had previously been hosting this mission locally on my windows gaming pc/client and never had this issue.  Through all my testing, I've been sticking with mission co10_Escape_BIS_NATO_vs_CSAT in Tanoa from the 1.9 release, but the same result happens on other escape 1.9 missions.  The mission files were downloaded from the links at the beginning of this thread

 

My setup

The server OS is ubuntu 16.04 - 64bit if it matters.  There are no mods installed.  Battleye is active.  I only have added two missions so far - Antistasi and Escape.  I just put the whole co10_Escape_1.9 folder and the antistasi pbo in the mpmissions folder.  The antistasi mission plays fine.

 

I have a bash file for my startup command, which produces the following, and redirects stout and sterr to a log file.

./arma3server -cfg=/home/steam/Arma3/install/basic.cfg -config=/home/steam/Arma3/install/server.cfg -name=server -mod= -world=empty -port=2302 -noSound
 

I've placed several files here, including both server and client rpt files, and both server and basic configs passed during startup - some information has been redacted (usernames and BE uid)

https://drive.google.com/drive/folders/1hZyflR2XPp_RvHczebB0fFC5hgfnAt0z?usp=sharing

 

What I've tried so far over the last 3 days

  • read all 48 pages of this post, steam discussions, and plenty of google search results (no autoinit, no default mission, no mission rotation, no mods anywhere on my server or client, also no saved games in regard to escape on my client)
  • freshly installed arma on a different pc to make sure there was no hidden saved game interfering.  All client side parameters default, with only battleye listed in the startup parameters.
  • Updating/validating arma data on both server and client
  • Verifying integrity of escape files on server - redownloaded files and compared hash's against files in mpmissions folder on server
  • Running the server with no config files specified, so it was all defaults and I could eliminate the possibility it was something in either config file
  • Removing the "-mod=" from my generated startup command since I currently don't have any mods

I see other people have had a similar issue, but usually it came back to the autoinit startup parameter.  I haven't found anybody who had a different fix for this, and I'm thinking it has to be some mistake I made somewhere since the mission works for everyone else, and it worked for me when hosting on my client pc.  It's probably something stupid staring me right in the face, or I overlooked someone's fix by mistake. 

 

I am a little confused about all the files within the co10_Escape_1.9 folder.  In particular, am I right for putting the whole folder within my mpmissions folder?  The part that made me think maybe I was making a mistake was that beyond the files in the co10_Escape_1.9/missionfiles folder, there are vanilla related files in the addonfiles folder.  Is it possible these addon files are supposed to go somewhere else?  Currently I'm only interested in playing the vanilla version of the missions.  I'm only a year into Arma, and I've felt like I had a good grasp of things but now i'm questioning if I really know anything at all... 

 

I don't normally ask for help.  I usually just keep trying things and searching google, but i'm at a loss here.  Anybody have any ideas? 

Thanks in advance

Halfsak

 

 

Share this post


Link to post
Share on other sites
20 hours ago, Halfsak said:

There's a lot of info in these 48 pages, but unfortunately I can't find a fix to one of my favorite missions

 

My problem

I very recently created my own linux dedicated server and when I try to play escape I spawn with full standard loadout, next to the same rock every time, with no prison anywhere around me.  I had previously been hosting this mission locally on my windows gaming pc/client and never had this issue.  Through all my testing, I've been sticking with mission co10_Escape_BIS_NATO_vs_CSAT in Tanoa from the 1.9 release, but the same result happens on other escape 1.9 missions.  The mission files were downloaded from the links at the beginning of this thread

 

 

Try renaming the mission pbo to all lower case. linux A3 servers are prone to casing problems.

Spawing with gear and at the same place just means A3 is loading the mission setup but is not starting any of the scripts. Most of the time (as you already said) this is related to autoinit but it can also be Arma3 just not finding the script files.

I suspect the A3 linux server is loading the mission.sqm from co10_Escape_BIS_NATO_vs_CSAT.pbo but is internally refering to all content in lower case form (what shouldn't be a problem on windows), so it now looks in co10_escape_bis_nato_vs_csat.pbo which is non existent in your file system.

 

Can you try renaming the .pbo and teting again? Also make sure to start server and client with -showscripterrors command line, so A3 will prompt warnings about missing files.

 

Regarding the amoun of pbos: They all go into mpmissions. You can copy the mods and terrains you want to use and leave out the rest if you want. Every pbo works standalone.

Share this post


Link to post
Share on other sites
23 hours ago, winter_mute_ said:

And yes we were screaming like girls during the attack. We thought it was over.

 

View the clip here:

https://streamable.com/z1vzi

 

Wish you had recorded that screaming aswell :D

Share this post


Link to post
Share on other sites

Thanks for the quick reply.  I think I may have found the main problem, but i'm still testing some things before i was going to post again due to some other odd behaviors surfacing.  I found there was nothing in the client rpt showing that initPlayerLocal.sqf was executed, so I started examining what would cause that.  I found the first line referenced "name player", and most likely the player object wasn't ready yet.  I assume this made the file stop at this point, with nothing put in the logs.   I updated it to use profileName instead of name player to achieve the same end result without relying on the player object being setup yet.

 

Here's the first 2 lines of initPlayerLocal.sqf after my edit:

diag_log format["initPlayerLocal run for %1 (prewaituntil)", profileName];

waituntil{!isNull(player)};

I repacked the pbo and tested it and I spawned in the prison just fine.  Although when trying to play it I noticed some new weird things.  I can't take weapons out of the backpack while it's still on the ground like I did when hosting from my client.  I have to pick up the whole backpack and then move the pistol to the pistol slot. 

 

Also, after equipping myself with a weapon, the system chat never shows that the player has a weapon like it should.  The alarm does go off when I open the gate, and all guards are there and engage me like expected.  If I'm correct, both these conditions are monitored by fn_initServer.sqf.  So that script is running since the gate triggers the alarm.  The only difference between checking the gate and checking for players possessing weapons is the weapon/run away check is enclosed in the if(_x getvariable ["A3E_PlayerInitializedServer",false]) then { statement.  I can't find what the A3E_PlayerInitializedServer is referring to.

 

I'll try to test it using the -showscripterrors like you suggested and keep digging.

 

Thanks

Share this post


Link to post
Share on other sites

Ok, so it looks like the edit to the initPlayerLocal file has been successful everytime for me.  I added a issue to your gitlab describing the problem and the fix I found.

 

The backpack issue I'm guessing is an Arma problem I can deal with.  I can't find any reason why it would be a mission related problem.

 

The other issues with the systemchat and alarms are not issues at all.  I had been used to seeing the systemchat from when I was hosting off my client, but it appears the way it's coded that it's never meant to be broadcast out to all the players.  I have confirmed that as soon as a weapon is picked up, the variable A3E_EscapeHasStarted is set to true.

 

Thanks 

Share this post


Link to post
Share on other sites
18 hours ago, Halfsak said:

Ok, so it looks like the edit to the initPlayerLocal file has been successful everytime for me.  I added a issue to your gitlab describing the problem and the fix I found.

 

 

After further testing, I realize I spoke to soon and this was not my issue at all.  I had been putting my edited pbo's directly in the top layer of the mpmissions/ directory, which is what was making them work - I just didn't realize it.  As I stated a few posts up from here, I had put the entire co10_Escape_1.9 directory structure as downloaded into the mpmissions folder.  This meant the original pbo's were several layers deep: /mpmissions/co10_Escape_1.9/missionfiles/*.pbo  Apparently my linux server doesn't like that.  After pulling the pbo's I wanted out of this directory structure and placing them directly into the top level of the mpmissions/ directory, right where I had been putting my edited pbo's, everything worked as expected.

 

Hopefully someone else finds this helpful

Thanks

Share this post


Link to post
Share on other sites
25 minutes ago, Halfsak said:

[...]

 

Hopefully someone else finds this helpful

Thanks

 

Thanks for your time you spend on this issue yourself and an even bigger thank you for you explanation and solution for the issue.

 

I didn't even considered someone placing pbos not directly into the mpmission folder (albeit I knew about this new feature that was added a few patches ago). I assume linux is just not handling the subpath aswell as it was meant to be.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×