found something interesting out about the hipnotic rotating stuff.

had never noticed this before, but you can attach ANY entity to a func_rotating_*

as long as the entity's targetname matches the target field of the func_rotating_*, that entity's origin will be continuously updated to match the position and angles of the rotater. i haven't tried, but i suspect it may not work with bmodels because of the way quake handles those, but point entities (even monsters o.0) work.

i was able to build a func_rotating_train which had torches attached to it as it moved about.

the effect is kind of ruined if the rotater actually does rotate though, because the angles of the child entities aren't updated, only their positions. 

clip brushes would help with BSP times as it's already telling BSP what areas to not put hulls. Some of the best ways to avoid high vis times is to avoid small brushes, huge open areas, and overly complex geometry (which is boring to me.)

I've never really understood the entire fretting about vis time other than your giving up use of your machine while vis takes place. Why should it matter if it takes 1 hour or 1 day as long as the map has good game play, is built properly, and looks great?

Most people playing these maps aren't wondering how long it took to Vis. They're having fun hopefully. 

Detail brushes have existed in Quake (1) for a long time.

http://quest-ed.sourceforge.net/files/mapc/qutils_2_src.zip
http://quake.chaoticbox.com/downloads/equakeutils.sit

It's a pity they've never been incorporated into more modern compilers, because they really do work to cut down vis times. I used pOx's eUtils quite a bit back in the dark days of mac quake editing. They even have nifty features the Quest tools don't, like non-solid detail brushes. So you can have your func_walls and func_illusionaries, but they still cast shadows etc. 

The problem is that, these days, people are making maps that don't so much take days to fullvis as weeks.

It wouldn't be so bad if this trend wasn't utterly unnecessary... 

I've ever made has taken more than ~5 hours to compile.

Someone's about to post a warp map compile of 6 hours to prove me a liar.

Remember that this is a mapping forum, on the mapping help thread - this is the place where we complain about vis times. 

In reaction to post #8797 posted by Lardarse:

Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ?

If you look at the work of people like Ijed, Tronyn, CZG, Necros, Kona and Kell(to name a few of the best ever), it's almost all huge. And I like it.

ID's Quake was great, but what these people have made is so much better. Better even than all the crap games you can buy in the stores these days. Works of art that inspire people like me to try and come close to, even without having all the knowledge that they've got. 

The size of the map shouldn't matter though. Proper construction and respecting the engine should result in reasonable VIS times. If you build a gigantic football field with bleachers, well, yeah, that will take forever to VIS but in my mind that isn't proper construction.

You can build a large map and still have VIS be reasonable.

Having said that, my current map is going to be a bastard once it's sealed. I've committed a lot of VIS sins and I know the VIS gods will punish me for it. 

"Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ? "

A map the size of an id1 map that was nicely detailed and well put together would be well received I think. You couldn't duplicate the originals and get away with it anymore but that size of map isn't necessarily a problem, IMO. 

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