I meant DKT BSP files, which TexMex can't seem to open :\

I have the original DKT WAL files but Wally doesn't like their format :\

So far the only solution is to convert them to BMP with Daiwal and use some other batch software to convert them to TGA. I downloaded Advanced Batch Converter but it only does 6 images at a time in demo mode :\

I can send you the WALs if you likey :) 

How much is the total amount compressed (7-zip, rar or zip in that preferred order)? Can you upload it somewhere and offer a link?

If you want to batch convert pics, I can recommend IrfanView ( http://www.irfanview.com ), it's small, free and very good at batch conversion. XnView is another pretty good free pic viewer/converter. 

~50MB zipped w/o removing any redundant files from the 47 folders.

I will try to break them up into bite-sized chunks and email(?) them to you -- probably not until next week though ;)

I will also give IrfanView a go. Cheers for the link. 

but via email might be problematic, even split up (e.g. account limits). Since binary data is encoded, it will also be much bigger as email attachments.

Best thing would be if you could upload it somewhere and offer a link. That way other people could also get it while it's up. But if you can't, we'll try the email variant. 

Two problems. One compiling, and one running my map.

BSP and VIS seem to run fine. Light crashes at startup after printing the following:

1686 entities read, 1318 are lights, 29578 faces, 3.6G casts
4 switchable light styles

That is a lot of lights, but it's worked fine until now.

When I try to run the map in fitzquake, it crashes. When I try Aguire's engine I get the following error:

Mod_SetParent: excessive tree depth in maps/current.bsp

The BSP stats of the map are now as follows:

11437 planes 228740
36809 vertexes 441708
16595 nodes 398280
3945 texinfo 157800
29578 faces 591560
32985 clipnodes 263880
7389 leafs 206892
35419 marksurfaces 70838
132081 surfedges 528324
67155 edges 268620
87 textures 1258432

VIS gave some nasty sounding numbers, but no warning:

average leafs visible: 149
max leafs visible: 522 near (384 960 -615)
c_chains: 28770619
visdatasize: 156 kb compressed from 1090 kb

I realise that I have exceeded marksurfs and clipnodes. The clipnodes can be reduced easily, but I don't want to start doing that yet unless it is the cause of this problem. I exceeded marksurfs before, with no errors.

Please help!

Note: After previewing my post I noticed that VIS has given me a coordinate for Max leafs visible. Is this the problem? Is the limit 512? 

couldn't you upload to quaddicted?

And if you compress using rar - multiple copies of same texture doesn't take any extra space since it uses compression between files too, unlike zip. (It can also chop up nicely.) 

I put in that error check to prevent bsps with corrupt node trees from generating an engine stack fault (which is probably why Fitz crashes). It indicates that the bsp node tree is too deeply nested.

The amount of nodes and leafs from your printout is not over any limit yet, so either the bsp has become corrupt somehow, your map is too complex or I'll have to increase the tree depth limit (currently 4096 and 8192 seems to generate stack fault).

I'll need the zipped bsp to investigate further. Btw, which qbsp/vis/light versions are you using?

The RVis max leafs printout is not a warning or error; just to help you locate the spot where many leafs are visible from and thus is likely to be slow in-game. 

The tools I am using are mainly Tyrann's, since I never had any problems with them (except Tyrlite) and so I am only using your light. I will try your other utils tonight, after I make some more adjustments to the area that possibly caused the problem.

Why do you think light crashed? Is there a max number of lights (surely it is impossible to cross that line).

If I can't get things working by tomorrow morning, I will send you the zipped bsp. Cheers for offering to help =] 

Since Light also loads the bsp node tree to do raytracing (check point-to-point visibility), it'll probably crash for the same reason; stack overflow. I haven't put that check into Light yet, my engines have the most robust file loading code.

Yes, please check with my TxQBSP to see if there's any difference. You shouldn't need to run vis/light before loading the bsp into the engine, as they don't touch the bsp node tree. 

I blocked up a window in a lift shaft and it fixed the problem. The same lift shaft has got some serious visibility issues (well, the r_speeds go to around 1300 when you ride it because I can't get it to split horizontally and the rooms at the bottom and middle are both visible at once), so I am not surprised it helped. I am going to be working away on this area tonight, so if it fucks up again tomorrow I'll mention it. Fingers crossed. 

your vis program does not compile the level. I get this error:

************ ERROR ************
LoadPortals: portalleafs 5692 exceed bsp leafs 3281

This was using your modified treeqbsp.

Tyrann's rvis+ seems to be handling it fine using the same bsp'd map I tried with your vis. It also works with Tyrann's qbsp.

Note that I have not seen any visual problems with the map recently, and it seems to work fine in all respects (aside from the recent compile problems).

The map is compiling happily now, hopefully it will finish without fucking up. 

You've repeatedly asked for help with more or less odd questions or bug reports regarding my tools or engines.

Each time I've tried to figure out what you're doing and each time I've asked for some material so I can investigate what happens. Each time you've "fixed" it yourself and each time you've refused to send me the material I've asked for.

Maybe you should actually do the right thing now? I need the zipped map+wad to be able to reproduce the problems you describe. 

you're right. Sorry.

I've encountered another problem now. Light isn't working. I will send the .map and wad :) 

I think I've found the culprit; the remove_skip utility trashes this bsp, probably because it's so big. This causes subsequent tools/engines to fail. More info in email. 

just a thought
how would it look if i made the weapons and pickup markers a litle higher just above the ground and such the smallest i could make them?
and also make them look abit more alike in general not based on the ground that they are in 

for some reason quake crashes when the player touches a specific info_notnull trigger, while the other notnulls work fine.
what does this error message mean:
http://www.negative.net.tc/quake00.jpg ? 

sorry for tbhe drunk email and also drunkness evident in this post. I will compile the map sans remove skip, but do you think that some kind of remove skip functionality could be implemented into your tools in the future? It would be reallt great if you could add that. xxx ;) 

The function you are trying to call with the notnull tries to precache a sound, but this is only allowed in the entity spawn functions that are called when the level starts.
Only functions that don't contain any calls to any of the precache functions can be used by the notnulls. 

I'm on a shitty connection and too lazy to search... What r_speeds would you consider ok for a new map? About 800-900 seems to be nice to me (yes, I just read nico's posts about the "new huge maps"). Yes, I finally decided to map and No, it's a small and not outdoor level. :) 

thanks.
again, i was too hasty posting that without proper searching/thinking.
it was indeed a sounds field i forgot to remove (even though on a different notnull). 

I would also like to see skip support implemented in qbsp. The current utility is fairly rough and doesn't really delete the polygons from the bsp file, only references to them. (I believe it simply reorders the marksurfaces list, and then shortens the marksurface count for each leaf so that the last few surfaces occur after the "last" marksurface.)

It's been a while since I looked at it, but I remember having to change the rendering in fitzquake .80 to fix the problem of skipped polygons being rendered in .75 :) 

The other advantage of course is that true surface removal would actually reduce lightmap usage, while the current method does not. 

if it is implemented better, should it also be renamed caulk, since that's what it's called in the Q3 engine, and skip is something else...?

�_� 

Metl's explanation is right and yes, the tool is very rough. It would be nice to redo the util properly (and call it caulk this time), but I don't think I'm going to find time to do it anytime soon. 

it's illegal to use q4 textures in d3?