Vdauphin / HeartsAndMinds

:heart::brain: 1.24.4 is out! 🎉
http://vdauphin.github.io/HeartsAndMinds/
111 stars 66 forks source link

[Possible BUG]Sub-mission arrangement issue in mission list #756

Closed GoldJohnKing closed 5 years ago

GoldJohnKing commented 5 years ago

Arma 3 Version: 1.94 (stable) CBA Version: 3.12.0 (stable) ACE3 Version: 3.12.6 (stable) RHS USAF Version: 0.4.9 (stable) Hearts and minds Version: master_daily branch (commit e6832f8)

Mods:

- CBA_A3
- ace
- RHS USAF

Description:

Setp to reproduce:

Vdauphin commented 5 years ago

I have launched a dedicated server and join after start, spawn side mission then disconnect and connect again. All task are in the correct order 20190815185904_1 20190815190306_1

GoldJohnKing commented 5 years ago

It does happen, but not that frequent. I've encounter this problem 2 time in almost 10 tries. So it might be just random? Besides, we use headless client, so could it be related?

Vdauphin commented 5 years ago

Besides, we use headless client, so could it be related?

Remove it and try to see if the bug still occur But side mission aren't link to HC

GoldJohnKing commented 5 years ago

Seems not related to HC.

I found a way to more likely reproduce the issue.

Vdauphin commented 5 years ago

I tried multiple time I removed the start option on my server "-autoinit" so I can connect even during the booting process and no issue occur You should check your rpt may be

GoldJohnKing commented 5 years ago

It's quite common on my side... Though not that frequent and kind of hard to reproduce, it does reproduce.

I've read the mission create code carefully as I could. Might it relate to unscheduled environment of remoteExecCall?

The Call part in remoteExecCall is a little confusing and doesn't mean that the execution of the remote executed function/command will happen right away, for example: remoteExecCall ["func1"]; call func2; // func2 can be executed sooner than func1 call func1; call func2; // func2 will always execute after func1 It just means that the execution of the function will be carried on in unscheduled environment.

BI's wiki about remoteExecCall: https://community.bistudio.com/wiki/remoteExecCall

For example, there's some missions waiting to be sync to player's client: 1-Main Mission 2-Main Mission's Sub-mission 3-Side Mission 4-Side Mission's Sub-mission

Though the four missions called "["btc_1", btc_player_side, -1] remoteExecCall ["btc_fnc_task_setDescription", [0, -2] select isDedicated, true];" one by one on the server, because of the unscheduled environment of remoteExecCall, they may not actually executed as the arrangement they are called.

If 4 executed before 3, the sub-mission would not be included in the side-mission. The arrangement of main-mission below side-mission could caused by similar reason.

I'm not sure if I "guess" it right...

Would passing an array of all missions' id then remoteExecCall "btc_fnc_task_setDescription" with the id array as the parameter at once would solve the problem?

Vdauphin commented 5 years ago

I've read the mission create code carefully as I could. Might it relate to unscheduled environment of remoteExecCall?

The unscheduled environment is the best way to execute code (https://ace3mod.com/wiki/development/arma-3-scheduler-and-our-practices.html, This ensures the execution order and is the fastest way for scripters to execute their code. (https://community.bistudio.com/wiki/Scheduler#Unscheduled_Environment))

Though the four missions called "["btc_1", btc_player_side, -1] remoteExecCall ["btc_fnc_task_setDescription", [0, -2] select isDedicated, true];" one by one on the server, because of the unscheduled environment of remoteExecCall, they may not actually executed as the arrangement they are called.

No because JIP data are recorded server side so, when two remoteExecCall are executed server side, the order is correct for the JIP player but I agree the results for player already connected is unexpected. But the issue here, happen only for connecting player

Also share your rpt

GoldJohnKing commented 5 years ago

Also share your rpt

I haven't kept the rpt file, for both my client and server run under -noLogs parameter. I'll share one if I met the issue again.

GoldJohnKing commented 5 years ago

This issue haven't been happening for a long while. I'll close this issue until I got more information about it.