Bug Fixes 20240712

[Fate-JH]

Fixes 1) Terminals did not properly regain normal operation when power was lost and restored - when thre Generator was destroyed, or NTU was drained. The unpowered state did not accept the clear hacking message. Should work. 2) Passive implants did not automatically activate upon being properly initialized. The clarification of how an implant counts as "passive" had changed to an explicit without being properly updated for the flag. 3) Having too many open doors will overwhelm the client's internal portal system which controls environment rendering and culling. To reduce the effect of this, only "nearby" doors will report as open to a given player - 100m for when indoors, 800m when vision can be augmented, 400m normally.

Caveats 1) The original portal system bug was suggested as result of a developer teleporting in front of doors sequentially to test their functionality, so they had an immense number of doors open, more than any normal player would ever accomplish. 2) Door closing actions will always be carried out and delivered as scheduled.

[Fate-JH]

Features 4) Facility turrets would instigate their jammed target aggro behavior when manned, resulting in the player being stuck in the turret, even after control should be restored to them, The turret will now check if manned before applying the targeting behavior.

[Dethdeath]

-Equipment terminals reset fine between generators being down and being brought back up, medical terminals do not reset properly. -Passive implants seem fixed, they also don't turn off when getting into vehicles/drop pods anymore, something that was reported in #bug-report. -Enemy AMS interference range issue is fixed. -Occupied wall turret jammer issue also seemed fixed. But then I tried jamming the turret before getting in and got this:

https://github.com/user-attachments/assets/d43305b0-c1ea-43bf-b60a-adc5a7f75e96

[Dethdeath]

Is this something that can also be put into this PR? This is how it appears in the killfeed when the mine/TRAP owner is logged off. When I died to a spitfire turret, shadow turret and cerberus turret that belonged to the same logged off player it showed the player's name instead.

[Fate-JH]

Is this something that can also be put into this PR? This is how it appears in the killfeed when the mine/TRAP owner is logged off. When I died to a spitfire turret, shadow turret and cerberus turret that belonged to the same logged off player it showed the player's name instead.

I think the turrets are the ones that get it incorrect and it's supposed to be the other way. The only reason turrets work the way they do is because they utilize typical projectile-based damage flow and that already accounts for the owner. The collision of the tank traps and the explosion of mines fabricates shortcuts that only integrate into the original damage system.

[Dethdeath]

Yeah, it's supposed to just show the name of the engineering object when the owner is offline. #977 is sort of related. So instead of "Mines" it should be High Explosive Mine. I don't recall what it used to be for TRAPS, maybe just "TRAP"? Saw this one back in March of this year, haven't seen it since, but that also would've been the wrong name.

[Fate-JH]

Features 5) Facility turrets break when mounted while being jammed because jamming cause indication took priority to proper turret operation. During an attempt at mounting the turret, the jamming cause indication action - pointing - is canceled prior to the mounting attempt. (The animation of the turret rotating back into resting position should mix safely with the turret mounting animation.) 6) Proximity terminals like the medical terminals were never extended the code to reset hacking conditions when unpowered. Should work now. 7) A noted minor issue exists where a deployed ANT would not trigger in proximity of a needy resource silo due to the driver exiting the vehicle. Although I had never been able to trigger the issue on my own, I understand the theoretical timing where the process might fall apart. This retooling of the start of interactions between the vehicle and the silo should always initiate facility charging.

Caveat 3) The new method for handling local doors has an obvious but difficult to encounter oversight. When, for two players, one player opens a door that is not in the loading range of the other player, and then holds that door open by standing in it, if the other player could physically travel over to the door, that player will not see the door open. If, instead of physical travel, the other player d/reconstructs or warps into the loading range of the door, both players will see the door open.

[Dethdeath]

-Jammed wall turret issue is fixed. -All terminals reset properly now after the generator has been down and repaired. -ANT deploys fine now if the driver gets out during the deployment animation.

About the door status and traveling there from afar, I decided to test this too. I traveled from Heyoka to the Ikanam backdoor on Amerish. The backdoor was being held open by another character.

These are the 2 character's perspectives:

It could be problematic that this player that is inside the door is basically invisible. But when I think about how often this would occur in combat, then it would be extremely rare. Backdoors were held open a lot back in the day for an incoming MAX crash, but those would usually start at the tower near the base, which is usually within something like 200-300 meters, so there wouldn't be an issue there.

[Fate-JH]

Features 8) Automated turret deployables would always report their owner as the killer even if the owner was not logged in anymore or was off-zone. This should have been changed to match mine explosives, which do properly attribute themselves if their owner is absent. 9) The Ancient Technology weapon "Radiator" has been disabled due to potential server crashing concerns.

[Dethdeath]

-This is working as this patch intends:

But these names still need to be changed to the CE object name. "High Explosive Mine", "Shadow Turret", "Spitfire Turret" etc.

-Radiator confirmed disabled.

[Fate-JH]

Since there are now two (potential) issues to deal with involving deployables, and it's far from the twelfth anymore, I will wrap this PR up and incorporate those both to a different PR.