oh and awesome news re: the shadow issue - cheers :) 

Mapping Help, Post #15623:
@dumptruck_ds I got a hack for qbsp that seems to fix the DP lighting issues in your map. Here is a test build: http://quakespasm.ericwa.com/job/tyrutils-ericw/

(I just added rounding for the bsp texture vectors, the same algorithm that is used for points - if a value is within 0.0001 of an integer, round it to that integer. It's not a proper fix but it seems to work decently well.)

Ericw, I can't find where I downloaded this test build, do you still have this?

Also, I found possibly a bug...maybe with JACK(hammer). When I compile I get a string of warnings:
line 11: Unrecognised string escape - U
line 11: Unrecognised string escape - J
line 11: Unrecognised string escape - D
line 11: Unrecognised string escape - Q

These correspond to letters in the directory path after slashes in the .map file JACK generates. For instance: "C:/Users/Josiah/Dropbox/QUAKE..." Compiler thinks they are escape characters like newline n<q/> for instance. The map still compiles, it's just annoying to have warnings. 

re: Darkplaces Lighting Fix: that stuff is in the most recent release (v0.15.5) at: http://ericwa.github.io/tyrutils-ericw/

Are you still having corrupt lightmaps in DP with this version? In my experience it only happens occasionally on faces with weird texture alignment (e.g. sheared texture). e.g. a few faces in ad_crucial.bsp from Arcane Dimensions have corrupt lightmaps in DP.

about the escape sequences warning, yeah, it's confusing... I should probably just suppress the warning for the "wad" key of worldspawn. 

there's nothing wrong with "c:/foo/bar/naff.wad".
there IS a problem with "c:\foo\bar\naff.wad" because that contains a new line and two dodgy chars.
"c:\\foo\\bar\\naff.wad" is fine of course, just ugly and specific to windows.
there's an even bigger problem with "c:\foo\bar\" because that string isn't even terminated properly. And yes, I have seen that in maps, and yes it does screw things over, and yes I hate the idea of getting the engine to do special things just because of the name of the field.
Its common enough that a terser and more specific warning would make sense, but I'd personally prefer if everyone just started using string markup consistently instead of varying depending on arbitrary field names.
Idealism can suck sometimes. 

I had a quick look at the winquake source.. these are my 2 cents:

- Double-quote characters can't be escaped, whatsoever (COM_Parse). Winquake, DP, FTE all fail with parse errors if a trigger_once's "message" string is "foo\"bar"

- The only escape sequence recognized by vanilla is \n, which gets converted to a newline character. (ED_NewString). Otherwise, the backslash and next character are left as-is.


Writing paths like "wad" "c:\foo\bar\naff.wad" would only be dodgy if the engine/gamecode needed to use them. Everyone uses forward-slashes for paths meant to be read by the engine/QC though ("noise" "sounds/nnnn.wav", etc.)

"wad" "c:\foo\" is not a problem because double quotes can't be escaped. A trigger_once with "message" "foo\" works fine in winquake, DP, and FTE (though FTE centerprints foo" instead of foo\ )

What would be a real problem is a wad path with double quotes in the directory/filename.. apparently that is forbidden on Windows, but OS X seems to permit it. Anyway, if anyone tries that, qbsp would fail to parse the .map file. 

How about making the compiler replace the backslash character with a forward slash, in the "wad" field only? 

I always wondered why it couldn't just check the relative Quake path for any wads or just require that the wads be located in a specific folder. 

enginewise, the biggest issue is that saved games and maps share parsing code. So double-quotes, new lines, carrage returns, and double-backslashes need to be saved, and thus also need to be reloaded. Otherwise mods will break - or at least mods designed for engines that can actually do string manipulation, anyway.

Whether that's consistent with winquake is somewhat irrelevant from my perspective - as you say, the only place backslashes would ever really be used in a map is in the wad key, or before an 'n'.
I'm personally okay with FTE breaking compat from winquake to ensure saved games work, so long as embedded chars are rare and don't corrupt other strings.

small correction:
FTE's entity parsing is actually performed by qclib's misleadingly named QCC_COM_Parse - which includes consistent escapes and a special hack for "c:\foo\"<NEWLINE> in an attempt to prevent the map from being unusable.
This is why you get foo" instead of foo\ - because FTE saw an escaped double-quote.

The wad field *IS* parsed by engines in the case of halflife bsps, where named wad files may be required for external textures. The paths are ignored (absolute paths are a definite no in something that has been shipped/released), but if they arn't escaped properly then wads starting with an n will still get messed up (clients with download mechanisms might also attempt to download such wads from servers). Additionally, fte can load .maps directly, although wad handling there is curently kinda screwed up thanks to replacement images overriding things and confusing sizes.

@mankrip, really its the editors that should be doing that, especially for relative paths which would allow such maps to still be compiled/loaded on linux/mac as well as windows.
Obviously absolute paths are problematic regardless.

@Rick, some -basedir argument for qbsp?.. and probably -game too... 

@mankrip, really its the editors that should be doing that

I agree that fixing this in the editors would help for when creating new maps, but for compiling old maps it wouldn't, specially if the user wants to compile some old maps directly from the commandline.

The Quaddicted database has tons of maps with source available, and sometimes it's useful to recompile them without modifications, when all the user wants is to compile them in a different way (e.g. enabling translucent liquids or lit water).

So, an ideal solution would be to fix this both in the editors and in the compiler - fixed editors would ensure that the maps can be compiled by any compiler, and fixed compilers would accept maps from any editor. 

even if you are recompiling it without any other edits, you'd probably have to fix all the wad paths anyway.
tbere's enough existing maps that auto-correcting the wad paths for any new ones is a little insignificant. I would personally rather that editors were aware of \", \n, \r, \\ when loading rather than \ getting switched to / in specific cases that 'the' engine will already need to deal with regardless. 1 well-worded warning is imho useful, 4 is excessive but still preferable to none.

on a related but different note, casually recompiling all your maps isn't something I can really endorse - if you do this, you'll find yourself kicked from vanilla quakeworld servers due to having an assumed-cheat version of the map.
vispatches and lit files won't trigger this issue, and can automatically run on maps without worrying so much about which qbsp originaly compiled it and how strict it may have been.
This won't give you everything, so there's no single winning solution, but it should give more consistant+reliable results if you're doing it in bulk. Assuming those tools support bsp2 etc, anyway. 

@Rick, some -basedir argument for qbsp?.. and probably -game too...

Something like that I guess.

Netradiant wants the wads in the ID1 folder. Put them there and it works fine, anywhere else and you have no textures in the editor.

Frequently I dig out old maps from years ago and run them through QBSP and get no textures errors. Then I have to go manually edit to fix "wad" "E: \\ worldcraft \\ test.wad" or whatever I was using back then.

I'd rather the map just used "wad" "wadname.wad" and let the compiler find it (with the assumption that the wad is somewhere in the Quake folder). 

 

 

 

 

yeah, if you do the classic 1:4 2:4 3:3 4:2 4:1 cylinders, you will have some angles that you can't perfectly line up the textures on with whole degrees. Not noticeable until you have a long enough surface with the same angle 

I'm getting this error with my map:

light: /home/benny/Downloads/tyrutils-ericw-ericw-v0.15.5/light/light.cc:656: void CalcualateVertexNormals(const bsp2_t*): Assertion `smoothedNormals.find(v) != smoothedNormals.end()' failed.

As well as a bunch of: WARNING: couldn't nudge light in solid at -1586.848267 174.062302 507.337677

Which I assume is because some of the surface light textures cover the entire brush and some are against other solids.

This same map didn't give me errors with an earlier version. Running ubuntu 16.04.

Also, isit possible to have phong shading on non func_details, I have a func_illusionary or two I'd like to use it on.

Thanks in advance! 

Mind emailing me the .map+.bsp+.texinfo?

phong shading on any func_ should work. You have to run a full qbsp to update the .texinfo file though.

btw hoping to make a new release pretty soon 

the new version compiled and works a treat.

also the "-gamma" command is amazing, saved me having to decrease all my light values after adding -bounce 

Liquid surfaces should be completely ignored when dirtmapping, but they aren't. Here's an E1M2 screenshot.

Ideally, lit liquids shouldn't receive or emit dirtmaps. 

I've taken that screenshot with the water fully transparent, and the map was compiled with these parameters:

$bsp_exe -nopercent -splitspecial $bspdir/$file

$light_exe -extra4 -dirt -dirtmode 1 -dirtgain 0.875 -dirtscale 1.5 $bspdir/$file 

 

"_dirt" "n"
For brush models, -1 prevents dirtmapping on the brush model. Useful it the bmodel touches or sticks into the world, and you want to those ares from turning black. Default 0.
Maybe it will work with water brush too? 

I've just tried it, and _dirt -1 doesn't work on func_detail. 

Well, actually _dirt -1 sort of works on func_detail. The water isn't dirtmapped now, but it still casts dirtmapping in the rest of the world model.