Print

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

[UberDemon]

Request (for the Java gods!):  Alternate Way for Adding non-BAT release Aircraft MODs

BAT releases take a lot of work, and thus the reason it takes a while.  As usual in the mean time, aircraft/vehicle modders are working their craft away and offer some really good additional feature while we wait for the goods.

I often suffer from chronic old guy laziness and end up not installing a lot of these great additions because of the manual editing of “air.ini,” and if included, “plane.properties” and “weapons.properties” entries.  Some time ago back in the UP days, I had come up with a complicated batch script and JSGME solution which involved parsing air.ini, but eh…  not that great a solution.

I have a recommendation for a potential solution, which is obviously the request for the Java-abled:

PROPOSAL:   Programmatically create a MOD that can be installed in BAT or SAS MODACT that would allow the addition of aircraft (and other player enabled-objects, such as vehicles, ships, etc) without having to edit the core BAT / SAS files (speaking of air.ini, plane.properties and weapons.properties).

Simple Solution 1 (Alternative MOD files)
------------------------------------------------------
* MOD plane information would be entered in three similar files:
1) air_MOD.ini (similar to “air.ini” with short name & skin directory name, java class) (required)
2) plane_MOD.properties (similar to “plane.properties” with short name and pretty text display name) (optional)
3) weapons_MOD.properties (similar to “weapons.properties” with short name+weapon code and pretty text display) (optional)

* Installing a mod would be similar to what is done today, with mod installed in the proper #BAT directory.  The MOD should be included in each module (SAS, WAW, DOF, TGA, JTW) so you can have mods for each version/era.

* Upon start, IL-2/BAT/SAS would load as usual, but would also look for content in “air_MOD.ini” to see what MODs are available.  Then I would request for the loadup routine to load the contents of “air_MOD.ini” (and related properties files) in memory, appending them to the loaded list of planes from “air.ini” and other under a header similar to the other headers, something like “***Custom_Added_MODs”

Another Potential Solution 2 (Standardized Initialization File)
--------------------------------------------------------------------------------
* This would work similarly to solution 1, but with a gentlemen’s/ladies’ agreement on standardized format.  So in addition to the normal mod files, the modder would include a file with a standardized format.  I recommend the Short Name (because they are compatible with directories for skins) with an “ini” extension.

For example, a fictitious mod called MiG-28 woud have a file name of “MiG-28.ini”, and the contents of the file would be something like:

Code: [Select]

[air]
MiG-28   air.MIG_28     1 NOINFO r01 SUMMER
[plane]
MiG-28     MiG-28, 1986
[weapons]
MiG-28.default        Default
MiG-28.TCM             2x Tom Cruise Missiles
MiG-28.BVMB          1x Beach Volleyball Massacre Bomb
MiG-28.Napalm       6x Little Balls of Fire
MiG-28.Listerine      Take Your Breath Away Smell Bomb
MiG-28.BirdFlipper  Secret Weapon
MiG-28.Jammer       Mission Unpossible
MiG-28.Bankrupt     Empty

Something like this would better work if it was in the same directory as the mod itself… really simplifying the addition of mods for the user.

Eventually a “Desirement” would be how to automatically add static versions of those mods without having to do any editing.

A requirement would be to maintain compatibility with tools such as Loadout Lister and the Object list export feature in FMB.  I would imagine they would work the same and simply add the enabled mods to the lists.

Anyway, just thinking.  Always gets me in trouble, but could be possible and of benefit to the IL-2 user community.

[SAS~Storebror]

Simple Solution 1 to me has no advantage to the current state we're in.
You have to modify the same number of files and take care to revert your modifications to them in case you remove a mod.
The only thing that changes is the location of the files and the fact that this "solution" would somehow separate "official" content from custom mods.

Simple Solution 2 sounds reasonable.

Automatically adding statics will be very tricky.
IL-2 uses separate (sub-) classes for static objects.
If you'd want to create these required classes "automatically", you would need to do so at runtime.
Runtime classfile creation is possible in Java, but it only became usable with the implementation of the "JavaCompiler" class in JDK 1.6.
Prior to this, there is a custom tool called "Javassist", but it currently needs JDK 1.4.
Mind you, we're on JDK 1.3.
There is an old version of Javassist available with JDK 1.3 compatibility, but it contains custom classes that would need to be added to the classloader of IL-2 at boot time, i.e. would require il2fb.exe to be touched.
In summary, I don't think anyone would want to wade through this mess.

Compatibility with other 3rd party tools... well, where to begin with and where to stop?
Either it works or it doesn't, in doubt the tools would need to be updated to reflect Simple Solution 2.


Mike

[UberDemon]

Thank you for the reply, Mike.

Solution 2 would be awesome if implemented, I think.  It wouldn't be too hard to compile "ini" files for existing stand-alone aircraft mods.                                       

The static aircraft was an idea, thus, a "desirement".  Understand the complexity of the versions now that you explained it.

For example, the "ini" file for the recently released C-46 Commando by Ranwers (https://www.sas1946.com/main/index.php/topic,71217.0/topicseen.html) would be:

C-46.ini

Code: [Select]

[air]
C-46           air.C_46 1 NOINFO usa01 SUMMER
[plane]
C-46           C-46, 1940
[weapon]
C-46.default            Default
C-46.26xPara            26x Paratroopers
C-46.6xCargoA 6x cargo (3000 kg)
C-46.none               Empty

The end of the Aircraft selection List would look something like this:

Code: [Select]

*
***Vehicles
****************************************
*

Kurogane Type-95, 1936
Kubelwagen, 1936
Jeep, 1939
Jeep+50CAL, 1942

*
***Custom_Added_MODs
****************************************
*

C-46, 1940


[UberDemon]

Of course I would have done this myself if I was more well-versed in Java and the inner workings of the IL-2 engine itself, but my experience is limited to the Aircraft mods I did in the past (Ki-43s with loads, Fw-190s, TBDs, Jeep Gunner Experiment, IL-2 41 field mod with playable gunner, IL-2I and T models... to name a few), and that is a while back.

If there are any takers in this endevour, I will do the mod "ini" files for available add-on mods, even WIPs myself... it is only fair.  Appreciate the consideration of the Java modders here.

[cbradbury]

Hi Uber,

this is not something I would ever use myself, although my BAT version is very heavily modded. I do see some potential drawbacks with your approach which you might have to consider.

I always add new aircraft, ships, etc., using jgsme. I also have a folder with all my .ini files in BATMODS, and always amend these when adding an item, as opposed to the files within BAT, as it means I can easily roll back if:

1. something in the new aircraft install doesn't work, OR

2. I decide that I don't like/want it once I have tried it.

This procedure typically takes me about two minutes (in either direction).

Also, I'm not too sure about your idea of adding a 'custom added mods' line to air.ini. Obviously I would always add a new plane into the relevant existing category in air.ini - otherwise I would have to scroll down an already overlong aircraft list to find the C46, for example, whilst I would naturally add this to ***USAAF_Transport, which is where anyone would want it to be in their setup, surely?

One more thing - although BAT updates are necessarily sporadic, when they are released they typically include new aircraft, some of which will inevitably be in your mod - I suggest that you would need to cater for this occurrence as well.

Yours,

Clive

[UberDemon]

Sure,

I considered those because I apply them currently.  I create Jsgme additions to apply new mods all the time.  About 10 years ago or so I created a whole bunch of Jsgme additions using batch scripts.  It is all good and all, but what I am suggesting is an easier way to get aircraft mods to be added between BAT updates so that it is an easier update.  For example, I could add a new aircraft to my setup for the time being until it is added to BAT.  But if it is not added for any reason, you could still fly it.

It is not a requirement.  It is just a feature that adds flexibility for those who want to experiment with new mods.  Maybe they don't like it.  They can remove it if they want.  It is just a suggestion.

That is exactly what I did right here:  https://www.sas1946.com/main/index.php/topic,71217.msg775817.html#msg775817

Or you could do something interesting like below:









Sure, naturally, C-46 would be added to "***USAAF_Transport" in a BAT update, but until then, it may be helpful to separate user added MOds from the release features.  I am saying that because I consider BAT the ultimate non-stock release for IL-2 1946... outside of TD, which I have kinda given up on... but again, that is my opinion.  I am just asking for someone to consider my request.  If it does not happen, it's all good.  I'll live.  (I'll cry like a little boy, but that is OK...  )

[cbradbury]

I don't think it is a bad idea, not something I would personally use as I am a bit OCD about what I add - I like to be in full control of each stage! I know there are a fair few users out there who are not too confident about installing mods, so if it ever came to fruition it might be useful to them.

The irony of my approach is that my recently released vehicle packs for BAT are designed for jgsme implementation, but I cannot use them 'out of the box' as my personal .ini files are too heavily modded!

[SAS~Storebror]

There's one issue we haven't talked about yet and which to me looks like a showstopper for the whole concept:
The way IL-2 accesses mod files.

Say we have the C-46 mod and we all agreed that the easiest way to make such mods "drag & drop" compatible would be to add dedicated .ini files to the mod folder(s).
In case of the C-46 mod, the proposed ini file pattern e.g. for BAT 4.x WAW would be:

Code: [Select]

[IL-2] +
       |
       [#WAW3] +
               |
               [00_C-46 Commando]
                                |
                                + C-46.ini(Squared Brackets indicate Folders)

Time to take a glance at how IL-2 deals with mod folders:
The former "MODS" folder - nowadays, in this example, it's called "#WAW3" - is the slightly more complex companion of the old "FILES" folder.
The difference is that in the "MODS" folder, modded files exist in subfolders - here "00_C-46 Commando" - whereas in the old days of the "FILES" folder, they all sat in the same space, causing kind of a mess in case of bigger modpacks.
The "wrapper" scans the "MODS" subfolders at game start, alphabetically, and keeps track of which file has been found where.
To IL-2, this process is transparent: IL-2 only talks about hashed filenames.
It queries a file with a given hash to the "wrapper" and then the "wrapper" looks for the place where a file with the corresponding hash resides.
That works a treat, but: There is no way for IL-2 to "scan" for an unknown file in side the "MODS" or "FILES" folder or any SFS archive whatsoever.
IL-2 can only access known files through their hashed filenames.
That means: No such thing like "dir" for the mods folder. No such thing like "load all classfiles found in the mods folder". No such thing like "list all ini files in the mods folder".
None of this is possible in IL-2.

And that gets us to the problem: How would the game know that there is a "C-46.ini" file in any mods folder at all?
It doesn't know that any of the mods files exist in the first place, until some .ini file (per default: air.ini) tells the game to load the aircraft's classes - which in our case is the classic hen egg problem:
Unless we load the C-46 class, the game cannot know about C-46.ini.
Without C-46.ini, there's nothing that could tell the game to load the C-46 class.


Mike

[UberDemon]

I don't think it is a bad idea, not something I would personally use as I am a bit OCD about what I add - I like to be in full control of each stage! I know there are a fair few users out there who are not too confident about installing mods, so if it ever came to fruition it might be useful to them.

The irony of my approach is that my recently released vehicle packs for BAT are designed for jgsme implementation, but I cannot use them 'out of the box' as my personal .ini files are too heavily modded!

Funny thing is that I am pretty OCD as well.  I definitely don't want a solution looking for a problem.  For the examples I presented above, I created JSGME MODs, named #MOD1, #MOD2, #MOD3, and #MOD4.  Problem is that each one of them has a different "air.ini"  and they can only be installed, de-installed sequentially.  Say if I wanted to keep only MODs 2 and 3, I could not do it without keeping MOD1... and I could not just remove that without screwing something up... quite a conundrum.  I am not sure there is a good way to do that.

[UberDemon]

There's one issue we haven't talked about yet and which to me looks like a showstopper for the whole concept:
The way IL-2 accesses mod files.

[...]

And that gets us to the problem: How would the game know that there is a "C-46.ini" file in any mods folder at all?
It doesn't know that any of the mods files exist in the first place, until some .ini file (per default: air.ini) tells the game to load the aircraft's classes - which in our case is the classic hen egg problem:
Unless we load the C-46 class, the game cannot know about C-46.ini.
Without C-46.ini, there's nothing that could tell the game to load the C-46 class.


Mike

Ah man...  OK, I see the flaw of my suggestion then.  IL-2 simply doesn't know how to handle that within the FILES structure.

Would it be possible to add a modification as follows:

* Create a folder, like the ones for SFS files, say, a "BATMODINI" folder which contais all the "ini" files, such as "C-46.ini" and others...
* Go through directory and gather the data from the "ini" files to compile something akin to my original Suggestion #1 (basically compile the data from all inis into something like an air_MOD.ini, plane_MOD.properties and weapons_MOD.properties), add the contents of those files (or could just be in memory) to to the original air.ini, plane.properties, and weapons.properties that will be loaded during program start.

This way the IL-2 engine would not have to think where to find the ini files, it would go back to what it knows, which is to just go through air.ini.  Not sure if there is a way to load that from memory info as opposed to having air.ini physically modified then loaded.  That goes beyond my knowledge.

That maybe beyond the scope anyone is willing to look into, and I apologize if I sound like I am minimizing the effort that this would take.  Although I am not as familiar with Java, sometimes what seems to be a small ask translates to a lot of coding effort.

Thank you for considering it though.

[SAS~Storebror]

Sounds like a plan.
Maybe in order to make this compatible with other game versions than just BAT, we could agree on some "encoded" air.ini line like...

Code: [Select]

***MODS_from_BATMODINI                       air.ModsParser...which would load the "ModsParser" class, and that class in turn would then do all the parsing tricks and add the found aircraft right after that particular line.
Theoretically the list of added mods could appear at any point in the list of available aircraft that way.
And furthermore, the name part after "***MODS_from_" would form the folder to be parsed.


Mike

[UberDemon]

I see.  That would be a great approach.

Is there anything I can help with?  I can start compiling ini's from known Mods.

The only caution I see is that if a MOD "ini" is in that directory but the MOD files are not installed, it may cause a problem similar to any MOD that is not installed properly (CTD, etc), so making sure everything is installed properly will have to be a user expectation (as it is for most things).

Something else I just thought about... it probably needs a distinction within BAT modules as well...  Something like

BATMODINI\#DOF
BATMODINI\#TGA
BATMODINI\#WAW
BATMODINI\#JTW
BATMODINI\#SAS

A WW1 plane may not work at all when starting JTW, as an example.

With the parsing looking for everything after "***MODS_from_", it would be a matter of different forlder names... if there is not issue with additional folders, they could be BATMODINIDOF, BATMODINITGA, etc, for example, unless there is a way to put subfolders in the BATMODINI directory and have the parser recognize that.

For compatibility, should there be the ability to get input from optional "[plane_ru]" and "[weapons_ru]" headers in the "ini" files?