Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Spireitemoose]

Will doing the above cancel out whatever I did wrong

You probably have a "BAT_MissionProCombo-PLUS_v2.0-Patch" or "BAT v3.8.X" folder in your BAT: delete it.

Does the X refer to the version I’m running eg 3.8.4?

Yes, any v3.8 version, including 3.8.4.

MPC-PLUS v2 will eventually be part of an official BAT-patch so if you don't feel confident just have a little patience

It works, thank you so much, incredible work by all concerned,  Cheers.

[cgagan]

Many thanks Whistler, great improvement (I find the object browser particularly handy)! Works flawlessly in my vp_modact. It's a great job your' doing!

[eddiek]

I just updated my VPmod installation. The only question I have is how to change the font size in the FMB?

[whistler]

Sorry eddiek, I missed this one. Try NG-HUD, it changes font sizes game-wide, including FMB.

[whistler]

IL-2 wasn't conceived as a mod-friendly game. No built-in support for mods of any nature. It is really difficult to create compelling mods that can be configured because of the lack of a proper mods interface. I dislike [Mods] conf.ini settings: you set your setting there and normally forget about it. That's one of the reasons I try my best to avoid any configurable setting in my mods.

An interesting Gunsight mod by FL2070 was recently released and this got me thinking: what if we could change [Mods] conf.ini settings directly in the game? Here is my (WIP) proposal, built in the widely available "Difficulty" screen:




It isn't elegant but way better than nothing. Depending on how mod X was created the changes may or may not apply immediately, without having to restart the game. In the case of the Gunsight mod I can change the settings "on the fly", before starting a new mission, and let me tell you the mod is more versatile and way cooler now!

Many mods, including some of mine, aren't ready to apply changes on the fly. The settings must be checked at run time and not during the initial load. I will be reviewing some of my mods and provide updates in the next few weeks while I keep working on the eventual MissionProCombo-PLUS v2.1.

Cheers!

[FL2070]

This is a very interesting development!

Maybe, I might make a suggestion or two: conf.ini settings in the [Mods] section have very technical (per se) looking names, and the range of inputs which can be used for them, and which input is default, is not always clear. Sometimes, the effect is not always clear too: for instance, the SpeedbarTAS setting could change the displayed speed to TAS, or add TAS as a second displayed speed, but it is not clear to someone who does not already know. The same lack of clarity found in these simple setting names can be said for, in some cases, which setting is used by which mod.

My suggestion is this: define and include a file—something like i18n/mods.properties—which controls the names of the properties as seen in this menu. For instance, "ReticleBrightness" might change to "[Reticle Brightness Config] Reticle Brightness (defaults to 70)" and "ngMAPhostile" might change to "[NG-MAP v3.1] Enemies on Map by Default (defaults to 0)".

Restrictions might also be implemented for certain settings like ReticleOnAtMissionStart so that the user can't set it to, say, -3, which may have disastrous or strange consequences. Maybe, certain settings could be marked as the "0=no 1=yes" type of on-off setting, and the "Value" box for those settings might be, instead of a text entry box, a dropdown menu with the options "False" and "True".

Anyhow, I feel slightly rude by now, having dumped all my ideas on you, but I hope I've given you some ideas if you weren't considering anything like this yet. I really like this development, and I'll be waiting for v2.1 with baited breath.

Cheers, and happy modding!
 

[whistler]

Very good suggestions, FL2070! Any idea can lead to good ideas so please keep them coming.

For a framework of the kind to work we must implement and document a set of rules and modders must follow the rules. If it had been done years ago modders would have probably embraced it but I am afraid we are a little late for all that. I like the idea of a i18n/mods.properties file (a lot!) but who and how will update and maintain this file?

Here is my take: we can implement a description field right below the list. When players select a parameter the description field gets filled with content located here:

i18n\Mods\ReticleOnAtMissionStarts.properties
i18n\Mods\ReticleBrightness.properties
i18n\Mods\ngMAPhostile.properties
...

Modders are in full control of their own files and they can provide any info and in whatever format, in example:

i18n\Mods\ReticleBrightness.properties

Code: [Select]

Reticle Brightness Config by FL2070
This setting allows you to change the Reticle Brightness at mission start.
Possible values: 0 (transparent) to 100 (opaque)
Default value: 70
Simple and functional.

[Vampire_pilot]

Very interesting approach there again, Whistler.

however, just as a note....

An interesting Gunsight mod by FL2070 was recently released and this got me thinking

You saw that there's this mod by WxTech, which offers a solution to the same thing without going into the conf.ini to begin with?

[whistler]

Yes, we are spoiled by so many great options!

The point however is about making more dynamic mods. The fact that players must close the game and open a config file to change something is influencing how mods get created in the first place.

[FL2070]

i18n/mods.properties [...] who and how will update and maintain this file?

Originally, I had assumed that the base mods.properties file would be updated by you, the creator of the mod which uses the file, with, maybe, some additions by individual contributors. Mods with conf.ini options would have readmes containing sections like "MPC+ 2.1 or later users add these lines to your mods.properties" so that the file could be updated to reflect mods that aren't in the base version of mods.properties. Mostly, though, releases of conf.ini-using mods tend to be very rare, so chances are it will almost if not never need to be updated. This may change, though, once version 2.1 with this new menu has been released. As you said,

The fact that players must close the game and open a config file to change something is influencing how mods get created in the first place.

Admittedly, the tediousness of maintaining such a file is a very good point. Such a situation is far from ideal, as members would need to check for new versions of mods.properties, and add new entries every once in a while, adding another layer of complexity to maintaining an up-to-date modded game with the latest and greatest from the community. Upon reflection, I prefer your way of going about things:

Here is my take: we can implement a description field right below the list. When players select a parameter the description field gets filled with content located here:

i18n\Mods\ReticleOnAtMissionStarts.properties
i18n\Mods\ReticleBrightness.properties
i18n\Mods\ngMAPhostile.properties
...

Modders are in full control of their own files and they can provide any info and in whatever format, in example:

i18n\Mods\ReticleBrightness.properties

This method is much more modular, reducing the chances both of of conflicts and of users having mods.ini with missing and/or outdated entries for the mods they're using. Allow me to add yet another layer to the idea: let's do this for the settings' names as well as their descriptions. The individual setting properties files could have two entries, allowing each individual setting its own file controlling both its display name and description. This would remove the requirement to have i18n/mods.properties, eliminating all the consistency problems. Here's an example of how one of these files would look, copying your description but in my format:

i18n/mods/ReticleBrightness.properties

Code: [Select]

name Reticle Brightness
description Reticle Brightness Config by FL2070\nThis setting allows you to change the Reticle Brightness at mission start.\nPossible values: 0 (transparent) to 100 (opaque)\nDefault value: 70

This system allows for individual modders to just include the appropriate properties files in their mods for the settings they use, removing the necessity of opening the now nonexistant mods.properties for players installing mods which use the conf.ini. In my personal opinion, it's...

simple and functional.

Cheers

[Flying H]

Man, (men) assuming you go on realizing theese ideas you make this ancient game more modern than many new games out there! I´m eagerly waiting for the result of your ideas!

[whistler]

I think this will work:



FL2070, thanks for the comments.

I am discarding your name / description idea and avoiding any rules to keep things as simple as possible. Regarding the "name", there must be a relation between what players see on screen and what's in the conf.ini. The description field is therefore free-form: Modders are free to write in their .properties files whatever they want.

The advantage of using i18n\Mods\ is that there can be multiple i18n\Mods\ folders! One for each mod to be precise. In example, you can deliver your Gunsight mod with this format:

Code: [Select]

+---0_ReticleBrightnessConfig
|   |   1F8E9514CA7C6CDC
|   |   DA40F18C338F4036
|   |   
|   \---i18n
|       \---Mods
|               ReticleBrightness.properties
|               ReticleOnAtMissionStart.properties
And it will work

I discarded an option to delete entries. I don't want the average player to have that possibility.

I am thinking about a "New Key" button. I haven't yet decided it. Mods, if created right, can automatically add or modify [Mods] conf.ini entries.