Fixing errors found by FL Error Checker

Just something Lancer Solurus added in. Increment the ranks from 1 to 25 to make it happy, like this (from the UnderVerse):

npc_ship = gn_a_bhelitelight_d1
npc_ship = gn_a_bhelitelight_d2
npc_ship = gn_a_bhelitelight_d3
npc_ship = gn_a_maru_d4
npc_ship = gn_a_tarsus_d5
npc_ship = gn_a_galaxy_d6
npc_ship = gn_a_bheliteheavy_d7
npc_ship = gn_a_bheliteheavy_d8
npc_ship = gn_a_starviper_d9
npc_ship = gn_b_racer_d10
npc_ship = gn_a_scorpion_d11
npc_ship = gn_a_gladius_d12
npc_ship = fc_ou_antaeus_d13
npc_ship = fc_ou_antaeus_d14
npc_ship = fc_ou_hornet_d15
npc_ship = fc_ou_hornet_d16
npc_ship = fc_ou_katanna_d17
npc_ship = fc_ou_katanna_d18
npc_ship = fc_ou_hornetmkii_d19
npc_ship = NPC_HornetMK3_d20
npc_ship = NPC_Arcudia_d22
npc_ship = NPC_U571_d25

hehe… i know how to fix it dwn, (thankx anyhoo) im just totally baffled as to why it’s suddenly showing up now, and only in some factions… when others are ignored

I’ve been using 1.3 for ages now, this is a totally new “error” and from out of nowhere, as i said i haven’t touched any NPC ship stuff for years (about 2 and a half now), and have run the EC 100’s of times over the many years since…

I’m more curious as to if this is a checker glitch… i just added a ton of ships… maybe it’s had a brainfart??

just checking with you guys before i spend hours doing something i’d rather not have to.

That’s referring to

[NPCShipArch]
nickname = ….
loadout = …
level = d1

and it was found, that there will be random crashes,
if your ‘npc_ship’ are not in ascending order in [FactionProps].

Besides the errorchecker starts with an default of 9,000 errors.
I m used to set this to 90,000.

Maybe try this m8 and find some xtra errors.

Yeah i have to wade through the errors and sift the real problems from the confusion… the fun of addon .dlls and extra code lines… lol (worth it though… very … worth it)

I guess it’s time to actually utilize all them ships i’ve spent years working on and fix this along the way, total replacement fix marathon… here i come hehe.

grumbles boring vanilla error prone trash starts tearing chunks of code away

Xarian_Prime wrote:
hehe… i know how to fix it dwn, (thankx anyhoo) im just totally baffled as to why it’s suddenly showing up now,.

I had exaclty the same phenomenon, last week or so. Have indeed, like you, used this proggy for ages, and never saw this before.

FLEC has no live update, has it?

Moonhead wrote:

Xarian_Prime wrote:
hehe… i know how to fix it dwn, (thankx anyhoo) im just totally baffled as to why it’s suddenly showing up now,.

I had exaclty the same phenomenon, last week or so. Have indeed, like you, used this proggy for ages, and never saw this before.

FLEC has no live update, has it?

not as far as i know no… hence our mutual confusion

wasn’t that hard to fix, so it’s all good now

Is there a way to find out what this is:
E:\FL\Scratch\Source\Server\Space\EqObj.cpp(3187) : *** WARNING: Fuse(0xaf1a9408) not found in FuseDB. Aborting.

I mean… is there a reverse-hashing way to get a useful “nickname” of the fuse?

Since I can´t find the error… must be a npc related fuse afaik but I´m stuck here.

Any help would be much appreciated.

Well, the way I do it is:

C:\contrib\games\Freelancer>whatis 0xaf1a9408
2937754632      death_comm

So if you don’t mind the command line, use CreateID to generate a database, then WhatIs to query it (or there’s also Flunhash to convert all codes in a file). If you prefer GUI (or also need to reverse effect_crc), use CRCTool.

Additional I found it helpful to use

• the procmonitor

to see what is missing.

Set filter to freelancer.exe and be surprised.

adoxa wrote:

 2937754632      death_comm

Well, thats the point…
I just cant find ANY file refering to this… from my observation its a fuse or maybe something inherited in it, which is called only randomly during NPC deaths… I´m not able to find it and it is annoying the hell out of me …

Anyways… Thank u so much for your replys… BOTH of u

Greetings

 2937754632      death_comm

Its a (very) basic death, first one in DATA\FX\fuse.ini

check to see if it has been deleted (open to correction but I dont think its used in vanilla, I try to avoid fuses)

Thaddeus, where’s your Lithium website gone?

Timmy, thanks for asking. I’ll have it back up in a few days… probably. Should really have my sig pointing at my forum. Suffice to say that 000webhosts dont like sharing of .txt files and update .zips for flmm off the back end of their free sites

THX MATE !!!

Finally found it in the old sdk 1.3

U saved my day !!!

I have a problem with the CRCTool from Adoxa, it generates CRCs which are wrong. For example the effect nickname gf_co_smallengine02_fireorange generates a crc of 443.410.325. But when i use this CRC then this effect is not displayed. But the original value of -4.293.718.779 is correct.

I think there seems to be a problem with converting the value to int range. The dacom however has routines where an unsigned long is used. However even unsigned long would just reach up to 4.294.967.295 where the -4.293.718.779 from the original ini also dont fit in properly. But when i use the CRCTool to calculate the CRC then it just shows a wrong value. Is the value from the ini probably an long long?

Any idea how to solve that? Also the error checker seems to prompt errors with some of CRCs which are then false calls.

–-edit:
Just did some manual calculations and it indeed seems to be an range exception that is not covered properly. The

-4.293.718.779 + 2 ^ 32 = 1.248.517 (too much in range)

But then i cannot comprehend how 443.410.325 is reoported as CRC, probably because the casting leads to this wrong presentation.

Huor wrote:
I have a problem with the CRCTool from Adoxa, it generates CRCs which are wrong. For example the effect nickname gf_co_smallengine02_fireorange generates a crc of 443.410.325. But when i use this CRC then this effect is not displayed. But the original value of -4.293.718.779 is correct.

It’s not wrong - the CRCs generated by CRCTool match those in the ini files; running through the debugger, the CRC for gf_co_smallengine02_fireorange generated by CRCTool matches that generated by Freelancer. What do you mean by original value? That nickname does not occur in vanilla, nor does the number, which does appear to be 64-bit (the 32-bit equivalent does not occur, either).

Yes it is no vanilla effect crc. The error checker notified that some of the CRCs we are using seems to be wrong - where one is the gf_co_smallengine02_fireorange. When i use the CRC from the tool then i dont see the effect. The one that we had in place before was -4.293.718.779 - which actually cannot represented with 32 bit. But the effect was shown for some reason. If i replace our previously value with the one from the CRCtool then it is not shown anymore. And i cant comprehend why this is the case, especially since the FL values for CRCs are also “unsigned long” which perfectly fits into 32 bit

Gonna dig again into the values this evening. There were more effects which are not shown anymore after we changed the CRCs to the ones output by the CRCTool.

We found the root cause, the error checker uses the nickname of the effect and checks its crc - that works for the vanilla crcs as the name of the effect inside the ale is the same as the nickname. We created new effects where this is simply not the case. The crc which have to be checked must be based on the name of the effect inside the ale and not by its nickname. Thatswhy it was working

And as -4.293.718.779 (64 bit) = 1.248.517 (32bit) it was working although we should have used 1.248.517 for the crc ;D

All OK now. The error checker here just does not check the correct reference.

That explains why my test with FLEC worked. I was going to suggest trying UTFXML, but no need now.

Hey - Adoxa is NEVER wrong! We know that from experience!