24 replies to this topic

[dabus]

@Ascension64:
Wouldn't it be possible to install all other required components if 201 is selected?
I don't know if INSTALL_BY_DEFAULT will install the component if --forec-install-list, but if it was, that would solve a few problems since you seem to update your application more often then the BWP-stuff is updated. Adding REQUIRE_COMPONENT 1000, 1100, n for 201 should also prevent the problem of broken ini-files, correct?

Thinking about it, wouldn't using REPLACE_TEXTUALLY on the ini-file when "1000 above"-components are installed be the better solution than using it in the 201-component?
That way, only components that are actually installed would be enable.

Another option would be to just install all the files by one component.
There are no tons of files that would bug people and you enable the options during runtime by editing the ini-file anyway (if I'm not mistaken).

[Ascension64]

I was thinking of plonking all the components together into one - apart from some textual changes, I don't see any issue with having the files in the override despite not using some hacks.

[Mike1072]

For detection by other mods, manual changes to the .ini after mods have been installed should be minimised. If a mod makes changes dependent on certain TobEx features, it needs to be able to determine if those features are going to be used.

I might recommend the core component disable all .ini options, and a component be added for each TobEx feature. Installing these components would enable their associated .ini options in addition to adding or modifying any associated game files. This would give mods an easy and reliable way to detect which features are being used at the cost of convenience.

[Ascension64]

Alternatively, other mods are free to modify TobEx.ini as they wish, so they could 'force on' certain components.

[the bigg]

A 'one component per hack' approach is superior - it means you can reinstall tobex (and/or earlier mods) without losing your edits to tobex.ini.