Higus wrote:Do you possibly plan on making mods like this not attached to IH, to go for a more external officially-integrated-kinda-feeling mod outside of IH's increasingly expanding trainer-like layout?
I want to add some kind of external "sub mod" like support for sideops (there's too much stuff involved in adding them to have anything completely separate from IH that wont conflict), but there's a couple of challenges.
IH system being able to figure out what sub mods are 'installed', I can either:
Handle it the way I've been handling the other stuff, have the user manually edit a list of them, but that can be a hassle.
Use os.execute to use dir to get a file list, but that pops up a command prompt for a second which can be annoying.
I kinda want to be able to include my defaults stuff without the user having to get/install it separately, but that kinda goes against my default-by-default policy.
It's the same issues that some of my other features (that I have no idea if anyone is using) fova for model swaps, new head mods, and profiles has, ideally I should come up with a pattern that handles them all.
Sideops have a couple of further restrictions that make things tricky:
Their open/active/cleared states are saved to an integer indexed array, while the game doesn't seem to care what goes in/out, so stuff could be added in any order, or removed, it does mean I'll have to figure out a way to handle that. Actually, head mods have a similar issue, which I haven't done anything about, but currently the user can just manually change the head setting and it will fix.
There's also possibly some kinks in the completion system, or something else, that I haven't discovered.
Another issue is the quest system uses a specific format for its questName - <something_>q<quest id number>
ie cliffTown_q11040 or quest_q52080
I see a couple of functions where it parses the questName by grabbing the last 6 characters (ex q20103) or 5 (ex 20103)
I don't think the <something_> has to be anything specific, the game does have them either named after their quest area, or just as "quest_". Again, it's possible that I've missed something though.
This means sideops mods would have to choose an id number that doesn't conflict with any existing ids (easy enough), or any other sideops mods.
Though for just testing/unreleased sidops you can use whatever you want and handle any collisions yourself.
Ultimately it could possibly be worked around, but would require an outside install step writing a given id to lng.xml files, running lang tool on those, packing it and who knows what else.
The simplest solution is 'hey tex, I want to release a sideops mod, what id should i use?', even though in general I don't like the 'relying on a guy' method, more so when I'm the guy lol.
nasanhak wrote:
Also, since your building custom fpkds now - how likely do you think it is that custom fpkds for armored vehicles can be successfully created now allowing for their usage in free roam?
Do you mean allowing the player to use them, or the reinforcement system to, or just in general?
At the moment the patched player/relief vehicle packs veh_rl achieves the the last two.
For the player being able to use vehicles, I'm not sure what actually flags them as usable, I had a brief look (a million years ago) at M30 since it has empty usable tanks, but didn't find anything noticeable back then.
For the reinforcement system in free is already complete as far as I can tell and it's something in the engine that's stopping the reinforcement vehicle call.
I think reinforcement vehicle should be able to be extended to other missions if the reinforcement block is included, was actually looking into that before I got side tracked by sideops.
Should also probably shift the patched player/relief vehicle packs to their own, but that would essentially be recreating them. I'm also still not sure what take priority in terms of data definitions of the same gameobject.
