News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
*shrug* Sure, to each his own. I obviously map for fun -- why else would I be making Quake maps? There's no money in it. 
Well 
I'm working on id1 remixes now and I find that everything gets slightly bigger - the originals feel very crampt by todays standards.

I tend to add lots more areas as well - my e3m3 is now around twoce the size but started off with a similar layout. I add the extra stuff just because it's fun to have.

A load of times in the id1 maps I'll come up to a dead end or a room just begging for expansion, and can't stop myself. Because it's fun :)

Still fullvising in under an hour in the above example. 
 
Haha, of course, I get the map sealed and a full VIS takes 3 minutes. WTF? 
See? You Got All Worked Up Over Nothing 
 
 
if a trigger_multiple killtarget's itself, is that the same as a remove() in a touch function? o.o 
Necros: 
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 
Necros: 
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. 
Necros: 
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? 
Seems 
to be the case unless there are special engines used or summat. 
Thought 
the squad shadow by making an object above the sky is the same issue. 
Aenoch: 
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... 
Dimensions / Metrics ... 
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. 
Willem ... 
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 
8 Units = 1 Foot ... 
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. 
Willem ... 
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. 
Willem ... 
Ahhh ... now it makes sense. Thanks for clearing that up.

-Mic 
It'sa Perception Thing 
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. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.