Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Foxer on December 17, 2005, 09:56:46 am
-
Hey. I like very much the idea of mod.ini files. But I want to learn how to make it myself :) it isn't look so hard. So here is my question: what is the difference between "primarylist" and "secondarylist" in the mod.ini files? What is their purposes? BTW. Is there some docs to new Launcher and mod.ini issues? :) (if not, you should place this case in your FAQs site Karajorma ;)).
Sorry for little off-topic.
-
At the moment the primary list entries don't have much use. If you enter something there it will be used as the name of the mod before the current mod. So if I have this in my inferno folder.
primarylist = ,TBP;
secondrylist = ,FS1_Port,Media_VPs;
The game would use any tables etc. it found in the TBP folder before anything found in the current folder. I really can't think of any use for that but if anyone can it's there.
-
Ok, i see. Now... I got another question :). How works "flags = ;" in ini files? This is what I place in \MediaVPs\mod.ini:
flags = -spec -glow -pcx32 -jpgtga;In "Features" plate in Launcher I do nothing. All features is off there. I enable MediaVPs mod, and Run FSO. Unfortunately non from my mod.ini flags wasn't active in game o.O... What I do wrong?
-
Flags currently don't work (and for that matter probably never will). RT added them to the parser but then got too busy to implement them. Taylor sounds like he wants to go a slightly different way with them so just leave them alone until we know what he's doing with them.
-
It's just a bad idea. -spec and -glow have more to do with user preference and system abilities than mod gameplay. And things like these "The Babylon Project features" and "Wing Commander Saga features" shouldn't even be command-line flags in the first place. :doubt:
-
Exactly. (@WMC's response)
That's the plan with the new ini file, it gets rid of the cmdline options. The options will only be in the new Launcher, or settable by hand in the ini file. Mod specific settings will be tagged as mod specific. Most everything else gets moved to the ini file and out of the registry and cmdline. When the new in-game options screen comes to be (which will mostly get rid of the need for a launcher) then that will be required anyway. The ini is file the first step though and will be mostly transparent to users at first, the only noticable change being the new launcher. That change-over from registry/cmdline to ini file should happen around late-Feb/March in CVS builds.
-
split this out, this has useful info that was irrelevant to the original thread it was in.
-
Yes you are right WMC, but... if I want to make mod.ini for FS2 Open (with all VPs and flags like: -spec -glow -jpgtga) and one for multiplayer purposes (clear tables, no VPs and only flags: -mpnoreturn -fps -no_vsync) the flag idea looks more handy here. It's more comfortable than move all VP files elsewhere and change custom-flag line everytime I want to play multiplayer.
BTW. Taylor, I very like idea of new launcher and in-game option screen is what I always dream about ;)
-
It's just a bad idea. -spec and -glow have more to do with user preference and system abilities than mod gameplay. And things like these "The Babylon Project features" and "Wing Commander Saga features" shouldn't even be command-line flags in the first place. :doubt:
:nod:
what special features do they have that they are not willing to share with other modders? :D
-
Yes you are right WMC, but... if I want to make mod.ini for FS2 Open (with all VPs and flags like: -spec -glow -jpgtga) and one for multiplayer purposes (clear tables, no VPs and only flags: -mpnoreturn -fps -no_vsync) the flag idea looks more handy here. It's more comfortable than move all VP files elsewhere and change custom-flag line everytime I want to play multiplayer.
BTW. Taylor, I very like idea of new launcher and in-game option screen is what I always dream about ;)
With an in-game options screen such things could be stored on a per-pilot basis.
-
That will be very cool and best solution :). Can't wait. I hope there will be options for shutdown VP files or their's additions and tables (just for multiplayer). Or... if all singleplayer stuff will be valid and work properly for multi there will be no problem with that :).