Exposing some hard coded elements to assist with Mod Development

[Intharth]

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).

Originally posted by @GooberRF in https://github.com/rafalh/dashfaction/issues/105#issuecomment-824336187

Hello, I was hoping to ask for something a touch more advanced to help out the modding of Red Faction - as more tools become available so do the 'limits raised' in terms of what can be achieved with new ideas. The limit that is still unfortunately not able to be worked around is being able to amend hard coded values in the Weapons table file - which has become a specific issue of late given all the experimentation going on. In line with Goobers previous comments on another TBL file format - It would be really neat to see a version of this for the weapons TBL - in hopes of exposing some more 'hard coded' elements to aid with tweaking and refining custom content going forward.

1 example of this type of thing would be that the rail driver emitting steam after firing a shot seems to be a hard coded element of its muzzle flash - which isn't present on other weapons. Being able to amend things like this would go a long way to giving some more flexibility and customisation to mod development.

[GooberRF]

To expand on this - I think the most elegant approach would involve having a single table file for all the overrides ("dashoptions.tbl" in the mod's folder as an example) would make the most sense. This table file could be broken down into sections for each "category" of change - ie. overrides that apply to weapons could enclosed between tags:

Weapon

//$DF Add Steam: "WEAPON" "TIME" Specify weapons.tbl class to apply to, and time delay into the reload animation where steam should appear $DF Add Steam: "Assault Rifle" "0.1"

End

Some additional hardcoded values from elsewhere in the game that I feel would be valuable to have exposed to mod developers are:

• Player movespeed modifier for multiplayer
• Scope mask bitmap to use (ie. "alt_zoom" flag in weapons.tbl adds a scope, but it's always the PR's green scope except in the case of the Sniper Rifle, which is hardcoded to use a different bitmap)
• Default mesh used for geomod craters
• Mesh used for geomod craters made by specific weapons (e.g. the ability for geo craters caused by rocket launchers to cut out a different shape than geo craters caused by grenades)
• VBM file used to wrap player/weapon models when player has amp/invuln in multiplayer
• RGB color of dynamic light used for amp/invuln/CTF flags in multiplayer

There are more - these were just the first few that came to mind.

I'd be happy to go through and develop a layout template/schema for the "dashoptions.tbl" file if it would be helpful.

[Intharth]

Some other examples of hard code that came to mind ...

• Co-ordinates of the main menu buttons

• Bitmap used by the Rail Gun to create the 'blue flash' on the screen

• Weapon forced for the Go_Undercover Event (Default is the Undercover 12mm handgun) something I would like to be able to do with that for a project is remove the weapon from undercover entirely - but more appropriately just being able to change which weapon you get for undercover.

• Entity the player spawns as (default is miner1)

• Alongside the last 2, Entity the player characters is set to when Go_Undercover event is used (default being the parker business/parker science entities)

[rafalh]

This issue is transforming into a wish-list. You realize every additional property is a distinct task that has to be done separately and requires non trivial amount of work? Every one of them should have a separate issue. Please keep this issue limited to starting level customization.