acre2
acre2 copied to clipboard
IDI-Systems
Core - Add PhysX Ropes as "connector wires" for Infantry-Phone/GSA/External
When merged this pull request will:
- Add the joy of ropes to ACRE2, which will finally resolve #727;
- Prevent 2 or more players from simultaneously accessing a vehicle's intercom, which would cause the previous players'
intercomPFHs to never disconnect them due to distance, entering the vehicle or being captured; - Fix desync that would occur when a player other than the one connected added/removed a GSA's Mast, resulting in both being connected to the antenna;
To-Do:
- [x] Ropes for Infantry Phone;
- [x] Ropes for GSA connection;
- [x] Ropes for shared radios (maybe only backpack radios);
- [x] Thinner ropes (maybe via a custom Rope Type?);
- [x] CBA Setting to disable ropes (is global because
ropeCreateis executed globally); - [x] Fix bug;
- [x] Fix passing of the infantry phone not regenerating the wire on the new user;
The current implementation was made by taking Advanced Towing code as an example. Attaching the rope's end to a "Franta Can" and attaching that to the player's pelvis is a good way to accurately place the rope on the player, there may be better ways though.
At the moment, the rope handler doesn't generate a visible rope for GSAs or other units (shared radios), need to investigate that further.
How does the rope going to the pelvis look? Would it be better to have it go to the hand? I think setObjectScale could be used to shink the franta can to make it functionally invisible.
Shrinking would still render the can whereas hiding doesn't (possibly deleting from, or even just skipping other unneeded data in, memory too), though.
Shrinking would still render the can whereas hiding doesn't (possibly deleting from, or even just skipping other unneeded data in, memory too), though.
Oh, yeah, hiding is fine too
How does the rope going to the pelvis look? Would it be better to have it go to the hand?
Depends, if there is an animation that puts the hand to the player's ear and maybe renders a phone handset like in ACRE Animations, sure. Otherwise I think it's best to keep the generic pelvis connection to symbolise that it's connected to the radio on the player's vest, just like the standard ACRE Gesture touches the player's vest to key any radio.
I've experimented further with player->player and GSA->player connections, the rope start object always has to be a transport, the smallest which classifies as such is a traffic cone with light.
Attaching that cone to a player works well to create the player->player connection for shared backpack radios, however it doesn't really work yet for GSA connections. For some reason when attachToing the cone to the GSA the rope's end won't connect to the player and instead dangle free. Another smaller issue is that the GSA+Mast center point is not in the model's center, so the rope start is kinda in midair, not visibily attached to the mast.
if there is an animation that puts the hand to the player's ear and maybe renders a phone handset
No phone, but I believe the sys_gestures component already in Acre animates the hand when speaking on a radio.
Sure, but you can't really keep the player's hand locked to his vest the entire time he's connected to the infantry phone.
That's why I think the pelvis is the best general location for the connector, it looks like this:
TBF, the cable needs to be tethered to something and then you'll need to route it through your uniform/vest to minimize getting tangled.
^ And being tethered in the middle it's quick to find the ends.
TBF, the cable needs to be tethered to something and then you'll need to route it through your uniform/vest to minimize getting tangled.
^ And being tethered in the middle it's quick to find the ends.
In both of these cases (infantry phone or using some one elses radio) you would not be routing the cable through your own gear, just holding the telephone on the end of the cable.
Going to the pelvis looks really ugly in that screenshot.
I'd appreciate a setting to either choose my own position or disable it.
Off Pelvis Hand Etc.
I'd appreciate a setting to either choose my own position or disable it.
Off Pelvis Hand Etc.
Sure thing, a setting to disable is in the tasks.
How do you think it would look in the hand though when the left hand is on the rifle or other personal equipment? Would you also lock the player in the "hand on vest" animation the entire time he's using the infantry phone?
I think it would be cleaner to use some dedicated helper object instead of the Land_Can_V2_F. Also a cable looking rope model would be neat.
What sort of dedicated object do you suggest? Or do you mean creating a custom one that's hidden by default, for better performance?
Yes, I mean that the rope helper should be a dedicated class for that, preferably with a model that's just empty. Attaching a can feels dirty.
Would you also lock the player in the "hand on vest" animation the entire time he's using the infantry phone?
Honestly probably yeah, when you pick up the handset you're presumably using it to talk so I think it makes sense to keep the hand near the head.
It seems that spawning the rope on top of the interaction's position noticeably reduces the distance from which the "disconnect" interaction can later be seen and used. Exact cause unclear, but it's most likely the rope itself and not the helper object, since it also happens on infantry phone interaction (which doesn't use a helper). The currently implemented workaround is lowering the rope start point, works pretty well for the infantry phone but more difficult on the GSA, because the spike is already at ground level, GSA+Mast unfortunately has the model's center point offset from the mast's center, so getting the rope to center in the mast regardless of model orientation will be trickier.
For some reason on both GSAs the rope doesn't attach to the player but dangles free, might be an issue where the rope collides with the GSA model.
I tested the man-to-man rope connection via debug console and it worked reliably, current implementation likely works too but I couldn't fully test it yet.
Finally got the GSA rope to work, attachTo-ing it would always lock the rope in place inside the GSA bounding box, probably because both GSAs are essentially buildings class-wise.
A different method of taking the helper object for the GSA, disabling its collisions with the GSA and moving it to the exact GSA location works nicely.
Also found a really small 10x10x10cm helper object PaperCar, fits much better than the Road Cone.
I just have a doubt regarding GSA disconnection.
There seems to be a GSA PFH on the client, sys_gsa/fnc_externalAntennaPFH.sqf, that checks for disconnection criteria, which will execute a local CBA Event to notify the player. There is also some similar CBA Server Event, I presume for handling multiple players trying to connect to the same GSA.
Rope handling is already global, so I presume they don't need to be integrated in any Server Events under sys_gsa.
I copied over the ACE Refueling hose model and config to make the connector rope black and look more like an actual wire, I presume that's ok since ACRE2 and ACE developments are somewhat related. Unfortunately I lack the 3D design skills to make a custom and better fitting model.
There is an ongoing issue with a created rope reducing the effective range at which the disconnect interaction can be seen to <1m, happens whenever the rope start location is within ~50cm of the interaction's position. Moving the start further than 20cm away from the interaction doesn't look good depending on which armoured vehicle you are connecting to, and looks downright ugly on the GSA (doesn't affect GSM though).
Looks like this now. Maybe a custom texture could be added to make the color less dark, but I think it's fine as is.
I wonder if the cable could be made breakable by gunfire & explosions, and/or by using the mouse wheel menu & ACE interact to cut it ?
^ Would increase realism, and depending on how you think about it, give engineers more reason to exist, or make life harder for engineers & mission devs & Zeuses.
Would be a neat feature for sure, though I guess it should come as part of a larger "radio damage" framework, possibly including what ACRE2 Radio Damage implements.
I wonder if the cable could be made breakable by gunfire & explosions, and/or by using the mouse wheel menu & ACE interact to cut it ?
^ Would increase realism, and depending on how you think about it, give engineers more reason to exist, or make life harder for engineers & mission devs & Zeuses.
That'd be nice for a field telephone system but I think it's overkill while there's only infantry phones.
Found an issue in MP where the helper object on a player was not deleted after using the infantry phone, presumably related to 2 people using the infantry phone simultaneously.
I figured out the cause, it's a bug that is also present in v2.12.0.1056.
The core issue is that more than 1 player can access the same infantry phone. Repro steps:
- Player A takes infantry phone;
- Player B takes infantry phone;
- Player A will now not be disconnected from the phone even when moving >20m from the vehicle. This caused the helper object for the ropes to not be destroyed when the rope breaks;
Haven't yet been able to verify how audio piping is affected by these steps.
Fixed the bug by checking the vehicle's (global) _unitInfantryPhone variable before generating a "take infantry phone" action.
This is almost complete, it just needs to handle passing of the infantry phone correctly, as well as a slight cleanup.
@Drofseh if you want to add the rope end selector feel free, I just think that would best be left to the modder of ACRE Animations to support, since that mod already has some decent handset models and animations in use right now.
PaperCar for some reason appears to be overridden into an invalid object by one of the faction/map mods my community uses. Still need to isolate which one causes it but maybe it's best to create a custom helper object after all, to avoid any issues like this.
Fixed an issue of helper objects not being hidden properly (again), I could finally verify it on a dedicated server though, so it's now definitely fixed.
I presume remoteExec is not the ideal way to do it though, CBA_fnc_serverEvent should be the way to go, right?
Alright, working now through CBA events. For some reason the event only registered to the dedicated server when placing it in sys_core/XEH_preInit.hpp, XEH_postInit.hpp only initialized events on clients.
Rebased everything, fixes conflicts and makes it buildable without errors by the latest HEMTT version.
Alright, working now through CBA events. For some reason the event only registered to the dedicated server when placing it in
sys_core/XEH_preInit.hpp,XEH_postInit.hpponly initialized events on clients.
https://github.com/IDI-Systems/acre2/blob/5024078f510717f17dff99f498ee7e6a8dda65fe/addons/sys_core/XEH_postInit.sqf#L11
