Location System newbie questions...

[nbohr1more]

Alright.

 

This wiki has me puzzled:

 

http://wiki.thedarkmod.com/index.php?title=Location_Settings

 

 

In my mind, the reason for a "Location System" is to establish arbitrary "zones" where "stuff happens".

Yet the wiki demonstrates that the "Location" is mostly a functional equivalent to a "portal-ed area":

 

 

info_locationseparator

 

As I suggested above, you have to mark all the portals leading in and out of a zone by hand. You do this with an entity called a info_locationseparator. Create one so it touches the portal you want as a boundary.

-> Create entity -> Darkmod -> Info -> info_locationseparator

If you don't touch a portal with this entity, than it will not register in the game as the boundary to a new zone, and the zone will continue into the area on the other side of the portal. This happens even if you have a second info_location (described below) on the other side (the game will just pick one and use that for the whole zone). This can be a good thing because, say you have a mansion with 30 portals inside. You can cover the whole area inside it by just marking the 2 or 3 portals leading into the mansion area through the doors and open windows, and everything inside that marked area will be counted as one location (just don't miss marking an exit, or have an un-portaled gap to the outside between brushes, or the location will leak outside. It has to be hermetically sealed).

I have read discussion that a door touching a portal marks it as a location boundary, but in my experiments the door did not create a new location and I still had to use a info_locationseparator over the portal to register it as a boundary.

 

 

What I would like to do is have a region in the middle of an open area that triggers a script when entered or when leaving. Based on how I interpret the above, I would need to enclose this area with a bunch of nodraw brushes or VP's so that the info_locationseparator's will work?

 

Is there a way to create a "free-standing" "location" or must all locations exist in buildings, corridors, tunnels, etc?

[Baddcog]

You just need a trigger brush.

 

When an ai or player steps into it it triggers... won't go into details.

 

But make a cube, add trigger texture to it. right click>create entity...

 

------

The zones are just portal areas that you can customize. A zone can be one area or fifty. The boundry is whatever portal and the info-seperator on it. if a vp doesn't have it then that vp just isn't a border.

 

They are used for sound changes, ambient light changes, etc...

[nbohr1more]

I thought about that but I want something to happen when I enter the region then the reverse to happen when I leave. The "call on entry" and "call on exit" spawnargs dont work with triggers AFAIK. I think that trigger_facing might work for this. If not, I'm gonna need to study S\R for awhile...

[Baddcog]

Have you looked at the trigger descriptions in DR? You might want a trigger_touch:

 

Continuously tests whether other entities are touching and calls a script

function for any such entities.

When active, this trigger is fairly expensive, so use carefully.

 

:if the player is touching it something will happen.

 

Same could probably be done with S&R, probably the same cost.

 

Just put a response on a brush to do whatever it is. Really depends on what you want to achieve.

[demagogue]

Locations were already around in id4 before we made this script to use them. Since the system already checks for them, it's very easy to check if the player or AI are in one of them and trigger something. If you wanted to use the system, you would indeed have to set up portals & separators to make a big "room" you enter and leave, although it doesn't have to be particularly functional. You could just make a few massive portals that spread out into the brushwork and "wall up" the whole area, that don't actually portal anything but only have one job to track when you enter & leave.

 

The alternative like Baddcog says is to use trigger brushes to trigger script_call entities (the old fashioned way), but just note that trigger brushes are a bit fiddley with "location like" things like this (which is why we made the location system in the first place). You want to avoid the player squirming out of the area without triggering the brush. And you don't want a "toggle" situation, but one brush "turns on" your thing, and the other "turns it off".

 

I wrote a wiki entry on it (when the location system itself was done by triggers) that might give you some ideas: http://wiki.thedarkm...ing_triggers%29. It's pretty much for exactly your situation

 

there may be a rare occassion when you want an ambient to start at an area not handled well by an info_location, e.g., because their boundaries are set by portals. But if you can't build a portal where you want the ambient zone to start, you might consider using a trigger brush instead. Then this system will teach you how to do that.

 

Then just make the buttons call whatever event you want. But if it's a simple turn on/turn off, you probably don't need that much detail & can just trigger a script_call directly from the brush.

 

S&R is another route.

[Obsttorte]

Is there a way to create a "free-standing" "location" or must all locations exist in buildings, corridors, tunnels, etc?

Visportals are working if they are surrounded by worldspawn or other visportals. So if you want to have "free-standing" location, you actually only need four visportals that form a cube (or some more dependend on the form of the area you like to have) and, if the visportals don't go to the top of your "room" (whatever may be there), one visportal to close the upper side. Put an info_location inside and seperators in all those visportals, that's it.

 

The only things you should keep in mind is that

• zone function calls (call_on_...) only respond to the player
  
• the functions you call must have the form void functionname(entity zone), where the entity called zone is the actual info_location entity that caused the call
  

Trigger touches are, as said, quite expensive. But unless you don't want to use dozens of them, this should be no problem. Note that trigger_touch reacts to everything. The player, AI, moveables ... . I used it making a trap. The problem is you have to check for the player being in there at the beginning of each function call. And if you lay some moveable inside, the function gets called every frame. This is quite senseless if it should response only to the player anyway.

 

Using stim/response may be a bit tricky. You could use a player response, but you can't adjust the distance and it is also dependend on how good the player is visible IIRC. Adding a custon stim on the player is another way. The problem here is, that you have to find a way to actually get it on the player. Adding stims onto the player start will not work IMHO, as it is only the the point where the player is spawned at map start. You would have to add the stim via script. Quite unhandy and not very error-prone.

 

Summary:

• player-only response: zone system
  
• player/ai response: s/r or maybe trigger_touch
  
• everything: trigger_touch
  

IIRC there is an entity that only checks for certain entities in its bounds, I forgot the name. This may also be used instead of the zone system, although I think the latter is the easiest approach.

Edited January 23, 2013 by Obsttorte

[nbohr1more]

Thanks all. I wish modwiki was not down for maintenance as the search feature doesnt work on wayback archives. So I've settled back on using dummy vp's as Obs suggested. It seems to be the lightest approach unless I can find that mystery entity specifically for this purpose...

[Obsttorte]

The entity you are searching for is trigger_once_entityname, create a brush->right-click create entity

set the spawnarg "entityname" "player1" on it

If you want it to work multiple times use trigger_entityname instead

It will trigger its targets once the player enters

setting the "call" spawnarg allows it calling a function

[grayman]

"trigger_once_entityname / player1" is equivalent to "trigger_once".

 

The "entityname" triggers are there so that entities other than the player, which don't trigger the normal trigger entities, can cause something to happen if they enter one.

[Obsttorte]

Didn't know that.

[DeTeEff]

As we're on the topic, I realized that a trigger_once box is not an optimal solution if you put it at the start of the map for some reason, so the player starts inside the trigger. It will fire several times before "used up"...

[grayman]

As we're on the topic, I realized that a trigger_once box is not an optimal solution if you put it at the start of the map for some reason, so the player starts inside the trigger. It will fire several times before "used up"...

 

Sounds worthy of a bug report, assuming no one's already taken advantage of the bug.

[Obsttorte]

As we're on the topic, I realized that a trigger_once box is not an optimal solution if you put it at the start of the map for some reason, so the player starts inside the trigger. It will fire several times before "used up"...

Wow, I just wanted to test if the trigger_once_entityname behaves the same way. Well, the mission crashed (infinite loop). Definetely something not working right.

 

Anyways, if you want something to be triggered from start it may be a better idea to use "call_once_on_entry" in the start location or use the main method/trigger it from worldspawn.

[grayman]

Or you can trigger it directly from your main() script.

[Baddcog]

depending on what it is, might be best to have the player step into a trigger anyway.

 

A lot of times someone might start up the map but not be ready to play instantly. If something triggers they might miss it... If they have to actually move into a trigger then you know they are present.

[Obsttorte]

but then the player start is not inside the trigger

 

Or you can trigger it directly from your main() script.

[...] or use the main method/trigger it from worldspawn.

[Tels]

Wow, I just wanted to test if the trigger_once_entityname behaves the same way. Well, the mission crashed (infinite loop). Definetely something not working right.

 

Tracker entry please. (Might be related to the message box GUI that asks for a click before the mission starts.)

 

Anyways, if you want something to be triggered from start it may be a better idea to use "call_once_on_entry" in the start location or use the main method/trigger it from worldspawn.

 

Or just put something into the main() routine (if that isn't what you meant by "main method").

[Obsttorte]

Yes, it is.

[Obsttorte]

Tracker entry please. (Might be related to the message box GUI that asks for a click before the mission starts.)

# 3302

[demagogue]

The problem spawning the player inside a trigger brush was something I was dealing with in the pre-release days and another reason I moved over to a location system (unless this is a different & new problem going on). Using the location call_on_entry, or the main() script, or even (IIRC) putting a target on worldspawn or an equivalent method, are all fine ways to trigger something at game start, so it's not very hard to get around it anyway.

[PranQster]

I thought about that but I want something to happen when I enter the region then the reverse to happen when I leave. The "call on entry" and "call on exit" spawnargs dont work with triggers AFAIK. I think that trigger_facing might work for this. If not, I'm gonna need to study S\R for awhile...

 

Try, instead of traditional brushes, to use patches instead. If, for instance, the area you want to enter/exit is circular, then make a patch cylinder. Then clone it and invert the cloned cylinder so the surface is on the inside. Use the appropriate trigger textures, entities etc. and whether they are multi or single trigger. If you are entering through doorways, then just rectangular patches obviously.

The point is that there could be separate triggers to be walked into depending on which direction you are walking. You should not end up lingering "inside" a trigger brush and triggering the wrong one.

I did an experiment where I made a patch cylinder around an AI, with a radius extending several 'yards' out from the AI. Made it a multi trigger entity and bound it to the AI, along with a speaker. If the player go close enough to the AI, from any direction, the AI barked a greeting. So yes, a patch can be used as a trigger.