Entity Interference

[Fate-JH]

Some combat engineering and some vehicles refuse to allow other combat engineering or vehicles to function too close to each other. This is called "interference". Previously, this was only ever a client-driven assertion - the client just barred certain attempts by changing the green-tinted target to a red-tinted one that does nothing. For the most part, it works to avoid weird stacking just fine. Like all things client-driven in this game, however, there are ways to mess what looked like an otherwise functioning system on the surface. So now we have to perform approximately the same tests on the server because we can't just have nice things.

[Dethdeath]

The CE/FDU issue is fixed. The 2nd person deploying an FDU object is frozen in place until the animation completes for the other player, but maybe that can't be helped. I tested double AMS deployment as there was something in the code about it:

While that is possible it might not be a big deal. I also noticed that AMSes and FDU objects share the same interference group, which means you cannot deploy an AMS within 30 meters of an FDU object and vice versa.

[Fate-JH]

The 2nd person deploying an FDU object is frozen in place until the animation completes for the other player

I thought that was just me during testing as it's not consistent. I will need to check whether it's just the runtime of the test or whether it's the messaging delay between the session actor and the CE placement. That is to say, I have to determine if the delay is consistent regardless of the number of deployables in one spot versus the same all the time. I do not think I can quick-stop the delay if it's due to the testing but I might be able to expedite it.

While [multiple deployed AMS's] is possible it might not be a big deal.

Will double-back on that. It's probably because there's no single authority for deployment like there is CE placement and I was hoping the server wouldn't mind.

I also noticed that AMSes and FDU objects share the same interference group, which means you cannot deploy an AMS within 30 meters of an FDU object and vice versa.

Now that I think about it. it's actually a bit weirder than that. For example, the shared group interference for the TRAP is 60m while for the AMS it's 30m. That means you should be able to deploy an AMS closer to an existing TRAP than you can deploy a TRAP from the AMS. It think it's reversed right now? This also depends on whether you preemptively factor in the interference of the new entity that is being placed on top of the interference from existing entities.

[Fate-JH]

Change client-driven vehicle deploy to need to propagate through interference tests in ZoneVehicleActor. This doesn't necessarily stop vehicles from deploying on top of each other but creates a future avenue of workflow. You probably won't see any change in behavior just yet, but you should be able to examine if multiple vehicles deploying is as sluggish as multiple CE being deployed.

[Fate-JH]

I updated the procedure so that it should start vehicle on vehicle blocking upon the moment of deploy attempt. It should work. I can't actually test it because I can't deploy-alt-tab-deploy fast enough locally. It should still be possible to have shared group violations since this temporary system is exclusively for vehicles and does not involve the other entities that have a "deployment" condition, e.g., combat engineering deployables. Would moving it onto the Interaction object help? Is this level of feature maturity beneficial, or is an AEGIS close to a deployed AMS really so bad?

[Dethdeath]

TRAPs cannot be deployed within 60m of each other either, this makes it impossible to put multiple near the gate of a base as players like to do.

Having to drive this far away from a TRAP to deploy an AMS still feels broken too.

I deployed an Osprey inside an enemy deployed AMS, maybe the minimal distance should be like 5 meters between a deployed AMS and these? When the Osprey was deployed under an undeployed AMS it bounced the vehicle like 10 meters away, seems pretty harmless.

There's some glitches I ran into while deploying a TRAP and clicking to get out of the animation. -If you spam click while deploying and move around, on the map it can look like you deployed 2 TRAPs while you only deployed one.

-If you're deploying a TRAP from holster slot 2 and click to cancel the animation, and then attempt to equip another FDU from holster slot 4 and then also click with that to deploy, anyone that comes into this area from large distance away will end up seeing this:

https://github.com/psforever/PSF-LoginServer/assets/77748540/e54041b6-8f61-442a-b314-f9c4f49f2f66

And multiple:

The person who fake deploys these cannot see the FDU object, only an observer that comes from afar can.

I don't know what this is, so I included it too:

[Fate-JH]

You can cancel the animation by doing what now?

[Fate-JH]

As mentioned above, originally interference was tested as the existing objects projecting a field that blocked the new object from being constructed or deployed and neglected the other mechanic. I have reversed this relationship and made the tests more specific to just one condition. For example, to use the interactions of an existing TRAP and a deploying AMS, they share the same interference group. In prior tests, the AMS would look at the TRAP and compare against the 60m shared distance check the TRAP imposed; now, the AMS will compare the TRAP against its own 30m shared distance check instead.

In a further change, if we were to compare an existing TRAP and a new TRAP, the TRAP's would recognize that they are both the same kind of entity and belonged to the same group and that they were deployables. However, all of these tests would no longer be run until one fails; instead, the TRAP's will stop only to check if they satisfy the primary interference distance check. An existing TRAP compared to a new spitfire will only attempt to satisfy the deployable distance check between the entities as they are not the same nor do they have the same shared group.

[Dethdeath]

This works again, which is good. AMS can also be deployed closer again, which is also good.

[Dethdeath]

Doesn't seem like I'm able to deploy ANTs?

[Fate-JH]

Ah, dear, that's right, conflicts ...