A Different approach to adding mods?

The problem with that is that not all the files are referenced in freelancer.ini. The location of files such as the NPC ship files are hardcoded in the DLL´s - content.dll in fact. This means you can only ever have one npcships.ini unless you want to try editing the executable code.

That´s true. But for adding ships and equipment, surely this way makes more sense? You could easily have a ship pack which involves just copying and pasting files and adding a couple of lines to freelancer.ini Maybe it´s because i´m used to OO programming but it makes more sense to me not to edit the original files unless you have to.

I´ve been working with the "new file" concept for a while too, and it DOES offer possibilities for clean extension that people simply haven´t exploited enough; however, it also has limits. Some paths are still apparently hardcoded in the binaries. The real reason why everyone uses FLMM is that it´s basically been the best all-around tool for this job that allows some degree of interaction between mods. It´s still bloody ugly to work with for some problems because it is does "simple" exploiting of Freelancer´s text-file-based data sources. It has now become the de facto standard because it generally "just works". There definitely are some better ways to do this. You´re exploring one that really could USE exploration. Another one is Bas Westerbaan´s Intrepid.Corelib library that parses "ini" files and returns an abstract structure which can be updated on the fly. The ultimate answer would be a project to actually treat the INI files as a database with real records and links. Datastorm does this in a weak way (the "datastorm.fl" file it creates is really just a simple Access database - unfortunately with no heavy link-creation done...). A ´real´ tool could produce a reference Freelancer database, then apply mods as sets of database updates - with the ability to roll back directly from the transactions list. Of course it would still need to generate the ini files from itself when mod sets are applied, but it would bring us very close to a situation where mods could really be thought of in terms of objects - systems, bases, equipment, ships - without having to worry about careful insertion of all the crossreferences everywhere.

WatercoolerWarrior, that is a very nice idea. Of course it´s a lot of work too. The main advantage i can see to adding new ini files is that you could chain up mods. Imagine 2 ship packs. They both need to edit shiparch.ini, market_ships.ini they could each have their own ini files. The only file they would both need to change is freelancer.ini even if the ships are sold at the same base the marketgood sections get added from each ini file referenced. This would make adding and removing equipment mods as easy as commenting out lines in freelancer.ini but as you point out some things are unfortunatly hardcoded. By my reckoning (although untested) you could add the following things without editing any file other than freelancer.ini -Ships -Weapons -Commodites -Universe I´m going to see if i can change constants.ini values with the addition of a file too. edit: Success. By adding another constants entry in freelancer.ini i changed the cruising speed by another file. Edited by - TheJkWhoSaysNi on 5/16/2005 6:39:02 PM

I´ve been playing around some more and the files dont even have to be in the correct folders. I have converted 2 mods to work in this way. Flyable osiris (buyable at manhattan) and the cruise speed 1200 mod. My directory structure is this: DATAMODSosirisshipsshiparch.ini DATAMODSosirisequipmentmarket_ships.ini ...etc... DATAMODScruise1200constants.ini All these files contain are the additions to the current files. Not new copies of all the ini files, just the mods. The directory structure doesnt actually matter. Infact all the market stuff can go in one file, all the equipment in another. I kept it like this for the sake of continuity. My freelancer.ini is set up like this: in the [data section: <pre><font size=1 face=Courier> ;############################################################################################## ;Mods ;Osiris Mod equipment = modsosirisequipmentst_equip.ini equipment = modsosirisequipmentweapon_equip.ini ships = modsosirisshipsshiparch.ini goods = modsosirisequipmentgoods.ini ;all the goods could go in the same file goods = modsosirisequipmentst_good.ini goods = modsosirisequipmentweapon_good.ini markets = modsosirisequipmentmarket_misc.ini markets = modsosirisequipmentmarket_ships.ini ;fast cruise speed constants = modscruise1200constants.ini ;############################################################################################## </font></pre> Is this method not a hell of a lot neater than modifying the original files every time? A lot of mods could be done like this and they would all work together. These are the things that cant be done in this way: -Info cards -HUD -Random missions Theres probably a lot more, but dont you think this method is a lot better for mods which add to the game?

Um... at the risk of sounding pretentious... While this idea has some merit, it´s not a panacea, and I´m not sure it gives us any advantages over what we can do with XML/FLMM. Take, for example, your adding ships issue. If you make mods with properly modular XML/FLMM scripts, you could add ship mod on top of ship mod, without any problems. This is because things like ship mods are always using append methods (at least they should be, except for one crucial area- market_ships.ini). So that, at least to me, is a non-starter. In addition, each mod would have to have a custom version of freelancer.ini in order to refer to the modules. This would also tend to make such mods difficult to integrate with one another in practice. In theory, we´d just append new data to freelancer.ini for each addon mod with XML scripts... but how is that any different from having multiple pure XML mods add their code to FL´s INIs sequentially? Ok, so now it´s just one INI, not multiple- it´s safer. But it´s also pretty limited, since we cannot do a lot´ve things with it. Like, for example, create Infocards and Strings with sequentially-executed XML scripts. I´ve been working on techniques to make mods fully-modular with XML/FLMM because it works, it´s simple, and it greatly reduces the need to use outside resources, such as hand-hacking DLLs (yuck!). Anything that trends towards more specialization makes me skeptical. Last but not least... there´s the efficiency issue. I´m no computer-science genius by any means, but I suspect that it´s less efficient for the FL game engine to refer to the various memory locations that each INI´s contents are assigned, for searching out the variable values. IOW, this idea might work great for one ship... but what about one hundred? That´s a lot of files! At any rate... I´m not hating this idea... don´t get me wrong here... I just think that there are some potential issues with it, and if we´re going to explore it, then we need to keep that in mind. If you want to understand why I´m such a big fan of using XML/FLMM, check out my mod´s current version, <A href=´http://www.lancersreactor.org/t/Download/Download.asp?ID=1753´ Target=_Blank>which can be found here.</a> Edited by - Argh on 5/17/2005 6:58:54 PM

Um... at the risk of sounding pretentious... yes you do <img src=smilies/icon_smile_wink.gif width=15 height=15 border=0 align=middle> This is exploration of the file, Argh you sound so defensive over the XML /FLMM method that I had to smile. I suggest that TheJkWhoSaysNi continues with this and sees what else can be done. Areas like this might appear on the surface to be limited, but its the other things that are learnt that help unlock other doors.

You´re right, there are some issues with the method, but they can be worked out or worked around, in my opinion. As for installing the mods.... XML isnt the answer to everything, and definatly not the best solution here. It would be very easy to have a program read file names from mods/modname and put them in freelancer.ini without the author needing to code anything but the mod itself. If the author wanted custom file names, you could have the program read inside the file to see what secions it contains and find out its type from that. (goods, market, equipment, ship, constant, etc) Infocards and strings, yes there is a problem here. If it were possible to edit the dlls on the fly (which i´m pretty sure it would be, with enough effort) you´d get the problem of ID clashes, again, with more complex programming, each mod which had ID cards could be given the next available id and the inis of the mod updated accordingly. As for efficiency, if you look at freelancer.ini, you can see what freelancer does when it loads. It takes each file referenced in freelancer.ini and puts it into a data structure (a tree by the looks of it) so each markets = file gets put into a data structure that contains all the other markets info. Adding an extra file does not change this, it just means it reads another file when it loads. Adding to the original files just means it has more to load from each file. The only difference in speed is the negligible time it takes to move to the next ini file. But lets not forget it´s already reading 100+ files anyway. Edited by - TheJkWhoSaysNi on 5/18/2005 6:55:34 AM

I can´t honestly see an advantage to this method over Argh´s XML method. What´s the difference between having multiple versions of each file and using XML to add multiple entries? FLMM handles appending/removing the sections perfectly adequately. Then there are the files that <i>can´t </i> be duplicated. Sure, you can add new ships to a mod in this way, but how do you expect to get the NPC´s to fly them. There´s only one, hardcoded file that deals with the NPC ships, so you´d end up modifying this one anyway. In the same way this will prevent you from adding new factions, missions, NPC´s and pilots, to name but a few. Then there is of course the danger of multiple files with the same name. What happens when two authors name their new shiparch file &quot;mod_shiparch_2.ini&quot;, for example? The phrase &quot;If it aint broke, don´t fix it&quot; springs to mind here...

What are the advantages? Ease of adding/removing, keeping everything seperate, no risk of needing to restore backup ini files if a mod messes up. It also keeps everything neater. Yes, there are restrictions although I have been looking into ways of bypassing them with limited success so far. As for name clashing, i already suggested giving mods their own directory so that shouldn´t ever be a problem.

JkWhoSaysNi: <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>What are the advantages? Ease of adding/removing, keeping everything seperate, no risk of needing to restore backup ini files if a mod messes up. It also keeps everything neater.. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> I think its safe to say carry on with what you believe in. If you think there are advantages for this, then with any work that you do - you can show the advantages of the system... hoping it catches on. However, contra to that - XML scripting can ensure mods can activate to be compatible. If its to ´build your own´ - I exampled the then &quot;new&quot; options of FLMM to an extreme potential of making customised things available. The added bonus was that you activate one mod - choosing as you go along. Your method would be roughly the same (build your own) - but you will need to activate more and more versions... Pursue it though, and demonstrate its use <img src=smilies/icon_smile.gif width=15 height=15 border=0 align=middle> Argh: <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>such as hand-hacking DLLs (yuck!) <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> Fraid some of us will never use the FLMM method. I cannot stand its generate IDS method - and much prefer to see my work in FLED-IDS. I have used it in the past, don´t get me wrong. Its just I don´t like it when compared to manually editing a DLL file. Edited by - Chips on 5/18/2005 1:32:07 PM

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 &quot;Argh_shiparch.ini&quot; 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 <img src=smilies/icon_smile_tongue.gif width=15 height=15 border=0 align=middle> 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 <img src=smilies/icon_smile_tongue.gif width=15 height=15 border=0 align=middle> 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.

Accushot keeps telling me that some files cannot be removed - but... <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade> goods = modsosirisequipmentgoods.ini ;all the goods could go in the same file goods = modsosirisequipmentst_good.ini goods = modsosirisequipmentweapon_good.ini markets = modsosirisequipmentmarket_misc.ini markets = modsosirisequipmentmarket_ships.ini <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> The goods files say in the square brackets what the object is, and also categorises it by its category line. I think you could condense that to just one goods = file: goods = modsosirisequipmentosiris_goods.ini and then add all the goods into that file. Same for markets... plonk ships and weapons and commodities all into one file. After all, I do not think its the filename that matters here - its the cross-referencing that makes the difference. Give it a go, it would cut down on file numbers etc. The worst that could happen is that it crashes - and I can finally (after about 2 years of speculation without trying) stop dribbling on about it <img src=smilies/icon_smile_tongue.gif width=15 height=15 border=0 align=middle> (no - never bothered enough to actually try it). Edited by - Chips on 5/18/2005 1:43:53 PM

i dont have time to address everything but i´ll mention what i´ve tried with market_ships.ini The third number in the marketgood line is whether or not that good is sold. It´s possible to stop one (or more) of the current packages being sold by changing the third number to a 0. This frees up one of the spaces. for example your custom market_ships.ini: [BaseGood base = Li01_01_base marketgood = lf_package, 1, -1, <b>0 </b>, 1, 0, 1, 1;stop this ship being sold, so the new one can be marketgood = new_ship_package, 0, -1, 1, 1, 0, 1, 1 I´m replacing the entry... but not in the conventional way. Of course there´s still a problem when two ships want to use the same slot on the same base, but doesnt this also happen with the XML method? Whatever happens there is the hardcoded 3 ship limit per base.

Chips : There´s no substitute for hand-hacking DLLs for some things, such as new Factions, anyhow. I think FLMM does just fine for ships, equipment, market items, Bases, Systems and Solars. If you write it sequentially then it builds the DLL entries

Chips: Yes, all the market files can be condensed into a single file.. the same with equipment and ships because they´re all of the same type. I kept them like that for the sake of consistency with the game :p File name makes no difference at all, so long as each file has only one type. Edited by - TheJkWhoSaysNi on 5/18/2005 1:51:05 PM

TheJkWhoSaysNi : Nope, the collisions that can occur with market_ships can occur with either method. What I´m pointing out is that with XML you´re a lot less likely to have complete failure. This is because while one mod may overwrite another´s entry

But then the original ship you´re replacing is likely to be no longer sold anywhere...

Nope... The first code appends the Dragon to every location selling ke_package. The second XML mod simply replaces the ke_package at one location ... it´s a targeted replacement, not a blanket one. This is a crucial distinction, and I thought it was obvious, so I didn´t explain it well, sorry... That´s the whole point. XML/FLMM allows us to do targeted replacements. With properly-formatted INIs that are ready for such targeting (one of the big goals for the Toolkit) you get as much control as you need. If you look at the way I re-formatted weapon_equip.ini in the Toolkit, you can see the exhausting lengths I went to, to make every Weapon´s specific variable values (for everything that´s core to gameplay) targetable, so that modders could modify with great specificity without having to include gigantic search matches in their XML scripts (a major bane to search efficiency). For example... take a look at the code for fc_j_gun01_mark01: <pre><font size=1 face=Courier> [Munition nickname = fc_j_gun01_mark01_ammo hp_type = hp_gun requires_ammo = false hit_pts = 5000 hull_damage = 50<b>;JUNKER PHOTON GUN1 </b> energy_damage = 0<b>;JUNKER PHOTON GUN1 </b> lifetime = 0.8<b>;JUNKER PHOTON GUN1 </b> weapon_type = W_Photon01 one_shot_sound = fire_photon1 munition_hit_effect = pi_photon_01_impact const_effect = pi_photon_01_proj force_gun_ori = false mass = 1 volume = 0.000100 [Gun nickname = fc_j_gun01_mark01 ids_name = 263175 ids_info = 264175 DA_archetype = equipmentmodelsweaponsli_auto_cannon.cmp material_library = equipmentmodelsli_equip.mat HP_child = HPConnect hit_pts = 5000 explosion_resistance = 1.000000 debris_type = debris_normal parent_impulse = 20 child_impulse = 80 volume = 0.000000 mass = 10 hp_gun_type = hp_gun_special_2 damage_per_fire = 0 power_usage = 8<b>;JUNKER PHOTON GUN1 </b> refire_delay = 0.12<b>;JUNKER PHOTON GUN1 </b> muzzle_velocity = 750<b>;JUNKER PHOTON GUN1 </b> use_animation = Sc_fire toughness = 2.400000 flash_particle_name = pi_photon_01_flash flash_radius = 15 light_anim = l_gun01_flash projectile_archetype = fc_j_gun01_mark01_ammo separation_explosion = sever_debris auto_turret = false turn_rate = 90 lootable = true LODranges = 0, 20, 40, 60, 100 </font></pre> Do you see what I´m driving at now? The problem, previously, with XML modding (besides people´s confusion about how it executes code and creates DLL entries, which I´ve gone to great lengths to explain and demonstrate in the code) was targeting the data you wanted and replacing it with accuracy. I´ve taken care of this problem in the areas that I thought were most important for everyday modding- not everywhere, because contextualizing every single INI entry would just take too darn long, even with the grep methods I´ve been using- there´s a certain amount of it that must be done by hand and cannot be automated <img src=smilies/icon_smile_tongue.gif width=15 height=15 border=0 align=middle> Edited by - Argh on 5/18/2005 2:18:22 PM