if a trigger_multiple killtarget's itself, is that the same as a remove() in a touch function? o.o 

killtarget is better because it sets the think function to SUB_Remove, which happens safely in the next think frame. If you remove() in a touch function it happens immediately, which could screw up the linked list of edicts, which can crash the engine. 

thanks for explaining the difference :)

now an even weirder question:

is it ok to build outside the 4096 boundaries if the player is never supposed to get there?

i know from past experience that the visual component of the map will be visible if it's outside the 4096 cube. the only thing that's bad is that the moment the player's pov passes outside, he seems to 'loop' back to the other side.

but the actual collision will still be correct, it just looks as if you're on the other side of the map.

so if i built a sort of skybox (brushbox? o.0) outside the 4096 as pure decoration and clipped the boundaries of the playable area, would it break anything? i've never tried making a full map with a lot of brushwork outside the boundaries, just usually it's a few stray brushes because i was careless. :P 

it's something i've thought of doing too -- should work, as long as the player or entities or anything else but world brushes stay inside teh bounds (e.g. if you shoot a rocket out past the bounds, it will look pretty funny.

If entities/effects/sounds etc go outside the bounds, the only issue really is that they will be rendered in the wrong place. Server-side physics and movement and and stuff will still work fine.

Anyway, you could make a pretty cool horizon/vista out past the bounds, like a cityscape or mountains or whatever. 

excellent! i wanted to make sure there weren't any kind of hidden engine glitches that would crop up.
there's still maybe a matter with vis.exe calculations? i don't know if it cares or not whether the pvs' it's calculating are within any boundaries or not. 

well, it's fairly untested ground, so there are no guarantees, but as far as i know, the only thing enforcing a +-4096 limit is the network protocol, so everything else should theoretically work with the larger space. 

well, i decided to try it out, so i guess we'll see. o.o

i guess the good thing about it being purely decorative is that if it doesn't work, it's just a matter of deleting it without impacting gameplay. 

So if you go beyond the 4096 boundary do you come out the other side like in Pac-Man? 

to be the case unless there are special engines used or summat. 

the squad shadow by making an object above the sky is the same issue. 

Yes, but it's a purely visual thing, your actual location on the server does not wrap around -- just the coordinates sent to the client. 

Are you sure about that? If you jump off an unsealed level and loop a few times, you can still land on the level itself and have proper collision which would imply that you are, in fact, wrapping around in terms of your coordinates... 

Hi,

Does anyone have any information on the metrics / dimensions used for the Quake world ?

I'd like to understand what each unit represents and how big fixed size entities are, in terms of real world application.

Thanks

-Mic 

I've heard it's 8 Quake units is a foot, but I don't know for sure. I just fool around until it looks right. 

It was actually ToeTag that prompted this question as I was wondering what size the grid squares represented and how you knew what size to draw the 'fixed-size' entities etc

-Mic 

Yep, just found confirmation on this page ...

http://toolz.nexuizninjaz.com/shader/shader/section2.htm

Unders the measurements section.

Will now work to this scale.

Thanks

-Mic 

Well, the entity sizes are specified in the .QC files and the models and things that are read in are automatically scaled correctly since the entire editor runs in Quake coordinate space. 

Thanks for pointing me to the .qc files ... that'll come in handy.

You see that's where I get confused, you said above 'I just fool around until it looks right' but now you say 'models and things that are read in are automatically scaled correctly since the entire editor runs in Quake coordinate space' so in order for that to happen you must use some sort of measure/unit size ?

-Mic 

It's a 1:1 mapping. 1 unit inside of a model file is 1 grid unit. That doesn't relate to the real world, it's just how it's mapped within the editor. I use the same scale as Quake which, internally, is 1 unit is 1 grid unit. 

Ahhh ... now it makes sense. Thanks for clearing that up.

-Mic 

8 units = 1 foot doesn't literally translate. The player is 56 units which would equal 7 feet, and can jump 32 units which would be 4 feet.

Even then if you create a room 80 X 80 and spawn in it, it doesn't 'feel' like a 10' x 10' room. 

 

Indeed, if you're asking what I think you are then the answer is 'it's irrelevant'.

The units in Quake don't really translate that well into 'real' units of measurement. It's just an arbitary unit. What you seem to want to know is standard sizes, in which case;

128 units is standard for a medium/small corridor width. It's also the standard height of a floor/storey (ie, there'll be 128 units from floor to ceiling).

64 units is a thin corridor or a large crate.

16 units is the height of a step.

Of course, a lot of these, such as floor height/corridor width can be expanded/contracted depending on the size of room wanted, I'd suggest finding the source files for some maps and having a look at the scale of them in editor (I know Vondur releases all of his, as do various other mappers...) 

Also you can determine in game by some of the textures used the size of a room since most textures are either 64 or 128, unless they were scaled.