Nice work!

Now, for all us that have NO clue how to program, could some nice, wonderfully talented person write a small proggy to allow us to MODIFY and/or ADD entries?

hehe..you know SOMEBODY was gonna ask..


Edited by - beltic on 11-03-2003 03:40:26

I have been considering doing just such a thing; a Freelancer-centered program to contain info of all sorts.

I was going to start off with just a database/map of systems, items, etc... Then make something to find or plot trade routes, based on your reputation levels, willingness to fight, etc... heheh.
Save Game reading would be required for that of course, and save editing would naturally follow that...
Editing game datafiles would of course follow.

Mind you, if someone else is already doing one or more of these, I won't pursue it.

In fact, I WILL do this, if someone else can provide me with the information I need... I am unfortunately too busy to dig through the forum twice a day to gather up all the stuff I need and put it all together and program it. :p

Ok, little problem here. I've been using the same system to get id numbers until I got to universe.ini.
There are set of miners there, all with the same strid_name which is: 60225
According to my hex converter: 60225 = 0xEB2B . Now, what is DLL number here?
E = 14





Edited by - XLancer on 11-03-2003 05:07:56

It would appear that the universe.ini file has a different field to ids_name. The
strid_name field is not the same as ids_name, so I would guess that the
strid_name info is held somewhere other than the resource dll files.

DA are using 2 different systems for storing string attributes maybe?

Well, universe.ini contains systems and bases, all with strid_name and those work just fine. Only these damn miners..

Edited by - XLancer on 11-03-2003 06:11:51

There's some < 65536 problems in systems/ as well. The Chugoku Jump Hole (Bw05_to_Ku06_hole) description is 60212 (ids_info) and one of the "extra" pieces to Baltimore Shipyard (Li01_14_shipyard_1) has 60231 (ids_info). I deduced it was Baltimore and not Norfolk by assuming the X-axis goes left/right, the Y-axis down/up, and the Z-axis forward/backward (-/+) from a "due north" facing of your ship. (So "north is always up" on the map would mean north is -Z, with east +X, and Y not represented.)

In addition, anything over 261,000 seems to have offset issues because the index to string entry value frequently ends up off the chart. My current ids_name fixup chart is:

$string_num -= 9 if ($ids_num >= 216600 && $ids_num < 216610 );
$string_num -= 4 if ($ids_num >= 261110 && $ids_num < 261120 );
$string_num -= 6 if ($ids_num >= 261160 && $ids_num < 261170 );
$string_num -= 8 if ($ids_num >= 261210 && $ids_num < 261220 );
$string_num -= 8 if ($ids_num == 261658 ); # LiNy->California jump gate?? (4066 : 10 -> 2)
$string_num -= 13 if ($ids_num == 261661 ); # BrLe->Texas jump gate?? (4066 : 14 -> 1)
$string_num -= 13 if ($ids_num == 261662 ); # BrLe->California jump gate?? (4066 : 14 -> 2)
$string_num -= 9 if ($ids_num >= 261780 && $ids_num < 261794 );

but absolutely no guarantees that the above is accurate yet as a bunch of them are trade-lanes that I don't yet know the names of (but I know how to make them). It's very distressing.

Are you SURE you add 1 when converting ids_info? Take the ids_info in universe.ini for the Outcast group, for example (fc_ou_grp), where ids_info = 66208.

66208->hex = 102A0 = infocards.dll
(2A0-> dec) + 1 = 672 + 1 = 673
look at table 673...it's the info for Planetform, Inc., whose ids_info happens to be 1 higher than the Outcasts'...and it also happens to be that the actual table where the Outcast info appears is table # 672, i.e. what you would have gotten if you didn't add 1. It's the same situation with like every single faction.