Fixing errors found by FL Error Checker

 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!