As some of you may know i ported the map called drain from xonotic, which we played on grangerlab.
This started as an experiment how difficult it would be to port a map, in this thread i describe how i did it.
I will split this guide in a few points, it is assumed you already know about the basics of maps.
Long story short, wasnt worth it, so im writing this to warn people, unless you absolutely want to go down this path, just dont.
1) The map
The map file itself is pretty much a standard q3 .map file, it can be opened in netradiant or similar programs.
Map files are located in the xonotic-xxxxxxxx-maps.pk3 of where xonotic has its files, on a linux global install that would be in /usr/share/xonotic/data.
A bit of cleanup with entities that are not used by tremulous is advised but not strictly needed.
And as always you need human and alien spawns placed on the map and a info/info_player_intermission.
2) Shaders
The second important step is setting up shaders.
As xonotic stock maps use shared assets, its not as easy as simply copying over a .shader file.
Shader files are in the scripts directory in the xonotic-xxxxxxxx-maps.pk3 (replace the xes with some date).
But since shaders are shared a map may reference many shader files, it would be inefficient to use them all.
You need to find and copy over all the individual shaders that are needed by a map and those arent few.
The shaders also use some darkplaces specific keywords, i believe both netradiant and tremulous ignore those, but im not certain.
In addition, if you want to use ogl2 features used in the 1.3 client, you must make a copy of your .shader file and make it to a .mtl file, adding all references to specular and normal maps.
Another hurdle is the fact that xonotic uses sometimes symbolic links in its pk3 instead of explicitly referencing the file like a .mtl file does.
Darkplaces uses specular and normal maps which are implicitly referenced, using the texture filename with norm and spec appended respectively that reside also in /dds where the textures are.
This requires looking up what every single file link references and extract it too.
With the darkplaces extentions aside, the shaders are standard.
Ofcourse you can chose to omit this step, but then you lose almost half of what makes the xonotic maps so good, but what you do have to do is the use the surfaceparm keywords or the map will be broken as these affect the gameplay.
3) Textures
This was a tricky one (thanks to sparky for helping me btw), xonotic uses direct draw surface(.dds) textures.
Instead of being in the /textures folder in the xonotic-xxxxxxxx-maps.pk3, most textures are .dds files placed relative to /dds/textures in the pk3.
Now the 1.3 client by gh can use .dds files, but 1.1.0/gpp and maybe tremfusion can not.
Therefor if you want to support these clients, you will need to convert all those files to targa(.tga) using a batch conversion tool such as imagemagick, which is accessable in most linux distros by the package manager if not already preinstalled.
A simple shell script that iterates on all files will suffice:
for i in
sdo; convert $i.tgabasename $i dds; done
This should be the same for osx, but for windows, i cannot tell how.
4) Other assets
Xonotic maps use other assets, such as models and ambient sounds.
Sounds are sometimes in ogg vorbis format, which again should be supported on 1.3, but not on 1.1.0 and co.
To convert them on linux and maybe mac, is the sox command line utility or what i used in this case was the audacity gui program.
Model props are sometimes used, they should reside in /models folder again in xonotic-xxxxxxxx-maps.pk3.
Often in .ase or .md3 format which are supported out of the box on 1.1.0, however .iqm is not supported even on 1.3, i think.
Opening .iqm should be possible with a tool such as blender and then exporting back to .md3.
The problem are the materials, with .ase that is a plaintext format and can be opened with a simple text editor and you can find the material names.
With .md3 the problem is a bit bigger as it is a binary format, ascii hexdump should be able to locate said materials.
In that particular case i asked cron to dissect them for me, but that is obviously not a reasonable way to do it.
5) Conclusion
I strongly dissadvise anyone from doing this, it was more work that it was worth it for me.
If anything i would recommend doing a set of automated tools to do this.
Any halfway competent programmer could do this in about a weeks time, but due to the difference in map designs between the games its not worth it either.
I still want to try a non-stock map, but i have to find a good one first.
