@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 sequentially and always uses the same order for DLL entries, which makes it work correctly for MP.

Copy-pasting an XML script and editing for a combination INI/DLL entry all in one go is very fast and efficient. But you have to be extremely consistant about your labeling conventions for the files. Hopefully Matt's next version will continue to act this way...

Come to think about it... he could make it write context-sensitive DLL entries, so that they're in the right ranges... you might want to bring that up with him- if he could make FLMM do DLL entries for custom Factions correctly, that'd be sweet

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 for a particular market_ships entry, if you put a given ship for sale at three locations, using differing methods... what is the likelihood that all three will get overwritten? Not zero, but close.

For example... you could write XML like this, using the Toolkit's market_ships:

<data file="data\equipment\market_ships.ini" method="append" numTimes="0">
<section>
marketgood = ke_package, 0, -1, 1, 1, 0, 1, 1
</section>
<source>
;////////////////////////////////////////////////////ADDED BY ARGH XML TOOLKIT
marketgood = ku_dragon_package, 1, -1, 1, 1, 0, 1, 1
</source>
</data>

This would add my Sacred Dragon fighter to every Kusari military base. So if another ship add-on mod included this code:

<data file="data\equipment\market_ships.ini" method="replace">
<section>
[BaseGood
base = Ku02_02_base;//KUSARI MILITARY BASE
</section>
<dest>
marketgood = ke_package, 0, -1, 1, 1, 0, 1, 1
</dest>
<source>
;////////////////////////////////////////////////////ADDED BY ARGH XML
marketgood = ge_csv_package, 1, -1, 1, 1, 0, 1, 1
</source>
</data>

...we wouldn't have a compatibility problem, per se, unless it was reeeeeally important that that ship be sold there as opposed to the other 3 places it can be found. So you get a certain amount of survivability in your code with this method. It took me re-writing market_ships from the ground up to make it relatively easy, but it's quite possible to do now.

I guess what I want proof of is that if you have two mods that both add ships to Manhatten and two other locations in New York... that running both mods will result in being able to buy both ships... somewhere in New York. I have a feeling that you're going to end up either being able to buy one ship... or the other... but not both, with the method you're outlining.

Edited by - Argh on 5/18/2005 2:02:48 PM

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;JUNKER PHOTON GUN1
energy_damage = 0;JUNKER PHOTON GUN1
lifetime = 0.8;JUNKER PHOTON GUN1
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 = equipment\models\weapons\li_auto_cannon.cmp
material_library = equipment\models\li_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;JUNKER PHOTON GUN1
refire_delay = 0.12;JUNKER PHOTON GUN1
muzzle_velocity = 750;JUNKER PHOTON GUN1
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

Edited by - Argh on 5/18/2005 2:18:22 PM

---

Chips: Yes, all the market files can be condensed into a single file.

---

Yah - I *knew* they could, but never tried it. Been bashing on about that for, well, ever. Good to finally know for certain - thanks.

---

he third number in the marketgood line is whether or not that good is sold.

---

Yah - I mentioned that about 2 years back as well, although there was no advantage in using that alone, and dropping 'convention'

What I didn't check was whether ANY value other than 0 = sell. So with 150 - if it were just 1, would it sell or not. I privately suspect that it would, because I don't think the values are linked to anything else at all...... but I never checked anything else out with the other files - simply because there can be no advantage to it (as far as I knew). Mind you, these days you can read your error spews as well - therefore knowing if anything is being thrown up as an error if the numbers are changed. That would allow you to find out if it did serve a purpose or something - as errors would come flooding up (I would imagine).

My biggest wish is still to find out how to make the moors method actually work. It is my one desire (well, apart from Sur files). Yeah - I would love a dynamic commodity market - but afaik - the code just isn't in the files. However - the moors SHOULD be there somewhere.



Edited by - Chips on 5/18/2005 2:45:34 PM

I've gotten Moors to work for players as well as the AI. The only problem is that:

1. You must raise the docking_sphere radius, or manually move the dockpoints in the CMPs- they're set up with the AI in mind.

2. You must hit ESC before the sequence ends... dunno why, but if you don't, you just sit around forever.

3. When you take off, you leave via a Berth exit. Can't fix that.

4. Raising the docking_sphere radius makes AI ships that don't use the Fighter/Freighter steering types accelerate in bizarre fashions as they approach the final docking point, resulting in really funny collisions and other disasters.

I've been looking into the way that the AI picks places to dock... and it may be quite possible to create locations where the AI frequently docks at Berths that resemble Moors, preserving the illusion... but without the side effects. Maybe I should begin making that side-jaunt a little more public, and see if can't get somebody to figure out how we can get the msg_id for Moors to apply to certain Berths, to further-strengthen the illusion...

As for combining the files by type... that's pretty interesting. I'm halfway-tempted to dump everything of each type into one file that FL already refers to, and put blank files in for the other ones, and see what this does to game behavior.

As for what that 3rd number does... I thought everybody knew that... what I would like to know is what the 4th number does, as in this example from stock FL:

marketgood = bfr_package, 4, -1, 1, 1, 0, 1, 1

Changing it doesn't seem to make a whit of difference...

Edited by - Argh on 5/18/2005 3:01:44 PM

Hahaha... The absolute best editor would be one that you go "I want a fleet to spawn here"... *click* .... Done! But alas, that would be one hell of a coding project. I currently think that the method we're using is the best one that will be available without putting some EXTREME time and effort into building a better one. Then again this game is somewhat old and most of us don't get paid to do this stuff, so what's the chance of that happening?



~Jay~

I've just had the most disturbing encounter with a mad woman on the Holodeck. - Holographic Doc