get them here (13.2 MB).

the skies are solid like the original and the lighting is 99% faithful i guess (haven't checked the singleplayer levels, but they should be fine since i batch compiled everything with the same parameters).

here are some comparision screenshots:
http://shub-hub.quaddicted.com/files/images/dm3_6_original.jpg
http://shub-hub.quaddicted.com/files/images/dm3_6_recompiled.jpg

http://shub-hub.quaddicted.com/files/images/dm4_2_original.jpg
http://shub-hub.quaddicted.com/files/images/dm4_2_recompiled.jpg

http://shub-hub.quaddicted.com/files/images/dm6_2_original.jpg
http://shub-hub.quaddicted.com/files/images/dm6_2_recompiled.jpg

i renamed dm1 through 6 into gpl_dm1 through 6 for making them easier to test without renaming the originals you may have.

gpl_end.bsp has no extra room in deathmatch (near final teleporter).

Nice work, especially including the tools that you used in the .rar

I like this.
However is this an issue? (Some maps used the same texturenames but different textures).

i think this is how id made the maps
from Quake Retexturing Project page:

http://facelift.quakedev.com/retexture/bugs/

Couldn't those be distributed with like nquake or something?

We need that alternative maps and models be recognized as original ones by mvdsv and ezquake.

of course.. the original textures were removed and replaced with solid colors and the map compiled from GPL source.

but MVDSV must be hacked to allow both original and recompiled versions to work together

isnt it much better to hack ezquake to give the correct crc sum even for gpl maps. This way nquake would work even on nonhacked mvdsv servers.

this way too
devs should come up with a standard solution.. hope they do something about this quick
it's a shame the GPL sources have been around for 1 year and nothing has been done

It must be done mostly on server side.

Quite a bit has been done, actually. Say, the code for using GPL maps seamlessly alongside the original ones, along with a set of tools to build GPL .bsps from .map sources + QRP textures.

Unfortunately there were no replacement sky textures so the work stalled --- till yesterday. Moon[Drunk] made the two sky textures (I hope spends some more time on the blue one, currently it looks too dull compared to the original), so now we have a complete GPL texture set for maps dm4-dm6; dm1-dm3 still miss a couple of textures.

I compiled dm4-gpltest.bsp and dm6-gpltest.bsp for your testing pleasure. These two maps are based entirely on free/libre stuff (GPL map sources + free domain textures by QRP) and can be legally distributed as part of your favorite QW package.

A couple of screenshots:
dm4
dm6

The screenshots look pretty faithful at these angles but ingame you will notice several artifacts where the automatic tga-to-wad converter performed poorly; some of the QRP textures are not very faithful either. I guess someone will have to correct the wad textures by hand before the final versions are mode.

EDIT: oh, I posted to the topic without looking at the top post, it appears Baker5 has already arrived at pretty much the same results his own way.

Aquashark, there's no point in "doing something about this quick" really until the final versions of the bsps are compiled and the bsps' checksums can be placed into the clients and servers.

One more thing that needs doing is the colored .lit files: unfortunately, these will have to be recompiled for use with the GPL maps. I can't find the sources for them anywhere! (I'm not sure but the sources are probably in .ent format). I don't even know who made the lit pack everyone is using now. Any help is appreciated.

This is a problem -- surely somebody somewhere has the .ENT lump that was used to produce those colored lits. Maybe fuh would know -- my original RAR of LIT files calls itself "fuhquake-lits.rar."

Also, what's the procedure for replacing Quake textures with Baker5's simple.wad textures on already-compiled BSPs? I should think if we could do this we could get Quake-content-free versions of CTF, TF, and so on -- of course the maps remain copyrighted their owners, but distribution of those is normally allowed. Can Adquedit do the texture replacement in the right way?

EDIT: Perhaps there'd be some interest in a "faithful" set of LIT files as well -- less primary-color lighting, essentially only changing light thrown off by torches (soft orange), lava (bright orange), slime (perhaps a faint green), and so on for ambiance. I know I'd like this -- I tend to think most colored lighting in games is overdone.

I don't see a point in replacing CTF/TF maps. You can't make them any more free than they already are by mixing in some free textures.

And I totally agree with you pencechp on the lighting issue - the intensity of most lits should be toned down.

Agreed.

Tested GPLed DM6/DM4 they are nice
Can't really tell the difference.

we are in the progress!
The blue sky texture can be better thats true. This looks really good guys..

why do we need new lit files?

id's light compiler generates lightmap data using multiple threads. the order the light data is written to the bsp depends on how long each thread took. It is not possible to recreate the exact same timings (and to copy the timings violates the quake license).
Thus if you don't use 'gpled' lit files for the gpled maps, your lights will come out plain wrong.

ok, then add some command to fte that can convert .lit to .ent files

Oh yes please! .ent files for items/lights/whatever...
Nothing left but walls and floors and platforms in maps!

That'd be awesome, if it weren't totally impossible. I don't think they *added* any lights when they made the LITs; I suppose some really patient person could recreate them by standing next to every light in every level and figuring out what color they are. :/

EDIT: Just wanted to make it clear that I was NOT signing up for that job.

yeah well i kind of figured.

But if the client knows how to show the lights, it should be possible for the client to convert it to ent format? should it not?

Nope. Has to do with the way lights are created. The lights, as stored in LIT files, are really the pictures of how the lights are cast onto the walls -- they don't have anything to do with the actual lights anymore. So those LITs are just, in essence, big packages of textures (lightmaps), just like wall textures. It'd be a true mathematical challenge, if not an impossibility, to convert those back to the actual light positions and colors.

afaik, nobody ever actually 'made' any faithful .lits by hand

mh from quakesrc, wrote a GPL utility (mhcolor) based on tyrlite that automatically generated coloured lighting based on the colours used in textures in the map

e.g., at lava sections it would add a red coloured light based on the colour in the lava texture, in 'tech' areas it would generate blue lighting based on the blue in the texture etc.

obviously the mh site died a long time ago and mhcolour is hard to come by, but I did find JsColour which appears to be a modification of the original mhcolour to allow more control over the colours assigned to textures (src included in the download)

I just used this thing to crank out a LIT file for the GPL'ed E1M1, so I can confirm it works. Looks pretty good, too. Plus, JsColour has configurable color values, so you can tone down the colors if you feel so inclined.

very simple source patch/hack to get jscolour to compile on mac gcc is available here (follow with a simple gcc -o jscolour *.c), probably also works for Linux

p.s. you need '-lit' commandline option to generate external .lit (otherwise it writes to the bsp)

i'd suggest there are more textures that could have colour definitions added, someone could take a look at the textures here and see if they should cause lights to be coloured or not (gpl.def)

FTE has something similar, although its built in to fte. I did have it standalone once.
r_loadlit 2 and it'll try generating something automatically. The colours are mostly fairly subtle. But nothing beats hand-coloured maps.

*Lots* more needs to be added to this file -- for example, I ran JsColour on CTF2M2 (my usual testing map for the CTF project I'm working on), and *none* of the textures turned up with color additions. What someone should probably do is come up with a "palette" of colors that these textures tend to use, and then click through the entire Retexturing Project list making a "comprehensive" .DEF file. A little extra work then for CTF and TF and we'd have a pretty general-purpose tool.

true, but you'd need some of those .rlight guys to have the sort of dedication required to actually do it :-)

one task that might be worth doing would be to modify the source so it will output a .ent file that could then be tweaked by hand before being compiled into a .lit