Mapping API support

[zer0k-z]

Could potientially go through every trigger on map start and gets its entity KVs

[GameChaos]

mapping api ideas:
bhop triggers, antibhop obviously
client-based collision toggling
sv_standable_normal 1.1 trigger

my ramblings about zones:

Start zone:

Timer starts on jumping (or walking out of the zone). This is to prevent too much annoying start zone optimisation.

End zone:

Timer ends when touching it.

Stage / checkpoint / split zones:

Will be triggered by touching.

There are 3 modes for a "checkpoint" zone, which are named differently to prevent ambiguity:

1. Stage zone - Stage zones need to be completed sequentially and every single one needs to be touched to finish the run.
2. Checkpoint zone - Checkpoint zones can be completed in any order and all have to be touched to finish the run.
3. Split zone - Not required to touch any split zones to finish the run. Purely for split times and won't prevent any skips. (Quake 3 Defrag checkpoint zones act like this, pretty useful).

Stage zones and checkpoint zones can be used to prevent skips, split zones are only for comparing time differences.
These different zones can all be used in the same course. Split zones can be used for more granular timing comparison. Stage zones will need to be named sequentially by numbers, but not checkpoint and splits zones.

Zones in game could be differentiated by colour and shape (wireframe vs translucent).

Examples:

Maps like kz_beginnerblock are probably only gonna have split zones, for keeping track of splits (wow!). But obviously could also use stage & checkpoint zones, though there isn't much of a point.
Nonlinear maps like kz_module can use checkpoint zones.
Complex maps like kz_olympus can use stage zones to force a sequential route.

[zer0k-z]

Add trigger volume that will mark every checkpoint made inside this zone with tag(s), that can be used by mapper to selectively delete certain checkpoints. Useful for non linear maps where you don't want the player to cheese by placing checkpoints before the path splits up.

[GameChaos]

i think that would basically be the equivalent of putting an anti-checkpoint trigger in that area, cos if the checkpoints are gonna get deleted anyway, then they should've never existed in the first place if you know what i mean.

[zer0k-z]

Well not quite, they will be deleted once they reach certain spots, but before that it's still possible to make a checkpoint and teleport to it. For instance zxp_interstellar gas mask and tank should wipe all checkpoints made inside that room once touched, but before the player touches it they can still place and go to any checkpoint just fine.

[GameChaos]

an anti-teleport trigger would be much simpler then

[zer0k-z]

If it's just a simple no tp trigger, then it's gonna cause a dilemma for mappers: make the trigger volume too small and the player can just cheese by slightly getting out of it and doing the same thing again, or make it too big and the player is unable to teleport while they should have been able to.

In interstellar it wouldn't work, if you only cover the gas mask zone with anti tp then they will cheese by moving a bit away from the zone, if you cover too much then you will also cover spots that are part of the legit route where the player should be able to use teleport.

[GameChaos]

filters exist

[GameChaos]

to expand a bit more: the problem with tagging checkpoints and maybe deleting them later is also how you would communicate that to the player. when you enter a trigger that tags checkpoints, then would it print in chat "your checkpoints will now be tagged X, they may be deleted later" and when they get deleted: "checkpoints tagged X have been deleted". i think that feels much more confusing than for example in interstellar after getting that key an anti-teleport trigger activates in that room and prints in chat "teleporting has been disabled in this area". i think this requires much less thought from the player about what the heck is happening with their checkpoints.

[zer0k-z]

I'm not sure how filter is supposed to solve it when the two non linear sections have overlapping gameplay. Regardless, communication to the player would be an issue indeed, and forcing the player to keep track of them isn't very fun. A simple trigger that would wipe all checkpoints should be alright though.

[GameChaos]

wiping all checkpoints would work nicely for those situations indeed. it'll be very jarring for the player, but that's fine. the message would be something like "the map has erased all of your checkpoints."

[Betel-Geuser]

Suggestion for the chat message. "erased/deleted/removed" all sound like potential errors. What about "locked"? That also communicates that your CP count is not reduced, just your access those CPs.

entering the no cheese trigger (e.g. after a key grab):
"New zone entered. All previous checkpoints have been locked."

trying to tp immediately after:
*buzz* "You cannot teleport to a locked checkpoint."

[Betel-Geuser]

Also, instead of a separate zone/trigger, this could just be a flag available to the 3 main zone types?

• maps with a central hub, and 4 checkpoints in the corners could simply toggle "lock previous checkpoints" on each one, to prevent the player from tping back to the hub.
• lap based maps like trackmania could use any of these zones (or a new lap zone) to do the same.
• non-linear exploration maps like olympus could use splits zones. Any time you're going to want to wipe checkpoints, is probably going to correspond to a split-worthy event anyway. Like a key grab or a door closing behind you or whatever.

[GameChaos]

Also, instead of a separate zone/trigger, this could just be a flag available to the 3 main zone types?

* maps with a central hub, and 4 _checkpoints_ in the corners could simply toggle "lock previous checkpoints" on each one, to prevent the player from tping back to the hub.

* lap based maps like trackmania could use any of these zones (or a new lap zone) to do the same.

* non-linear exploration maps like olympus could use splits zones. Any time you're going to want to wipe checkpoints, is probably going to correspond to a split-worthy event anyway. Like a key grab or a door closing behind you or whatever.

yup, perfectly doable, i've already got an attribute "system" set up.