[IDEA] trigger state checking / proximity

Issues that were previously reported and since dealt with.
Forum rules
This issue tracker is now in read-only mode. Please see this topic for more information on how to contribute to Red Eclipse.

[IDEA] trigger state checking / proximity

Postby unixfreak » 22 Oct 2014 23:18

As far as i know, there isn't a command to get the current state of a trigger, which can be problematic depending on what you're trying to do. The main issue is with proximity based triggers that do not "reset" when leaving the radius.

Consider this in a map file:
Code: Select all
on_trigger_1 = [ floorcoast 100 ]
on_trigger_2 = [ floorcoast 100 ]
on_trigger_3 = [ floorcoast 5   ]
on_trigger_4 = [ floorcoast 100 ]
on_trigger_5 = [ floorcoast 5   ]
on_trigger_6 = [ floorcoast 5   ]
on_trigger_7 = [ floorcoast 100 ]
on_trigger_8 = [ floorcoast 100 ]
on_trigger_9 = [ floorcoast 100 ]


It would be used to dictate where a patch of ice would be. As you enter the trigger proximity, the floorcoast is set higher so that you slide about on the icy patch. I made a simple concept map attached below.

uf-ice_concept.zip
(43.38 KiB) Downloaded 61 times


The corridor that you spawn in works correctly as all of the exits are surround by triggers, so as you leave the area floorcoast is reset by the corresponding trigger at that exit.

However the issue is with open areas, like the icy patch in the example map, the floorcoast is not reset when leaving the proximity of the trigger (reload the map to reset it, or manually set floorcoast back to 5). It could be interesting for some winter themed maps, and open up other possibilities, like anti-gravity rooms, or gameworld changes in a specified area of a map. Rather than having a problem of trigger spam by creating walls of triggers that surround other triggers, a simpler non-messy option is needed.

My suggestion is to add support for 'else' assigned to the on_trigger_N commands (if possible), at least, for proximity triggers.
For example:
Code: Select all
on_trigger_1 = [ floorcoast 100 ] [ floorcoast 5 ]

So that if a player enters the trigger proximity, floatcoast would be set to 100. When the player leaves the trigger proximity, it changes back to 5. It would then allow for a single trigger to change game world variables on demand without entity spam being a problem.

Also, a question; do gameworld commands inside of a map config (such as floorcoast or gravity) get set for all clients when a single trigger is activated, or just for the player entering the trigger radius? I'm hoping it only changes the gameworld var for a single client, so that those effects of sliding around on ice could be used in multiplayer maps.
User avatar
unixfreak
 
Posts: 224
Joined: 02 Feb 2014 18:47
Location: Bristol, UK

Re: [IDEA] trigger state checking / proximity

Postby SniperGoth » 22 Oct 2014 23:36

You could change gravity with triggers back on 1.3 . But that was considered a bug and was removed.
Quin said some time ago that he could make gravity entities for that matter.
Ex Iron fist level designer/ Ex Revelade Revolution level designer, 3d/2d artist, and still trying to figure out sound design...
User avatar
SniperGoth
 
Posts: 473
Joined: 03 Feb 2014 13:08

Re: [IDEA] trigger state checking / proximity

Postby shirepirate » 22 Oct 2014 23:48

boognish managed to accomplish sliding around on ice in this map (the center part, where the tree is):

christmasdutility.zip
(1.9 MiB) Downloaded 63 times

how exactly he did it i haven't been able to figure out (it only works on that particular texture). maybe it is some legacy thing that was removed from the game, or maybe it's an undocumented command. has nothing to do with a trigger ent though, as far as i can tell.
For every action, there is an equal and opposite reaction. For every freedom, there is a new limit. For every joy, a new sorrow. For every act of kindness, an unspeakable cruelty. Where someone succeeds, someone else fails. A new association means a new separation. Loyalty meets treachery, honor breeds disgrace, free expression yields censorship. Each piece of knowledge forms new ignorance. Even death gives rise to new life. But the balance of existence is the beginning of wisdom and discernment.
User avatar
shirepirate
 
Posts: 704
Joined: 27 Mar 2014 07:20

Re: [IDEA] trigger state checking / proximity

Postby qreeves » 23 Oct 2014 03:06

As I have mentioned previously, triggers are not supposed to modify stuff like this, as they are often done better with alternate methods (which is true in this case especially).

In RE you can define a specific texture as having a modified "coastscale". In your map config, use "texcoastscale" after your texture definition, or "/vcoastscale" in the editor and "/replace" to modify all instances of the currently selected texture. The parameter for this is a floating point value from "0.0" to "1000.0", which is multiplied against the "floorcoast" value for the map. Eg. to get a quarter of the current "floorcoast" use "texcoastscale 0.25".

I might copy this to the SRE thread.
Quinton Reeves | Lead Developer, Red Eclipse
Check Out My YouTube Channel | Leave Me a Tip on PayPal
Contribute to Project Costs via PayPal or Patreon
User avatar
qreeves
Site Admin
 
Posts: 1619
Joined: 02 Feb 2014 05:04
Location: Australia

Re: [IDEA] trigger state checking / proximity

Postby unixfreak » 23 Oct 2014 03:46

qreeves wrote:In RE you can define a specific texture as having a modified "coastscale". In your map config, use "texcoastscale" after your texture definition, or "/vcoastscale" in the editor and "/replace" to modify all instances of the currently selected texture. The parameter for this is a floating point value from "0.0" to "1000.0", which is multiplied against the "floorcoast" value for the map. Eg. to get a quarter of the current "floorcoast" use "texcoastscale 0.25".

Perfect! That's the behaviour i was looking for, didn't know of that.
I always enjoyed playing this map on quake live which made for really fun matches. I'll see if i can make something similar.
User avatar
unixfreak
 
Posts: 224
Joined: 02 Feb 2014 18:47
Location: Bristol, UK


Return to Closed Issues

cron