External Doors

[Fate-JH]

Going In
Inside
Inside a Base
Tank Outside
Inside a Base, Dying to Tank Outside

Facility walls became paper thin since the PlanetSide became free-supported. In fact, uberwood and materials in general no longer seem very material at all, a fact that any caught nearby an expoding vehicle might attest. While tank spam isn't as significant an issue as concern suggests because one's own client does most of the heavy lifting when starting the target resolution process, not all damage is so fortunate that it's hand is held. Infantry small arms and rifling and most vehicular weapons benefit from this hand holding. A few of the specialized weapons and all ancient weapons and at least two Battleframe gunner weapons possess a property that should require the server decide whether some target will be affected. Various explosions, some pojectiles that confer damage for a certain duration, jammer grenades (as a courtesy), all ignore the suggestion of "walls" and damaged whatever they please.

When discussing facility composition, one must acknowledge the existence of doors. They usually open for the worthy but woe be you if you are not! Open doors. Locked doors. Interior doors. Important are the external doors, most of which possess a corresponding IFF Lock amenity, that must have an outwardsness to be respected at some point. When a player passes through such a door, they go between the outside and the inside region that is otherwise defined by the facility's "walls". Even though the "walls" do not exist to us, the door does, and we can leverage the flow of players across that fixed position to determine whether any given player is "inside" or is "outside"; and, by doing this, we may also assign such conditions to sensitive damage that would otherwise need to acknowledge the "inside-ness" or the "outside-ness" (or the "between-ness") that stops causes targets to be unfairly hurt. In short, movement between doors prevents the "bleed through" of some damage that would otherwise have hurt if it did not care about which side of the wall it was on.

Players, vehicles, and projectiles, and damage types pay attention to sidedness. In addition, various amenities in the facilities also have a listed sidedness; but, that is mostly for clarification and rarely for examination. An example where it is more useful for processing involves the vehicle spawn pad - any vehicle that spawns inherits that pad's sidedness state. Additionally, anywhere that uses geomtry to determine targets beign affected by a damage type has been changed to reflect the potential for being affected by sidedness calculus.

Features Sidedness The primary flag state for being "inside" or "outside" of a facility. Also defined is an "in between" condition which represents being in an open door. This "between" state is often used as a default value and is accessible to both "inside" and "outside".

InteriorAware Primary interface for entities dealing with sidedness. Has both a standalone mixin, and a more complicated mixin that searches for a zone interaction relating to the door.

WithInterior The zone interaction that deals in the Sidedness of players and vehicles. This interaction looks for special fields that are emitted onto the block map by doors and then sits on that field until the target has sufficiently moved past the door frame. Vehicles technically have a dedicated unimplemented version of WithInterior but it doesn't work as intended in its current form and may remain unimplemented and purged.

InteriorDoorPassage The special environment field emitted onto the block map by doors to indicate to any target moving between the "inside" and the "outside" about which "side" of the door it is on at the moment.

VolumetricGeometry A better attempt at using Geometry classes as a PieceOfEnvironment field, allowing them to be represented on a zone's block map. The classes benefit by allowing some effect to be contained within a limited 3D region while normal environment fields are either encompassing of an entire region and all its verticality or a region below an altitude.

Zone Assigning outward directions to external doors and sidedness to various amenities for all sanctuary buildings and towers and all primary continent facilities and towers. Bunkers do not have an inside to protect occupants (mostly, Gemini Live accurate).

zones/Zones Changes to entity allocation for doors allow the different defintions of a "door" to be created and applied as appropriate to the object type listed in the zone map files. A door is still just a door but it may have a specific type such as a gr_door_int or a gr_door_main which affects the fields available that allow it to function.

Commands !nearby - a GM-level command that searches for the nearest facility or tower and displays both its local name and object type. Served a purpose in determining which cavern facilities were what type of facility but due to circumstances and complications it is not necessary anymore. The command is fairly harmless and has been retained for GM use. For normal users, saying "facility name", "tower near facility name", or "facility name's bunkers" or such, is more than enough to explain the details of "where". Additionally, as a reminder, !loc is a command accessible to a normal user. It serves the same purpose as the standard /loc but provides more concise information.

Caverns Caverns are not supported by this change. This is probably the most dramatic non-change in this feature update but the caverns present a non-trivial roadblock. Firstly, unlike facilities and towers in the other zones, where a varity of doors are employed to indicate purpose of that specific kind of door entity, the caverns only have one type of door - ancient_door - and no special features that would indicate whether the door is external or the direction of the outside if it is. There's also an ancient_garage_door but that's not much help when there's only two per cavern. Secondly, outside of the primary structures common to all caverns - the core, the redoubts, AT plants, and the module buildings - all other buildings in the loose campus style facilities of the caverns have variations in configuration that make the already difficult door estimation that much harder. For example, in some facilities of a certain type, a door has been made completely missing or, if the door is present, a feature which would be necessary to appropriately estimate its outwards direction is missing. Furthermore, some features in the zone are not considered amenities of the building in which they are physically housed and, thus, a zone-wide search must be conducted to determine where they are, if they are even there in the current version of that building. If that feature is considered necessary to help define the outwardsness of a critical door, instances where the feature is absent or moved slightly are highly problematic. Finally, the caverns contain natural teleportation rings that exist as level geometry rather than actual entities. (You could completely hide the cavern features like crystal buildings and terminals and such things by removing the application flags that allow them to be visible, but the teleporters will remain floating in midair.) Since they are level geometry, they are not entities and have no actual representation in the zone asides from visual regions. Even worse, since the teleportation rings are just defined by the associated locations of their entry point and their exit point, they do not correlate in any way to their actual location in the zone's facilities. Not only are they not conventionally searchable, they also can transfer a target between interior and exterior without having anything that marks the transition. A potential solution for the caverns might involve a "facility interior" field that would always mark a target in that region as "interior", rather than a checkpoint system using the doors as critical, but that's a significant amount of further development, Fortunately players should not be too affected by mechanics that would abuse this lack of interior awareness for cavern facilities.

Caveats This change should only reinforce protection of the interior of a facility from concerns of the exterior, specifically against explosions and against EMP. The linked issue should demonstrate an issue that was resolved. This does not protect something exterior from exterior dangers - a vehicle exploding in the courtyard can still damage something on the other side of the rampart wall - or something interior from interior damages - Boomers can still cause damage through thinner facility walls and closed doors. This was a flimsy interior flag; it's not a proper substitute for searchable level geometry.

Addenda 1) Fixed an issue where players were unable to acknowledge being mounted in anything but a strict vehicle. 2) Fixed issue where custom chat bang-commands were being skipped because the scope of the message channel was being caught before the content of the message. This is actually a rewrite inspired by #1189 by @Resaec. 3) What was the previous attempt at using geometry as environment fields? was it remote projectiles? I don't remember off the top of my head. 4) The file of object global definitions was previously a bit of an eyesore not unlike the original WorldSessionActor. The file was so large, it caused signficiant lag upon openig it or tabbing over to it. To ease the trouble it caused, the different sections of the file were removed to their own files. The calling mechanic that connects the files and makes certain they all load in the correct order is somewhat clunky but other dynamic attempts failed to work with object and trait simpletons so it is what it is for now. The main GlobalDefinitions file will merely store the references; the individual files connected to it apply the properties. Check the /global/ package. This was not absolutely necessary for the PR but it eased the stress of the environment overall. 5) As is typical, no new tests. :/ The test system needs an overhaul anyway. We have too many tests trying to be run at once, and the actor tests remain a hassle due to timing issues.

[Dethdeath]

Can't get a bunch of chat commands to work like /fly and /capturebase, even /suicide stopped working for one of my characters. /certadd says no arguments will add/remove all certs, but then only displays the same info message instead of adding/removing certs.

[Fate-JH]

Aren't those GM-level commands? I didn't realize the test server was adjusted to have an override for that. As for suicide, I'll check that one.

[Dethdeath]

They work fine on other test servers. /suicide broke after I spammed some of the other commands that didn't work, perhaps that is the way to reproduce it.

The /speed command does appear to work. !progress is also broken

[Fate-JH]

Forgot to link to the issue that should be solved by this feature.

[ScrawnyRonnie]

Standing near a door inside a base does protect you. There is a safe range you need to stand back, a little further than how far back you need to be to make the door close, but it works.

I wasn't sure how far away from doors this was supposed to apply, but I did try a few other areas in a Dropship. In the stairs I did two spots, one was safe and the other not.

Also in a corridor leading to the bottom level of the main stairs, a vehicle explosion directly above still killed the player but I didn't think a door would be considered in this scenario.

Some / commands were still not working. I only tried one ! command !ntu and that did not work either.

[Fate-JH]

The door is merely a trigger that assists assignment of an internal or external state. Getting close to the door put you into a state that pays attention to the door's open state and when it's open you are susceptible to damage from either side. It shouldn't matter where you stand in a hallway after passing through the external door since the state should remain consistent.

Ah, I did forget one caveat: when you log in, the game can not verify where you are, so you are marked as "in between" until you interact with a door that assigns sidedness. Another consideration is whether the exploding vehicle thinks it is inside of outside at the time, though that shouldn't matter in most cases. The VehicleSpawnPad defaults to external and vehicles from terminals get assigned the same side as the pad.

Might I have additional information about your movements prior to this test.

[ScrawnyRonnie]

I think my problem was the use of /warp to get into position faster, but I wasn't able to replicate dying inside. Prior to this image, I died and respawned at a base, then used warp to the base. I stayed outside and allowed a vehicle to get blown up right next to me and took no damage. I guess the insideness state was still with my character?

I stopped using warp and when I went outside, I died. When I went inside (or stayed inside after respawning) I did not die. So flawed first round of testing.