Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Tomo on December 13, 2009, 03:37:02 am
-
At present, FS2Open actually never looks at the Mod.ini file. Instead, the Launcher parses the mod.ini (if present), and creates a command-line for FS2Open using the contents.
My suggestion is that instead of doing this, the launcher should pass the (relative or absolute) path of mod.ini directly to FS2Open and FRED2Open.
The main advantages are as follows:
- In the Feature Request: 4th Font (http://www.hard-light.net/forums/index.php?topic=66942.0) thread, Wanderer suggested that a mod.tbl or mod.xml be created to hold mod-specific settings (eg fonts for fiction viewer etc).
As mod.ini already exists, it would make more sense to include this data here. - It has been mentioned several times that it would be useful to be able to 'suppress' Retail data for total conversions, as that way you can use the same executable for all your TCs.
The mod.ini could include a line specifying No Retail data. (This way round ensures backward compatibility) - It means that FS2Open and FRED2Open can have more information about the mod.
Eg The Pilot Select and Credits screens could show the proper name, credits and logo for the mod.
FRED can show the currently-selected mod name, and the other mods it relies upon. - The folder for all the mods a user has doesn't necessarily have to be a child of the same folder as the executable. (This is good for Win7 and Linux)
Retail data stays where it is, as that should never be changed.
For backwards-compatibility:
A) Launchers older than the first to support it simply ignore the new options, and pass the old command line.
As FS2Open itself will parse the existing mod.ini, all existing mods behave exactly as before with the new launcher.
- The only danger is 'new' mods using the new options will have these options ignored if started with the old launcher.
B) We use a different command-line switch that tells FS2Open to use the mod.ini directly. This is passed instead of the existing 'mod' switch.
If the existing switch is passed, FS2Open behaves as before.
Unfortunately there is no way at present for FS2Open to determine which of the mod list is the 'main mod', as it could be at the start, end or middle depending on primary and secondary list options.
I'm happy to start and assist with coding this kind of change, but it needs to have a consensus before starting as it relies on changes to the Launcher as well as FS2Open and FRED.
The changes to FS2Open are actually fairly trivial, but unfortunately I'm unable to compile FRED2Open as I do not have MFC.
-
I'd rather have a proper mod.tbl than bastardise the mod.ini to do this.
-
How do you intend to point FS2_open to the right ini file?
-
I'd rather have a proper mod.tbl than bastardise the mod.ini to do this.
Agreed. Leave mod.ini how it is, add a mod.tbl or somesuch.
-
I'd rather have a proper mod.tbl than bastardise the mod.ini to do this.
Agreed.
how would you see it being implemented?
-
really i dont see why we dont integrate mod support with some kind of pre-load screen. kinda like how id engines have the mod menu.
-
I'd rather have a proper mod.tbl than bastardise the mod.ini to do this.
It's not bastardisation - this is exactly what mod.ini is for, it's just used by the Launcher instead of the FS2 Open directly.
Any data that should only be loaded by one mod and no other would go in mod.ini. You cannot use tables for that, because tables are always loaded by everything.
Eg: Someone creates a mod (FOO) relying on a previous modpack (BAR). At initial release, neither mod has a modtable.
In a patch release to BAR, a modtable is added. This now breaks FOO, because the new table gets used by FOO even though the designer of FOO did not want it.
Thus FOO is forced to add a modtable to override BAR's and issue a new patch release.
mod.ini on the other hand is not loaded by everything - only the first mod.ini is ever loaded - and therefore such a change to BAR has no effect on FOO.
This also opens up the possibility of using the data that already exists in mod.ini to enhance the game - like the mod image, the modder's name and credits.
How do you intend to point FS2_open to the right ini file?
That is trivial - exactly the same way basically every other application works, including the browser you're using right now.
Right now, the launcher creates an ini file (or someone makes a link) that contains a section something like the following:
-mod foldername#1 foldername#2 foldername#3 foldername#4 foldername#5 foldername#6 foldername#7 foldername#8 foldername#9 foldername#10 ... foldername#n
The actual mod itself could be any of those arguments, as mods relying on assets from other mods must load some of it before their own data and the rest after. (This is what primarylist and secondarylist are)
Instead of doing this, we pass a single switch in that ini or command line switch:
-modini 'modfolderpath'(or similar)
modfolderpath can be either a relative path (from the location of the FS2 executable, the default), or an absolute path (from root).
FS2 Open follows that path and opens the mod.ini it finds there.
If there's no mod.ini file there, it opens the folder 'standalone' (including FS2 root vps of course)
FS2 Open then loads everything as it currently does based on that path - essentially building its own modlist.
(Edit for grammar)
-
The changes to FS2Open are actually fairly trivial
:lol:
Right, we don't tend to look kindly at people who say things like that when they clearly have no idea about the type or extent of changes involved.
Sorry, most of the things you suggest make very little sense, and the ones that would be useful (such as displaying the mod name) are already implemented. I'm afraid we'll have to decline.
-
Take look at the cmdline section.
I'm away from my main PC now so don't have the actual variable names, but the psuedocode is as follows:
During initial command line switch parsing:
if ((commandLineSwitch == 'modini') and (commandlinemodlist is empty))
{
Open mod.ini file pointed to by modini argument.
If opened
{
Locate Primarylist
Add contents to commandlinemodlist as done by the for-next loop that's commented with 'this loop is a work of art'
Add modini clause to commandlinemodlist
Locate Secondarylist
Add contents to commandlinemodlist
}
else add modini clause to commandlinemodlist
}
Then continue as before.
- Support for 'absolute' paths not in the FS2 Open folder may be harder - I haven't checked the how VP loading algorithm gets its path yet.
-
Why would we use the mod.ini for this though? Why not simply a new file?
-
Main reason being that it's already there, so using that is automatically backwards-compatible with all existing mods.
The mod.ini is a file that is always unique to a given mod and never affects other mods that rely on it.
Therefore any setting that is genuinely mod-specific should go there.
-
And a lot of ships and weapons are mod-specific. Should we put those in mod.ini too?
Name one good reason why (for example) additional fonts should go in mod.ini as opposed to fonts.tbl.
-
Almost. But if you have data in two MOD ini files that are specific to the mods and Mod FOO needs mod BAR and you have parsing and inheritance set, then settings in BAR are going to take effect and modify FOO.
Maybe it's just me, but I'd like to see mod inheritance myself. In testing BluePlanet SVN and trying to run it with the FSU SVN (to ensure no compatibility issues) doesn't work so well. Makes for one hell of a long command line, because you can not just change the "mediavps" in the bpsvn mod.ini to point at the FSU dir and have it load non-vp subdir data.
Mod specific data should and needs to go into mod specific tbls/tbms. If FOO is getting bad data from BAR that it want's to over-ride, then the maker of FOO should learn to set appropriate over-riding entries in said data for the mod.
-
Gah! I am sick of example things named Foo and Bar! I don't care who came up with it as a precedent, it's retarded! :hopping:
:nervous:
-
I think FUBAR disagrees. I know I do.
-
I tend to agree. I prefer terms like frotz, zork, blorb, etc. Or even names: fred, dave, bill.
-
The FOO and BAR usage even predates my computer lifetime (started in 1980 on an Apple II+). Goes clear back to the early 70's at least. Remember seeing it in some of the first stuff I read.
-
Considering how quickly programming can go FUBAR, I think the names fit perfectly. :p
-
First of all - the fonts note was an example. Maybe a bad example, and a fonts table may well be a better place for it.
But please read past that line in the original post!
Right now FS2 Open does not and cannot know which mod was selected.
It does not display the selected mod (only the selected campaign), the credits for the mod or the additional artwork created as a mod 'logo'.
- I wrote a patch a while ago that attempted to display the chosen mod, and found that it was actually impossible.
Instead it could only display the list of mod terms used in order - so the user could know he was running "blueplanet,mediavps" or "fsport-mediavps,fsport,mediavps", but not that he was running "FSPort MediaVPs v3.1.1"
There may be other data that is genuinely mod-specific - and by that I mean should not be automatically inherited by other mods.
The nature of that data is a matter for later discussion, and I am sorry for allowing the thread to become derailed by it.