Vdauphin / HeartsAndMinds

:heart::brain: 1.24.1 is out! 🎉
http://vdauphin.github.io/HeartsAndMinds/
110 stars 65 forks source link

[BUG] Random player gets setPos + Loadout of saved Data when another player joins the game #1486

Closed OverlordZorn closed 1 year ago

OverlordZorn commented 1 year ago

We noticed this behavior sporadically and we havent exactly figured out whats going on or how to reproduce the issue but here is what we observed so far:

Seemingly random player will be put to the location where player X has logged out before with player X kit.

Player A and B swapped slots (from medic to TL vise versa). Player C got Player A Kit and Pos.

heres our respo https://github.com/PulsarNeutronStar/HeartsAndMinds currently based on 1.23.0

the only change on the core we did is ace_banana -> ACE_Humanitarian_Ration "Oplitas" -> "Insurgents" commenting out the BTC Arsenal actions on the btc_gear_object.

Vdauphin commented 1 year ago

Hello,

Read this https://forums.bohemia.net/forums/topic/165948-mp-btc-hearts-and-minds/?page=75&tab=comments#comment-3469051

Also: https://github.com/Vdauphin/HeartsAndMinds/discussions/1485#discussioncomment-5091997

Cheers

OverlordZorn commented 1 year ago

@Vdauphin if you want me to provide more information, reopen this issue and ask.

Vdauphin commented 1 year ago

If a Random person, which is actively playing and currently in a firefight gets teleported to a random location with a different kit when a further person joins the server and loads in is the intended behavior, i prefer not to use the feature.

This is not intended yes but as you describe it in the first place it sound like an intended behavior :

If Player A use the medic slot, when Player C will use the same medic slot after Player A left, player C will get kit and pos of player A when he was using medic slot

So please update the ticket with the template provided when you opened the issue. Without it, it is impossible to reproduce a bug

OverlordZorn commented 1 year ago
Player A and B swapped slots (from medic to TL vise versa).
Player C got Player A Kit and Pos.

Player C was jsut sitting on the server, doing nothing and simply playing the game. No switching of slots. nothing. Other players, A and B, switched slots.

OverlordZorn commented 1 year ago

This was 3 weeks ago, ill have to look if i still have the RPT. Same goes for missionfile.

OverlordZorn commented 1 year ago

And no, to my knowledge, no one of our guys used a cracked version of arma. We propagade mods via steam, upload our own mod to steam, use key verification, kickduplicate = 1and all that jazz.

And it has happend to myself, i ended up with the kit of someone else when they loaded in the game, and i am 100% Certain i have a legal version of the game. If you want i can show you the invoice for it.

OverlordZorn commented 1 year ago

Arma 3 Version: x.xx (stable / rc / dev) CBA Version: 3.x.x (stable / dev + commit hash) ACE3 Version: 3.x.x (stable / dev + commit hash) Hearts and minds Version: 1.x.x (stable / dev + commit hash)

Mods:

https://cdn.discordapp.com/attachments/1006511361804738580/1082367857066770582/Arma_3_Preset_CVO_HM_NorthTakistan.html

Description:

When a new player (A) joins the server and loads into the misison during a running mission, a random player (C) that is currently connected to the server gets the loadout and position of the player (A) who just joined.

They do that and a further Player Z suddenly recieved the loadout and got setPos on the Position.

We tried both Parameter settings, nether of which seemed to have stopped the issue, therefore we decided to turn off the feature. https://github.com/PulsarNeutronStar/HeartsAndMinds/commit/1a553e2ac1a33af2ca6f780d1afb15359c66604d

Add mission file: To long ago, dont have it anymore. Here is the Mission on Github before we disabled the feature. https://github.com/PulsarNeutronStar/HeartsAndMinds/tree/defc6f413ff1990889e870ccb60900af53d1edde

RPT log file: Cant retrieve .rpt since arma nuked the older .rpt (We disabled the feature 3 weeks ago - https://github.com/PulsarNeutronStar/HeartsAndMinds/commit/1a553e2ac1a33af2ca6f780d1afb15359c66604d)

server_console.log file to proof to you that non of us is using a cracked version 🙄 server_console_7592.txt

Vdauphin commented 1 year ago

If you want i can show you the invoice for it.

In the first place, I just need a ticket with a properly filled template. Sad you didn't do it 3 weeks ago but now we can start to investigate

Can you reproduce the issue with the last 1.23.1? 1.23.0 was for testing and had a bug with ACRE2 (which was messing with the saving slot system during serialisation) Also, enable debug log in mission parameters so we will have more information when the issue appear

Ideally with:

[format ["_player %1 _key %2", _player, _key], __FILE__, [false, btc_debug_log, false]] call btc_debug_fnc_message;

in deserializeState_s.sqf after the params

OverlordZorn commented 1 year ago

In the first place, I just need a ticket with a properly filled template. Sad you didn't do it 3 weeks ago but now we can start to investigate

Sad you closed the issue immediately without asking for more information 🙄

I'll add the line, but idk when ill be able to find some people to test it.

The mission itself is based on 1.23.0. I'll need to look if i added 23.1 or not.

Vdauphin commented 1 year ago

You are not the first player creating issue and remove the template which ask you all the necessary informations I usually don't close issue when template is not followed but as there was an already ongoing discussion about this topic, I thought it would be better to have then occur in the same place so people can share their experience. As I said, an issue closed can be open at anytime if any of us fill it relevant. Closing an issue is not a dead end especially in this case where there was an ongoing discussion. Sorry if you found that rude but it didn't mean to be

Fixing issue can be a complexe process and I put a lot of effort to found them when playing and dive into user tickets (this is why I do monthly patch). You have good exemples here https://github.com/Vdauphin/HeartsAndMinds/issues?q=is%3Aissue+is%3Aclosed+label%3Abug

OverlordZorn commented 1 year ago

changes of 23.1 had been applied to the mission when the issue has been reported. i added the debug line to the deserializeState_s.sqf past the params line. btc_p_slot_isShare = 1.

Will update when i have an rpt ready.

OverlordZorn commented 1 year ago

We did some testing

Here are our actions:

We slot in the first 3 slots.
Start:

Zorn Medic (pp2000)
Mimi AR    (RPK)
Kyo SQL    (?)

1.
I change in the 4. Slot

Zorn -> Marksman (MM)
=> Kyo got some random Marksman kit (+pos?)
=> Zorn spawned at the default location with default kit

2. 
Mimi changed into the old Zorn Slot

Mimi -> Medic Slot
Kyo => TP Zorn Pos + Zorn Kit (from initial spawn)

3.
Kyo goes into Mimi's old Slot
Kyo -> AR Slot -> Default Spawn Pos & Kit
Kyo => AR Kit of someone else + Pos

4. 
Zorn -> SQL Slot
Mimi => TP to old Kyo Pos
Mimi => Kit of old Zorn (first slot)

5. 
Mimi -> MM Slot
Mimi => Default Pos+Kit
Zorn => Old MM  Pos+Kit

6.
Kyo -> Medic Slot
Kyo => Old Mimi Medic Kit + Pos

7. 
Zorn -> AR -> Default Spawn Pos & Kit
Mimi => Kyo Kit + Pos (rpk)

8.
Mimi -> SQL Slot 
Mimi => Default Spawn
Zorn => Old SQL Pos + Kit

9. 
Kyo -> MM Slot
Kyo => Default
Mimi -> Old AR Kit+Pos

https://youtu.be/YK3f8XbLo04 I started the recording somewhere in the middle

RPT's of server (Server auto rstarted in the middle of testing) RPT's of each client RPT.zip

Vdauphin commented 1 year ago

I took a look to the end of the video and look at the same time at the server.rpt:

This _player B Alpha 1-1:3 (Kyoptic) REMOTE clearly state that btc_slot_fnc_deserializeState_s send to Kyoptic computer the new position, loadout etc. But, looks like Mimi is actually receiving the remoteExecCall. This mean that at this precise moment Kyoptic caracter is local to Mimi computer.

I am noticing you created groups of caracter in your mission.sqm. In A3, all IA in the same group are local to the actual team leader. I think when a payer join a group, he is first local to the team leader computer (here Mini) and then the created caracter is sent back to the actual player joining (here Kyoptic). This explain why Mini get teleported when Kyoptic is joining. Kyoptic is local to Mini so the remoteExecCall is sent to the wrong computer.

If this is true, you should be able to fix the issue by just creating a group per player. I will think about a fix if you confirm the issue is gone

(wtf)

OverlordZorn commented 1 year ago

i would prefer to keep the groups in the way they are, otherwise the slot selection will just needlessly long...

would a simple sleep/CBA_fnc_waitAndExecute work in that context?

Vdauphin commented 1 year ago

Well, first we need to make sure the issue is coming from this, just use one slot per group for test

Vdauphin commented 1 year ago

I played this weekend and players didn't notice this isssue when JIP a game with slot sort by group from the screen selection. But, the server didn't require such long mod list (only CBA, ACE and TFAR). May be one of the mod or just a long list of mod trigger this specific bug. During loading, a lot of stuff happen, especially with a lot of mods, so the player object locality could stay much longer wrongly define I guess

Did you give a try to #1499?

OverlordZorn commented 1 year ago

https://www.youtube.com/watch?v=qrvFOWiZI6g Been a few busy days - we tested it last friday.

Edit: tested without 1499, i can add it this week end test at the end of the week.

Vdauphin commented 1 year ago

So the bug is not there when using different group for each player?

From my test #1499 don't change the intended behavior but I would like to make sure it fix this bug

OverlordZorn commented 1 year ago

So the bug is not there when using different group for each player?

I think it seems so, yes.

OverlordZorn commented 1 year ago

anything else you need me to do?

Vdauphin commented 1 year ago

Just testing https://github.com/Vdauphin/HeartsAndMinds/pull/1499 to make sure it has gone and we should be fine

OverlordZorn commented 1 year ago

i added the #1499 changes to our file, will update once we got to testing

OverlordZorn commented 1 year ago

We conducted the testing, the issue of the SQL being teleported away has been resolved!

Vdauphin commented 1 year ago

Oh! Great news! 🎉 Thank you for testing this!