How many commands can FLMM process?

Bullwinkle

Moonhead wrote:
I’m working on what is meant to be a total reworking of most of the game data, and I’m doing it all thru XML scripts…

But now I’m wondering if there is a max to the number of commands FLMM can process[?]

IIRC, the limit is 2,000 in FLMM 1.31. I do not know about 1.4.

Updating your DLLs from a human-readable format is an excellent idea. However, I am not so sure that FLMM is the ideal tool for the job.

FriendlyFire’s FLDev has a template feature that may be a more suitable candidate. It allows you to keep your data as spreadsheets and FLDev will populate your DLL(s) from it.

Documentation is a little hard to find, but here are some threads that may help:

Freelancer Developer Stickied Thread

Appending Data to Freelancer String .dlls

Coding Concepts

.

Moonhead

Bullwinkle wrote:

IIRC, the limit is 2,000 in FLMM 1.31. I do not know about 1.4.

Updating your DLLs from a human-readable format is an excellent idea. However, I am not so sure that FLMM is the ideal tool for the job.

FriendlyFire’s FLDev has a template feature that may be a more suitable candidate. It allows you to keep your data as spreadsheets and FLDev will populate your DLL(s) from it.

Documentation is a little hard to find, but here are some threads that may help:

Freelancer Developer Stickied Thread

Appending Data to Freelancer String .dlls

Coding Concepts

.

Thanks for the links, Bullwinkle! I’ll look into them coming weekend.

Managing the DLLs is just one of the reasons for the method I use. I also think it’s more convenient to have e.g. the faction-specific weapons in separate documents. (I’ll post a screenshot to show what I mean when i’m at my own comp) So, it’s more my personal SDK thing I’'m working on… It’s rather time- and resource consuming though; that’s why I’m wodering whether I will run into limitations before I’m done.

Now, would it be easy to hack FLMM into being able to process more instructions?

Bullwinkle

Moonhead wrote:
Managing the DLLs is just one of the reasons for the method I use. I also think it’s more convenient to have e.g. the faction-specific weapons in separate documents.

Now, would it be easy to hack FLMM into being able to process more instructions?

Oh, I have an idea about what you mean… I am very much in favor of taking a more organized approach to Freelancer data. I completely agree with your goals.

I am just pointing out that FLMM 1.31 and 1.4 have problems that cannot be easily overcome because the developer left the scene.

FLDev is being actively developed by theStarport’s FriendlyFire. FLDev already shows more promise than FLMM for managing your data.

For a quick way to see FLDev’s potential, take a look at this post from the Coding Concepts thread:

Coding Concepts - Example

The above post gives you example spreadsheets and a template that will populate your DLL for you. Try it before you think any more about FLMM.

.

adoxa

Yes, there is a limit of 2000 resources (each, I think). There’s still no sign if Crazy has got back access to his source, so FLMM development is in limbo. If you’d like to risk it, I have found where it tests the limit, but I don’t know if just increasing it will work. You’ll need upx (or equivalent) to unpack it first, then go to offset 0x27D23 and replace the 2000i (D0 07 00 00) with whatever. To be complete, you might also want to go to 0x7672D and change the string (maximum of 99999 in that case).

Edit: The 1.4beta4 offsets are 0x24E95 & 0x72EC5.

Bullwinkle

:lol:

This is like a sport for you, isn’t it, adoxa?

Terratec

Why limit of 2000?Come much about it!

Gisteron

most mods contain files instead of script commands. this is safer btw. it is unlikely that IGx89 planned to make the mod manager a modding&coding tool but an activation program copying most of the files. the data tag feature is probably implemented for not to waste too much hard disc space when you change about 5 lines of a 5000 line file. FLMM is supposed to backup, copy and delete, not to make all the changes itself.

Crazy

Hey,

well… I’ve recently found the original code from 1.4 beta 4 on my old HDD (which I’m using atm).
I think it would be worth to restart the FLMM 1.5 project by not adding new features but by fixing the 1.4 bugs (cause I still dunno why most ppl are still using FLMM 1.31)

Cheers,
Crazy

adoxa

Any chance of seeing the source?

Moonhead

Crazy wrote:
Hey,

well… I’ve recently found the original code from 1.4 beta 4 on my old HDD (which I’m using atm).
I think it would be worth to restart the FLMM 1.5 project by not adding new features but by fixing the 1.4 bugs (cause I still dunno why most ppl are still using FLMM 1.31)

Cheers,
Crazy

Supposedly it is less stabile. It was reported that it didn’t always clean up added files, and i must say that I once noticed that too. But now, in my ‘second modding life’, I haven’t experienced it.

The cool thing about 1.4 is that it can create mutliple ids_info’s on the same line, enabling you to use XML to generate the proper base info into InfocardMap.ini. 1.31 Couldn’t do that.

I would welcome a FLMM 1.5!!! (as long as it keeps the multidple ids_info functionality) It might, to get back to the OP, be convenient to have the max number of commands it can process as a modifyable value in the GUI…

Moonhead

Gisteron wrote:

FLMM is supposed to backup, copy and delete, not to make all the changes itself.

As longs as it works, it would seem fine to me. Besides, I think it’s more convenient and more elegant to use FLMM this way.

A hypothetical distributional version of a mod created this way, need not be in this format: the modder would just need to copy all the modified files into a new folder and add a script.xml to it.

Moonhead

adoxa wrote:
Yes, there is a limit of 2000 resources (each, I think). There’s still no sign if Crazy has got back access to his source, so FLMM development is in limbo. If you’d like to risk it, I have found where it tests the limit, but I don’t know if just increasing it will work. You’ll need upx (or equivalent) to unpack it first, then go to offset 0x27D23 and replace the 2000i (D0 07 00 00) with whatever. To be complete, you might also want to go to 0x7672D and change the string (maximum of 99999 in that case).

Edit: The 1.4beta4 offsets are 0x24E95 & 0x72EC5.

Thanks!! I’m gonna try that out.

I assume I don’t need to “re-pack” it, right?

Gisteron

ouch! tripple posting… whatever
moonhead, there is a FLMM 1.5 already though it is yet a beta and not required by any mod we know (that deserves the name yet being a two-weaps-expansion like the pre-installed minimods of FLMM). i used it several times before i recognised that there is nothing that needs it. what i heard of it is however that it is for now more buggy than 1.4 but as it was released recently it is likely that the development is actually going on even if we are not informed properly about it.

Bullwinkle

Crazy wrote:
I think it would be worth to restart the FLMM 1.5 project by not adding new features but by fixing the 1.4 bugs (cause I still dunno why most ppl are still using FLMM 1.31)

I completely agree, Crazy. An issue-free version of FLMM would be terrific for the community. It would be the best thing since… well… FLMM.

In the Issues Department (not new features):

In addition to generating two IDs on one line, there are times when it is necessary to use the same ID in more than one INI file.

InfoCardMaps is also an example of this issue.

Regarding issues with making reliable backups, one alternative would be to simply backup and restore the Freelancer tree. It would not be dramatically slower than the current system when used with complex mods. Many people already do this manually. If FLMM is going to attempt to make backups, then it might as well make backups that really work.

Moonhead

Bullwinkle wrote:

Crazy wrote:

In the Issues Department (not new features):

In addition to generating two IDs on one line, there are times when it is necessary to use the same ID in more than one INI file.

InfoCardMaps is also an example of this issue.

FLMM 1.4 does assign the same number to identical multiple instances of ids_names and ids_infos! Without this, there would indeed be no point in managing InfoCardMap.ini thru FLMM XML scripting.

Moonhead

Btw, here is an example of how I’m organizing stuff. Argh’s Toolkit was a big example (although I didn’t care much for what seemed Argh’s one true passion: his ship handling modifications)

Bullwinkle

Moonhead wrote:
FLMM 1.4 does assign the same number to identical multiple instances of ids_names and ids_infos!

In the Deja Vu Department, I see that you made the same request, and received the same response, four years ago! (about using the same ID in multiple files)

I started to do the same thing as you with my data but stopped because of limitations in FLMM 1.31. Now you have me persuaded to pick it up again with 1.4.

Thanks for the tip, Moonhead. I’m a convert.

So you have been doing this for a while… what do you do about InfoCardMap?

PS: The FLMM Mod Guide (Help/How do I make a mod work with FLMM?) says that the limit is arbitrary, so adoxa’s offset may solve that problem.

Don’t forget that you will then have to distribute your customized version of FLMM with your mod… and maybe support problems that could be caused by changing a user’s FLMM.

.

Gisteron

you could store multiple xml’s in one file, that would probably make it simplier to overlook.
kill me for this comment but this amount of xml based changes is just… weird…

Moonhead

Gisteron wrote:
you could store multiple xml’s in one file, that would probably make it simplier to overlook.

That would be defeating the purpose.

Gisteron wrote:
kill me for this comment but this amount of xml based changes is just… weird…

I can only agree on that :lol:

Moonhead

Bullwinkle wrote:

So you have been doing this for a while… what do you do about InfoCardMap?

Make sure the first ids_info in InfoCardMap.ini is identical to the one you use in the starsystem’s ini (and also, make sure there is no other base using an exactly identical text):

 <data file="Data\Interface\InfocardMap.ini" method="append"><source>
Map = 0;GENERATEXMLRES("<xml><rdl><push><text>CLASS: Cocoon</text><para><text>AMENITIES: Yes</text><para><text>POPULATION: 120</text><para></para></para></para></push></rdl></xml>"), 0;GENERATEXMLRES("<xml><rdl><push><text>Whatever Station.</text><para><para><text>In order to retain its geostationary orbit, the quick brown fox jumps over the lazy dog.</text><para></para></para></para></push></rdl></xml>")</data>

from the file that writes the starsystem’s .ini :

;
;================================{ Whatever Station }
;
[Object]
nickname = Aa00_01
ids_name = 0;GENERATESTRRES("Whatever Station")
pos = 0, 0, 80000
rotate = 0, 180, 0
Archetype = outpost
ids_info = 0;GENERATEXMLRES("<xml><rdl><push><text>CLASS: cocoon</text><para><text>AMENITIES: Yes</text><para><text>POPULATION: 120</text><para></para></para></para></push></rdl></xml>")
base = Aa00_01_base
dock_with = Aa00_01_base
voice = atc_leg_f01
space_costume = pl_female5_head, pi_order_female_body
reputation = fc_or_grp
behavior = NOTHING
difficulty_level = 3
loadout = trading_outpost_co_03
pilot = pilot_solar_easy
visit = 1

I use one XML file for each base, containing all the stuff that makes up a base, to be written to:

Data\Interface\InfocardMap.ini
Data\Universe\Universe.ini
Data\Missions\mBases.ini
Data\Equipment\Market_Commodities.ini
Data\Equipment\Market_Misc.ini
Data\Equipment\Market_Ships.ini

Bullwinkle wrote:
Don’t forget that you will then have to distribute your customized version of FLMM with your mod… and maybe support problems that could be caused by changing a user’s FLMM.

A distributed version of such a mod would preferablybe the files as installed, copied from the game folder when the XML plethora version is installed. So, in the distributed version, the XML scripting will be brought back to a minimum, and the mod can be sort of FLMM-version-independant.