Now this will be very interesting work Argh, I am looking forward to this immensely It certainly would open up a whole field of mod options, download and install mods into a folder ('components') to construct a mod 'as you like it'. All modules could install to a single folder - called "build a mod". I know this isn't what you are indicating, your method would be to activate as many mods as you like. I just think differently - with people downloading any module by using "open from location" - which will autounzip and create mod. Other modules will do exactly the same, but "over-write" the previous one.........read this as just including a new xml script instead though, in the same folder (how patches are done by me at this time).

Only problem with that would be the index.xml (although I will have to wait to see what you have done), as it wouldn't be possible to have it update per download to dynamically show what modules (and therefore what mods) are installed

Sounds like a fantastic idea to me though

Edited by - Chips on 4/13/2005 2:54:19 PM

Something as fully-modular as what you're describing, Chips, will take modification of FLMM's code.

What I'm going to do next, now that I've gotten a better grasp of the essentials, is to work out a very important part of this puzzle, which is how to get FLMM to process XML sequentially, under the full control of the game designer.

What I'm aiming for here, more or less, is a way to do some of the trickier "big jobs" in FL modding through very automated procedures. Adding a ship to a Faction was originally a pretty annoying process... and I have some other ideas here, such as how to (finally) standardize weapon damage and shield resistances, so that players can (finally) make intelligent decisions about what weapons will work best for what situation, without having to consult guides or whatnot.

Creating a standardized table of weapons could be a very interesting use of this- and once built, anybody could use what I've done here to re-balance FL in all sorts of interesting ways, among other things, without nearly as much pain and suffering as there is now.

Hmm..
I CAN see plus points to this but then again, I see negatives. Maybe its me and I'm not understanding it properly but I'm going to reserve judgement on this.
Well done on your discovery though

Well... one of the biggest pains with modding has been how little compatibility there is between mods- and how little coding standardization there is. I have literally learned everything I know... mainly through tearing apart other mods, and studying coding practices. Mephistopheles's work was my main starting place for this- he really upped the ante for what a clean XML mod could look like

Rationalizing coding procedure will help everybody.

FLMM needs a few more features to really do this well:

1. Grep search-and-replace functions and wildcards. It would be soooooo nice if I could just write an XML script that searched for 600.??????, instead of having to do that manually. Weapon_equip is full of that kind of junk... it's driving me a wee bit mad. DA did a really terrible job there, leaving all sorts of floats in their code where there wasn't any need

2. A "make a mod" feature, with built-in error-checking (say, a dialogue that said, "This multi-mod will modify XY and Z (a) times. This is unlikely to be compatible- do you want to remove A mod or B mod from your MultiMod, or save a textfile containing all of the search-and-replace duplications?"

FLMM also needs more graceful error-handling. For example, it'd be nice if there was a XML switch we could put into our scripts that basically said, "If <dest> X <> X, goto next <data>". Right now, a script will halt if *anything* doesn't match the required parameters, which makes the prospect of "layered mods" which might search a string that was changed by a previous operation... completely impossible.

After I get done with my current demonstration stuff (I decided to rationalize weapon_equip, and get the pain and suffering over with, since this is, by far, the ugliest part of FL's code) ... hopefully people can take standard "templates" and work with them, and I'll see if the creator of FLMM could be convinced to either release the sourcecode or add these features.

The big issues are the naming conventions and proper labeling by modders, really- it's our own haphazard and often lazy coding styles that are the main obstacles here, and for this approach to work, we need to pay more attention to method- not just results.

For example, a mod should probably contain information about exactly which files are being modded, so that figuring out what has gone wrong is fairly easy. And modders who write mods that replace data should tell you that- replaced data will generally cause any other XML that tries to change that data to halt, whereas appended data generally won't.

First let me say that it is an honor to address you, Mr. Argh, especially since you made that Giant Killer Rabbit in my Personal Honor. I salute you and your abilities.

Now let me say that, as a member of the Royal Guild Of Freelancer Server Operators, I, Unfortunately, have issues with this technology and I fear that some of my fellow members may have issues with this as well.

I think it could cause us server operators a big pain in the posterior buttocks, cheating wise. But I could be wrong.

Plus, as a member of the Royal Guild of Freelancer Modders, I must quote Tom Hanks in "A League of Their Own" who said "Baseball is supposed to be hard. If it was easy, then anybody could do it." That said at the risk of sounding Elitist, which I am.

But we remain on friendly terms, be assured.

Glock36
"No Comment"

Whee.

Glock... my answer to your concerns are actually pretty simple (and maybe simple-minded, but I think not):

1. FLMM is being used in just about every mod around.
2. You can build a server-side mod that can be used to compare against suspect clients very easily- simply install the mod, copy the files that have been altered, and use them as the basis of the hash. I *think* that will work.

At any rate, I'm not super-worried about security at this point- I have a lot've obstacles sitting in my way... like the fact that making things like game-balance variables (notably, weapons) easier for people to mod is pretty nasty stuff... DA's code makes a teenager's room look clean. I am beginning to understand why revamp mods take so darn long to develop, and when I'm done... they won't.

I've finally bit the bullet. I'm going to totally revamp the weapons ramps. Basically, I'm going to build a set of FLMM scripts that will:

1. Create guns and turrets, level 1-5 for each of the main types, with appropriate labels, replacements in the Loadouts so that everybody's using the new guns... etc. I'm going to do some of this on the INI side of things, because I'd rather have FLMM modifying a tight INI that accurately reflects the manifest in the XML scripts, rather than have a half-dozen <dest> tags replacing a half-dozen guns that can hardly be told apart, stat-wise.

2. Rebuild the shields, so that they make some sort've sense for once. DA's original stab at it was incoherent at best- there were a lot've shields that simply weren't worth buying.

3. Rebuild Market_Misc, again with the same reasoning behind it as rebuilding Loadouts... there's simply no reason not to clean house.

I didn't really set *out* to create a new mod here, darnit. But what I'm going to end up with, more or less, will resemble a heavy-handed reworking of FL's game-balance from top to bottom. I doubt if anybody will want to *play* it, mind you... I'm not making new FX, ships or other toys... this is just about the fundamentals, and making a codebase that actually makes sense for once, as a newbie modding kit.

It's just looking like the best way to attack these problems is to hit them head on, and revamp DA's work from the ground up... as usual. Sorting out the guns is zero fun, but once I'm done, anybody should be able to adjust game balance to whatever they want to, with a lot less pain. When I get this completed, the old guns can all go bye-bye, and nobody will miss them very much, because the new ones will be stealing their art and sounds, and will be functionally similar. At least that's the plan, hehe...

I'll keep it nice and organized and well-labeled, so that people can, say... find the Plasma IV and make it more deadly and more expensive... and not wonder whether it was the fc_lr_plasma_is_good, or the fc_lr_plasma_for_dummies... sheesh... if there's anything that's irritating about tackling this, it's the sheer stupidity of the naming conventions, and the incredible lack of organization... it drives me a wee bit nuts here. It's like they just made stuff up by Faction, and then dumped it all into a common INI at the end. And people wondered why I decided to do a TC as my first mod, instead of making a regular space-simmie thing- I knew I wasn't going to do this unless I could actually clean this mess up for once and all

Still, I'm just about done with the tough issues- I'm down to pure, boring slog.

I think that I'll just rebuild Market_Misc and Market_Ships so that they actually make sense- surely, in the far future, you don't have to travel across the Galaxy to buy a gun you want- that's what UPS is for. People can tweak them to *not* make sense later, if they want to- they can just use a <filereplace> to comment things out, or whatever.

Edited by - Argh on 4/14/2005 12:21:21 AM

I believe we need a new editor, I mean most of the stuff thats done in FL-XP can be done in a simpler interface.

I don't know if any of you have ever played halo pc and modded it, but it had this nice little tool called halo map tools, and used a tag editor.

Basically with Halo you had tags which held the dependencies and settings for all the elements of a map file, if you expanded the tree down to a weapon, you'd have in the right hand side an XML form that allowed you to change rate of fire, ammo used, how many shots were fired, ammo count, zoom count and a bunch of other stuff.

In this way I believe it could sort of work for Freelancer, because everytime you edited something you could have it so it would automatically create a script to append or anything required, much simpler if you ask me.

Aha!!!!

I have found a grep method (with a little bit of help from an expert, hehe) to evaluate and replace floats in a range with integers.

In short... I can now rationalize FL's weapon damage curves and at the same time, get rid of all of the nasty floats that made manipulating this with XML scripts darn-near impossible. And... I won't have to rebuild the weapons, so I can leave everything intact. I will go ahead and replace weapon_equip.ini with my "rationalized" one.

For example, there were lots of entries like this one:

muzzle_velocity = 600.400024

Why these were left like this... nobody knows. But you sure couldn't design an XML script to take care of problems like this, without a terrific amount of pain, previously.

So... now I "just" have to determine whether I want to mess around with FL's balance while I'm at it, so I'm going to ask for opinions:

1. Would anybody think it heinous of me, if I rounded every weapon's hull and energy damage up to the nearest 5 points? Same for Energy usage? I think that's plenty of "granularity" for the game design, myself, but I'm asking...

2. Does anybody care if I move all weapons with a muzzle_velocity of <650 (with the exception of missiles, etc,) to 650, and moved all weapons with a muzzle_velocity of >651 to 750? This would get rid of a lot of the icky weapon-velocity mismatches that are scattered throughout the game design, and make making a mod that changed these variables a snap, but if everybody's really enamored of a system where there are 5 different muzzle_velocities (and more if you count cruiser guns and things)... lemme know.

3. Lastly, I'm going to go ahead and leave refire rates alone, but convert them to shorter floats. I do not care for the weapons at 0.500000 (I've always thought their hit-rates were too low to bother with, myself), but I can write a script that drops them to something more rational very easily, if that's what I want to do later.

Yay!!! So, folks... I've figured out a way to tear everything up and rationalize the game's variables... without having to rebuild everything by hand, or build an entirely new mod. Sweet

Oh yeah, and Pwn@ge... basically, when I'm done here... people will be able to build mods that feature choices like, "double every weapon's damage", "double the damage of all Plasma weapons vs. shields", "make the X weapons do more damage", etc., etc.

That's the objective here- to make the previously un-moddable (or, at the very least, practically-un-moddable) easy to alter, distort and change. It'll give coders a whole bunch of practical options, not just a few.

Edited by - Argh on 4/14/2005 11:11:06 AM

Oh yeah... duh... I should share the grep method. Please bear in mind that this may or may not work, depending on the grep parser- I'm using Advanced Find and Replace (www.abacre.com) and this feature was added to the latest Beta release (funny how that works).

At any rate... using AFR's Regular Expression Builder, I can build a search grep like this:

muzzle_velocity = (\d+.\d+)

And a replace grep like this:

muzzle_velocity = <%=iff(($1>2.0001) and ($1<=3.0000),2,$1)=%>

Basically, the first line says, search for muzzle_velocity = some number .

The replace says, if that number is greater than 2.0001 and less than 3.0000, replace it with a 2.

In AFR, you also have to turn two options on- G and E (this allows numbers to be evaluated as numbers... I'm working with a beta, after all)

And that's all there is to it. Dunno how many grep search-and-replace tools can evaluate this kind of expression, but I'm sure that AFR probably isn't the only one. At any rate... for this little job, I'm going to be doing it for y'all. Just thought I'd share this search-and-replace technique with you guys... there are a lot've games I've worked on, previously... where I would've given my right arm to be able to do this so easily...

Argh ... did you recieve my email? I sent it to the one linked to this board, just incase it got picked up by your SPAM filter or anything lol.

Ok, here's how things are going to get re-organized. This is information that I'll be including with the readme of the final version of this mod codebase, but here ya go:

Muzzle_Velocity Changes

All muzzle_velocities will get assigned to standard categories. This will allow modders to do things like make all Missiles launch at a faster speed, but leave the rest of the weapons alone... very easily. Here's how it works, on the math end:

0 = 0
>=0.000001 to 20.000000 = 20 (this covers Mines, mainly)

>=20.000001 to 50.000000 = 40 (this will make some Missiles launch at slightly greater speeds, but it's a very minor change)

>=50.000001 to 100.000000 = 100

>=100.000001 to 200.000000 = 200

>=200.000001 to 500.000000 = 300 (why 300? Because that won't be overly disruptive to Missiles with a high muzzle_velocity, is why)

>=500.000001 to 651.000000 = 650 (Goodbye, speed 600 weapons. Hello to standardization)

>=651.000001 to 1000.000000 = 750 (Good riddance, speed 700 weapons. You were always ugly step-children in the game design anyhow)

>=1000.000001 to 10000.000000 = 1500 (this covers a few weirdo weapons, including Cruise Disruptors)

So, now... we'll have 9 categories of muzzle_velocity, and modding them will be a cinch. Here's an example:

<data file="data\equipment\weapon_equip.ini" method="filereplace" numTimes="0">
<dest>
muzzle_velocity = 1500
</dest>
<source>
muzzle_velocity = 3000
</source>
</data>

... and voila! Cruise Disruptors now move at uber speeds.

More details when I settle on numbers, but basically I think I've got a plan, now.

Replied to your reply

Weapon Damage and Energy Usage
Ok... this was a very tough row to hoe, but here's what I ended up doing for my new ramp:

1-100, by increments of 5. So everything from 5, 10, 15, etc.
100-400, by increments of 25.
400-3000, by increments of 100.
3000-10000, by increments of 1000.
10000-50000, by increments of 10000.

This ramp applies to all hull_damage, energy_damage, and power_usage. In general, the overall effect is that all weapons do more damage, but use more power- it all evens out, more-or-less. You could very easily tone this up or down, using an XML script at this point, or mess with specific brackets or weapon types... stuff that was a logistical nightmare before. For example, you could make all Plasma weapons do twice as much damage, with a script like this:

<data file="data\equipment\weapon_equip.ini" method="sectionreplace" numTimes="0">
<section>
weapon_type = W_Plasma01
</section>
<dest>
hull_damage = 125
</dest>
<source>
hull_damage = 250
</source>
</data>

And so forth. You'd want to go in descending order , otherwise you'd overwrite your previous changes (FLMM isn't very smart about that sort've thing), but it's going to be practical now

Wow, my processor got a workout today- I'm glad I have the Cooling Fan of Godliness +5 Search-and-replace with such huge lists + mathematical operations per seach = mondo calculations.

But... it's done! I have replaced every single entry in weapon_equip with new values for the following variables:

muzzle_velocity
hull_damage
energy_damage
refire_rate (all I did here was change the 0.120000 to 0.12, and so forth... don't have heart-attack, anybody- I left that alone).

We're talking over 60,000 different variables standardized here... ain't computers something?

Now that everything's broken down to integers in discrete sets... it is now quite practical to make XML mods that change the profiles of weapons in all sorts of nasty ways. Or, if you're still an old-fashioned kind've modder... at the very least, you can now edit the damage for a whole series of things with ease, directly in the INI, without having a nervous breakdown as part of the process

Now... for the Shields- the other side of this coin. I'm thinking, given the way that things have been altered... I should bump them up to the nearest 500 points. I'll leave their weighting alone, but I'm going to rationalize their recharge rates.

Finally... I'm going to take a look at price ramping, which now makes little sense. For example, there are guns with exactly the same stats after the bumps that were done... that have different prices. In some cases, this is significant, in most cases, it's pretty minor. Still, I hate leaving something like that in there, where it doesn't make any sense.