[Tool] Chinese sELedit v458 + guide

[NateDogg]

[post deleted]

deleted

 

[count0nz]

Re: Chinese sELedit v458

Awsome work so far Bro...

 

[SlaSH DaSH]

Re: Chinese sELedit v458

Indeed awesome work. I will try to finish the rest if you haven't yet.

 

[NateDogg]

[post deleted]

deleted

 

[SlaSH DaSH]

Re: Chinese sELedit v458

Yeah, in order to finish this I would need some more info on the elements.data structure. I'm familiar with hex editing and have hex edited my gs to give 100xp. However, I don't know enough about the elements.data hex structure to figure out how it defines breakes between the fields or rows. Otherwise, I could probably examine the file and manually figure out what those last 6 rows data types were.

Anythingthing you can do at this point is definitely appreciated

------ update ------

I made one discovery which may help. The hex at the beginning of each line of verdata.txt needs to match the hex at the first 8 bytes of the elements.data file. This is probably why the chinese editor cannot read the english files, not because of locale problems, but because only the first 4 bytes of the north american file matches, the next 4 bytes are different in the north american files.

I see. that itself explains a lot! Now we just need to find a way on how to make them match

 

[NateDogg]

[post deleted]

deleted

 

[SlaSH DaSH]

Re: Chinese sELedit v458

I've done some more examination of the files and I found out why the converstion didn't work. I've kind of deciphered the elements.data formats by looking at the hex and i'm building a python tool to scan the file and tell me how many records are in it and what their data widths are.

The north american elements files have an extra table in position 15 with no rows in it. So everything after table 15 won't match between the config files and the elements file. It appears that the chinese either don't have this table at all, or set their offset to 12 bytes for that table, basically skipping over the 8 bytes that define the table with no rows. I learned this by comparing the north american 449 config file and the chinese 449 config and saw they have different offsets for that one.

Basically, here is how to read the elements.data file:
If you are looking at a config file entry like this :
1 - EQUIPMENT_ADDON
140
ID;Name;type;num_params;param1;param2;param3
int32;wstring:64;int32;int32;int32;int32;int32

The number 140 is the offset. It defines how many bytes you need to read as metadata from the end of the last record (or in the case of the first record, from the start of the file). The last 4 bytes of the metada are the width of the records. After reading the offset, you read another 4 bytes and those tell you how many records are in the table. You can multiply the number of records by the record width to get the total number of bytes that make up the actual data of that table. So if you have a hex editor open and you are on the first character of the data of a table and you move forward x positions where x is the table width times the number of rows, then you will be at the start of the next table (or technically the start of the offset).

Here is an example of the 449 elements.data to illustrate it starts at byte 136 of the file and ends at the end of the first record of the first table (position 231)

00000088h: 58 00 00 00 EA 1B 00 00 86 1B 00 00 4E 00 2F 00 ; X...?..?..N./.
00000098h: 41 00 5F 00 4B 6D D5 8B 28 75 44 96 A0 52 5E 5C ; A._.Km諎(uD枲R^\
000000a8h: 27 60 31 00 00 00 00 00 00 00 00 00 00 00 00 00 ; '`1.............
000000b8h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000c8h: 00 00 00 00 00 00 00 00 00 00 00 00 4D 00 00 00 ; ............M...
000000d8h: 02 00 00 00 B9 01 00 00 01 00 00 00 00 00 00 ; ....?.........

To understand how to convert forsaken world hex to decimals uebari wrote a great tutorial here as part of her hex editing gs tutorial : http://forum.ragezone.com/f784/changing-exp-hex-editing-information-945319/

The first 4 bytes are 58 00 00 00. Basically you want to reverse those so its 00 00 00 58, or basically 58. You use a windows calculator in hex mode of the hext to dec converter here :

You must be registered to see links

to convert that into a number and you get 88. That's right because 88 is the width of the records in this table in bytes. You can confirm this by adding up the numbers of the table defintion field types:

int32 (4 bytes) + wstring:64 (64 bytes) + int32 (4 bytes) + int32 (4 bytes) + int32 (4 bytes) + int32(4 bytes) int32(4 bytes) = 88

The next pair is EA 1B 00 00. That translates to 00 00 00 1B EA which is 7146. That's right and we know it because we can open up the 449 elements editor and load a 449 elements file and see that the first table has 7146 rows in it. The next 88 bytes are the data of the first record in the table. If you look at the first 4 bytes of the record, you see 86 1B 00 00. That translates to 00 00 1B 86. We know from the table definition we should interpret this as in an integer so its a number, 7046. If you look in the elements editor you will see that 7046 is the value in the ID field for the first record of the first table. After those 88 bytes that make up the record, the next 88 bytes are the next record. There is no delimeters in this file. The records are all fixed width.

I see what you mean.. I had an examination myself and saw the extra table aswell. I wasn't sure if it had something to do with the conversion errors but after reading your post I can confirm that it had something to do with the config conversion.

 

[NateDogg]

[post deleted]

deleted

 

[YesOfCourse]

Re: Chinese sELedit v458

Just note that there is one section (or table) where the size of each block doesn't match the size that is on the elements file. (Example: elements files says int BlockSize: 88, int Size: 10 but the BlockSize is different than the real data that comes after). Not sure which section is like this but there is one for sure.

 

[NateDogg]

[post deleted]

deleted

 

[YesOfCourse]

Here you can see the part I talked about.

 

[AnthonyX]

Thank you so much for your hard works NateDogg and the people are working on FW tools development project!

Could you please for me and everyone here know there is any way to edit task.data and task.data1.... in this version?

I think there are tools to edit task.data file but I don't see anyone share it again or url to download it does not work!

Thanks again.

 

[count0nz]

Thank you so much for your hard works NateDogg and the people are working on FW tools development project!

Could you please for me and everyone here know there is any way to edit task.data and task.data1.... in this version?

I think there are tools to edit task.data file but I don't see anyone share it again or url to download it does not work!

Thanks again.

We don't have a Task's Edit at this time. but there are people working on it.

 

[Bola]

here a guide to get elements.data struct

You must be registered to see links

and if you want get tasks struct, look for ATaskTemplFixedData on gdb in libtask.so