Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API manipulation of vehicle racks on dedicated servers (removeRackfromVehicle not functioning as expected) #1312

Open
DoctorTemporis opened this issue Jan 4, 2024 · 1 comment · May be fixed by #1334
Labels

Comments

@DoctorTemporis
Copy link

DoctorTemporis commented Jan 4, 2024

Mods:

  • Arma 3: 2.14.150957
  • CBA: CBA_A3 v3.16.1.231025
  • ACRE2: 2.12.0.1056
  • Unsung Redux Stable Update: 27 Sep, 2023 @ 7:32pm
    Description:

A CBA "InitPost" ClassEventHandler is added in init.sqf to a parent class of vehicle (uns_plane).

The config for the test vehicle is such that two rack mounted radios are added.

The intention is for this event handler to remove the vehicle racks on vehicles of this type and replace them with other vehicle racks, as the vehicles in question, when placed in Eden Editor or via Zeus and entered by a player, have a type of rack and mounted radio that is not desired (117F instead of 77).

The event handler calls a CBA function using RemoteExec to (per ACRE2 functions documentation) run only on the server, and as the event handler has been added fires on all connected clients, it also only calls RemoteExec if the event is firing on the server itself. An alternative would be to implement the event handler on the server only via initserver.sqf and avoid the need for remote execution of a function.

["uns_plane", "InitPost", {
params ["_vehicle"];
if (isServer) then {	
_vehicle remoteExec ["TACD_adjustRadioRacks", 2];
};
}, nil, nil, true] call CBA_fnc_addClassEventHandler;

As no player has entered the vehicle at the point at which the event handler fires, it first initialises the vehicle racks and waits until this is done. Then it attempts to delete the racks which have been initialised and add the new ones, forcing initialisation of the new racks via the flag in the addRackToVehicle function.

_target = _this;
[_target, {}] call acre_api_fnc_initVehicleRacks;
waitUntil { _target call acre_api_fnc_areVehicleRacksInitialized };
_racks = _target call acre_api_fnc_getVehicleRacks;
{[_target, _x] call acre_api_fnc_removeRackFromVehicle} forEach _racks;
[_target, ["ACRE_VRC64", "Panel 1", "Dash", false, ["crew"], [], "ACRE_PRC77", [], []], true] call acre_api_fnc_addRackToVehicle;

When this mission is run "multiplayer but locally" (ie, using the 'play in multiplayer' feature in Eden editor), the effect is that only one rack is removed, and one is added. This is not as expected, since the construction of forEach _racks would expect that both racks found in _racks would be removed. If the code is adjusted by adding a copy of row 5 (ie, just calling the rack remove function again), it works correctly.

When this mission is run on a dedicated server, the effect is not as desired. The original two racks are not removed at all, but the new rack is added.

If the code is executed manually via the console after a player has joined the dedicated server, rather than via an event handler, then it works as per a local server (with the issue above - only a single rack is removed).

I cannot find in the documentation references to this. Is it necessary to also waitUntil acre_api_fnc_isInitialized returns true on the first connecting player?

@mrschick
Copy link
Contributor

I've been investigating this lately. The issue currently is that acre_api_fnc_areVehicleRacksInitialized is not at all reliable at telling whether the Racks have actually been initialized, so code waiting for it to return true ends up running before init is complete, and not properly removing/adding Racks.

A workaround for the time being is making the code wait 0.5s after acre_api_fnc_initVehicleRacks, to be sure that it could complete. Can be done via sleep 0.5 or CBA_fnc_waitAndExecute.

@mrschick mrschick linked a pull request Jul 30, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants