I've taken a longer look... here's what I think. Strail... I'm not being defensive. I said that I was risking being pretentious because I rarely come down against somebody working on a wild and crazy idea- if we didn't have wild and crazy idea people around here, nothing would ever get done that was new. I really, really appreciate that
TheJkWhoSaysNi has shared this approach. He's more than welcome to build some test cases to prove my doubts wrong, just as I have done to deal with people's doubts about some of my crazier schemes- maybe I'm just not seeing something obvious, k? I try to remain objective about this stuff- it's all science, and if it works better than what I already know how to do, I'm going to rebuild my Toolkit to use this technique.
I just don't think it works any better than what we already know how to do.
Here's why.
The whole adding ships to have NPCs fly them problem referred to by Accushot is just the tip of the iceberg. You can solve that with XML in addition to the XML you'd already have to write to make a truely modular and extensible freelancer.ini... so why not go the whole way, and just make the whole thing XML? This chicken/egg scenario keeps coming up over and over again. Basically, you have to keep returning to XML to get things done, or hand-alter INIs all over again. Trust me... I am in total sympathy here. For the Toolkit, I had to also hand-edit a lot've INIs, or use very extensive grep find-and-replace techniques. I was building it to help others build things faster, though, so I figured that the work put in now would be worth it, in terms of time saved later.
But... there might be one use for this that is superior in the limited areas it can mod. You could leave your new "Argh_shiparch.ini" file blank, refer to it in freelancer.ini, and then have an XML script append your ship's script to the blank file... thus creating a clean, seperate shiparch entry with Infocards (this is a trick I've used extensively for new System names, among other things). This would give us a seperated shiparch ini that also generated DLL strings on execution.
I just don't think that would do much for us, other than slightly lowering the already-low chance that our data became corrupted along the way- but that could happen anywhere along the file-transfer process. FLMM doesn't corrupt data, in my experience, if you write your code correctly. That's why I wrote the Toolkit Mod... to demonstrate good coding practices with XML, including sequential operations and modularity. Since it appears that we will probably get at least one new version of FLMM (Matt is working on it now), we will have even more features to play with, which makes this approach even less attractive.
For things like ship CMPs and everything aside from INIs, Freelancer allows for users to define the directory locations, etc., at will. So we're just talking about the very few INIs that are important enough to mod, but not important enough that DA hard-coded them
And there's that problem with market_ships I was referring to earlier, whose implications seem to have been ignored.
Market_ships is one of the areas where you're going to run into serious trouble. Why? Because you cannot extend it, is why. Market_ships can only be modified by replacing existing entries, or by building entirely new Bases with Mbases entries, etc.... or adding Rooms to existing Bases (which is what i've been working out for awhile now).
So making a seperate market_ships for your ship to be sold on Manhatten, for example... is useless. There are already three entries there... it won't work. I dunno about even adding entries to shipdealers that already have one or more... and I certainly expect that if you had multiple mods with their own customized market_ships... surely they'd overwrite each other. It sounds like a mess to me
I'd need to see a side-by-side pair of ship mods active to test with... but I have a feeling that one of the ships simply won't show up at the Shipdealer. Best to use XML and the stripped-down market_ships from my Toolkit to do this with, imo.
I've been working on a solution to that issue for the next version of the Toolkit- a better-organized and easier-to-mod market_ships for stock FL. It won't cover TC mods or system add-on mods, but it'll provide a better template for this kind've modding. But it still ultimately involves some modification of the core file- you simply cannot avoid it. You can get around it with things like ships or weapons, but when you're touching upon areas that are keys for gameplay... I think this approach breaks down. XML/FLMM allows us better code control and greater power, and with properly-prepared INIs (which was the bulk of work put into the Toolkit) you can do a lot more with it than people think.
Mon May 16, 2005 9:53 am 
