News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Sorry I Lagged Out 
thanks for the teleport help guys, ill try it out. sorry for the lag outs. wernt sure if my messages got through so i posted twice for save keeping. ima go try out these suggetions :D thanks alot 
Ricky 
I'd love the kingpin set and maybe the ikblue... I'd love tons of them to be honest, but those two sound pretty inspiring right now. Thanks, dude! 
OK, Gimme A Little While....... 
(at work) 
OK Success!!! 
That was very hacky!

Yeah - for some strange reason IKBlue wouldnt convert because of two or one weird files within the wad. I had to remove a rather cool door texture (like 8 triangular wedges with symboly on it) and the pallette file to get it to convert.

As for the kingpin textures - well that wouldnt convert and it wouldnt say why! So what I did was open Wally (good old buggy Wally) and make a new package, a half life package (to which it attributes the file extension ".wad" rather than ".hlwad"), than I opened the kingpin .wad in wally, manually select all of the textures (using the left hand index column of Wally), copy them. Then go back into the new package, paste all of the files in. Then I saved this new package.
When I went to the directory through windows to view my new wad, it appeared as a 0Kb file, but when I copied it into another folder it came up as being 23Mb. Then all I did was rename the file from "kpin.wad" to "kpin.hlwad" using windows rename function (right click on file, click rename). Then I tried to load it into Worldcraft and it worked!! Job done!

Weird and annoying NOTE:
First I tried to do this on Windows Vista. Putting the original ikblue and kingpin wads in my worldcraft\textures\ DIR then loading WC brings up the all_wads_to_hlwad tool on startup. In Vista it calls an error for each wad, but wont show any details of either errors. In Windows XP it calls out the error for texuture No. 51, which atleast helped me identify which texture it was causing the problem. I used Wally to remove the bad texture and pallette file and it worked as normal.
But even under XP there was no detailed error report for the kingpin texture.

So in conclusion Drew I would recommend the following method in future:

1 - find your wads of choice

2 - open a copy of Wally: http://www.quaddicted.com/tools/wally_155b.exe

3 - open your first wad to convert

4 - click on "file-> new-> Half Life Package (wad3) (wad)"

7 - when the new empty wad file is opened, go back to the quake wad you are converting, select all of the files using the left hand index column, then drag and drop them into the new package.

8 - save your new package as normal, wherever you want.

9 - close Wally, and navigate to the folder with the new wad inside. Rename the new wad to "title.hlwad"

10 - Go and make a cup of tea! :P

PS - I will email you my results shortly! :) 
Another Question 
ever since i started compling maps ive noticed I cant even see my hud in the quake(I use the ezquake client). did it fuck up my resolution somehow? i mean my resolution is 800 x 600 like its alwayus been. but now part of the console drifts away and flickering where my hud should be. that happens on all hud types, 'classic' 'new' 'combined' and so on. PLEASE can someone help? 
Well 
+ and - make the HUD bigger or smaller, but I doubt that's the problem.

What engine are you using? 
 
ezquake is for Quakeworld. Use Fitzquake for singleplayer: http://www.celephais.net/fitzquake/ 
Well 
the thing is ive always used ezquake for singleplayer before and it only JUST started happening when i began compiling maps. idk what could have gone wrong. its hard to describe. i cant see my HUD, usually whatever i was previously looking at(such as console) fills that in... if you know what i mean, how if you ever float outside a map that kinda thing happens. its relaly really annoying and its completely fucked up my HUD. no idea how to fix it. but yeah ive ALWAYS used Ezquake for everything and its been just fine up until now 
Great 
thanks! 
Ilovequake: 
maybe try gl_clear 0? 
Hmmmmmm 
that makes it a black box with only the numbers shwoing up and other small things where my hud should be ... very very strange................ 
Tools 
My current map is breaking my compile tools in bad ways so I was thinking of upgrading to some better ones. Are these the best available?

http://user.tninet.se/~xir870k/

And, if so, am I looking for Tx/TreeQBSP or "Enhanced versions of RVis, Light & BspInfo"? Which tools are guys using for large maps currently? 
Both 
And use Tx instead of Tree. 
 
Are you sure? The TX has an older release date than Tree. What's the difference/problem with Tree? 
 
Afaik, aguirRe once mentioned that Tx is the preferable one because of the tjunc calculation (which Tree apparently lacks). 
Yeah 
Your looking in the right place! TxQBSP is proabably considered to be the best (fastest, most stable, extended limits, enhanced bug and error reporting etc, etc, etc). Infact AguirRes light and vis tools are also awesome - the light tool has some fantastic features, and it can even emulate other modified light tools, as well as giving the most hi-res lightmaps for Quake that I think are currently possible!

All Hail AguirRe!! (Mr Yardrup for those who dont know him as AguirRe)

Only problem for you will be running them on OSX, Mac thingeymajig... I think they're all Win32 applications, designed for use with Windows XP.

Seriously though, the TxQBSP is a godsend - used it to compile horrible maps like Sickbase, which were full of errors. 
/me Shows His Amateurish Colours 
 
Hmm 
Yeh, but I'm sure you can use Wine or some other VM on Mac to run the tools fine. And it's not like there's a viable Mac native alternative... 
Alternatively 
Compile them yourself? 
 
He includes source code. I'll convert them to Mac (it's usually just a bunch of warnings that need cleaning up as the id tools are written in portable C) and replace the ones inside of my level editor with those. I remember asking him about that a long time ago and he was cool with it... 
Hmm 
Aaah, I wasn't aware it was that easy to cross-platform compile. Lack of GUI/anything except proprietery math I guess.

But yeh, if it's that simple then that'd blatantly work... 
 
Didn't stevenaus, lazy_bum or gb port aguirre's qbsp and light to linux? That would be a start. 
 
http://www.quaddicted.com/tools/bjptools_linux.zip

I hope that is the latest version.

Willem, some stuff is dependant on Windows system calls, although Bengt always said that he tried to avoid that. The wildcard support in wad names for example. So for convenience I simply cut that.

Treeqbsp was easier to port than Txqbsp. Whatever, I don't have problems with tree - quite the contrary.

If you port Txqbsp, I would be interested in the source. I'd also be interested to know if the current stuff compiles on a Mac.

I planned to multithread the vis using your code, but haven't done so yet due to my whole life being absorbed by that bloated monster over there that was once an innocent little project.

I also want to implement origin brush support, since I seem to be the last man standing on that front, but haven't done so for the same reasons.

Anyway, if you do something, can you upload the source somewhere plz? 
 
It's also a c/c++ mixture so I use g++ to compile, even for the C files. There is some compiler option that makes it possible, look in the makefile plz. 
 
Yeah, I'll do what I did last time ... I'll create XCode projects for the tools and then I can set flags and all that junk pretty easily. Shouldn't be an issue although if there is Windows specific stuff now that will take a little longer. Still, shouldn't be a problem. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.