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
Heh 
There is no editor similar to Quark. And for good reasons.
Give the most popular ones a try and see which one you initially feel most comfortable with. 
:\ 
when I tried WC was like starting with chinese language... :| 
Heh - I Felt The Same Way About Quark 
IF you look in the help tab in Worldcraft you will find a really good simple tutorial that will get you started. 
 
i'd stay away from WC if you're new to it. it barely runs on modern systems and it's just really weird to use it.
i find hammer 3.3 much slower in general for general brushwork and i don't imagine WC 1.6 is any better. the constant need to shift+key to switch modes just to add entities or do texturing is a huge time sink.

if you're already comfortable using it and such, then this post isn't aimed at you. i'm mostly talking about people who are considering using a new editor.

i'm of course biased towards sikk's QE3/radiant, so take all that with a grain of salt. :) 
Moore's Law 
Doubling the number of transistors in a CPU makes Quark run 50% slower :P

I'm in the same boat as you, Trinca. Seriously, I never had a problem with it on my pentium 100 in '97, but somehow on a 2.3 ghz cpu it struggles to run. I guess my maps are bigger now.. but it's gotta go after I finish my current project. 
 
Try some editors and see what you like... the worldcrafts, the Radiants, BSP... Toe Tag if you're on a Mac...

personally, radiant made me map 300% faster and better. Like switching from a rusty kitchen knife to a scalpel... 
Yeah - Toe Tag 
I wish there was a Windows port of that. It looked awesome. Anyone still in touch with Willem BTW? I miss him :D 
He Spends Time 
over on Worldofleveldesign.com forums - much less drama over there. Goes by ... I forget what name he uses. 
His Blog Is Here 
Texture Lump Size Too Big? 
Hello all

Been working some more on a Quake 1 mod and I've got an error that crashes Light.exe

LoadBSPFile: Texture lump size 2103368 too big (max = 2097152)

I was wondering what can be done about this, the mod is more a TC so it has a lot of textures, I would be okay ditching all of the id1 textures if it means I can make more textures (I am not done making all of the new ones I need by far)

any info would be helpful.

Thank you all! 
 
iirc, that sounds like you have too many textures in your map. basically you need to reduce the total size to less than the max (~2mb) so just remove/replace lesser used textures with others, or reduce the size of textures. 
Are There Modded Build Tools? 
Ah, thats a bummer

Just wondering since the game will end up using Darkplaces engine, are there any modded build tools that can maybe increase the size above 2mb? Game doesn't have to be Winquake friendly ect.

Thank you for your help so far 
Are You Using Bengt Jardrup's Tools? 
I think they're currently the best. Not sure if it will help with this error though.

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

There are modded versions of his vis/light with multithreading and colored light support:
vis: http://celephais.net/board/view_thread.php?id=60365&start=93
light: http://celephais.net/board/view_thread.php?id=60480&start=35 
 
use aguirre's tools, his are the most advanced compilers out there. they will compile maps right up to the max that can be done with the .bsp format.

or rather, use his qbsp. for light, use MH's modified version of aguirre's light: http://www.quaketastic.com/upload/files/tools/windows/BengtLightColouredR2.zip
it has coloured light support and multi-threading.

and for vis, use tuna's fixed version of willem's modified version of aguirre's vis (hehe...)
http://www.quaddicted.com/tools/wvis_20100119.7z
which likewise enables multi-threading (and fixes the bug with the vis progress saving) 
 
BJP's qbsps have a -hilimit switch to enable extreme capacity. This may be worth a try, though probably not solve the texture lump problem. If you can't reduce their number/size (considered grouping several similar textures into one?), and are aiming at DP anyway, you can use the Q3 map format and compile the map with hmap2. This way the map will have external textures which should bypass the texture lump issue. 
Wow. 
 
Neg 
aguirre's (BJP) qbsp already has > 2mb tex lump capacity.

also, i've never been able to get -hilimit to work.
i mean, it compiles and whatever, but no engines can load the map. not even aguirre's engine. :P 
I Use -hilimit 
I need -hilimit. Without it my map wont compile. My map runs in Fitz .85 (and its children), Darkplaces, Aguire-Quake etc. When you hit the vertex limit weird stuff happens. The map will compile, but DP and Fitz&co no longer run it, and AguirRe's invincible, un-crashable engine will run it but you get artefacts in the form of giant flickering polygons all over the place. 
Moral Of Story: 
Dont break the vertex limit of 65### whatever it is. 
I've Used -hilimit 
I think -hilimit merely allows the map to compile, it doesn't magically make engines support the resulting bsp. I used it to exceed 32k leafs I think, and it worked for that test. Not sure if you need it even to exceed marksurfaces though. 
Right 
that's really all i meant. i mean, what's the use of compiling a bsp that can't load in anything at all. :P 
 
Probably aguirre hoped that engines would add support once there were bsps to test it on. At least, he added a lot of support to his engine. Sounds like he didn't get to everything though. 
My Map Runs Fine On Engines As Long As I Keep The Verts Below 
The 65thousandish mark. But I started to need the -hilimit command way back when it was only 40'000 or something. If -hilimit wasn't there, really large maps would be a no-no. 
Odd 
i have a map that is right at the 65k vertex mark, but the other things are either below or very close as well, hence why i felt -hilimit was completely useless.

must be in the way the map is made that makes other things balloon up faster than vertices. 
 
How much does the openess of an area affect VIS time? If an area is huge but low on detail does VIS time still get hit really bad? 
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.