Custom values for $First Level Filename parameter in game.tbl seem to be ignored (in mods)

[GooberRF]

$First Level Filename: What level gets loaded first when starting a new game

Above is the description of this parameter in the comments at the top of Volition's game.tbl

The default value in the stock game is L1S1.rfl (first level in the game). This parameter can be changed in a mod via editing game.tbl, however when the mod developer sets the parameter to reference a different level, the play button under New Game will still load L1S1.rfl, not the level the mod developer specified.

[rafalh]

It could be fixed in Dash Faction but it will cause some inconsistency because RF has two "first" level: L1S1 or train01 - one is selected based on what player clicks in a dialog window. What I'm trying to say is that mod authors will still have to tell people to not click the wrong button so I'm not sure it is much better than telling people to open console and write "level xxx"

[GooberRF]

My impression is that modders would be aware that they wouldn't be changing the training mission by editing this field, but they would expect to change the main campaign starting level.

An ideal solution I suppose would be to fix this bug, and then also have Dash read an optional $Training Level Filename field, but the stock game would error when loading the game.tbl file then.

Perhaps an ideal 2-part solution could be something like this:

1. Fix this bug, so the $First Level Filename parameter works properly in Dash when specified in game.tbl
2. Make Dash Faction load an optional file named "dashoptions.tbl" (as an example) from the mod folder if present. That "dashoptions.tbl" file would load and apply a $Training Level Filename field if present. It could also provide a good way for you to in the future expose any additional optional settings to mod developers you wish to, without risking making mods incompatible with non-Dash clients (since they just wouldn't load the "dashoptions.tbl" file).

[tunbridgep]

My impression is that modders would be aware that they wouldn't be changing the training mission by editing this field, but they would expect to change the main campaign starting level.

An ideal solution I suppose would be to fix this bug, and then also have Dash read an optional $Training Level Filename field, but the stock game would error when loading the game.tbl file then.

Perhaps an ideal 2-part solution could be something like this:

1. Fix this bug, so the $First Level Filename parameter works properly in Dash when specified in game.tbl
2. Make Dash Faction load an optional file named "dashoptions.tbl" (as an example) from the mod folder if present. That "dashoptions.tbl" file would load and apply a $Training Level Filename field if present. It could also provide a good way for you to in the future expose any additional optional settings to mod developers you wish to, without risking making mods incompatible with non-Dash clients (since they just wouldn't load the "dashoptions.tbl" file).

Don't need anything this complicated

People already understand that Training should load training, not the mods first level

but if you want a custom training level field, just make the game look for the $Training Level Filename field, and if it doesn't find it (or the file doesn't exist), just load train01

[GooberRF]

but if you want a custom training level field, just make the game look for the $Training Level Filename field, and if it doesn't find it (or the file doesn't exist), just load train01

This is not a backwards-compatible solution. As I stated in my post above, "...have Dash read an optional $Training Level Filename field, but the stock game would error when loading the game.tbl file then" This approach would make mods that take advantage of this function completely incompatible with the stock version of the game (without Dash).

I don't think that's at all a showstopper if there was no way around it - realistically, Dash is required for many mods released these days anyway for other reasons. But in this case, there's a relatively simple way to avoid this issue and maintain compatibility, so I would prefer that approach.