... do whatever you think is cool... And you end up in a 2 month fullvis map :P 

I dunno. I guess I'm of the mind that you have to keep evaluating your 'return on investment'. A map that takes 2 months to VIS isn't necessarily 60 times better than a map that takes a day. It may just be built wrong. 

I agree that lack of skill or knowledge is the bottleneck for people who start mapping. Even people who have been doing it for years could be making things more difficult for themselves without them ever knowing. That's why it is a shame that so many websites dedicated to map making are disappearing. 

ID's Quake was great, but what these people have made is so much better
bear in mind that id's levels was made ~95/96, do you remember, any custom levels of such quality those years? 

If I build a map and people enjoy it, that's my return on investment (your pleasure is my pleasure, in a non-kinky way). I map for fun, not for money. My computer is not a 'resource', it's a hobby.

Sixty hour vis times is fine by me, I'll be doing plenty of other things in the foreground. So, time is not the issue: impatience might be. 

*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. 

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? 

 

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