Repeating the Obvious

[Fate-JH]

Signs are like insurance. The people who want don't need, and the people who need don't want, and when things go wrong everyone complains about it not being helpful enough to a customer service representative.

These messages mainly become visible in events chat under certain circumstances. Determining these circumstances based on the format of the message, and accounts by former players, is the most difficult part of this effort. A lot of it was determined just by reading the messages generated and deciding on an interaction to target. The server is developed enough that the majority of cases are either already represented or are easily integrated without extensive changes. With the exception of a few messages, all of these are just plain packets dispatched in already defined cases. The most common type of ChatMsg is known internally as UNK_227 and all that does is print a text string into the events chat (the text region above normal in-game chat). Different messages use different message types, eliciting different effects from the client, including sound effects, splash text that covers the middle of the screen, a message integrated into in-game chat, infrequently color, etc..

To be completely clear, the messages are actually short-hand fragments that expand into much more details alerts. They begin with an @ symbol and may use ^ and ~ to mark off regions where customization text can be defined. They are all transmitted to the client though the ChatMsg packet.

Features

• ams_decayed - The conclusion of an ownerless decay for an AMS, this message indicates the decay for the vehicle is over finally and it will deconstruct. Only players whose immediate last spawn is the AMS will see this message. The message might have been intended for players that have bound themselves to the AMS rather than those who have spawned on it.
• ams_decaystarted - If an AMS goes ownerless, this warning will be issued to every player whose previous spawn point was that AMS, as a warening that someone must claim it post haste. The message explicits calls out 15 minutes, so that is the deconstruct time, give or take a few seconds. If the player respawns somewhere else other than the AMS, they will not see this message. Only players whose immediate last spawn is the AMS will see this message. According to the literal text, the message might have been intended for players that have bound themselves to the AMS rather than those who have spawned on it.
• ArmorShieldOff - If the player belongs to the New Conglomerate, and is wearing a mecahnized assault exo-suit, and the player is using the special ability of that MAX - the energy shield, if the player runs out of power from its capacitor, then the shield will deactivate.
• ArmorShieldOverride - If the player belongs to the New Conglomerate, and is wearing a mecahnized assault exo-suit, and the player is using the special ability of that MAX - the energy shield, and the player is opening fire with its arm weapon, then the shield will deactivate.
• CannotBailFromDroppod - Although the drop pod model does possess a door on its side that will allow a player to step out of it in midair during a bail, this is unused and should never be seen. The drop pod should never be bailed from as the drop pod itself is a form of bailing.
• CMT_CULLWATERMARK_success - When the watermark has been successfully culled by a prior command message. Not really useful for anything.
• CTF_Failed_FlagLost^ - During a facility capture that involves the LLU, if the LLU enters a state where it should become unreachable and the facility hack should be cancelled, this message will display as the facility is restored to its normal (current) circumstances. The main way the LLU can become "lost" is by being destroyed on account of the user stepping into an environmental hazard but it will also trigger upon entering a warp gate bubble.
• CTF_Warning_Carrier^, CTF_Warning_NoCarrier^, CTF_Warning_Carrier1Min^, CTF_Warning_NoCarrier1Min^ - During a facility capture that involves the LLU, after a certain period where the capture has not been completed by a successful delivery of the LLU, a periodic warning will be displayed about the necessity for completing the hack in a certain way. A timeout will occur if the LLU is not delivered. These warnings are displayed at 10 minutes until timeout, 5 minutes until timeout, and a special format message that always calls out the last minute until timeout ("within the next minute"). Rather than be given their own dedicated timer protocol, these messages piggyback off the high frequency capture flag timer that updates the state of the flag to all people on the server, but sends only to the faction that should manipulate the flag.
• DeployingMessage - Displays when a vehicle enteres a "deployed" state (DriveState.Deployed only).
• FacilityRequiresResourcesForHackCriticalWarning - If a facility hack had been executed but the NTU drains itself at some point before five minutes completion, this message will be displayed at 5 minutes before the hack completes. If the facility does not return to positive NTU levels, the completion of the capture effort will result in a neutral-aligned facility.
• FacilityRequiresResourcesForHackWarning - If a facility hack had been executed but the NTU was already drained before it started, this warning will be displayed at the start of the hack. It specifically mentions a 15 minute hack.
• InventoryPickupNoRoom - When the player collects an item (equipment) from the ground, it will either be placed in one of the player's inventory slots, or in the player's free hand. If it has gone into the free hand, the item has failed to find free space in the backpack and will probably be dropped on the ground again.
• ItemsDeconstructed - When switching exo-suit types from an order terminal, and switching to an exo-suit type with smaller inventory space, common and faction-affiliated items are deleted from the backpack rather than being dropped on the ground. Certain items that are too important to be deleted, either needing to be maintained for the sake of server stability, or are too valuable to just allow the player to lose, are still dropped. The MAX arm weapon is always deleted when switching from a MAX suit to a vanilla exo-suit and does not count towards the appearance of this deletion message.
• JackStolen - When a player jacks another player's vehicle, this is the message will appear in chat for the jackee, alerting them to the fact that theit vehicle has been stolen. This message will be in red.
• JackVehicleOwned - When a player jacks another player's vehicle, this is the message will appear in chat for the jacker, alerting them to the fact that they now own the vehicle they have stolen.
• no_permission - When the player attempts to use a command that they do not have permission for, this message is down. This is most likely for attempting to use a command that is above one's mod status - a normal player calling a CSR/GM only command - but it should activate for any sort of message that is not supported under the current conditions.
• nomove_intersecting - If a deployable is blocked by another deployable entity, or an entity within the same entity shared group, it will not be placed. The message does not distinguish between being absolutely right on top of another entity or just too close to a valid blocking entity. This may not be the correct message for this situation but it does get the point across.
• nodeploy_ams - When a vehicle that is an AMS can not transition to a deploy state, this message will be displayed instead of a generic custom one.
• PadDeconstruct_Done - When a player orders a vehicle spawn but, for whatever reason, is not capable of mounting the vehicle upon it being spawned, but that does not also count as a reason for the vehicle order being invalidated, the vehicle shall sit idle and occupy its spawn pad. The owner, while that player remains the owner, will see this message when the idling vehicle is finally deconstructed.
• PadDeconstruct_secsA^ - When a player orders a vehicle spawn but, for whatever reason, is not capable of mounting the vehicle upon it being spawned, but that does not also count as a reason for the vehicle order being invalidated, the vehicle shall sit idle and occupy its spawn pad. The owner, while that player remains the owner, will see this message before the vehicle is deconstructed across 30 seconds, at 23 seconds, at 15 seconds, and at 8 seconds.
• rpt_i - Typing /report <player name> in chat will result in this message that says "Player reported ...". The call and respond work properly even if the actual feature doesn't.
• SA_CannotBailAtThisTime - A generic message expressing an inability to bail, though used here mainly for vehicles that are under the control of auto-pilot conditions such as having just been spawned and moved away from the vehicle pad. Drop pods do not count.
• SA_CannotDismountAtThisTime - A generic message expressing an inability to dismount, though used here mainly for vehicles that are under the control of auto-pilot conditions such as having just been spawned and moved away from the vehicle pad.
• TooFastToDismount - When in a moving vehicle, a player can can not dismount. (But the player may try to bail.)
• UndeployingMessage - Displays when a vehicle enters an "undeployed" state (DriveState.Mobile only).
• Vehicle_CannotBailInWarpgateEnvelope - The warp gate envelopes (the bubble) are special places and count as safe, protected regions. There is no reason to bail while in them.
• Vehicle_OS_PlacedOutsideHallway - When the orbital shutle is to take off, anyone in one of the shuttle's gantry hallways will be ejected outside of the hallway into the HART shuttle building lobby,

Other Features

1. WithWater for both players and vehicles now keeps track of casual interaction with water, a state called "wading". A player or vehicle will wade through water up to the point where the player begins the process of drowning (or remains wading in water, if the vehicle floats or hovers). To accommodate this state of "interacting, but not drowning", the drowning environmental interaction was completely reworked to detect this initial shallow walking then revisit and test as many times as is necessary until the depth for drowning is achieved. It can then transition between dry--wading--drowning--wading--dry as many times as necessary. Wading currently begins at 0.2f depth from the surface for both players and vehicles. See: @CTF_Failed_FlagLost^.
2. Various checks have been placed to ensure that capture flags (LLU's), wherever they might drop or be dropped, are protected against settling somewhere where the LLU would otherwise be unavailable if it were carried by a player. The LLU is destroyed. Destruction of the LLU results in the facility that spawned it no longer being under the threat of a "facility hack".

Caveats

1. If a player exits the water too quickly, causing a truncated transition between drowning and out-of-the-water, the player might continue drowning. The speed at which this transition occurs typically can only be achieved by CSR/GM's and by spectators and will probably not be encountered in casual play.
2. The LLU can still be lost in places from which it can not be retrieved, but that was always the case. The fact that some terrain invalidates a precarious LLU placement merely draws attention to the existing unhandled situations. It is what it is.
3. The capture terminal that was hacked does not always reset visually. Sometimes it does, rarely, but often it does not. This does not appear to impact proper interactivity with the capture terminal or the facility and is a visual bug.
4. As noted in a comment somewhere, certain message may change their message type based on the side of a given event the given targets of the message are situated. In other words, if it's the attacking group, the message is delivered as one thing. If it is the defending group, that message is presented another way. This presumed switch is not respected at the moment.

Addenda

1. Players were capable of bailing out of drop pods while they were in mid-air, despite the fact drop pods should have never be escapable until they land and their passenger escapes the splitting pod. Also, occupants "bailed" through the unused pod door and immediately teleported to the ground. Marking the vehicle as being controlled by auto-pilot makes it operate correctly and produces a testable condition for a message.
2. Failing to disembark from flying entities would cause the pilot to succeed to dismount anyway because the flying vehicle begins to deconstruct itself and kick the pilot out. This unfortunate series of missteps is how I discovered the previous point about being able to bail from unbailable drop pods. By moving the relevant checks to a dismount result, the flying vehicle will no longer attempt to deconstruct itself upon a failing dismount/bail.
3. In additional to @ams_decaystarted and @ams_decayed, a custom message has been included that is based on the former's message format, dropping the explicit time limit. This custom message will be seen by every player who spawns on an AMS while it is undergoing a state of ownerless decay at their timwe of spawn.
4. Corrected an issue with vehicle deployment where some of the result messages were not sent to the correct destination and were consumed by the vehicle control agency itself. This did not result in incorrect behavior but a conclusion to the deployment transition logging was skipped. If these logging cases were to be used as callback, they would never execute.
5. A distinction now exists for timeout with a facility capture involving an LLU if the flag was never interacted with by players, left in the socket. The message that is displayed will be different than if the LLU was normally manipulated but the facility capture was still not completed in time. We should be able to make this window of interaction deficiency more wide-reaching in the future if we choose.
6. Somehow all the active tests can pass (inactive ones need extensive rewriting). I can scarcely believe it myself.

[Fate-JH]

The depth to count as wading is much more dynamic for vehicles.

[Dethdeath]

Working:
-Inventory items deconstructed due to lack of space message works.
-No room to pick up item message works.
-Deploy/undeploy messages work for AMS, Router, ANT and Switchblade.
-Cannot bail messages during auto-driving work.
-Vehicle moving too fast to dismount works.
-NC MAX shield weapon override message works.

Not working:
Often getting "vehicle too close to vehicle pad" messages when just pulling a vehicle and auto-driving, pull 4 different vehicles and you will see them all. Different characters pulling a vehicle will result in the first character getting the 23 seconds message, the second 15, third 8 etc.
The messages also seem to be lacking a time check and a character check. The last message says "the vehicle has been deconstructed" without anything actually being deconstructed.
These messages were mostly intended for vehicles driving onto the vehicle pad, vehicles that have just spawned should be excluded from receiving these for some period of time.

I don't think some of these AMS/Router messages were implemented, but they probably should be.

@nodeploy_ams=You cannot deploy this vehicle as you are too close to another deployed AMS of your own empire.

Didn't trigger.

@nodeploy_sharedinterference=You cannot deploy this vehicle as you are in the interference range of a deployable object.

Didn't trigger near TRAP.

@nodeploy_router=You cannot deploy this vehicle as you are too close to another deployed Router of your own empire.

Routers can be deployed right next to each other (new bug) and so this never triggers.

NC MAX shield depleted due to empty capacitor doesn't show up.

@ArmorShieldOn=Shield activated

Should be implemented too if ArmorShieldOff is.

The AMS decay messages were indeed meant for players that were matrix bound to the AMS.
We could leave it like this until matrix binding actually gets implemented?
I've seen the decaystarted one pop up when spawning at an AMS, haven't tested the full decay one yet.

Reporting players works, you can even report yourself. This should probably give more feedback saying the feature is currently not implemented to avoid possible confusion.

Still need to test the LLU/drowning stuff.

[Fate-JH]

A preface I forgot to add is that I only implemented messages that I have found in our packet captures. Messages that do not show up in our packet captures, I do not know about.

Not working: Often getting "vehicle too close to vehicle pad" messages when just pulling a vehicle and auto-driving, pull 4 different vehicles and you will see them all. Different characters pulling a vehicle will result in the first character getting the 23 seconds message, the second 15, third 8 etc. The messages also seem to be lacking a time check and a character check. The last message says "the vehicle has been deconstructed" without anything actually being deconstructed. These messages were mostly intended for vehicles driving onto the vehicle pad, vehicles that have just spawned should be excluded from receiving these for some period of time.

The trigger for being "clear" of a vehicle pad so that the next vehicle order may be processed is distance, and the distance is not actually that far. Different pads may have different messaging results due to the speed of the vehicle or the forced pathing the vehicle must take. For example, this was mostly tested from the ground vehicle pad in a dropship facility (good ol` Anguta, Ceryshen) but vehicles were also pulled from Tootega, Ceryshen, and from Sanctuary, during the course of this branch. It's difficult for me to test multiple players pulling a vehicle without forcing certain results such as the not being able to mount contingency. Also, too many players will grind my clients to a standstill. While it sound like the order routine doesn't reset properly, the fact that it takes the game seven seconds to spawn a single vehicle and move it off the platform far enough needs to be examined.

I don't think some of these AMS/Router messages were implemented, but they probably should be.

@nodeploy_ams=You cannot deploy this vehicle as you are too close to another deployed AMS of your own empire.
@nodeploy_sharedinterference=You cannot deploy this vehicle as you are in the interference range of a deployable ...
@nodeploy_router=You cannot deploy this vehicle as you are too close to another deployed Router of your own empire.

I only implemented nodeploy_ams in theory with all pootential conditions wrapped into that one message. I didn't know about the others. I mention that there are a lot of cases that show up but the conditions for them don't necessarily make implementation sense. For example, there's one for the trunk being too far away to open, the terminal being too far away to access, can't mount because too far away, and so forth. The realistic option is that the game checks distance between player and accessed element - container or terminal - but the server may only vaguely keep track of that, accessed terminals especially.

NC MAX shield depleted due to empty capacitor doesn't show up.

Will check written conditions.

@ArmorShieldOn=Shield activated
Should be implemented too if ArmorShieldOff is.

Never saw this message used. It's always just the normal shield activated protocol followed by the normal shield deactivated protocol, or the normal plus override, or just the off message. The existence of unused or virtually unreachable messages is possible.

Reporting players works, you can even report yourself. This should probably give more feedback saying the feature is currently not implemented to avoid possible confusion.

Counterpoint: reporting players never seems to help anyway.

[Dethdeath]

-Both vehicle jack messages work.
-Hart hallway ejection message works.
-LLU message with carrier showed at 10, 5, 2 and 1 minutes.
-LLU message with no carrier showed at 10, 5, 2 and 1 minutes.
-LLU lost message showed up fine too.
-AMS full decay message works.

Haven't seen anything weird with the new drowning system

LLU carrier timer is not always synced to the base hack timer, it was off by 3 seconds for a carrier. Only had this happen once so far.

@ArmorShieldOn=Shield activated
Should be implemented too if ArmorShieldOff is.

Never saw this message used. It's always just the normal shield activated protocol followed by the normal shield deactivated protocol, or the normal plus override, or just the off message. The existence of unused or virtually unreachable messages is possible.

I cannot confirm that message was used either.

[Fate-JH]

So, about @nodeploy_router: the copy of the ADB file I'm using doesn't list any interference information for the Router vehicle, either against its own type of vehicle or against shared group information. It technically blocks nothing and should be blocked by nothing, I considered the possibility of generic interference if none is explicitly listed. Compared to a Switchblade, which is certain to never interfere with itself or any other thing during deployment, there are no flags that would likely indicate this freedom from defaults. The wiki also does not specify any information about interference about the Router.

If we include interference information, it'd have to be custom.

[Fate-JH]

Interference should block on same vehicle and preexisting shared group 3 - the AMS / TRAP group.

Blocked pad warning should reset upon progress in the vehicle order queue.

Causing the NC MAX shield to lose power will cause @ArmorShieldOff to be displayed.

[Dethdeath]

-NC MAX shield depleted message works.
-AMS shared interference with TRAPs message works.
-AMS too close to another of same empire message works.

I cannot get the "too close to the vehicle pad messages" to trigger at all anymore now.

The Router situation:

[Fate-JH]

I cannot get the "too close to the vehicle pad messages" to trigger at all anymore now.

That's a good thing in this case as long as everything remains working. It's a failsafe for failing to seat the driver or failing to move the new vehicle from the spawn pad.

The Router situation:

I think you can lose your animal husbandry license for this.

[Fate-JH]

20m should be enough.

[Dethdeath]

20 meters is working for AMS', TRAPs and different Routers. The only problem is that a single Router cannot be deployed near an AMS now, it should allow for one within the cloaking bubble which is/was the most common way of using them.

[Dethdeath]

FacilityRequiresResourcesForHackCriticalWarning - If a facility hack had been executed but the NTU drains itself at some point before five minutes completion, this message will be displayed at 5 minutes before the hack completes. If the facility does not return to positive NTU levels, the completion of the capture effort will result in a neutral-aligned facility.
FacilityRequiresResourcesForHackWarning - If a facility hack had been executed but the NTU was already drained before it started, this warning will be displayed at the start of the hack. It specifically mentions a 15 minute hack.

Both of these messages are also working.