Open ghost opened 10 years ago
Well yes. They should be. The problem is that the remote control seems to be a bit weirdly implemented. FIrst off, the player
variable still points to the actual game master. The control of the unit seems to be implemented using the UAV system. Since the menu doesn't work either, I also think that it's probably using another display. So I doubt an implementation would be possible; someone correct me if I'm wrong.
If BIS is using the UAV System, then https://community.bistudio.com/wiki/getConnectedUav might work. I've seen other mods struggle with this aswell, so I guess it's not possible atm.
This might help: Arma 3 1.24: New command playerControlled (like the player command, but it will return the remote-controlled unit) http://dev.arma3.com/post/spotrep-00029
This might help: Arma 3 1.24: New command playerControlled (like the player command, but it will return the remote-controlled unit) http://dev.arma3.com/post/spotrep-00029
I tested this command on the editor and it doesn't seem to work.
cameraOn in (curatorEditableObjects (getAssignedCuratorLogic player))
returns true
if player is controlling a Curator placed unit.
So cameraOn
would return the controlled unit in that case.
cameraOn in (curatorEditableObjects (getAssignedCuratorLogic player))
If that's what it takes i'd say BI can blame themselves, because I'm certainly not going through everything and checking for that.
Hehe, I can relate. Let's hope they come up with something better.
Nice find @jodav. Added AGM_Core_fnc_player in https://github.com/KoffeinFlummi/AGM/commit/706f756b48f4da01999bc1f75c16c56b41ff54e6, which returns the player or remote controlled unit if zeus. I tried to get that to work with the weapon resting, but that would require further re-writing, because the global mission namespace variables there need to be public unit namespace variables now.
Nice find @jodav. Added AGM_Core_fnc_player in 706f756, which returns the player or remote controlled unit if zeus.
A small suggestion: it might be better to install an onEachFrame event that calls this function once and caches the return value on a global variable. We use player
way to many times all over the place.
because the global mission namespace variables there need to be public unit namespace variables now
The nice thing about that is that it works toward allowing better team switch as well.
I don't think so. Yes player
is used more than 10 times in the weapon resting scripts. But the function can be called once and the return value saved in a local variable. I don't think player
is used more than 20 times per second on average.
I don't think player is used more than 20 times per second on average.
Probably. I was thinking on interaction condition statement mainly. When the medical Interaction menu is opened I counted 65 uses of player
on conditions alone. Maybe the function could be called once for the interaction menu and cached.
The work around @jodav posted, doesn't work reliably as described in #1220.
Putting on hold.
Did some experimenting:
Variable bis_fnc_moduleRemoteControl_unit
is set when a unit is controlled, giving access to that unit but you cannot access the vehicle of it (guessing the RemoteControl
call just fucks that up).
But it is possible then to do the expensive call of
((bis_fnc_moduleRemoteControl_unit nearEntities [["car","tank", "air"], 5]) select 0)
To get the vehicle, I am completely unsure of the reliability of this in returning the vehicle at the start of the array. But if need be, if could be combined with some more sanity checks.
_vehicle = bis_fnc_moduleRemoteControl_unit;
_vehicles = (bis_fnc_moduleRemoteControl_unit nearEntities [["car","tank", "air"], 5]);
{
if (bis_fnc_moduleRemoteControl_unit in (crew _x)) exitWith {
_vehicle = _x;
};
} foreach _vehicles;
_vehicle
On second test. Actually it is possible to simply use bis_fnc_moduleRemoteControl_unit
it works with vehicle bis_fnc_moduleRemoteControl_unit
So bis_fnc_moduleRemoteControl_unit
is basically player
or does it return the units current vehicle like cameraOn
?
bis_fnc_moduleRemoteControl_unit
is the unit that is being remotely controlled, so functions like player
.
I am going to run some more tests with it in AGM and I might have a PR for it in a couple minutes if it works out.
missionNamespace getVariable ["bis_fnc_moduleRemoteControl_unit", player]
?
Yeah, going to put that in the AGM_Core_fnc_player. Then just run some tests to ensure it is working.
It would be really great if that worked. Where did you find the variables name?
TFAR is using it and I confirmed it by checking the code in the function viewer for the curator modules.
It seems to work, I did test it with AGM_Parachute however, it seems if you deleteVehicle (vehicle bis_fnc_moduleRemoteControl_unit)
it causes it kicks back to the curator. But there will probably be workaround for that.
@CorruptedHeart Awesome!
:cake:
So, now ... replacing every (where it makes sense) call to player
with AGM_Core_fnc_player
?
(Saving it in a private var, making subsequently use of the private var ...)
You can use _player
for the key actions and the menu actions, which is the majority of content of AGM. Some things like weapon resting will need further rewriting of code.
So, I tried to start with changing the calls to player but stumbled upon the Extended_PostInit_EventHandlers
. How would you change that to make it work with curator placed units? I have sort of an idea how to do this, but I don't know if it's viable at all and it feels dirty.
The Extended_PostInit_EventHandler
is executed after all objects are initialized when the client connects to the server or otherwise on mission start.
The Extended_Init_EventHandler
is assigned to a class and is executed on every machine when a unit of this class is created. Maybe thats what you are looking for?
work on this will continue in v0.95.
Edited OP. I'm unsure about these, can anyone test them?
Also Note:
AGM_player
now replaces call AGM_Core_fnc_player
[missionNamespace, "AGM_Core_playerChanged", {
_newUnit = _this select 0;
_oldUnit = _this select 1;
}] call AGM_Core_fnc_addCustomEventHandler;
Good enough for now -> v0.96
Added:
curatorObjectRemoteControlled
scripted event handler triggered when Zeus takes or release control of a unit. Passed arguments are curatorLogic:Object, player:Object, controlledU nit:Object, control:Bool (control argument is true when Zeus takes control and false when he release it afterwards)
Thats awesome. Although this way we would sacrifice team switch compatibility.
If you teamswitch the player
variable is updated, isn't it?
If you teamswitch the
player
variable is updated, isn't it?
Yes IIRC
Yes, but the eventhandler doesn't trigger.
Yes, but the eventhandler doesn't trigger.
True; but it could work as following: AGM_Player always returns player except when the event handler triggered with true, and until it triggers again returning false, in which case AGM_Player = zeusUnit.
The only thing this would not handle is is you team swith while remote controlling a unit, which I don't think should be possible.
The issue is that something like this won't work: https://github.com/KoffeinFlummi/AGM/blob/master/AGM_NoRadio/clientInit.sqf
This unmutes the (now) AI and mutes the new player unit. This will not work with team switch if we rely entirely on curatorPlayerChanged.
We can raise that same event when the player switches units; inside the onEachFrame EH we could check if player != lastFramePlayer
.
EDIT: I think I get your point now. We still have to check each frame if the player switched units, so there's no gain on using the event anyway.
Yup.
Nothing more to add. When you use the Zeus module to swtich into a character on the field and play them, you are unable to use the interaction-menü (the self-interaction-menü works).
Best regards Luca