Trenchbroom: Add support for Soldier of Fortune

[JohnnyNatrium]

Required features:

• [ ] m32 texture reader
• [ ] fgd file
• [ ] game config file
• [ ] game icon

Which model format does SoF use?

[kduske]

Please remove that link, it might have licensing issues.

[kduske]

When converting SoF textures from .m32 to .wal, palatte isues occur in Trenchbroom when trying to use them.
For work on support for this game (maybe others?) .m32 native support would be useful.
Should a general Soldier of Fortune support issue be created instead/additionally?

palette problems:

[JohnnyNatrium]

Here is a partial .fgd file for SoF which can easily be added to (includes comments):
https://www.nexusmods.com/soldieroffortune/mods/187

Model files appear to be Ghoul (.gpm); there have been releases of importers for 3DS Max for SoF models.

[JohnnyNatrium]

Might I suggest starting with implementation of .m32 compatibility? Using custom configuration files I have the game sort of 'working' in Trenchbroom but for further testing and adding to the .fgd it would be good to have textures working first. I don't know how time consuming .m32 implementation would be; Anything I could do to reduce ETA?
This is a (short) forum thread on QuArK's m32 file handling and includes a programmer linking to a version with updated code relating to .m32: http://www.sof1.org/viewtopic.php?t=4196
I suppose any QuArK source more recent than 2jan2016 would include this.

[kduske]

As you can see, this feature is currently planned for the 2.1 milestone, which means that I'm not going to start working on it right away. I have very little time to work on TB, and getting the 2.0.0 milestone out is more important right now.

[JohnnyNatrium]

I think I now know why everything was displayed in orange+black......
This is the colormap.pcx as distributed with the game:

Anyway I found the real palette (ravenpal.lmp) and pointed TB to it, and now the textures display correctly; at least as far as the converted-to-.wal images go. The .wal images which I converted raw from .m32 are degraded (I'm guessing because they don't take 32bit colours) so either way using .wal extension for SOF in TB isn't a true fix.
Because I would like to start using TB with SOF while the .m32 support is still pending, also so I can more easily start working on the other stuff like the .fgd file (not a coder), I'd like to know if there is any existing support for 32bit textures at all, and if so how I could point TB to that extension in the .cfg for this game. This because I can easily convert .m32 to other formats like .png, .tga, .bmp etc. without the degradation that .wal has. So could TB just use one of those common extensions?

(example of the degradation of the .wal files with certain colours being replaced by some yellow-brownish):

I know this is fairly irrelevant if the solution is just to have .m32 be supported in the first place, but I'm guessing this is going to be a long time away so I'd like to have a workaround in the meantime. If I could write something myself to include this support, based on some existing source code, I would. I just wouln't know where to start as someone with only the slightest bit of programming knowledge and no experience.

[kduske]

https://github.com/kduske/TrenchBroom/pull/2010 backports this functionality from master to 2.0.0 and will be part of the next RC. To use it, look at the game cfg file to find this (copied from Quake2.cfg):

    "textures": {
        "package": { "type": "directory", "root": "textures" },
        "format": { "extension": "wal", "format": "idwal" },
        "palette": "pics/colormap.pcx",
        "attribute": "_tb_textures"
    },

It should look like this:

    "textures": {
        "package": { "type": "directory", "root": "textures" },
        "format": { "extension": "png", "format": "image" },
        "attribute": "_tb_textures"
    },

You could also try tga and other extensions there.

[JohnnyNatrium]

Sorry, I have no idea how to implement and compile functionality from these commits; are you saying I should wait for the next RC?
Interestingly, in the current RC the .png extension seems to be supported, but the format "image" is not recognized (neither is "freeimage"). Could it be that there is another format in place which will read .png, that I could input in the .cfg?

[kduske]

Sorry, I have no idea how to implement and compile functionality from these commits; are you saying I should wait for the next RC?

Yes.

Interestingly, in the current RC the .png extension seems to be supported [...].

Why do you say that?

Could it be that there is another format in place which will read .png, that I could input in the .cfg?

I don't think so.

[JohnnyNatrium]

Sorry; I remembered seeing an exception for "tga" being unrecognized in TB, whereas this wasn't there for "png" as extension, which made me think that .png might be supported. Turns out the "tga" exc. was yielded because at that time I had entered it as the format, rather than extension (which I assume never yields exception).
A somewhat more important matter: I thought TB didn't support .def and only .fgd definitions, but Daikatana's folder contains a .def file and now I'm reading some things on that .def is supported. This would speed things up because I have a finished .def file already, whereas the .fgd needs a lot of work.
However when I point TB to the .def file, TB stops responding when choosing SoF for a new map.
Is .def support unstable?

[kduske]

.def support should be okay, but it's quite limited since the .def format doesn't support many of the features that .fgd has. Could you upload the .def file somewhere so I can test it?

[JohnnyNatrium]

SoF entities.def:
entities.zip
This was distributed as part of the SoF SDK for sofRadiant by Ravensoft.
I'm sure that SoF SDK was available freely, so I'm guessing it really should be open source as well (it includes full source code)? By that logic wouldn't it be fine to incorporate source code for the .m32 definition? Documentation included also seems to imply that using and altering their code is encouraged in modding.

[etc0de]

I'm sure that SoF SDK was available freely, so I'm guessing it really should be open source as well (it includes full source code)?

Not a lawyer, but I'm pretty sure that's not how licenses work. Unless it includes explicit licensing as free software, it might still not be allowed to include it in other projects and/or distribute it at all. While RavenSoft might no longer care, it might potentially be illegal and therefore I don't think it's safe to use in a properly licensed free software project. (unless you can track down the actual confirmed licensing and it turns out to be a proper free software license that is compatible with the TrenchBroom project)

[JohnnyNatrium]

I understand, it's just that this is about pieces of code that belong to some tools used in the SDK (in Radiant) itself, for reading a proprietary image format. There are no real copyrighted assets or materials distributed in the process I feel like, just a definition for an image format that they seem to have developed and they basically can't be contacted on the specifics. There literally doesn't seem to be any license specification with the SDK package unfortunately. I guess maybe I should look towards the QuArK devs to see how they used it.

[DanielGibson]

Might be OK to use the entities.def (and mention somewhere it's from the SDK), but I think it's better not to copy any code.
And TBH I don't think .m32 is a very complicated format, it shouldn't be too hard to support without copying code from the SDK.
Quakesrc.org had a tutorial on how to integrate it into Q2, including a C struct for the header, see http://web.archive.org/web/20030308122237/http://www.quakesrc.org:80/?Page=tutorials&What=./tutorials/Quake2/gfx/M32_TextureSupport.txt

(UPDATE: Half-related: There also seems to be a proper mirror of quakesrc.org tutorials at https://www.quakewiki.net/quakesrc/)

[ericwa]

There is also a GPLv2+ implementation of a .m32 reader in GTKRadiant:
https://github.com/TTimo/GtkRadiant/blob/master/plugins/imagem8/m32.h
https://github.com/TTimo/GtkRadiant/blob/master/plugins/imagem8/m32.cpp

[JohnnyNatrium]

Thanks for the help with this guys!
If only I knew how programming worked, the format might be 'not hard to support' for myself too. ;P
One of these days.. -- meanwhile I'm happy to spark interest among the coding talent, and do some other legwork.

[DanielGibson]

Go on and learn programming then - even if someone else ends up implementing this, that skill is always useful!

[JohnnyNatrium]

Oh I am learning - except I've only recently started. In my free time learning to program is one of many priorities however - another one right now is to get mapping for SoF in TB.. before the time it takes to become useful at programming ;p. I am fully aware that this also needs to be a priority for others in order to expect anything of course.

[JohnnyNatrium]

Anyway, any idea why the .def file doesn't work?

[JohnnyNatrium]

I'd like to mention that this SoF entities.def file is not the only one which didn't work with TB.
When trying to use the popularly distributed RTCW .def file, I also ran into problems. Except instead of crashing, I got an error warning me about a 'fault' in the .def file. Basically there were spawnflag entries which are normally a list of words separated by a space, but in Wolf there were some spawnflag lists with skipped entries (SUSPENDED SPIN - RESPAWN). The "-" character triggered TB, because it expects a "word". After replacing every one of the many instances of these characters in such a context, the .def file worked (as far as I can tell so far).

It should be noted that the original RTCW .def file does work in the Radiant based editors that I've tried.
The same goes for the SoF entities.def file, which works in Radiant as well without problems.
Now the problem with identifying the issue that TB has with the SoF entities.def is that it doesn't give me an exception message, it just crashes upon loading it.
Basically my question is if .def support is somewhat broken or very limited in TB, and if perhaps it throws errors too easily for certain format/syntax. Or if somehow these .def files should just be fixed.
(I'm not sure what TB doesn't like in a .def file so it's harder for me to identify the problem in the SoF .def; does it also not like single letters for Spawnflag entries?)

[kduske]

Please create a separate issue and attach the def files in question. DEF support is Limited in TB, but I‘ll see what I can do.

[JohnnyNatrium]

Thanks for the swift improved support for the .def files in the latest release!
I've been working with them already and things basically seem to be quite usable already.
I've also been contacting people on a SoF mapping forum. Hopefully there will be some help in the added support of .m32 textures and especially the entity models. They've already helped me on more general mapping related issues but I just broached the topic of TB support.

One thing that I'd quickly like to ask/check because it's kind of a specific Trenchbroom thing:
When not using models for the entities in the editor (as I believe is the case of all .def usage to begin with?) we get the BSP esque coloured bounding boxes for entities. As I believe you're aware, the rotation function doesn't work properly for these inside the editor. Well, you can set the rotation properly, but the entities don't reflect this rotation in terms of their rectangle position.
Is this a thing that will be possible? Or can be manipulated at this point already?
I know there was is a topic that was closed, on rotating .bsp based entities. I still believe this is a relevant question right now since that was 3 years ago and I believe different functionality was applied for things such as the ammo boxes etc. (models added or something?)

textures so far are converted into JPG (I should note that .tga and .bmp extensions do not work properly in the editor as of yet; they are very distorted when used there; perhaps something for the "multiple texture formats support" topic since in games like RTCW these are some of the native texture formats)
SoF1 in the editor now:

[ReindeerFloatilla]

Question, could this config be uploaded/worked into the newest version?

[eGax]

Question, could this config be uploaded/worked into the newest version?
@ReindeerFloatilla

I don't think there is support for m32 in TrenchBroom yet? That requires the end user to convert the m32 textures to something like PNG or other TB supported formats before they could map for SOF.

I can share my personal, slightly(?) more advanced SOF support for TB. I have it setup to use JPG, TGA, or PNG:

I'm using PNG's I converted from the game's M32 format with Slade.

It's just my own custom gameconfig.cfg with what I consider a few niceties, adding in a few of the surfaceflags SOF uses, etc.

It should work in 2020.2 and it definitely works in current code base many commits after 2020.2. Its very untested with the sof compile tools, but you are welcome to try it.

sof.zip

[JohnnyNatrium]

Someone did post the ready to use open source code for implementing.m32 (from another editor) somewhere up this page.

As you know, it's not much of a hassle (especially with better tex support since I opened this) to just bulk convert the mt32s to TB supported formats.

The biggest issue really is getting this game's models supported I think. Or since we're using .def for entities so far, the real working problem is that the bsp based entity bounding boxes will not rotate in the editor viewports. I can put down a closet or a bench and apply correct rotation params but in the editor it still looks like it's sideways clipping through the wall it's next to. Ingame they show up fine and correctly rotated ofc But it's a real pain for trying to position things properly without visual feedback in editor

[ReindeerFloatilla]

to be honest I don't mind bounding boxes for models as long as textures are working.

[eGax]

to be honest I don't mind bounding boxes for models as long as textures are working.

Yes, most quake engine family game editors back when only had bboxes and map textures, but people made some pretty great maps.