. 

Will try it as soon as possible,
thanks for the hint!

using several world.qc documents made my Quake engine somehow drunk... 

Hi!

I just got GTKRadiant 1.4 working the other day, and I'm using texmex for textures. There's one problem I've ran into. When I export textures from .wads the *water/*slime/*lava textures etc are renamed to #water/#slime/#lava because you cant use * in filenames.

Naturally when I compile the map the compiler cant find any #water texture in the wad cause its called *water there. Any suggestions?

And btw, isn't it time soon to make a new mappinghelp thread? I only refresh this thread every time I go to take a shit, cause it takes an age to load. No broadband. 

use proper wadconverter that will convert all the wads to tga and back:
http://www.orbiter-productions.com/alchemy/#qonverge

and use proper mapconverter which u can get here:
http://rem.fov120.com/rem/projects.projectDetails.action?id=3

and kay, log in properly, in this case you'll see only new posts. go to account section and register there... 

Necros, it worked...
many thanx from a spacewalker! 

Kay: use gtkradiant spogbranch, it doesnt require you to convert the textures to tga 

Would it be possible to modify a light util to create higher res lightmaps for surfaces? I understand the lightmaps are currently generated on a 1:1 ratio to texture resolution, would it be possible to increase that to a user specified ratio such as 3:1 4:1 etc... ?? 

To do that, you would at the very least need compiler support (light.exe) and engine support.

To make it a per-surface property (like in medal of honor and other games) you'd need editor and qbsp support, too.

However, a hack that would work in most custom engines is to build the map with HIGH-res textures, with texture scale set to 0.5 or something, and then include LOW-res .tga replacements. This would effectively increase the lightmap resolution.

P.S. Lightmaps are at a 1:16 resolution to textures, not 1:1. 

well no wonder no-one has done it already then... :)

Would be great if it did become possible though, re-lighting all my old maps to see the changes would be very cool. 

At 1:1 ratio would not every pixel in the textures be sampled in, and would not any ratio level above that be redundant? Just my guess (hey, those old tutorials on flip-code have to sink in somewhere). 

when i say 1:16 i mean that one lightmap sample covers a 16x16 texel area. 

is it possible to create an invalid shape just by using the clipping tool on a block? i've made this simple torch holder shape just by clipping (no vertex manip or rotation or anything). it looks fine in the editor, but is curiously warped ingame.

also, hammer doesn't report it as invalid either, which is odd, considering quake clearly deforms it as if it were. 

try moving it out of the wall to 1 unit (it shouldn't touch wall i mean) 

thanks, i just tried that. unfortunately it's still warped.

basically, i just took a block, clipped two corners off in the x/y plane and then clipped it in the y/z plane so it had a sloped top.

actually, it's not really a problem as far as my map is concerned; i'm quite happy to leave it as it is - the only thing that bothers me is that i don't understand why quake sees it as an invalid brush. maybe i should split it into triangles to be safe? 

well, when using the clipper tool, if you make the vertices not be on the grid, this will cause problems for the compiler. a good trick to see if the brush is going to be ok or not is to simply move it back and forth a bit. gtkr seems to check if the brush being moved is good or not and corrects faults if it finds them, so after you clipped and or vertex manip, just give the brush a nudge.

there's also a plugin that comes with gtkr, i think that fixes brushes...
in plugins->bobtoolz->brush cleanup it will fix all brushes, and select them, so you can see what changes were made... be careful, because it really will fix everything, even brushes you thought were fine. ;)
i now do this often, it gets rid of a lot of funny qbsp warnings like duplicate planes and others like that. 

damn, i can't believe that didn't occur to me.

hammer doesn't seem to have the same sort of vertex correction that you mention gtkr having. i copied/pasted a few of my torch holders around and they all had the same bad shape.

anyway, thanks for your help guys. i have now solved the problem :) 

I've sent you three emails regarding your ne_lend_q1 map without any reply. If you don't reply I can't proceed troubleshooting it since I need more data/info. 

i've replied both times now...
isn't your email: bengt -dot- jardrup -at- ebox -dot- tninet -dot- se?
that's what i've been replying too...

i'll try again right now... 

I'll check if the progs.dat helps reproducing the crash and then I'll get back to you. 

With this progs.dat I also get the error if I use Fitz/TyrQuake, with my new engine it doesn't happen.

The cause seems to be an excessively large message between client and host at startup and I've already increased that limit in my version because of trouble in other maps.

I can see that something called prespawn is about to execute or to be sent and this overflows the message size (8000).

My guess is that there's too much going on at startup time, e.g. too many spawning entities. Is it possible to delay some of the entities so all don't spawn simultaneously?

I've also tracked backwards to the QC code for the monster_egypt and if I put in a return statement just before the setmodel call, the map loads fine. If I move the return to after the setmodel call, I get the same error message again.

Does this make any sense to you or offer any hint what to do? 

i'm not quite sure...
it sounds like all you are doing by placing the return; before the setmodel is stopping the monster_egypt from starting up... so that would certainly cut down on the amount of stuff getting started.

i do know that there is a delay of random amount that gets set for each monster before it gets setup is already present in the code... i'll see if maybe spawning the monsters in manually (ie: going through the startup sequence of model setting and such) will help that.

thanks for the info. i really wish i knew how to do engine coding. :P 

that there's a difference in that I still get the error message even if I return right after the setmodel and before the walkmonster_start call.

The actual call to setmodel is what triggers the error. Could something be wrong with the ne_egypt.mdl or is it just that including it becomes too much for the engine? 

i think it's just that there are a lot of monsters, so with the added setmodeling of the other monsters is what pushes the engine over the edge, so to speak...

have you tried doing return; on other monsters?

i don't see what could be wrong with the model though, it was straight from the DoE expansion with only a reskinning, and it worked fine for that pack (and was used again in SoE, i think? or was that OuM?) and plus i've had him working before in test maps, earlier versions of the map, etc...

i think it's just quake choking on so many setmodel calls. 

a return at the same spot for any of the Ogre, DeathKnight or Shambler will also do the trick. It certainly looks like it's the total sum of them all that pushes the message size and thereby engine over the edge. 

used a modified version of the zer spawn code, so that way it sets model only when needed (ie when spawned) theoretically, this should allow ridiculous amounts of monsters... hmmmmm ;)