Trenchbroom: "Launch Engine" window Parameters field not saved

[ericwa]

The message in this window says the commandline parameters should be saved in a worldspawn property, but this doesn't seem to be working in be692ac / OS X.

Every time I open "Launch Engine" and select my engine, the Parameters field is blank. It doesn't seem to be saved in a worldspawn key.

[kduske]

Did you save the map? Unfortunately, you have to save it (I think it says so either in the dialog or the manual) for the parameter strings to be saved in the map.

[kduske]

Thinking about it, maybe it's better to save such things elsewhere - but where? I don't want to introduce "copilot" files that sit next to the map file, so maybe it could be saved along with the compilation profiles in the user's data directory (~/Library/Application Support/TrenchBroom on macOS).

[ericwa]

Yes, I saved the map. Entering engine launch parameters didn't mark the document as modified (with the filled circle close button on Mac OS), but even if I made another change (moving a brush) and saved, I still don't see a worldspawn key written to the .map file.

Anyway, maybe these parameter strings don't need to be saved per-map, as you were saying.
The parameter strings can use variables like "+map ${MAP_BASE_NAME}-compile.map" (should that be the default?), so there's really no need to save them per-map.

Maybe the launch params should just be saved per engine configuration. If the user wants to pick between multiple launch parameters, they could just make clones of an engine config, and tweak the params per engine config.

e.g.

• "/Applications/QuakeSpasm.app" with "+map ${MAP_BASE_NAME}-compile.map"
• "/Applications/QuakeSpasm.app" with "+map ${MAP_BASE_NAME}-compile.map +r_lightmap 1"

[jmickle66666666]

If it helps, doombuilder (the leading map editor for doom) saves properties files for maps alongside the .wad files, for storing extra data and settings like this. I don't think it would be a huge problem to do the same for trenchbroom too.

[kduske]

I think I'm going with @ericwa's proposition as it's simpler and covers most use cases.

[kduske]

Changed in e0d77b9.