JPL: no, it's quakish :P

I forgot to mention, even though it doesn't have hardware support, the texture view is pretty precise and in combination with the (admittedly extremely slow) polygon mode, which let's you align multiple textures on different planes by visual offset, allows for very neat texture work.

gb: I never use texture locking though. I hate how it changes every face to some strange values even if you just move the brush slightly. If you have slanted faces or rotations, it totally screws up the aligning. I often pressed it by accident only to find out later on when a good chunk of the map suddenly looked borked. 

I often pressed it by accident only to find out later on when a good chunk of the map suddenly looked borked.

Haha, I know that :-)

I use texture locking for crates etc. when I copy-paste them. It seems to work for me. Anyway, the face mode (texture alignment) is rather comfortable, so doing it manually isn't too bad. But when I have 20 crates it gets tedious.

I was SO glad when I found out how to set spawnflags and targetname for multiple entities at once. ^^ The 3D view is rather comfortable I think, I do most things in that. Like selecting brushes and faces. Even copy and paste.

I haven't found out how the group stuff works, do you ever use that neg!ke? Does it let you hide or copy and paste groups? 

Yes, groups are useful in large maps with complicated brushwork or if there's a considerable amount of DM/SP-only stuff. ALT+G opens the group window. Select some brushes (or entities), press ALT+G and "create group". You can change their colors and hide them. Not sure about copy/paste.

Btw. you can align multiple faces in the same plane with the regular face edit window. It always uses the texture and settings of the last selected face. 

See here: http://quest-ed.sourceforge.net/doc/manual/questdoc.html

If you flag "s", selecting one brush from the particular group will automatically select all its brushes (then c/p). 

Useful stuff. So creating groups works like creating models. 

Cool shots - SP or DM in mind? 

pf_precache_model: overflow

-> segfault...

bspinfo says I have 211 models, is that already too much? Isn't 256 the limit?

I could use some help here, I'm stuck until this is resolved. 

The brush drawing feature sounds pretty cool. Don't think I'll be picking up any new editors though, since I'm too comfortable with wc.

PS - nice shots, as always. 

dude, that balcony looks badass. 

BspInfo only tells you about the brush models (e.g. doors) in the bsp, it doesn't count all the alias models (e.g. monsters) that in the engine will be added from QC.

So already 211 brush models is pretty much and apparently is enough to put you over the limit. With my engines, you can see how many models that are required.

I've just also noticed that the limit is 256 for precached models, but only 255 for sounds due to a bug in the server code. 

Is there a document that explains what are the maximal limit values in quake, like edicts, maxsurfedge, maxmarksurface, entities, etc... ? 

Presumably the 256th model wouldn't ever display in game, as it would have modelindex 0, which is the invisible model... 

...I started one ages ago, but each time I got close to putting it out someone released a new engine that changed the previous limits :) Some engines have remained stable with respect to some limits I suppose... 

gb: You can save some brush models by e.g. turning all individual func_walls of room into one large entity (if visibility permits it) and trigger_counters as well as trigger_teleports in monster cabinets into point entities.

JPL, distrans: The standard engine limits are listed in the glquake-bjp readme. 

Thanks a lot for the information: I'll check it right now ! 

Thanks, AguirRe. That makes sense.

It appears my rotating lift alone contains 133 "bmodels", 132 of which are func_movewalls.

Another problem with rotating stuff... all those movewalls will rapidly increase the brush model count. And it looks like they need to be brush models and not point entities.

Think about this: A normal rotating door might have 8 or 12 movewalls, plus the door bmodel(s). Four of those could already add 50 bmodels... then I tried to make all crates in the map breakable, which apparently is not a good idea at all... 20 more bmodels... that's 70... and then I have this sucker of a rotating lift cabin. ^^ All this is not counting the monsters.

So it's rather easy to have over 200 bmodels like that. You live, you learn.

Neg!ke, thanks for the tip with the point entities. I use the Quoth spawning already though, so I don't even have monster trigger_teleports. I'm not even using func_walls yet, but that sure sounds useful.

This map has only 5 rooms and some corridors yet, btw. and only 6 or 8 monsters already placed. And wham, it breaks the model limit. ^^

Good opportunity to learn how to creatively save entities without being too obvious, I guess...

this game gets more and more interesting... 

Is there a way in standard quake to make a teleport that teleports only monsters but not the player? 

...oh good, there is a list of the standard limits. Might be useful at some stage...ta mate! 

I have recently completed a Q1SP map, which has roughly 20,000 portals. It is hence taking a very long time to VIS -level four it. Is 20,000 portals much larger than a normal map, and if so, what can I do to remedy it?

Thanks. 

Make some complex things func_wall entities?

Make sure complex geometry doesn't see other complex geometry (curved or dogleg corridors..)

Send a fast-vised or non-vised version to some mapper for testing. 

Basically, either reduce visibility via level design (90 degree corners, etc), or reduce the polygon count (make trim flush with walls rather than sticking out, func_walls, etc).

There's really no magic to VIS, just lots of tedious work. :) 

How goes the vis project with the map I sent you Willem? 

Yes, 20k portals is very big, with older vis tools you wouldn't even be able to vis it at all, make sure to use an enhanced vis that can handle it (mine does and I think Tyrann's works, too).

Also, make sure to use a modern qbsp that doesn't create bogus prt files with a huge amount of portals, all wrong. Again, mine and Tyrann's should do.

For more info about improving vis times, see my ToolTips doc. 

"How goes the vis project with the map I sent you Willem?"

My interest sort of petered out there, sorry. I got caught up in other stuff but thanks for sending it along anyway! 

Yup, mine has 20000 portals, too. Fastvis is bearable, fullvis is ... not nice.

Both Tyrann's and Lord Havoc's tools can handle it. So should AguirRe's.

I'll not do that again, though :-)

Question: Do any Q1 tools support Hint brushes?

Question 2: Do sky brushes block vis the same way that normal brushes do?