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

if you split a brush in half, but the texture is the same and the sides are still coplanar, will they be split in game or will they be recombined by qbsp?

ie: you're using two sides of a brush for a wall, but one side has trim and the other doesn't, the trim side will obviously be split because the texture will be different, but what about the other side that has the same textures on both new faces? 

My next map will also have leaning crates, haphazardly abandoned bricks, and fallen beams, but unlike Mike it will not be on purpose. :( 

In general, they will be rejoined by QBSP if they are coplanar, have the same texture, and have the same texture stretch, shift, and rotation.

However, if you're just making a column in the middle of a room and split it horizontally so it has a cap with trim on one face, then it's quite possible that QBSP would go ahead and split all the other sides of the column, too. 

Marcher: The Compiler's Cut 

This is a shot of Marcher's geometry in hull 1 using the original brush expansion logic:

http://img214.exs.cx/img214/4742/oldhull1ri.jpg

This is the same area, in hull 1, using the new brush expansion:

http://img222.exs.cx/img222/4244/newhull9co.jpg

'nuff said o_O 

Thanks to aguirRe for the above screenshots :D 

I've tested last week a "beta" release of aguirRe's new TxQBSP tool, and I noticed some improvement in VIS process.
Accordig to aguirRe, it seems it was pure coincidence, but.. I'm not convinced... so I just would like to know if anybody noticed this kind of effect ?
I saw that with this new expansion logic, VIS runtime process was reduced... For long process, winning some few percents for the "base start value" is a real gain in global runtime... So anyone noticed something equivalent ? 

bloody hell! 

... 'kin' 'ell! 

Hmm. Surprisingly, that second one actually looks like it's built correctly by QBSP. Who'd have thunk it?