Currently, users have to modify either their TB game config or Qodot itself in order to enable obj_neverball support in their game configs.
The short-term solution is to add obj_neverball to the game config template as a default, but a better approach would be to expose all of the game config settings as properties.
It would probably be useful to add an 'extra fields' dictionary-of-dictionaries, so users can define fields not explicitly supported by Qodot in the event that TB's game config spec changes and Qodot hasn't caught up yet, as is the case with obj_neverball.
Currently, users have to modify either their TB game config or Qodot itself in order to enable
obj_neverballsupport in their game configs.The short-term solution is to add
obj_neverballto the game config template as a default, but a better approach would be to expose all of the game config settings as properties.It would probably be useful to add an 'extra fields' dictionary-of-dictionaries, so users can define fields not explicitly supported by Qodot in the event that TB's game config spec changes and Qodot hasn't caught up yet, as is the case with
obj_neverball.