Couldn't keep my hands of the Sinlevel "Gogre".

Something in the map's layout was puzzling my fantasy in the way the long road stretches out the whole outstreching level.
The ground under it is builed on several layers and gives a very canyon atmosphere.

Converted it to quake and got a nasty pack of homs on my plate but now it fits well.

U 4 = bad 

That archived Worldcraft page Cocerello linked to, while very useful, doesn't say anything about trigger_counter on its func_door and func_button entries either. So without mfx's explanation I would have been lost anyway. Thanks again, mfx!

Also, while said page does have a trigger_counter entry, it lists only three variables, instead of the six mfx listed. Does anyone know of a site that has a complete list of all entities and all variables in Quake (i.e. including the things one cannot find on that Worldcraft page)? 

As said on the func_counter entry, it works on any entities triggering it with the ''target'' field and trigger any trigeareable entity that matches the ''target'' field it has (that includes fun_doors and func_buttons as they are triggeareable).

The variables that webpage has are the ones that were known back in 1996, those that Mfx posted are those that you could see in subsequent years.

About oher sources of information. On the wiki, on the entity list page, on the top part of it, there is a link for an old web with info. Maybe you can fill the gaps with it. 

Yeah, what I mean is that the problem is that the converse information is not there -- if you already know about trigger_counter entities, then that's great.

However if, like me, you just knew about func_door and func_button entities and were trying to get the two to interact in the right way, then there is sadly nothing on either quakewiki.org or on on the The Forge that tells you you should be looking at "trigger_counter". (A simple "see also: trigger counter" would have helped tremendously. As it stands, the entries on The Forge just say "see also: func_door_secret, func_plat" and "see also: trigger_once, trigger_multiple" respectively.)

As for adding the missing information myself (as mfx also suggested), I may very well do so soon, but as I am still currently learning, it would be great if there were a source of up-to-date information I could refer to. Hence my question. 

There is of course always the option of asking in this thread (and people have been incredibly helpful here), but I usually try to figure things out on my own and to use the information that is already on the internet, before posting questions here. 

There are not that many entities. If you're using an editor that shows you the fields then just open it and start plonking entities in to find out what they do.

Some entities are test stuff or only useful in very specific situations, but most do work for something.

All games have their entities built around a structure that can be learned.

It would be nice for 'someone' to update the wiki, and possibly even write some simple tutorials. I'd like to, if I could find the time and energy aside from everything else.

That sort of stuff has existed, but gotten lost over time as websites have been closed or been forgotten. 

total_newbie, yeah, I understand completely why the words "trigger" and "counter" would never have occured to you. I hate having a problem and the only barrier to me finding out how to fix it is that I don't know what it's called, so I have no idea what to google. like you can't learn unless you already know, so your only recourse is making vague hand motions and using words like "thingy."

(there's probably some academic education term for that kind of block, but I don't know what it's called. :P )

The trick to sussing out where a solution will be comes from an understanding of how targets and targetnames behave, and how entities handle them.

Each one is essentially a parameterless "ping." A button sends a ping. A door opens when it receives a ping. You want the door to appear to open only after receiving two pings - to count to two first - but doors only ever respond to single pings at a time. So, you need something in between that can count pings from other sources, and then send its own single ping to the door.

Every entity only really has domain over itself. Any interaction more complex than ping-respond is going to require some kind of flow chart of entities.

Of course, if you don't know that, it's like its own small barrier to finding out. You've got buttons and a door, and each one is a mess of poorly documented spawnflags and keyvalues, so you figured what you wanted was in there, and not some extra middle man entity that isn't visible in game. Everyone else here already knew that you wanted a trigger_counter, but more importantly, they knew that doors only offer complexity and options with regards to how they go up and down, and not when.


I'll plug the quake editing wiki before spirit does: http://quakewiki.org/wiki/Entity_guide 

Other handy shit you might already know so if you do no offense or nothin im just bein thorough:

- If you want to impose a delay between one entity firing its targets, and the targets receiving the message, use a "trigger_relay" in between. Use the 'delay' key.

- If you want something to trigger multiple entities, which already have different targetnames, use a "trigger_relay" for each target entity to map from one targetname to another. Give each relay the same targetname, so one entity can fire them all at once, then give a different target to each one individually.

- A trigger_once is just a trigger_multiple with 'wait' set to -1. Otherwise they're identical. (the spawn code for a trigger_once is literally two lines, "self.wait = -1; trigger_multiple();".)

- a "func_" entity is always visible and brush-based. "trigger_" entities unfortunately aren't so consistent - relay and counter are point entities (because they're activated by a 'ping' so you don't need to touch them), while all the other triggers are non-visible brush entities (because they're activated by touch). (in Quake2 they cleaned that up, and point entities that only served to manage firing targets were prefixed with "target_" instead.)

- You can target a monster at something and he'll fire it when he dies, but if one of them is a path_corner he'll start walking towards it when he spawns.

- Trigger_relays only pass along pings. If you happen to want a monster that does both of the above, you only have one 'target' label to work with. The trigger_relay trick works here, but only for the targets he fires on death. If you try to point a monster at a path_corner through a trigger_relay, he won't "see" the path_corner through the target network. That's one of the rare non-ping-based uses of targetnames.

- Anything that fires a 'target' can also have a 'killtarget' key. At whatever time it would send its 'ping' to its target, it will also find whatever entity has a matching targetname to 'killtarget' and remove it from existence. This is handy for breaking entity connections once the player has done something, because you can 'kill' a trigger_relay and stop the pings from getting through, or kill a trigger_multiple so it no longer fires anything when the player steps into it. An entity doesn't have to have a target to have a killtarget. 

A trigger_relay with both a target and killtarget will not work properly - the killtarget bit won't but the target will.

That's fixed in Quoth I think. 

What? Since when?

looking at the 1.06 progs source right now I don't see anything that would cause that. 

Well, wait, here's something. It makes killtargets work and targets not, though. It breaks out of the entity-finding loop by returning, so if the killtarget loop happens it returns before the target loop is reached.

I did not know that.

(I appear to have fixed that in lunsp2, so apparently I once did know that 

I tripped over it years ago and couldn't remember very well. 

yo, quakewiki.org -> random mapping tips or something? 

going to point out that this is exactly why I wanted to make a compendium of knowledge that covered things like this over a year ago. The Quake Wiki was a compromise.

There needs to be a more firm collection of not only the basics but the nuances of the process or everything will be lost. 

That's cool. Many things need to be but they won't if people just keep pointing out that they need. 

Thank you very much, Lunaran, for those two extensive posts. Most of what you wrote in #14359 were things I did not know, or certainly did not understand as clearly as you explained here.

And thank you, ijed, for that additional tip. 

i wonder if it would be better to just have a way to grab a post in it's entirety, put some tags on it and then throw it in a pile to be searched... 

 

I've made the wiki my homepage to guilt myself into writing something on it.

We'll see what wins - stubbornness or frustration. 

Dunno if its useful, but i stumbled upon this skybox generator. Its online and ... check for yourself.

http://www.nutty.ca/webgl/skygen/ 

 

Using Trenchbroom to create rocky paths and walls ... these verts were all perfect sitting on top of each other. Is this just something I have to accept or should I be snapping all vertices to INTs or what?

https://dl.dropboxusercontent.com/u/161473/Misc/VertexDrift.jpg

(in before FifthElephant tells me he has snap to grid bound to space bar) 

in before FifthElephant tells me he has snap to grid bound to space bar 

I'd like to check that out. Maybe send just the part in the picture. 

I'll work on a solid repro and send that to you. I already fixed that area. I've got drift everywhere now and I'm wondering if I need to burn the boats and start over.

Is it recommended to turn "Force integer plane points" on for maps full of organic shapes? It seemed to do bad things to the brushes when I reloaded the map ... cuts moved into nearby planes and made extra verts on a bunch of brushes.

It's hard to describe.

Maybe I'll just make an interior map with axis aligned walls. :P