News | Forum | People | FAQ | Links | Search | Register | Log in
Q1 Tools Update June 2006
at . All engines are updated with many features/fixes, e.g. selectable texture quality and server protocol, running "fullscreen" in a window and a number of visual glitches corrected.

Engines have now also higher model capacity and more warnings for e.g. excessive QC stack requirements or brush entities with missing brushes. There are also more possibilities to reduce CPU load with only minor performance loss, useful when having cooling problems, saving batteries or just reducing fan noise.

RVis, Light and BspInfo have many more bsp validations and some minor fixes. ConvDem can now limit # entities in a demo (to make it playable in engines with lower limits). Please see readmes for details and there's also a new ToolTips version.

Any comments are welcome.
It's hard to find something to say about tools and utilities except that AguirRe's tools page is invaluable.

I added a link to the page in the QuakeOne tools download section. 
your tools are great, but I would really love to see you implement native skip texture removal support into bsp - even if it was just the removal of the texture from solidents and not the worldspawn, this would be awesome.

Would it be difficult to remove faces from brushmodels? I have never seen problems occuring with Tyrann's tool when only removing faces from bmodels BUT it doesn't support maps with more than 32768 faces :( 
Not Entirely Related: 
Would it be totally insane to visualise the compile process so you could actualy see it cut up the space and all other things that is done? Natually it would result in at least a little bit longer compile times and there might be hard to show what's going on in any remotely educational way. 
Baker: Thanks!

than: Nothing planned atm.

bear: I'm sure it's possible, but I can't imagine how much work that would require or how much slower it would be. In QuArK, you can load the finished prt file and inspect how the portals are distributed in the map.

However, it's pretty slow and very hard to make anything out of in a big map. You can use it to identify portal intensive areas, though. 
What would we do without you! Thanks a lot for great work! 
Good Going, AguiRe, 
I'll be playing around with these tonight to see what else you have stirred in the pot. 
sounds pretty fucking cool actually.

Don't think I will be making a switch, since I plan to make even fewer Quake maps after QExpo so that I have time to do other things, but it might warrant an investigation. 
You can view the portal file in Radiant, its pretty fast and the visualisation, while naturally confusing at times due to the nature of what is being displaying, is still pretty enlightening. At the very least, it can tell you at a glance if the file is very good or very bad. :D

Just use the prtview plugin, by default it will specify the .prt file for the current map, with the path and filename set up assuming it is in the same directory as the .map file, you can override this path and filename if you wish though. 
ohh i�m not a mapper iet but i like a lot your tool�s :) good work! 
ohh i�m not a mapper iet but i like a lot your tool�s

That's what she said.
func_group parsing on BSP stage plz plz ( so they just get moved back to world)

and dont point me to the java thing 
If it was added, you'd need to make it a compiler option, and probably off by default. Some mods might feature brush entities called func_group, and the ability to compile maps for these mods shouldn't be compromised. 
Ever considered making versions for linux? 
Nope, I don't have any *nix here. I think I recall someone mentioned having porting some of my tools to *nix, though. 
Rexroom / AguirRe 
Recompiling the code source (provided in each release if I remeber well) sounds to be the easiest way to build your own Linux executable.. isn't it ? 
Don't they work easily with Wine? 
Wine sucks: we use it at office in order to work with MicroSoft Office tools under Linux (word, excel, etc..). And it is slow as hell !!!
I think you would not get any advantage to launch a vis process with wine, as it slows down process (remember it is a additional layer above Linux that "emulate" Windows). IMHO it is preferable to recompile it for your Linux / Unix environment... ;P 
You could use VMWare to run Linux within a virtual machine from a running Windows session. This way you would be able to do Linux development without having to screw around with multiboots and whatnot, it works very well. 
actually the tools work very well under wine. Wine may suck for a lot of stuff, but you can get quite a lot of simpler stuff to work well. I've used it for AquirRe's tools, texmex, wally, and other little non game related nick nacks, and it has worked fine, and not slow at all. 
I have myriad *ix machines here, lemme know if you would like a developer account. I'd like to see these tools become as multiplatform as possible. 
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.