5 réponses à ce sujet

[FollowTheGourd]

Hi,

I can't seem to get any GDA column hash to match the CRC32 I'm seeing in the toolset or in the GUI scripts.

The wiki even contradicts itself between the GDA entry:
"Generated with the CRC32 hash algorithm used on the lowercase of the string (so it is case independent)" and the 2DA entry: "Column names are case sensitive. This is because of the CRC32 algorithm
used to generate the hash key. Changing the case of a column name after
it is in use will break the game. White space before and after a column
name will be removed before hashing".

I've tried using zlib's crc32 function and the cksum utility to see if I can reproduce the hash values, but so far nothing...
Let's take the column name "Label". Supposedly it's CRC32 is 3521861138 decimal according to the the _2DA ActionScript class and when I look at the GDA in the toolset.

I've tried appending NUL bytes after each letter, NUL at the end, two NULs at the end etc. Upper case, lower case, and so on.

I'm probably missing something obvious, but so far I'm not sure what it is.

Modifié par FollowTheGourd, 08 janvier 2010 - 01:33 .

[elys]

I did not have any problem coding GDApp converting the strings to standard CRC32 hashes.

But you have to hash the string in its lowercase unicode form (not including the null terminator)

So the string "label" made of 5 unicode characters,  so 10 bytes to hash using CRC32 which gives the result: 0xB49CA166

Modifié par elys, 08 janvier 2010 - 03:05 .

[FollowTheGourd]

Yeah, I think I was looking at the wrong numbers actually... somehow managed to look at the CRC32 for "Color" in the list (3521861138 or 0xD1EB5612) ... plus I converted the word "label" to UTF-16 incorrectly - works as soon as I just use a function to do that for me. I had also tried one earlier without any null bytes at the end.

Thanks for the confirmation of how it's supposed to work.

Modifié par FollowTheGourd, 08 janvier 2010 - 04:09 .

[elys]

What are you up to with the hashes ?

By the way, I have generated from the source XLS a const array of 1271 strings and respective hashes which are found commonly in GDA, if you need a reverse hash -> string table.

Modifié par elys, 08 janvier 2010 - 04:18 .

[FollowTheGourd]

Two things:

1) There are some UI 2DA functions that take a hash value instead of a name, and I wanted to see if there was any huge performance difference (not that I notice a hit now).

2) I was poking around the GDA format since I need to make it easier to change some GDA values externally, as I can't use custom INI values from the UI (no DAScript either). I'm not writing a full-fledged GDA editor - more like a simple config utility that changes some of the values. The hashes weren't essential to it, but I just knew I was doing something stupid somewhere (like not putting the nulls around the right way)...

Modifié par FollowTheGourd, 08 janvier 2010 - 04:38 .

[elys]

Oh I've missed the topic you just highlighted ( basically I missed anything before the first days of 2010 )
Gonna read it now.