I updated my flow yesterday with your new TxQBSP (and RVIS tool), and what a surprise !! Some non understood texture alignement warnings disappear with your TxQBSP new release (there was some r_CuteNodePortal warnings, pointing some textures location out of polys !!!)... I don't know what you exactly did, but it seems to work better with this new version !!

About readme file not included into zip file, I don't think it's a real problem... Downloading some kBytes files is not a big challenge, even with a standard 56k modem... it took approximatively ... 10 seconds at worst... I really it's not able to increase your phone bill, unless you are a little stingy...

Thanks a lot aguirRe..

Bye.. 

I don't know why the latest minor Tx update seems to make such an improvement for you, but I'm glad it did. 

With last TxQBSP, it appeared some r_CuteNodePortal warnings, giving a texture location out of any poly face... so it becomes hard to find from where the problem comes (regarding the read of your Q1ToolTips text file: it comes for sure from a unaligned textures..) The more when QuArK "search holes in map" tool found nothing... (in most of case, QuArK "search holes in map" tool can point up problem sometimes not detected, or not clearly detailed with TxQBSP (like poly unaligned location, or texture unaligned, or others..).. Anyway, trying the new one, these warnings disappear... so that's why I'm rather happy the problem seems to be solved... I will see later if they will reborn later (hoping not)

Bye.. 

warning has nothing to do with textures or their alignment; it's caused by brushes being off-grid or misaligned to each other.

The reason why the coordinates sometimes seem to be in empty space, is because the warning then appears in hulls 1/2, where the brushes are invisibly expanded (see also ToolTips for more info).

To find the culprit, look in the nearby area for non-axial or complex brushes and perform force-to-grid actions on them one by one until you see the warning disappear. It can be a bit cumbersome ...

Also, the QuArK built-in leak detection is not very good; it often finds a leak where there is none or fail to find one that really exists. 

Thx for these precisions... But then, why these warnings disappeared from old TxQBSP version to latest verison ??? Have you an idea ?? 

by old version, previous i.e. 1.07?

The only thing I can think of is that I know QuArK is shuffling all brush faces around within each brush each time you perform a save-load-build sequence. That can affect all kinds of things like warnings/leaks etc.

However, in both my compilers since a long time, I automatically perform a deterministic face sort to avoid these build variations. It can be disabled by using the -nosortface option. Normally I wouldn't recommend using that option.

I know GlassMan had a similar problem in GtkRadiant when building his gmsp3 map. By manipulating a light entity, a leak would appear/disappear nearby. The editor is probably shuffling the brushes/entities around and this can affect build results slightly.

Otherwise I don't really know. 

What Do You Mean by old version, previous i.e. 1.07?

Yes, I used the previous 1.06 one before I updated it yesterday. And I still don't know why it works better now...(??)

By manipulating a light entity, a leak would appear/disappear nearby

Typically, these problems come when complex brush (i.e. staircase maker, arch maker, etc...) exist in the map... It can also appear/disappear with a polygon add/substract... It's again a mysterious work way..

Well, sure you are right in your analysis.. You are too strong man ;-)

Thanks again

Bye 

Hello,

I'm back with my beginner's problem... :) I'm currently mapping a base-based map, and I would like to know how to change the key looks like in the game. When I use keys, they preserve their castle-gothik looks, and I would like a "base key card" look...
So, what is the additional field I have to add in my key description ??

Thanks 

...open map properties and change ambience to base. 

Set worldtype 2 as a worldspawn key.

Stuff like that would be easier if you were using gtk. 

Well, so I need to change the map ambiance property by the worltype field in the worlspawn description
...
Thank you very much, I was looking about item_key properties only, so after a carefull look at

http://www.gamers.org/dEngine/quake/QDP/qmapspec.html

I found what I was a looking for... Thank you very much for your help...

Bye.. 

Please don't be afraid to post, or send me any links like the above that you come across. I like collecting stuff like that, so when I am the last man alive still playing around with Quake I can have as much info as possible at my disposal 

Happy to see you enjoy the link... Just an additional information: this link describes only standard Quake Map Specifications, and many other fields can be added (for example in lights description or worlspawn description, or others...) which are specificly used by BSP / VIS / LIGHT tools... (see light aguirRe's VIS and LIGHT tools for example..) but I'm pretty sure you already know that ;) 

Those of you that are building Q1 maps with terrain generators might have noticed that the player can sometimes get caught on invisible objects while moving close to the terrain.

This is due to limitations in the brush expansion logic for the clipping hulls in qbsp. To get a better understanding of how this logic works, you can enable the -hull 1 option in Tx/TreeQBSP to make hull 1 visible.

Then you'll actually see the protruding objects that the player collides with. You'll probably also notice that some brush designs will produce worse results than others. 

A-ha! ( not the nordic pop band, mind you ) There's an example of this in my terrain map where a steep angular hillside sticks out onto a ledge; there's already limited space to move over to the end of the ledge to get a health pack, and both I and the monsters in the area get fux0red by something sticking way out from the slope.
I'll maybe try -hull 1 and see what's what.
Still can't run a full vis on the thing though, since it estimates over a month in compile time o_O 

and most monsters use hull 1 for collision detection, while e.g. shamblers use hull 2 which is even more expanded (looks really weird).

Making the clipping hulls visible doesn't fix anything but it might help understand why these symptoms occur. There is an option -altexpand to alter the behaviour of the brush expansion logic, but it's a bit controversial and usually doesn't really fix the problem. 

Just a general question... if only large monsters use hull 2 (and the player does not use it at all), would it be possible to remove that hull from a deathmatch-only map and save some space?

Of course the reduction in file size would probably not be significant at all, so I doubt it would be worth it. I don't necessarily want to do it, I just want to know if you <can> (potentially). 

Can covering the offending area in clip brushes sometimes help this problem? 

and now my Quake1 cries with SIGSEV failures... 

This isn't what you wanted to know, but if you did that then you couldn't play the map in DMSP. 

It's pretty hypothetical but yes, in theory it should be possible (if the engine also was changed in a similar way).

Other games (e.g. Hexen2, HL, Q2) has an extra crouching hull so I can't see any obvious reason why it should be impossible to remove the shambler sized hull if there are no shamblers around that can complain.

You wouldn't save much space, though. Especially since DM maps are generally smaller and with less detail to keep r_speeds low. 

Yes, if the clip brushes would completely cover the invisible protruding objects in the hull in question.

The clip brushes get expanded the same way as other solid brushes so if you can't confirm by "feeling" that the the clip brush works, you could use another texture momentarily and build with -hull 1 to visually confirm it.

The main problem with the expansion is that it gets unexpected on complex brush shapes. It's always simple to imagine how a cube is expanded, but pointy triangular shapes that look great in the editor, can grow like cancer in the other hulls. 

I've spent some time looking at the expansion code, trying to solve the strange clipping bugs you guys are talking about. It SEEMS like the code was designed the way it should be, and i wonder if there just isn't some implementation bug. Or, a precision problem?

I never checked out your visible hull stuff, and it would probably help me understand exactly what wrong results the current expansion code is generating.

Anyway, this is one of those things i really wish could be fixed in qbsp, if anyone ever finds the bug or realizes why it doesn't work. 

AFAIK the brush expansion isn't really a "bug" since there's no obvious way to do it without getting protruding parts in some junctions.

Changing this logic is controversial because most experienced Q1 players (not to mention speedrunners) know how a map should "feel" when they see it.

Me and Tyrann have spent a long time spanning several years trying to find the cure for the brush expansion related problems, especially the theoretically impossible leaks in hulls 1/2 (when hull 0 is sealed). Same for the annoying clipping errors; there are a whole list of variants just for them.

I've also contacted XP-Cagey who works with the HL tools and he confirms the problems and it appears that in HL, the situation is even worse. Apparently, he's found some kind of solution (or at least improvement) for HL and I've tried to translate it to Q1 but I've only managed a partial implementation so far (available with the -altexpand option).

Any help or suggestion regarding these problems are welcome, but I've a feeling that the solution might be complex. The whole build process seems to be something of a hazy floating point stochastic (or even chaotic) process, where small changes can have large impact elsewhere. I hope I'm wrong ...

But check out the hull visualization, I think it's a real eye-opener for most mappers (and players too). 

mention that the brush expansion logic is also the reason why I think that e.g. creating a block of natural rock from one multifaced brush is better than several triangular ones that together form that block. Even though there's no difference when looking at it in the editor, the expansion might be different.

The multifaced brush will just expand pretty logically outwards and will not generate any weird protruding objects. The expansion is always done for each brush separately so it won't notice that after expansion, the brushes might not join nicely anymore.

There are probably other aspects of this issue too.