I think in terms of approximation, 1 foot equalling 8 units is about right.

7ft for the player doesn't sound to outlandish. Dolph Lundgren stands about 6ft 6in and I would have expected the player to be about the same physique as him.

And I would also expect someone of this physique to be able to jump about 4 feet.

-Mic 

The reason I'm asking for this is because I'm currently working on an .skp (Google SketchUp) -> .map converter, but the maps when loaded after conversion are too small because SU works in inches & feet and 1 foot doesn't map to 1 Quake unit. Therefore I need some sort of scale to work with.

-Mic 

If you jump off an unsealed level and loop a few times, you can still land on the level itself and have proper collision

this actually isn't the case. if you loop around, the geometry is drawn as if you had looped, but everything is non solid and monsters cannot attack you, even though they look as if they are able to.
any geometry that goes beyond the boundary though, will be solid to you when you loop over. but it won't be visible.

it's like the client is running on floats but the server is running with doubles. 

maybe this is for hl/hl2, but i believe they do 1 unit = 1 inch which works out good for like stair heights and such, but i think the quake player is shorter than the hl2 player. 

even shrter than the q2 guy 

necros

Oh yeah? Weird, I could swear I remember doing that but maybe I never actually tried it. 

it's like the client is running on floats but the server is running with doubles.

Literally, the server is using floats and the nework protocol sends them as 16-bit fixed-point numbers, with 13 bits for the integer part, and 3 bits for the fractional part (so the smallest representable difference is 1/8 of a unit, and the largest possible value is 4095.875) The client converts them back into floats, but of course you've already lost the extra range at that point. 

you can see this 1/8 thing if you stand on a slope (like the beginning of e1m1) and zoom in on the wall nearby. As you slowly slide, your view ratchets forwards and downwards in noticable increments.

When working on protocol 666, i tried various techniques to add range to the coordinate system without increasing packet size. They were all very complicated and still made packets bigger. The simplest is just to always send floats, but this makes packets much bigger and I didn't want to pollute the protocol that way (as it is now, the packet sizes are about the same as 15 until you need to send special data like alpha, 2-byte modelindex, etc.)

I still have plans to support this in the future, I just wanted to get a functional version out and that requires locking down the feature set at some point.

The packet size limit is the toughest part, and there's not much I can do about it (but I should add a cvar so you can attempt larger packets on a LAN, which might have higher MTU than the internet at large.) 

angles are another thing where the precision is incredibly low.

the hanging corpses that slowly rotate in quoth are animated in the mdl because the engine's angles round to like, nearest 5/360th instead of nearest 1/360th degree. when you start doing rotating brushes, and the brushes are large (or are placed far from the origin) it can get incredibly ugly with this gigantic gaps between rotations.

it would be nice to beef up whatever handles angles if possible. 

protocol 666 does have high precision client angles (so aiming your gun is accurate) but not on rotations for entities.

I noticed the problem with hanging corpses but I thought the rotation was a model animation (so they could be static ents) rather than entity rotation. I guess that's a good feature to add to the next protocol.

Though, It seems like something that mappers/modders should avoid relying on, otherwise you'll have the huge ugly bmodel rotations you talk about happening in all other stock engines. I had this problem with a rotate train in rubicon2 and the fix was to spawn it near the world origin. 

maximum distance a player can jump without falling into water, lava, or traps
225 units

maximum distance a player can jump straight up and get up to another object:
42.5 units

maximum distance a player can fall and not be injured:
275 units

minimum gap in the floor spacing, slatted bridge or floating squares of lava:
35 units

maximum height that a step can be before a player must jump:
17 units 

What is a unit ?
I always have trouble making lifts go the right distance, most of it I guess and then adjust.
When you speak of units, how do they relate to the grid in Worldcraft ? 

(makes "shoot myself in the head signal")

FFS, its just been repeatedly explained not a couple of posts previously (like yesterday)

1:1, one grid unit = 1 unit, one 1:1-texture-pixel 

After researching this more, I have come across the Quake Editing Primer at ...

http://gamers.org/dEngine/quake/QDP/QPrimer.html

... which suggests 1 Quake unit is about 3cm or 1 foot is approx 10 Quake units.

This seems to make more sense now, especially with what others posters have suggested above.

The only thing that still puzzles me is the standard height of a step being 16 units. At 8 units equalling 1 foot, 16 units or 2 foot is far to high I feel, and although 1.6 foot (using 10 units per foot) is getting nearer the mark, I feel this is still too high.

5 ft 6 for the player size, and an 80 x 80 room equalling 8ft x 8ft rather than 10ft by 10ft perhaps seems more reasonable.

What do you guys think ?

-Mic 

It also suggests that vertical and horizontal scales are different ...

Vertically : 1 unit = 3cm, 10 units = 1 ft
Horizontally: 1 unit = 2cm, 16 units = 1 ft

-Mic 

I always had the impression 64 units roughly corresponded to 1 meter. Then 16 unit steps would be about 20-25cm which kind of makes sense for the world. The scale for entities is totally different, though.

In the end, it's no use translating RL scale to Quake units - the dimensions of the environment isn't determined by logic, just by the textures. 

The scale in Quake is shot: a 16 unit step/stair just doesn't look right with a player model next to it and larger monsters look ridiculously small when viewed from above. Go with what feels right and don't get too caught up in the unit conversions. 

" the dimensions of the environment isn't determined by logic, just by the textures."

^^ This. Just work with it until it feels right. 

It's a matter of perception. Do what looks/feels right, and adjust from there. 

... to players size, that is 16 units tall if I remember well :) 

When you're dealing with dimensions/proportions in a game engine, you're almost always going to have problems if you try to rely on exact conversion numbers and translation of stuff directly from the Real World.

In FP games in particular, the camera height and FOV are going to differ at least a bit (and often significantly) from what you're used to seeing in real life, so some things will feel right and some won't.

And then there's the problem of stuff being on a small flat screen, rather than actually being in front of you... 

there is a limit after all to how far out you can build. it appears to be 8192 (doubles?) where, anything after that just doesn't draw. 

Hmm, I guess there are probably some client functions that assume the original bounds. For example:

- the far clipping plane

- the skybox size

- the trace vector used to light entities based on floor lighting (was 2000 units in original quake, now 8192 in fitzquake) 

you guys ever go back and play some of your really old stuff?
i was playing nesp09 and i discovered my lame sense of humour hasn't changed at all. 

i guess what i was really driving at was: do you enjoy your own maps after sufficient time has passed that some or most of it is almost like new?