Friendly Fire Bug?

[ToejaM]

Anyone else getting lots of friendly fire kills on their server since the patch?

 

It seems sometimes the actions for players don't load and this seems to be directly related to the friendly fire bug, oddly a shift - flush fixes it for that player but often players dont realise until they are friendly fire killed.

 

Any ideas?

Edit: Just had a thought.

 

Recently I put in a fix to stop the loading screen issue which basically does "End loading screen" after a certain amount of time, now I can't say I've got stuck on this since but I'm wondering if the reason for it not loading is because it is hanging on loading the epoch actions or epoch related scripts, something a shift - flush fixes.

 

Since this fix now that I think about it, there has been a much higher increase of friendly fire related deaths so I'm thinking this could be related?

 

Any ideas devs?

 

This is the fix in this compiles.sqf

 

-   Line: 437         if (dayz_clientPreload && dayz_authed) exitWith { diag_log "PLOGIN: Login loop completed!"; };
+  Line: 437           if (dayz_clientPreload && dayz_authed) exitWith {
+  Line: 438              endLoadingScreen;
+  Line: 439             diag_log "PLOGIN: Login loop completed!";
+  Line: 440         };

 

If I'm reading that right, its exiting the script so it doesn't continue to load the compile functions below? Either way this is where the problem is.

[ToejaM]

Anyone? :-)

[ToejaM]

Pretty sure this is the cause but I'm unsure of the fix. Any ideas at all, anyone?

[f3cuk]

Same for us. Had some other issues that i had to fix and look into first, will start on fixing this one today. What have you found so far?

[f3cuk]

Okay so this is harder then i anticipated. I seem unable to find where the deathmessages get feeded from. Correct death messages show up in global channel (e.g. f3cuk was killed) and the friendly fire ones show up in group channels (e.g. f3cuk was killed by ToejaM [Friendly Fire]).

I've done a search on terms like

• was killed
• killed
• Friendly Fire
• globalchat
• groupchat

etc. but couldn't find anything related.

I did however find server_playerdeath.sqf which contains some after death stuff. There is a globalChat reference there, but enabling DZE_DeathMsgGlobal did not make a difference (i think the code is wrong). Enabling DZE_DeathMsgTitleText does work and removes the global/group killed message. A nasty 'fix' would be just replacing.
 

_message = format["%1 was killed by %2 with weapon %3 from %4m",_victimName, _killerName, _weapon, _distance];

With

_message = format["%1 was killed with a weapon %2 from about %3m",_victimName, _weapon, _distance];

Or something else to suit your needs. I will be doing this on restart and will keep that untill i find the fix to get them to show correct in global/group.

[ToejaM]

As far as I'm aware the reason for "friendly fire" kill messages is due to not initializing the player as a non blu for player on the blufor side, the friendly fire message is something hardcoded into arma2. So something in the compiles changes the status of the player.

 

Its similar to why when you blow up a vehicle you cannot get into a vehicle with a player, because the vehicle you blew up was blufor and the players you are trying to get in with are blufor to but the arma2 auto punish stops you from getting in with them. Odd you cannot turn this off.

Something is definately getting stuck on the compiles bit causing issues though but its odd there are no errors, is it possible that its a battle eye interference due to authentication?

[f3cuk]

I removed it altogether and switched it for the custom death messages described above. I know it's not a fix but atleast it's a workaround i can live with. It might be a compile thing, but i'm not willing to invest any more time on this issue.

 

It sucks that there is still so much stuff hidden in source that are causing issues.

[ToejaM]

Something has changed somewhere in the related compiles files thats causing this issue.. something since the last update as I'm sure this wasnt in the previous release.. but its a spiders web following the files looking for changes and chances are, I wouldnt understand it or see that the change which has caused the issue. Though I think we can safely say its to do with either 1) Character creation or 2) Initializing the extras that players need for epoch like actions or similar.

[RimBlock]

Anyone else getting lots of friendly fire kills on their server since the patch?

 

It seems sometimes the actions for players don't load and this seems to be directly related to the friendly fire bug, oddly a shift - flush fixes it for that player but often players dont realise until they are friendly fire killed.

 

Any ideas?

Edit: Just had a thought.

 

Recently I put in a fix to stop the loading screen issue which basically does "End loading screen" after a certain amount of time, now I can't say I've got stuck on this since but I'm wondering if the reason for it not loading is because it is hanging on loading the epoch actions or epoch related scripts, something a shift - flush fixes.

 

Since this fix now that I think about it, there has been a much higher increase of friendly fire related deaths so I'm thinking this could be related?

 

Any ideas devs?

 

This is the fix in this compiles.sqf

 

-   Line: 437         if (dayz_clientPreload && dayz_authed) exitWith { diag_log "PLOGIN: Login loop completed!"; };

+  Line: 437           if (dayz_clientPreload && dayz_authed) exitWith {

+  Line: 438              endLoadingScreen;

+  Line: 439             diag_log "PLOGIN: Login loop completed!";

+  Line: 440         };

 

If I'm reading that right, its exiting the script so it doesn't continue to load the compile functions below? Either way this is where the problem is.

 

The code is called in a spawn {}; which runs it is a seperate process in parallel.  This spawned process being exited should not affect the compiles.sqf completing.

 

Int he Github code the spawn starts at 436 and ends at 482.

 

The only endloadingscreen that looks relevant is in the player_monitor.fsm so there is probably a bug in there that is getting tripped.  The FSM files need s tool to read (freely available) but for this reason, I suspect not a lot of people have taken a look.

[ToejaM]

Ah ok good to know, I thought itd be something server side!

 

You can open the player_monitor.fsm with notepad++ it seems.

 

I think its the compiles.sqf that doesnt get finished, looking at the compiles there is this:

 

player_monitor =   compile preprocessFileLineNumbers "\z\addons\dayz_code\system\player_monitor.sqf";

 

Inside this file is:

 

if (isServer) then {
waitUntil{dayz_preloadFinished};
};

 

It would make sense if a "waitUntil" was hanging the system up?

 

Also there is this after the player_monitor.sqf in compiles:

 

player_spawn_1 =   compile preprocessFileLineNumbers "\z\addons\dayz_code\system\player_spawn_1.sqf";
player_spawn_2 =   compile preprocessFileLineNumbers "\z\addons\dayz_code\system\player_spawn_2.sqf";
onPreloadStarted    "dayz_preloadFinished = false;";
onPreloadFinished    "dayz_preloadFinished = true;";

 

Which are all things that are related to.. loading so I think there is definitely something hanging up there.

 

The problem is it can happen so randomly, there are times where I login fine each time and other times where I have to force the game to quit. Though I think if its just me on the server it tends to work fine (test server is almost always just me) and without knowing exactly where to start with some diag_logs I think it could take a while to troubleshoot. I'm surprised there isnt much more on this issue!

 

When there were forced endloadingscreens inserted, it was obvious if you had bugged out as you couldnt tag friendly. Is it perhaps an issue with retrieving friendly tags. I'm sure a few other things didn't work aswell but I forget what they were, it just seemed like a lot of Epoch specific things bugged out.

[mgm]

So guys no post since end of August - did you resolve this issue or just give up?

 

I'm thinking about diving into the pile of "friendly fire" threads and testing every single suggested fix comprehensively...

but you know how long arma takes to startup & test each change, so I would be most pleased if one you has already done this & willing to share information?

 

Thanks

[f3cuk]

Seemed to resolve itself for me. Possibly after applying to PP4L.