having such warnings pop up or disappear while changing seemingly unrelated stuff. It can be the editor shuffling things around in the map file or qbsp balancing on the edge due to the float calculations.

Most likely you don't have to worry about it, otherwise check out the position in hull 0 and see if you can find any off-grid vertex. Hulls 1/2 will probably follow a fix for hull 0.

You could also try Tyrann's new qbsp; it has a lot of changed logic that might help. 

No, but if you have the same 1st letter and the same number of letters in your name, then you're the same person ;)

Starbuck is Shambler! 

I just wasted a good hour of my night trying to prove a point, but it was all worth it.

You'll notice that no more than 3 of the "terrain" triangles share any point. You'll also notice that you have the ability to move through some of the brushes, despite the fact that there are no func_illusionary brushes :(

It will eventually compile without those brushes that you can move through if you play with the size and style of the troubled brushes a bit. The .map file is included as well as a .bsp, so have at it.

http://blitz.circa1984.com/terrain.zip

P.S. I suspect that this map file would work flawlessly (i.e. without the move-through-able brushes, in Q2 or Q3) 

You'll notice that no more than 3 of the "terrain" triangles share any point

You'll notice the pertinent inclusion of quotation marks around the word 'terrain' :P

No more than 3 triangles share a vertex because this isn't terrain, it's a path. 

. 

Hey - this solves many of my problems! 

OK, I retract "geometrically impossible", since I admit that you've got some "terrain" here, and that of it's vertexes, none has more than 3 attached triangles. But that's only becuase...

a) I'm a very sweet, lonely guy;
b) "Terrain" is a term flexible enough to encompass not only general solutions to the problem of tiling an area with triangles, but also freaky special cases like this;
c) You're cheating.

PS Nice maplet...especially the trigger_changelevel. :p 

This map compiles perfectly first time with the latest tyr-qbsp. No modifications required. 

Starbuck is Shambler!

Go map. 

Was the point simply to show '3 sharing a point' or were you looking at something else to do with terrain?

I have more than a passing interest in building terrain so am keen to learn anything even if it's not everything. 

You mean it compiles without the messed up brushes? 

Yup. 

This is mapping related...

I am writing a compiler GUI in VB6 as the one within my editor (BspEditor) is a bit long in the tooth and has only a very, very few options: it mainly works off batch files.

Can anyone tell me if, when I save a map just before compiling, that file information (specifically the file's path) is held anywhere in the Windows environment AND could be extracted/used by a stand alone VB6 program? A sort of this-was-the-last-file-saved variable.

I realise that I could 'hard code' something or let the user (me) select the current map from a CommonDialog1.ShowOpen command, but the editor has a save-before-compile option, which I always use. Also, as I save versions of the current map, I am looking for a way to automatically pass this information to the GUI compiler - or, more correctly, let the VB6 program 'grab' the file information from somewhere.

I know a little bit about VB6 and very little about Windows OS.

I hope this makes sense.

Your suggestions will be appreciated. 

That could be tricky, since only BSP knows where it saved the map and if it doesn't store this info immediately in the bsp.ini file, I doubt you can pull it out. This info is probably only updated when BSP exits.

AFAIK there's no "last saved file" var in the Windows environment (wouldn't make much sense anyway as files are saved pretty often asynchronously).

Is your frontend completely stand-alone or is it called from BSP at compile time? In the latter case maybe BSP could pass the path in the call. 

I can't find any files that BspEditor saves immediately other than the batch file that BspBuilder uses. I know that BspBuild is written in VB6 but looking at the history of the two programs, it seems as though Yahn B. and Tony B. co-operated on this point: BspEditor has a BspBuild option built-in so passing the data across would not have been difficult (but at present, I don't know how).

To answer your last point, my program is written as a stand alone .exe. However, BspEditor has the BspBuild option, and if I put my .exe in the same directory as BspBuild and rename it BspBuid, I can run my program from within BspEditor. And I wanted to use the the editor in this way to ensure that I always compiled the latest version of the .map.

Of course, I could do all this from outside of BspEditor, and in fact this was the original intention. But in testing, I realised that everytime that I wanted to increase the version number of the current map in the editor, I would have to update my compiler routines. It's not that it's difficult, but there is a 'nuisance' element and, knowing me, likely to be forgotten if I have to do it manually. And the result of that is that I will compile an older version of the map without realising it!

At present, my thoughts are; I know the directory where the .map file is stored, and I know that it has just been saved, so I could look at each file in that directory in turn and use the file with the most recent time stamp - no hard-coding and reasonably foolproof. But it adds to the time factor.

I am trying not to hard-code any directory information i.e. have not, but I do save all current selections to an .ini file and that gets loaded as a start position each time the program is run (I don't want to use the registry). Generally I am only working on one map at a time and during the course of (say) two hours mapping, will compile three or four times. I do not change the options much in that time.

You've seen the GUI, it's only a case of clicking check boxes and selecting the relavent directories and again, these do not change much. Also, if run as a stand-alone program, I do not have to exit the program: it can sit on the task bar until I want to compile again. If I run it from BspEditor I will have to exit and close it to avoid having many versions of the program running. Each of these scenarios has benefits.

Mmmm, bit of a long post again, sorry guys. 

I expect BspEditor is passing the name of the map file as an argument to the BspBuild program. This should be easy to test (VB must have some argc, argv equivalent). I don't think that there's any communication between the two programs after BspBuild is launched, so BspBuild won't pick up a change in the map's filename if you re-save the map in BspEditor with a different name. Myself, I always use batch files. 

Looking at the batch files supplied with BspEditor, the file name is passed to the different statements by the DOS variable %1. Perhaps that might work?

Slight pause....

Nope, didn't work.

Tyrann, what are argc and argv? 

are the commandline parameters passed to the executable, a la "-heapsize 48000". In VB the string of parameters typed in after an executable is called Command. Type Command in your VB code, highlight it and hit F1 for more details. You could use this and your mock BspBuild executable to test for any commandline arguments being passed from the BspEditor. 

Thanks for that.

The map name is indeed being passed from BspEditor to BspBuild in this way and I can now read it.

What a very helpful forum this is :-) 

I am glad I have finally made a significant contribution to someone around here :) 

at http://user.tninet.se/~xir870k . All engines are updated with many features/fixes, Light includes a new skill target check and Tx/TreeQBSP includes new clip hull code by Tyrann, especially beneficial for terrain maps. Please also see readmes for details.

Any comments are welcome. 

The clip hull fix in these (also in tyrann's latest compiler) is awesome -- not just for terrain maps, but also for maps where you have lots of miter joints, hollow pipes that bend, crazy spog-like cylinder stuff, etc. 

That using these new compilers, Marcher's #clipnodes dropped from around 32k, to 25k.

I'm tempted to restore all the stuff I had to chop out in the release version o_O 

. 

I've been using BspEditor for about 6 or 7 years and have just found out today that holding CTRL and LEFTCLICK allows you to rotate a brush in the map view in real time. And the degree of movement is shown on screen as you move the brush.

Up until now I've been using the RotateBrush button - you know, nudge it 5 degrees have a look; no, not quite right, nudge another 5 degrees have another look; no, still not right...

Obviously therefore, my next map will have plenty of leaning crates, haphazardly abandoned bricks, fallen beams etc :-)

Just thought I'd share...