Batch Compile Tool - Released!

[qUiCkSiLvEr]

Hello everyone!

----> vbct has been released!

This tool is a compile manager that you can use to compile maps from stock and custom Source mods.

This tool has many features that will lend itself to high-end mappers and yet is simple enough for even beginner mappers to use.

The tool has one big advantage over compiling from within Hammer and that is that the modules are all run asynchronously to the tool so your desktop doesn't freeze up and you can continue to edit or browse or even play games with minimal impact.

Of course it offers a great deal of flexibility and control compared to normal batch files.

You can also immediately launch the game and load the map with one button. I also have a button to launch and load Hammer with the map as well but unfortunately this feature is broken in the SDK right now. If Valve fixes it then I'll update to tool to support it (for now it just launches the SDKLauncher).

The tool has been tested in most Win32 platforms, XP, XP64, Vista, Vista64 and Server 2003.

I think everyone will be very pleased with how simple and yet complete this tool is.

If you are mapping for a custom mod, I've implemented a strategy that will allow you to compile maps for, and run those mods from the tool. If for some reason your compile is not working as expected, or the game won't launch let me know and I'll tell you what you need to do (basically a 1-line fix).

Here are some screenshots and version history, the download link is now enabled:

http://qsextreme.com/vbct

Some additional information:

The tool has a number of options where you can save and restore your preferred settings as a default and on a per-map basis. If you enable it, the tool will load all the settings for a particular map when you select the map.

There is also a full MRU (most recent used) list of files so you don't need to search around for your map files, and in fact you can even drag and drop a vmf onto the desktop icon.

In addition, the tool keeps a history of every time you do a compile and the times in an excel compatible csv format.

There is also a button that will launch the selected mod and autoload the compiled map for you to look at.

In essence, you can load a map and then compile it the way you want in just one or two button clicks and then run the game and look at the result in a third button click, very efficient and very simple.

Although I have error detection in the tool now that will highlight some problem areas, this feature will be an on-going task of improvements since there are literally many dozens of possible classes of errors in each module and they will take very specific test time to fully implement.

I also have some additional work on the vmpi portions (Valve needs to update the SDK for this to fully work). If you have problems compiling maps, especially in Orangebox mods, please don't use the VMPI options.

NOTE: If you run Vista or Win7 and you are having problems with the tool recognizing your selected mod, please download the latest version.

qUiCkSiLvEr

[Kalenzo53]

Hey man thanks let us know when it comes out or post it up and let us play with it!

[lodle]

Any chance you could at network compiling to this. :P

(looks great btw)

[qUiCkSiLvEr]

Originally Posted by lodle

Any chance you could at network compiling to this. :P

(looks great btw)

The tool has complete support for vmpi but Valve will have to fix VMPI in the SDK before it will work reliably.

[slayer89]

Quicksilver, i own you one.

[AkFuttySeben]

Is there any improvements to the actual compiling code?

[qUiCkSiLvEr]

Originally Posted by AkFuttySeben

Is there any improvements to the actual compiling code?

This tool is a front-end manager that uses the SDK modules so the results will be identical to what everyone has now.

Think of this as a user-friendly GUI front-end to the SDK compile tools.

[Spore]

I'm excited about this:

the modules are all run asynchronously to the tool so your desktop doesn't freeze up and you can continue to edit or browse or even play games with minimal impact.

[qUiCkSiLvEr]

I've solved the problem of missing log files from vvis and vrad in vmpi mode so I'm getting a lot closer now. Working on documentation and starting comprehensive testing in all mods and modes now.

It's amusing but I have to make a map that has a collection of virtually every non-fatal error so I can test things heheh.

[Kalenzo53]

I think at this point we've had about enough of your carrot dangling Quick. How about you let us test it for you eh?

Being a quad-core owner, I'd love to see a tool that can process vvis on one core and vrad on another at the same time. Any compiler taking advantage of multiple cores would make me smile.

[qUiCkSiLvEr]

Originally Posted by Fizzter

Being a quad-core owner, I'd love to see a tool that can process vvis on one core and vrad on another at the same time. Any compiler taking advantage of multiple cores would make me smile.

Vvis and Vrad are already multi-threaded and will create threads for all your cpus or you can limit the number so they don't affect other things going on.

As far as running vvis and vrad simultaneously for the same map, that doesn't strike me as too useful a scenario since if you slow down VIS by limiting the cores available you just delay the total compile time regardless.

Better to use all 4 cores and get VIS done and then use all 4 cores and get RAD done. VRAD for EP2 is especially efficient with Yahn's accelerator.

Still, if there is value and a demand to run both vis and rad at the same time I can eventually add in affinity control and simultaneous launch capability. Grabbing simultaneous console outputs will make this scenario a bit unpleasant though.

[lodle]

You cant run vis and rad at the same time. There is a reason they run in order because they need information from the process that ran before it.

[qUiCkSiLvEr]

Originally Posted by lodle

You cant run vis and rad at the same time. There is a reason they run in order because they need information from the process that ran before it.

I just ran a test to see what the differences were (all full compiles):

1. normal compile sequence (1.bsp)
2. vbsp, then vrad then vvis (2.bsp)
compare 1 & 2 = thousands of byte location differences

3. I then took 2.bsp and ran only vrad on it again
compare 1 & 3 = exactly 12 bytes were different

So a very simple test indicates that running vrad on a file before vis indeed is not a good idea.

Can't wait till it comes out I have been in need of one of these
I look forward to using it soon.