[mjn.mixael]

That's a decent temporary idea.

[chief1983]

Mod.ini isn't even enforcable by multiplayer, and easily tweakable by the end user, so you're really not forcing it at all.  A table for that would be a better option, but still a temporary fix.  I'd also like to see mission-support, or at least multiplayer host time support for requiring additional flags on top of that, to allow further balancing if desired.

[karajorma]

Using mod.ini gives the the mod developer exactly the same choices as my suggestion and now moves the selection out of the logical place it should be (in a table somewhere) and out into the open air where any fumble fingered idiot can play with it.

[chief1983]

What was your suggestion?  I read a very good detailed description of the problem in your last post, but didn't see any possible solutions.  Unless it was in a previous post.

[karajorma]

Table flags consisting of "Use Feature", "Don't Use Feature" or "User Choice"

To be honest we can probably ditch the 3rd one and just have that as the default but it doesn't hurt to make it explicit.

[Iss Mneur]

Table flags consisting of "Use Feature", "Don't Use Feature" or "User Choice"

To be honest we can probably ditch the 3rd one and just have that as the default but it doesn't hurt to make it explicit.

Ya it would be a good idea to make it explicit, that way, when someone copies the entire example table from the wiki (that lists all of the options) they won't break something they didn't plan on.

Is there any way we can have forced launcher flags in the mod.ini?

I think all that needs to be said on this topic has been said, but I would like to add that wxLauncher does have forcing flags on or off as a proposed extension to the mod.ini file.  The feature is not currently implemented, and because -tbp and -wcsaga have been removed from .12 the need of this feature is diminishing rapidly.  But because we intend to support .10 builds for at least a year or two more (wxLauncher does) the feature will likely end up getting implemented anyway.

[extremeforce]

[extremeforce]
forcedflagson  = -tbp -ship_choice_3d
forcedflagsoff = -3dradar -infotext

Now we're getting technical. In this section you can specifically name some flags that must be always enabled or always disabled for the users of your MOD.

    * Use extreme caution when adding flags to this section. Be very sure that your mod needs those particular flags to be always enabled or disabled, or you might end up with an avalanche of hate mail in your inbox. Worst case scenario, we'll get them too for allowing you to force some flags.

Be careful with the flags set in this sections. Even better, try to have no flags in there if possible. And keep in mind all the user has to do is open your mod.ini file to remove this.

Note: forcedflagson takes precedence over forcedflagsoff. That is, if you specify a flag on both lists the flag will be forced on. This allows the default forcedflagsoff flags to be enabled for the mods that use those flags. See forceflagsoff for details.

Also Note: If you find it necessary to use these options, you should also bring it up with the SCP as it is likely something that should be moved into the tables.

forcedflagson

A list of flags that are a must for your mod to work. The format is very simple. List flags one after another (including the "-" character) and separated with one empty space. Take a look at the sample above for an example.

forcedflagsoff

This section does the opposite of the one above. It disallows the user to activate some flags that you know it will break your MOD or will add gameplay-altering elements to it.

Note: -tbp and -wcsaga are always on this list.

[chief1983]

That could work, and I think that giving 'user choice' options the ability to be further limited by a multiplayer host would be ideal.  That could be something like an F3 options menu that they bring up on the hosting menu maybe that lists the remaining options and whether to leave them user controlled or forced to the server setting.

Many things that are desired to be controlled by a launcher though would be better served by an in game control, even as opposed to a menu option.  Cockpits are a very good example of this.  Most games allow you to disable the cockpit with a key in game.  With the new pilot code, adding a control for this should be possible.  FOV changes would be a good candidate for a look as well.  Instead of setting on the command line, defining preset FOVs to toggle through, perhaps even aspect-ratio specific lists.  It could just be increase by .5/decrease by .5 keys, returning to either the FSO default or a mod configured default every mission, or possibly saving the last one to your pilot with that particular mod (I believe the new pilot code will support that last bit, not sure though).

[Nuke]

i think this whole issue skates around something the game engine seriously needs, but nobody wants to deal with. frankly the game needs a new interface. i consider the launcher (as good as it is) a very hackish way to control game settings. nothing it does can be enforced, so i dont consider it a solution tot he problem. it still has its place and function though. its a good way to display information about mods and to let you pick them, you still have system level settings, like video mode, which has to be set at start up. i think in a perfect engine the engine itself would handle all that stuff and the need for a launcher would be completely eliminated. but i think that might be too much to ask from the scp. i dont want to invalidate anyone's work on the launcher of interface templates (i consider it a brute force way to customize an interface which should have been upgraded a long time ago, but it too still has its place (see below)), i just want to point out an area of the engine which i think is in dire need of improvement.

we already have the means to render a gui, all the scripting hooks are there for all parts of the interface. you can execute script at the opening, while viewing/interacting, and on exit of any section of the interface. i have put some effort to creating a script to deal with gui elements, which exploits those capabilities. its a system ive been working on mainly for my own mods, so that i could have in game settings that work in game. my script puts a lot of changes into the users controls, and given that all users do not have the same control options, and asking the user to edit a text file to change a preference is not a very good option. the idea was i could just "add a button" to the options screen, by placing it over an unused area of the interface. then i considered that it may at some point be able to replace the entire interface. one idea i considered is that the gui would need to do everything that can be seen in the hard coded interface. i even considered the idea of making a scripted interface with the exact same layout of the hard coded interface, which could be skinned with the interface templates. mod developers could of course design their own interfaces with a few function calls to my gui script.

now heres the problem, such an interface can only speak lua, it cant control anything that scripting cannot control. however if scripting did have control over ingame options the above system would be indispensable. you could use the engine without any of the fs2 resources or standinds thereof, you could expand it as more options become available, you could customize the hell out of it, you could even use it in-game and make it part of the gameplay. if theres a game setting we want to lock down, we can just hard code it in script tell the engine the value we want to use and dont give the user a gui interface to change it. with it we can change graphics settings, change multiplayer options on the fly, and do away with the mess of launcher flags we currently have to deal with.

im not going to get into the developers vs players debate of what the user should be allowed to change. if i dont like the radar, il script a new one (its actually very easy). the developers have a right to decide the rules of the game, including what should be an option and what should be enforced. i personally always hated going to multiplayer and being told that i couldn't ease my pyromaniac urges with infyrnos. as far as i was concerned these weapons were a valid part of the game, put there by the people who wrote the rulebook. anyone who uses their skills to break the rules is called a cheater. if you cant deal with the rules, dont play the game. now if the developer did something stupid, like force me to use a non-inverted mouse, i would probably be so pissed off about it i wouldn't play the game. as a developer id hate to force people into something that was detrimental to their experience, id want to give them as much control as i could. pure multilayer fps games showed the way by giving the game host more control over the rules, an idea which is really cool. where does this bring us, back to the original problem, we need a better options interface. it would solve most of the problems in this thread.

[chief1983]

I think my main issue with the options being controlled being in the code, and the control for them being in scripting, is making sure the control for an options gets added.  Whereas with a hardcoded in game menu, you'd have it as soon as you change builds, you'd need to constantly script-swap when a new option is introduced.  So I'm not sure scripting is something I'd want to see doing this.

[The E]

Interface rewrite? Yes. Interface rewrite using lua exclusively? Hell no.

There already is a stub for a new UI system in the engine, added way back when the F3 lab was introduced. That's what we should make usable first, Adding scripting hooks while we're at it.

[Nuke]

it wouldn't use scripting exclusively, scripting would just provide the gui. many game engines use their scripting system to place gui elements. say i wanted to edit sound effects volume, when i moved the slider and let go the script would tell the game what setting is being changed (sfx volume) and what its being changed to (the volume level), the game could then decide if the setting was valid and provide a return to indicate to the gui whether or not it was successful.  yes, you would need to update the script when the engine adds a setting. but then again you would need to edit the interface graphics anyway each time a setting was added. you may have too many settings in one place and need to rearrange the gui to make everything fit. seems you would have some deal of maintenance to do to keep the interface up to date anyway. a good gui would also include a console where you could change settings by typing in a command, just in case it hadnt been added to the gui yet. this would come in handy for the experimental builds that have new settings so they could be tested with the console, and then when the official release comes out, you can update the gui. the engine would decide if the setting is valid or not, it could look up the settings table tags to see if the user has the right to edit it or not.

[chief1983]

The ship lab gui doesn't have any 'graphics'.  You'd update the code that draws the option elements at the same time you update the code to support the new option.  No scripting changes needed, only code, and builds only show the options they support.  Scripted menus are just too inflexible for a dynamic system like that I think, unless the scripting is truly used to draw it, but told what to draw by the engine itself.

[Nuke]

The ship lab gui doesn't have any 'graphics'.  You'd update the code that draws the option elements at the same time you update the code to support the new option.  No scripting changes needed, only code, and builds only show the options they support.  Scripted menus are just too inflexible for a dynamic system like that I think, unless the scripting is truly used to draw it, but told what to draw by the engine itself.

i was thinking the gui could query the engine about a setting to see if it was available, what range of values is supported, whether the user could have read or write access. the gui would then be able to grey out or completely disable the gui element of any setting based on that information. if the setting is available it would say what the valid range is and the script could adjust the interface accordingly. having the gui scripted lets mods completely rearrange the interface and make it look any way they want it to look.

as for the lab gui i really wish we had scripting access to that. if the gui elements were handled by the engine you wouldn't need to have a huge script file for the gui itself, you could get right down tot he nitty gritty of where everything goes, what it does and how the user controls it. i know the interface is somewhat skinable, i think i provided some interface graphics to wmc for testing it (i dont think it worked very well though). i was under the assumption that it was kind of an abandoned oddity in the engine to which nobody really pays any attention. it should be able to mimic any gui element in the game's hard coded interface. doing everything with hard to see drop down menus might get a little bit annoying. with the right skinning capabilities it could do anything a scripted system can and faster. still it should be customizable through scripting and settings for scripted features should use the same interface as hard coded features. in game interfaces in general should be fairly consistent.

[The E]

Here's a plan for you. Take a look at lab/wmcgui.cpp and lab/wmcgui.h.

There we have a system that is already set up to create a UI based on parsed tbl data. What we could do is first enhance it, so that it can do more than just draw strings and buttons, then set up a tbl parser so that we can override screens as we wish (similar to the HUD rewrite), and then write tables to our heart's content. Building a new UI system that exactly mimics the retail UI would be stupid, IMHO. Better to build a completely new system from scratch that modders can use, and keep the old system around as a fallback. Just as an example, this is what the engine is currently looking for as an interface.tbl. I'd say that's a starting point we can use.

[Nuke]

il have a look, but last time i did i went insane.

no wonder, it looks like this thing was slated to become part of ferrium.

[Goober5000]

Too many responses, not enough time...

I did want to address this one part:

We're starting to get working cockpits for FS2 ships now. And it's only a matter of time before people start wanting to put those in the mediaVPs. And then we'll have this issue all over again. You'll have people who don't like cockpits and want to play the game exactly as it was in retail and other people who want to play with them turned on. So someone will suggest having a launcher flag, keypress or menu option to turn cockpits on and off. Which will work just fine until some mod, be it Blue Planet, BWO, or whoever takes the cockpits and makes them a part of the game which isn't optional.

Now we have a problem. Since cockpits aren't optional for this mod the developers haven't bothered testing the mod to see what happens if you turn them off. But a significant percentage of the userbase have already activated the -no_cockpits launcher flag. So now what? Either you force the developers to support having no cockpits even though they may have designed scripts, missions and effects with them in mind or you make them release the campaign and somehow tell the users that they must turn on cockpits. We all should be well aware of how successful we have been in the past when we've told people that they must do something in order to have a mod work.

Substitute "mediavps_3612" for "3D cockpits" and you have exactly the problem that's going on now with the FSUP.  Regardless of user preference, mods have the responsibility to accommodate both the presence and absence of an optional feature.

[karajorma]

Only if it is an optional feature though. And that's my entire point. If a developer doesn't want something to be optional they definitely should have that choice.

Sorry but you are dead wrong on this. I'm a NOT going to waste the teams time insisting that Diaspora support users who decide to turn off "optional" features like cockpits, DRADIS, DRADIS icons or any other feature that the team have decided is an important part of the game by making those features work in a different way if turned off. The number of possible permutations will only increase as more features of this type are added and people insist on having some way to turn them off even if that would ruin the mod or game. Instead of actually working on the game as we want it to look we'd have to waste increasing amounts of time on stupid questions like "What if the user turns off DRADIS but leaves Radar Icons on? What if they turn off the cockpit model (using RTT) but leave DRADIS on?"
 It's a completely pointless waste of developer time and I flat out refuse to do it.

Nor am I willing to put up with any such choices from the user ending up in crashes that we then have to support by talking the user through turning those switches back on. I took the -wcs and -tbp flags out precisely to avoid that kind of stupidity and I'm definitely against having it back.

The only sensible solution to this issue is to allow the developer to decide which features he wants to support and which ones he doesn't. Some people want to do this by forcing launcher flags while others agree with me about using tables but either way it definitely is something the developer has to be able to decide.

[Fury]

Every time I think I couldn't disagree with Goober more than I already do, he always manages to surprise me in ways I never would have thought of.

I strongly support karajorma in this. Mod developers should have control over what features are optional and what are not and also have control over what are enabled by default.

[chief1983]

Goober's point about the MediaVPs is still valid though, as slaving oneself to them in bad ways can cause problems down the line.

[The E]

Wrong. Slaving yourself to a specific version of the mvps should always be safe.

I mean, why should we (as BP, for example) design our mod in such a way that it can run without issues using only retail as a base? We've deliberately set it up so that you need BP1 and the mediavps 3.6.12 installed because that's the only way that we can guarantee a consistent experience (not to mention, small downloads). Could we make it to run on retail alone? Probably. But why the hell should we? Why should we spend days testing all the permutations, when we know that we already have a working configuration that can be used by the vast majority of people?

I'm very sorry, but with all the data a mod like BP needs, making it all independent of the mediavps just isn't a viable option.