GTG Safe Zone

1.0.0

GTG Safe Zone -- update

FIXED: WEAPONS COULD NOT BE DRAWN INSIDE A ZONE

Console players reported that standing in a safe zone made it impossible to
equip or draw a weapon at all. It affected everyone, but on a keyboard it
usually went unnoticed because the weapon tends to be up already on entry.

The fire block was a timed engine lock, refreshed every frame. Vanilla uses
that call in exactly one place -- after a gadget is put away -- and in that
state the animation layer also holds the weapon down. Refreshed every frame it
meant anyone inside a zone was permanently in the engine state "just stowed the
binoculars".

Removing it was not an option: without it, firing inside the zone worked again.
Clearing the fire input does not hold for a player, because it is a per-frame
flag and the shot has already gone off by the time the check runs. Grenades and
melee stay blocked either way -- those can be cancelled mid-motion, a shot
cannot.

The lock is now applied to players only once the weapon is raised. A weapon
that is not in hand cannot be raised, so equipping and drawing stay free and
the lock arms only afterwards. AI keeps the unconditional lock.

Consequence to expect: inside a zone the weapon cannot be held raised, it sinks
back down. That is the block doing its job, not a glitch.

Verified on the live server: weapon draws on controller and keyboard, firing
blocked with both, grenade throw still cancelled at the pin.

0.1.15

0.1.14

0.1.13

0.1.12

GTG Safe Zone -- changes since the first live server test

Running on a dedicated server surfaced six faults that cannot occur offline or on a listen server, where the calculating and the displaying machine are the same. Several of them shared a single cause -- and three of them turned out to be the same wrong assumption at different depths: that the order in which things happen to be created means anything.

FIXED
GAME MASTER SETTINGS NEVER REACHED THE SERVER
Reported as three separate faults: enemy AI was invulnerable inside the zone, weapons were not released on alarm, and the boundary switch did nothing.

It was one. SCR_BaseEditorAttribute decides via a field m_bIsServer whether a setting is sent to the server. That field's default value is applied by the serialiser -- but our attributes are created with "new", so it stayed false and the dialog wrote every change locally only. The server therefore never had an owner faction, and without an owner nobody counts as an enemy: no alarm, and attackers are protected along with everyone else.

Provable in the logs: the client reported the boundary switch as set while the server simultaneously reported the zone had no owner.

Fixed by overriding IsServer().

A ZONE WITHOUT AN OWNER STAYED SILENT
The state above is reachable without the bug: "Owner" defaults to "Automatic", and if the zone finds no base inside itself it has no owner. The consequences look like three different faults but are one.

The zone now reports this as a warning in the log, including the remedy. An explicitly neutral zone stays silent, because there it is intended.

THE BOUNDARY DISPLAY WAS INVISIBLE ON EVERY CLIENT
It was drawn through Shape.CreateLines(), Enfusion's DEBUG drawing interface. That renders in the World Editor and in diagnostic builds, but not on a retail client. The feature never worked in game, not even offline -- it was only ever visible in the World Editor.

Replaced by a map display: outline and alarm ring are drawn on every player's map, green and red while the alarm is active, the ring in yellow. Switchable per zone so a zone can stay hidden.

THE OUTLINE DIFFERED FOR EVERY PLAYER
The map display first built its outline on each machine from the replicated point entities, on the assumption that this yields the same shape everywhere. It does not.

The order of the outline was the creation order of the points -- the order in which their EOnInit fires. On the server that is the order they were placed in. On a client it is the order in which the network layer delivers the entities, which is neither guaranteed nor the same for two clients.

Every player therefore connected the same corners in a different order. Three players, three different shapes, most of them self-crossing.

Worse than the display: the action block tests against that same polygon, so the no-fire rule was full of holes in different places for every player. Damage protection stayed correct -- the server decides that.
Now only the server builds the outline and replicates it, already ordered. The ring width is replicated as well, since the map draws it client-side.

THE OUTLINE ORDER WAS LOST ON SERVER RESTART
With persistence running, the points came back in whatever order the save system restored them -- so the zone reloaded as a different, usually self-crossing shape.

Same root cause as the previous entry, one level deeper: the outline order was the order in which the points were CREATED, and nothing guarantees that order survives anything.

The order is now derived from the positions themselves. Starting at the westernmost point, the chain always continues to the nearest unused one. The same points therefore always produce the same outline -- after a restart, on every client, with nothing stored anywhere.

Limit: where two distant parts of the perimeter come very close, the chain can take a shortcut. The explicit order number on each point still takes priority and is the remedy for such shapes.

THE RING WAS DRAWN WRONG
The alarm ring was produced by offsetting each edge outwards and drawing it as a separate stroke. At larger ring widths that produced a scatter of loose lines instead of an outline.

Now the offset edges are extended to their intersection at every corner. The result is closed and keeps exactly the configured distance along the edges. Very sharp corners are trimmed so no long spikes appear.

The calculation lives in GTG_SafeZoneMath and is shared by the map and the terrain display -- previously there were two copies, and predictably only one of them had been corrected.

DEBUG LINES DISAPPEARED IMMEDIATELY
Shape.CreateLines() returns an object that keeps the line alive. The return value was discarded, so the line was collected in the same frame. Fixed with ShapeFlags.ONCE. Only affects the World Editor, where these lines appear at all.

KNOWN LIMITATION: SETTINGS DO NOT SURVIVE A RESTART

A zone placed in the Game Master keeps its SHAPE across a server restart with persistence -- the outline is rebuilt from the point positions. Its SETTINGS do not: owner, ring width and the rest fall back to the prefab defaults.

The session save does store attribute values per entity, but it reads them from an attribute list defined in a Vanilla config, and this mod adds its settings to the editor at runtime. Injecting them into that list was tried and broke the properties dialog for every entity in the game, so it stays out.

For a permanent zone, build it into the world in the Workbench: the settings sit on the prefab and apply on every start, with nothing to save.

CHANGED
"Draw boundaries" is now "Show on map" and sits under "Display" instead of "Debug". What was a developer tool became a player feature, so it now defaults to ON.

All diagnostic output switched off. The log now carries only the zone build, owner changes and real errors.

CONFIRMED UNCHANGED

Verified on the live server and working:

- outline identical for two clients in different places
- outline unchanged across a server restart with persistence
- alarm replicates in roughly 550 ms
- hold time keeps to the configured 60 s
- forfeiting protection works -- the safeguard against the invulnerable firing position
- infantry weapons blocked inside the zone
- vehicle turrets still fire (known engine limit, mitigated by the forfeit rule)

0.1.11

0.1.10

0.1.9

0.1.8

0.1.7

0.1.6

Fix Client Repllication error for Zone Area Calculation

0.1.5

Updating Game version to 1.8.0.10

0.1.4

================================================================================
GTG Safe Zone -- changes since the first live server test
================================================================================

The first run on a dedicated server surfaced three faults that cannot occur
offline or on a listen server, where the calculating and the displaying machine
are the same. Two of them had a single cause.


--------------------------------------------------------------------------------
FIXED
--------------------------------------------------------------------------------

GAME MASTER SETTINGS NEVER REACHED THE SERVER
    Reported as three separate faults: enemy AI was invulnerable inside the
    zone, weapons were not released on alarm, and the boundary switch did
    nothing.

    It was one. SCR_BaseEditorAttribute decides via a field m_bIsServer
    whether a setting is sent to the server. That field's default value is
    applied by the serialiser -- but our attributes are created with "new", so
    it stayed false and the dialog wrote every change locally only. The server
    therefore never had an owner faction, and without an owner nobody counts
    as an enemy: no alarm, and attackers are protected along with everyone
    else.

    Provable in the logs: the client reported the boundary switch as set while
    the server simultaneously reported the zone had no owner.

    Fixed by overriding IsServer().

A ZONE WITHOUT AN OWNER STAYED SILENT
    The state above is reachable without the bug: "Owner" defaults to
    "Automatic", and if the zone finds no base inside itself it has no owner.
    The consequences look like three different faults but are one.

    The zone now reports this as a warning in the log, including the remedy.
    An explicitly neutral zone stays silent, because there it is intended.

THE BOUNDARY DISPLAY WAS INVISIBLE ON EVERY CLIENT
    It was drawn through Shape.CreateLines(), Enfusion's DEBUG drawing
    interface. That renders in the World Editor and in diagnostic builds, but
    not on a retail client. The feature never worked in game, not even
    offline -- it was only ever visible in the World Editor.

    Replaced by a map display: outline and alarm ring are drawn on every
    player's map, green and red while the alarm is active, the ring in yellow.
    Switchable per zone so a zone can stay hidden.

    No networking is involved: every client builds its outline from the point
    positions anyway.

THE RING WAS DRAWN WRONG
    The alarm ring was produced by offsetting each edge outwards and drawing
    it as a separate stroke. At larger ring widths that produced a scatter of
    loose lines instead of an outline.

    Now the offset edges are extended to their intersection at every corner.
    The result is closed and keeps exactly the configured distance along the
    edges. Very sharp corners are trimmed so no long spikes appear.

    The calculation lives in GTG_SafeZoneMath and is shared by the map and the
    terrain display -- previously there were two copies, and predictably only
    one of them had been corrected.

DEBUG LINES DISAPPEARED IMMEDIATELY
    Shape.CreateLines() returns an object that keeps the line alive. The
    return value was discarded, so the line was collected in the same frame.
    Fixed with ShapeFlags.ONCE. Only affects the World Editor, where these
    lines appear at all.


--------------------------------------------------------------------------------
CHANGED
--------------------------------------------------------------------------------

    "Draw boundaries" is now "Show on map" and sits under "Display" instead of
    "Debug". What was a developer tool became a player feature, so it now
    defaults to ON.

    All diagnostic output switched off. The log now carries only the zone
    build, owner changes and real errors.


--------------------------------------------------------------------------------
CONFIRMED UNCHANGED
--------------------------------------------------------------------------------

Verified on the live server and working:

    outline identical on server and client (13 points, same radius)
    alarm replicates in roughly 550 ms
    hold time keeps to the configured 60 s
    forfeiting protection works -- the safeguard against the invulnerable
        firing position
    infantry weapons blocked inside the zone
    vehicle turrets still fire (known engine limit, mitigated by the forfeit
        rule)

0.1.3

0.1.2

0.1.1

Added: Loggin found 2 Bugs

0.1.0