Customer Service

[Fate-JH]

The role of customer service representative, game moderator, was previous a role shared within the faculties of basic players. That is to say: the additional responibilities of being a moderator were baked into the same code that governed normal player behaviors and it would have created a tangling of code paths if only such moderator abilities were greater at the time. In fact, they were not developed more thoroughly primarily for the reason that they would have to be jumbled up amongst normal code. That would have to be handled either by writing some things twice, slowing down the processing of player actions, or mixing the difference in, making presentation messier and a still bit slower. Another issue involved the lack of ability restriction that came from code sharing, though most would know that spectators bore the brunt of this issue, and this is mostly a fault of myself and I did not put the necessary logic to make it so that certain aspects of spectators would not trouble normal players. The most common issue was players being kicked because explosives could damage the otherwise undamageable through no fault of their own.

Now that the responsibilities of being a game moderator have been exorcised and distanced from the liberties of being a normal player of the game, the responsibilities can be allowed to expand and contract without causing strife with the aforementioned liberties. Everyone logs in as a normal player but a flag from the database indicates whether they can elevate themselves into a game moderator. This is similar to the flag that is necessary to become a spectator that walks amongst the normal players silently.

This last part is extremely important. As of this update, servers will start in "development" mode and must be switched over to "released" in the configuration file. Read the first entry in the addenda below.

Features
Customer Service Representative
Being in the shoes game moderator is still, actually, not much different from playing the game normally in temrs of what one is allowed to do in the game. One who is assuming the role of moderator is not expected to play the game normally, however, as that will be unfair to the other players. The elevated player is visible to and properly interactive with the playerbase of zone that they inhabit. The elevated player may shoot friend and enemy alike and that target will die just the same as anyone else; the player may fabricate, drive, and ride in any vehicles of choice; and, the player may transfer zones and spawn points within a zone just like normal, following the footsteps of their empire affiliation. All the basic amenities of a facility are available under the standard conditions only. Becoming a game moderator does not stop one from being a leader of a squad or from joining someone else's squad. That player may interact with and contribute to facility upkeep and facility capture. That player may be affected by a jammer grenade and other sources of jammering.

In obvious departure from normal, game moderators will recover from any damage and physical strain up to 100% of their strength near instantly and are thus not possible to easily kill, as it is necessary for them to be alive (as players) to execute the majority of their role. If the elevated player does die for some reason, they will just self-resuscitate on the spot no worse for wear and will be able to continue as if nothing had happened to them. This includes the vehicle in which they are riding being destroyed. In theory, they are completely immune from environmental triggers, both positive and negative, e.g., sidedness, mines, etc., as well as environmental effects, e.g., radiation fields, etc.. The player will never be the cause of collision damage or suffer from falling damage. A more minor departure of normal behavior involves loyalty of combat engineering equipment - where normal players can only build equipment that is loyal to their own empire, game moderators will only place down equipment of neutral loyalty, with the exception of Boomers that will behave and assign itself standard faction affiliation as per handling of its companion detonator. A moderator should gain no experience of any sort from their actions but may inadvertantly be assigned merit commendation progress for their efforts.

A customer service representative can be recognized by the merit ribbons on their shoulders - two customer service commendations separated by two loser commendations.

Spectating as a Customer Service Representative
Normally, a normal player may access spectator mode if they have been given prior permission and may use that mode to explore the battlefield and record interactions and engagements as an unaffected third party observer. This is mostly for the purposes of documenting and movie production, though it can be leveraged for observation of infractions against the game, cheating or hacking or such, Distinctly, they may switch into game moderator mode and actually manage aspects of the game and its players related to setup and infractions against the game, i.e., punishment. In theory, this is a line of communication betwene spectators to game moderators, both of which have blended into the player ecosystem in their own ways. The roles are ektp separate. A player who is a spectator would normally be incapable of being a game moderator at the same time.

As a permissible truncation, game moderators are allowed to assume their own form of spectator mode that is different from the formal spectator mode. From the perspective of other players, it is little different than normal spectator mode; but, from the eprspective of the player using the mode, it is much closer to a game moderator than a spectator. The spectating moderator is invisible to all other players and may walk around amongst them without blocking them or being blocked by them. In this mode, interaction with vehicles beyond access to the trunk is forbidden, and access to terminals that would produce such vehicles is restricted. A spectating moderator loses the ability damage opponents directly, with some exceptions (that should not be indulged). A spectating moderator may not use combat engineering.

If the spectating moderator (or the normal spectator for that matter) were made visible to other players, that spectator's nameplate would be rendered as "spectator:name". Were their communications visible to chat, their name would read the same and the context of their message be displayed in light blue font color.

Commands
/gmtoggle ([o[n]] | of[f])
Accessible by a normal user, testing the responsibility flag, to switch over to the in-game customer service representative mode. Not accessible while as a traditional spectator, but a player may enter traditional spectator mode because of having access to csr mode.

/spectator ([o[n]] | of[f])
While csr mode is active, switch over to a hybrid csr spectator mode. Deactivating will return to normal csr mode, while deactivating csr mode while in hybrid spectator mode will end both and return to normal mode.

!togglespectators ([o[n]] | of[f])
While csr mode is active, can be used to enable rendering of otherwise invisible spectator players and observe their actions. Works for both traditional spectator mode players and hybrid csr spectator mode players.

!showspectators
While csr mode is active, has the same effect as !togglespectators [o[n]].

!hidespectators
While csr mode is active, has the same effect as !togglespectators of[f].

!sayspectator [message]
While csr mode is active, say something in the spectator communication channel.

Note: usage format for mode ([o[n]] | of[f]) means that "", "o", and "on" will all activate the given mode that is currently inactive; and, either "of" or "off" are needed to deactivate the given mode that is currently active.

Caveats
Chat channels will probably not work as was intended. The idea was that normal players, spectators, and CSR's all have their own communication channels that are separate from each other. The ChatService as it currently exists would not support what I intended and modifying at this point risks all current communication capabilities flor this minor update's sake. The code needs a bit of an overhaul. If you can communicate with someone, just roll with it for now. (I'll post a better explanation of expected communication channel access later.)

Addenda

1. Explanation to the server mode change: Elevated commands will no longer be supported as they were originally a workaround to allow access to slash or bang commands while players on the test servers could not be promoted for spectator mode access or CSR (gm) mode access due to obscure database accessibility. Special commands would have to be allowed individually, and that would mean somehow modifying and updating a tertiary project of our group, the PlanetSide Forever Continuous Integration (PSFCI) system, each time a new command was introduced. This is problematic for a number of reasons. The obvious solution was obvious, however: default to being a test server until made different from the configuration file, and check whether the server is set to be a "test server" when allowing access to spectator mode or CSR mode.
2. I did a lot of refactoring to the player modes for the benefit of code re-use between the CSR mode and the normal player mode. Had been waiting to find a good reason to do this since the introduction of a formal spectator mode. Thsi is the majority of the changes in this PR and most can be ignored. Special note, however, should be taken to what I have done to the functions from GeneralOperations that return Handled and Unhandled.

[theonetrueduddy]

So I was able to get some testing in today and the following are my findings.

Most of the functionality appeared to work as intended. Can't be sure I tested everything, but I did try to test the things you mentioned at least. The core stuff appeared to work, and as a result I'll mostly be talking about fringe cases.

1. As you expected !sayspectator did not function.
2. When spectating in CSR mode, I found I had suffered from collision with other non-spectator players. Intended?
3. Whilst vehicles successfully regenerate armour/shields to prevent death in CSR mode, Phalanx/Deployable Field Turrets did not, meaning they could be destroyed normally.
4. Whilst dying in a Phalanx/Deployable Field Turret in CSR mode you successfully were resurrected, in this case next to the now dead turret but requiring a /gmtoggle to become visible to other players again. The same can not be said for other vehicles whereby your death (say by falling into lava or the ol' /suicide locked you into "purgatory" unable to do anything and forcing a closure of the game.
5. Use of /gmtoggle, on or off, in most vehicles appeared to leave the 3rd person view limited to the view range of solider rather than the intended range of the vehicle (this was inconsistent),
6. Enabling /spectator on during CSR mode whilst inside an implant terminal or vehicle immediately crashed the game for the player doing so, and on a couple of occasions nearby players too. Doing this I managed to get one character stuck displaying spectator:NAME, I also did it to a second character but them somehow cleared it? It persisted through death, and relog otherwise.
7. There was some inconsistency with the ability to make use of certs/vehicles when toggling between CSR mode. I found whilst it displayed all certs as available on the character pane, I could only make use of certs the character had otherwise. Similarly one could not acquire armour or vehicles from terminals if they didn't already have the certification outside of CSR mode. This also extended to being unable to re-enter a vehicle that you exited after using /gmtoggle on whilst inside, though this would remedy after toggling the mode back off.
8. Somewhat related to the above, I found placing Combat Engineering entities to be broken. Attempting to place any would result in no resources being expended, a single boomer being placed, and you not receiving a trigger. Further attempts to place would be met with a message stating "you are busy" prevent placing more until you toggled CSR mode.
9. Last one is a bit more fun; MAXes have unlimited capacitor in CSR mode, allowing VS MAXes to fly to the moon. TR MAXes however get stuck in their overdrive mode with no ability to exit it due to this.

That's it for now, I'm sure Deth will find something I did not.

[Fate-JH]

2. When you say "suffered from collision" do you mean you took damage? I attempted to disengage all of that. You still physically exist in the world on your own client but you should not cause or be inflicted by damage. I did not go through the standard spectator activation packets because I intended for CSR spectator to still be able to interact with terminals and such. There's a longer story about this but it's not very important right now. Should I just stick to normal spectator behavior?
3. Noted and will be fixed.
4. When you normally die in a vehicle, it kicks you out of the seat and conceals the corpse. I have to remember to undo that.
5. Weird. I'll research it a bit more.
6. I think I know why and can fix it easily.
7. Weird. I'll research it a bit more. (blatant copy paste)
8. Weird. I'll research it a bit more. (blatant copy paste) (blatant copy paste)
   Wait, wait, I can explain the lack of Boomer Trigger at least. The trigger is only awarded to the player who will be the owner and deployables placed by CSR's do not gain the CSR as an owner. The trigger does not spawn. Also, the server needs to reset the deploy animation but it does not thinks anyone one performed it.
9. Block the TR Max from using its special ability or reset the capacitor (and the capacitor ability) only after the capacitor has hit zero. Got it.

[theonetrueduddy]

Sorry I should have clarified further from "suffered from collision", and it appears in my haste to get that typed up I also missed out "when spectating as CSR".

There was no damage but I found myself bumping into, being displaced by, and being unable to pass through other characters who were not spectating.

So yeah was bumping into others characters as a spectator in CSR mode.

[Fate-JH]

Fixes have been applied, as per comment above:

2. CSR Spectator now utilizes standard spectator behavior mode benefits. That should remove most player collisions and even out door interactions. This does mean that they are now incapable of interacting with entities in the same ways that a normal spectator is. CSR commands will be expanded in the future to restore some functionality I wished they retain.
3. Mountables in general should now regenerate health and shields where applicable. The main issue was tying into the most obtuse of the upstream packets - the one where there is only KeepAliveMessage to know that the client is still connected.
4. CSR player should be visible when ejected from a mounted vehicle upon rare vehicle destruction. In fact ...
5. Activation of gmtoggle and spectator after that both kick the CSR player out of whatever he is mounted in at the moment. This should maintain the correct camera. Deactivation of gmtoggle also ejects the player from mounts.
6. See below
7. Corrected for certifications and probably for vehicle access. A CSR player will properly have access to all certifications, both in viewing their character stats and when using terminals and vehicle mounts and equipment. All other limitations for vehicle mounts should apply, sadly, so exo-suit requirements still restrict.
8. Deployable animation reset allows the CSR player to place multiple deployables with the same construction tool (ACE or FDU). The FDU has an unavoidable delay in anticipation of an animation that will never play but should still return control to the user shortly. Constructing a Boomer now properly creates a trigger, placing it in a hover right about the Boomer.
9. MAX capacitor now wraps around, draining when in use but becomingn 100% when zero'd. When the capacitor hits zero, TR MAX's turn off their special ability explicitly as it lacks a proper interupt keypress condition; but, all other MAX's should have their special abilities remain unlimited and persist between value changes.

In addition, I reversed my position of Handled and Unhandled returns from GeneralLogic: handleUseItem specific methods. I should have just created a flag to interrupt zoning cancel messages from the start.

In addition again, purchase timers for the CSR player should have less of a chance of interfering with purchases.

Chat is still busted and I have no prospects of fixing it right now. I'm working on tests for (6) just to make certain I am aware of conditions where this issue may arise.

[Fate-JH]

Apparently, "the conditions where this issue may arise" are every time. I did what for it that I could.

[theonetrueduddy]

The changes appear to have fixed the problems related to death in vehicles/mounts, but I found some other oddities;

1. Vehicles do appear to survive lava now with a CSR occupant but sometimes they will suddenly die. Best I can ascertain it appears to happen on game window loss/regain of focus?

2. CE stuff is still a little weird...

• Attempting to mount a field turret placed by a CSR will be met with a "busy" message. Curiously this appears to be due to the turret, not the player.
• Spitfires (and variants) placed by a CSR cannot cause harm (outside of detonating on death), but they do shoot
• Mines placed by a CSR either go off immediately (if you happen to be standing on/near them when placed), otherwise they never go off unless jammered
• Warning for ACE deployables are not show (e.g. too close message) they just fail silently. Does appear to work for FDU deployables though
• CE appears to be entirely ownerless and it doesn't get recorded against the limits of the placing avatar... which is I think is the point but thought I'd share nonetheless
• ACEs and FDUs are not consumed upon use whilst in CSR mode
• Technically from before these latest changes but somehow I managed to do this whilst in CSR mode: However been unable to replicate this one

3. I think with this version the strafing bug can be reliably triggered? Tangential, yes, but I found that using /gmtoggle when in a moving vehicle would reliably cause me to be strafing to the right after being ejected from the vehicle. Amusingly using /spectator in the same way (as a CSR) would regularly cause me to be stuck strafing to the left. I also found it sometimes happening whilst using auto-run and then using /gmtoggle. Inconsistently toggling back whichever mode was toggled would fix it, toggling another mode (e.g. spectator whilst CSR and vice versa) was more consistent in fixing. Best I can tell it appears to have something to do with being in a state of motion when your avatar is relocated? Can get footage if desired.

[Fate-JH]

1. Best I can ascertain it appears to happen on game window loss/regain of focus?

Yeah, I can't do anything if it's that. Modern computer telephony and Internet architecture is no match for ancient packet deviltry.

• Attempting to mount a field turret placed by a CSR will be met with a "busy" message. Curiously this appears to be due to the turret, not the player.

You technically can't mount the turret because it is NEUTRAL and you are still whatever faction you belonged to at the start. That's why the empire insignia on the base is replaced with a white square.

• Spitfires (and variants) placed by a CSR cannot cause harm (outside of detonating on death), but they do shoot

They cause you no damage or they cause no other target any damage? If they do shoot at you, it might be a problem anyway.

• Mines placed by a CSR either go off immediately (if you happen to be standing on/near them when placed), otherwise they never go off unless jammered

Once again, the mine is NEUTRAL and you belong to a faction, and that's why they go off instantly. In fact, this moment of detection upon placement is the only time where the mine will detonate on its own initiate and not because a player or vehicle dared to move and exist too close. "Move" is the operative words in that condition. Otherwise, your CSR-privileged player does not interact with the zone like that. I'll check about any other player being a target of it's effect.

• Warning for ACE deployables are not show (e.g. too close message) they just fail silently. Does appear to work for FDU deployables though

I did hide a lot of messages in CSR mode, though I don't know what happened to this one.

• CE appears to be entirely ownerless and it doesn't get recorded against the limits of the placing avatar... which is I think is the point but thought I'd share nonetheless

Intended. In fact, because it is ownerless, it originally only had a default three minute decay. I had to intentionally tell it that it has a twenty minute delay.

• ACEs and FDUs are not consumed upon use whilst in CSR mode

Intentional and not a big deal. Being able to place deployables as a CSR is all about setup, not combat.

• Technically from before these latest changes but somehow I managed to do this whilst in CSR mode:

Totally keeping this bug, whatevere it is

3. I think with this version the strafing bug can be reliably triggered? Tangential, yes, but I found that ...

No, I noticed this too. Since the unstoppable side-strafe bug is an old client issue, solving the actual problem is beyond us. It did give me an idea about how we might finagle use from it with PlayerStateShiftMessage but I don't know if my idea would work yet.

[Dethdeath]

4. CSRs are visible to other players after dying in a vehicle, but not to themselves:

invisible.mp4

10. Something small: Is this progressive XP something that should happen between all the revivals?

11. If you toggle GM powers on and then DC/crash and relog, you will have the merits on your arm still without any of the powers. If you then toggle GM mode on and off, you will continue having them on your arm, even though they should normally disappear when toggling off.

12. I was doing a test in lava, blowing up a CSR Fury with a BFR. The vehicle blew up and the CSR died and got DCed. I relogged, toggled GM on, got a new Fury and moved to the same spot, this time outside of the lava. DCed just from being shot at:

DCfromBFR.mp4

A few relogs later I couldn't enter my previously owned Fury and all my ammo was down to 1 for each weapon. Toggling GM on gave me my inventory items/ammo back, but still couldn't enter these vehicles because I was missing the certs for them now? Probably related to issue 7.

[theonetrueduddy]

• Spitfires (and variants) placed by a CSR cannot cause harm (outside of detonating on death), but they do shoot

They cause you no damage or they cause no other target any damage? If they do shoot at you, it might be a problem anyway.

2024-10-31.10-09-27.mp4

The spit tracks but doesn't fire unless fired upon first. It doesn't do damage to character avatars, nor vehicles whilst they are occupied. It does however damage empty vehicles?

Also something I found here; knives don't deal damage in CSR mode.

[Fate-JH]

The knifing issue was actually a range issue that has probably persisted in the server for a while. The difference between normal stabbing distance and testable stabbing distance was some one-hundreth of a meter against, and this did not affect the katanas because the katana's test against one extra meter. It's still possible to make knife stabs connect with the target within the correct distance but it's hard to do when standing still, probably easier to do when constantly moving towards the target since that causes temporary overlap. In any case, the solution was an additional meter on the testable stabbing distance by increasing projectile lifespan.

I discovered that the spitfire refactor had a few issues and corrected them. For starters, rather than isolating a target when no existing target can be found, it would incorrectly return no projectile information and that short-circuits the whole process. Secondly, because it looked for having no target to cause damage rather than a confirmed target to cause damage, it only caused damage against a target the first hit and no time after that.

Changes to how player characters interact with the blockmap has resulted in CSR's not being interactive with environmental fields anymore. These changes have also allowed other entities that probe the blockmap to never encounter these "uneffected targets" while they are now allowed to remain as blockmap entities.

Killing a CSR player should no longer result in experience gain and suppress some other messages, in the logs especially. Also, the player should remain visible, hopefully.

Incidentally, as a CSR, if you drive a vehicle into lava, you will more easily see an understated feature of how lava damage was coded and the amount of damage a target receives is related to the depth of the target. Health is restored to the vehicle near instantly; but, the amount of health stripped off the vehicle in one go is easily visible in the brief moment of red status; and, the deeper the vehicle is driven, the larger that momentary red status. Driving around the crater allows the user to watch the health of the vehicle seasaw with depth. It's even possible to do this with an ATV without destroying the ATV.

[Fate-JH]

By the way, I was unable to confirm an unfocused game window causing a build-up in damage as was suggested. I only had one instance of two ticks of damage before the CSR auto-heal kicked in. Personally, I find it strange that it happened at all.

[theonetrueduddy]

By the way, I was unable to confirm an unfocused game window causing a build-up in damage as was suggested. I only had one instance of two ticks of damage before the CSR auto-heal kicked in. Personally, I find it strange that it happened at all.

Hmmm, it appeared to coincide with that when it happened for me. But it is true I couldn't get it to replicate consistently either. Chalk it down to "because PlanetSide" I guess? Whatever the cause, I did describe it as a fringe case so I doubt it'll go on to cause problems.

[Fate-JH]

I corrected the issues in #1245 here in CSR because I wanted to correct the issue but then realized that I changed a part of the code critical for the bug fix in this PR.

[Dethdeath]

Router and router pad SEP works.

Zoning in spectator mode doesn't work properly. You end up in some inbetween state with broken weapons and inventory:

SpectatorZone.mp4

Toggling GM while being dead can lead things like being stuck on the map screen if you attempt to use /zone. GMtoggle should probably be disabled whilst dead?

GMtoggleRev.mp4

[Fate-JH]

Zoning in spectator mode doesn't work properly. You end up in some inbetween state with broken weapons and inventory

That's normal spectator mode, correct? not csr spectator?

[theonetrueduddy]

Zoning in spectator mode doesn't work properly. You end up in some inbetween state with broken weapons and inventory

That's normal spectator mode, correct? not csr spectator?

Just tested this myself and it appears to be during just normal spectator.

[Dethdeath]

Yep normal spectator mode.

[ScrawnyRonnie]

To add, this spectator zoning issue existed already. Tested on local (up-to-date minus this PR). The spectator that just zoned is visible to others, but frozen in place.

You don't want to shoot them!

[ScrawnyRonnie]

This was amusing 😄 Do these deaths actually count against the gm?
https://github.com/user-attachments/assets/d109ad16-7cba-4464-b6d5-bd3f85c69355

[ScrawnyRonnie]

My comment about spectators in only still partially true. They no longer become visible to others upon zoning (thus can't be shot at), but the avatar/inventory issue is still there. Should have fully tested here too...

[Fate-JH]

For the record, attempting to zone as a spectator deactivates spectator mode and returns the player to their sanctuary.
A player should not be able to activate csr or spectator while dead.

[ScrawnyRonnie]

As Fate said, attempting to /zone while a spectator did send me to sanc.
& while dead, attempting to /gmtoggle or /spectator gave the 'you do not have permission...' message.

[Fate-JH]

A field turret constructed by a CSR-level player is now completely neutral. Although it's mounted weapon can not be seen or interacted with, that's merely a limitation of the client. The default field turret weapon is just a transparent parent object from which the faction others are instanced. It should function without crashing even if the user were capable of mounting the turret seat. When a deployable is constructed by a CSR-level player, the GUID of the resultant deployable is printed in event chat.

Included also is a new custom bang command called setempire which allows the CSR-level player to change the faction affiliation of a game object. Usage is !setempire <guid> [faction]. Entities must be represented by their current GUID. A faction must be represented by its two letter code and NEUTRAL is not allowed; if not listed, the player's current faction is selected. Entities behave differently based on how to most appropriately reflect a changed faction affiliation, e.g., field turrets (like above) deconstruct the old one and completely fabricate a new turret, facilities flip faction affiliation like being captured, facility amenities behave as if they were hacked, etc.. Certain entities such as players and Boomers do not change faction affiliation for obvious limitations.

As a combination of these features: !setempire on a field turret will construct a turret with a mounted weapon appropriate to the faction in question.

[ScrawnyRonnie]

CSR field turret and setempire both seemed fine from the little bit I did with them. Is there a way to get a guid without using /destroy? For an equipment terminal, that seemed to make the terminal not work for the empire I set it to with the setempire command, but leaving and reentering the zone allowed that character to use the terminal as if it were hacked. Not sure if destroy did something to the terminal or it is just something with the setempire command.

[Fate-JH]

/destroy is a horrible command that actually affects the environment of your game client and the server does not get polled for its permission. Of course, any changes to it are undone by merely reloading the zone for the majority of cases; but, for the duration while in that zone. anything with a GUID can be "killed". The only benefit of the command was that it displayed the GUID of an element in the events chat and that lost developmental usefulness to us immediately after we determined how to process hit information from projectile damage.

At the moment, !setempire is only best utilized for manipulating deployables that a CSR-user places in the game environment. All deployable entities should have their GUID posted to your events chat. Even the field turret that gets remade by setempire announces its GUID.

To answer you question directly, no, I've found no other commands that have the same affect. I was working on a "nearest" bang command to reveal the GUID of some nearby entity but I lost my battle with useful parameterization. My ultimate goal for CSR players is to use specific direct hit weapons to reveal debugging information about game entities rather than cause damage. Knives, anniversary pistols, and the sniper equipment are probably the best outlet for this since they shoot straight and behave the same way regardless of who holds them.

[Dethdeath]

/capturebase doesn't work using the character's location anymore, this makes capturing bases in caverns and towers harder or impossible.

[Fate-JH]

Can't be helped if it's the caverns. Those places aren't expected to have all their working bits and bobs and may not even play nicely with well-established commands.

As for the overworld, a change I introduced for CSR's meant that they no longer were being recognized as players in an SOI and, by not being recognized as players in an SOI, a shortcut I was using to assess their current faciltities by curr was not longer working. I've gone back to doing the math to check if they're in the SOI and that should resolve the issue.

[Dethdeath]

SOI capturebase works again.

I reproduced the BFR particle cannon disconnect yesterday:

DCfromBFR2.mp4

My current theory is that the disconnect is caused by the first damage tick of the radiation field. Unfortunately I haven't been able to repeat it since. I'm also not sure if this can be reproduced on the main server or if it's something that only happens here.

[lazer1982]

if i recall there a a bug with the Radiator making ppl crash as well

[Fate-JH]

If the NC Particle Cannon and the AT Radiator are both infrequent issues, then the commonality might be a flaw in the remote projectile system, or a flaw in the radiation field damage calculations, related though different as they are. I am not going to attempt to extend this PR's scope again. That will be a different fix.

[Dethdeath]

Using gmtoggle repeatedly before entering/exiting vehicles can lead to a severe slowdown in actions and weird stuff happening. If you do it for long enough, characters trying to load the continent will crash too.

toofast.mp4

Spam G to enter a vehicle and the mounting will take place at a random time in the near future, even while driving another vehicle:

teleported.mp4

Preventing users from exiting vehicles with gmtoggle might fix a good part of this.