Sun Sep 25, 2005 11:01 pm by Argh
Um... well, basically, you need to get rid of a lot of things in order to have a "blank" FL. Anything that references anything else needs to have been removed, where possible, and that's a very long chain of items.
If done properly, you should end up with a "reverse SDK", where 95% of the INIs are blanks, or contain just a few entries, and FLMM would essentially replace just about everything with blanks, which should shorten load times for TCs to a very small fraction, as well as providing super-efficient execution- you'd get to see how well FL can run with very little "stuff" to eat up RAM and slow down its internal parser/search/execute routines.
This is on my list of projects, but I have other fish to fry first- I will be coming back to this at some point, though. I would like to see this get built about as much as anybody, but I have to prioritize my time spent on modding, and getting the next version of the Toolkit released is my highest priority right now, followed by several other things before I get to this. If Bejaymac or others are interested in pursuing this goal... basically, here's some concrete advise on how to build this:
1. I would use Alternative OpenSP as a starting-place, but have it point to a new System, that features exactly ONE Mbase entry.
2. Gut everything having to do with Systems, Bases, Solars, Universe, Equipment, Shiparch, etc., etc. etc. Blank them all out.
3. Building from start, create one System. It needs to have a Light, a Dockable object that docks with a Base, and that's it. You could be nice and include a Zone or three and a Nebula and a Field, so that there is "one of everything" in the mod.
4. Building from start, create a Ship. This includes an Engine, a Thruster, a Shield, a Weapon, a Powerplant, a Light, etc. This will also require entries into market_ships, goods, etc. to complete correctly.
5. Build a single AI, a Faction, and assign a Loadout, npcship, etc. to the Faction, so that it can spawn the Ship and fly it around.
... and that's pretty much all there is to it. I'm making it sound easy but actually executing this will be a pain, and rather time-consuming. It's not something you want to try if you aren't thoroughly experienced and understand what INIs refer to other INIs... because for this sort've project, neither FLSpew nor FLScan are likely to help you get things fixed if you screw up.
If I were wanting to try this, I would start with the XML Toolkit Mod laid on top of the SDK 1.5, and then go from there. Why start with the Toolkit? Because:
A. It already has complete Shiparch/Npcships/Loadout stuff already implemented in XML/FLMM format, so you can skip that part.
B. It already has the AI files almost completely gutted, and the AIs that are in there are "complete", so that it's obvious what you need to do there- just delete all but one.
Basically, you're going to spend a lot've time blanking out all of the INIs, and then you're going to need to painstakingly build up everything, one step at a time, until you have a complete, working game.
Using workarounds via Alternative OpenSP is a easy alternative... but it's not really a complete solution, nor does it avoid potential conflicts and errors. Which is why I think that it will be in everybody who wants to work on TC mods of various kinds interests to get something like this built, so that coders can start with a "clean slate".
Edited by - Argh on 9/26/2005 1:34:56 AM
Just think OSP in a mod thats between 10-15kb in size, and TC's that can finally get rid of the mission files and every other reference to the vanilla systems.
) will nolonger get slagged for not testing their mods in SP as there is no SP with this. But because FLMM doesn't edit them there are no options like starting place, so players have to take their chances with where ever the mod maker puts them. This also means that because no 2 mods are exactly the same my files will work on vanilla and most small mods, any mod that has new factions, or altered/deleted vanilla ships & equipment will have to make their own.
).