Text Version of Ability Files: format in SINS 1.09+ ?

Somewhere I read that Ability Files in SINS 1.09 (Beta 1.1) don't convert with the ConvertData utility, likely because the format of those files had changed in some way...

I was hoping that it's because of new Buff Types being added into SINS, but if that were why, then at least some of the files would have converted the same way...

Anyway, I was wondering specifically how has the format changed for SINS abilities, and how will it affect already made abilities?

 

Also, what is a good way to convert large, precise numbers (that are stored in variables) into byte-sized chunks that files can handle?

6,084 views 4 replies
Reply #1 Top

Also, what is a good way to convert large, precise numbers (that are stored in variables) into byte-sized chunks that files can handle?

I don't understand the question, mostly because 'large' and 'precise' is usually somewhat contradictory. Precision typically means decimal places, in which case Sins is precise to 6 decimal places. Large implies lots of digits. :P

Can you give an example? Generally speaking, when you write to a file you only need to make sure that the file keeps to the boundries set by the game engine, you don't need to "convert" anything, just write the variable as-is. Obviously if your variable has more than 6 decimal places it's not going to work since all the GameInfo at least only takes 6.

Reply #2 Top

Sorry, I need a good measure of both, and was thinking I could just use the SINS number conversion methods for binary files, since my mesh-generator uses numbers in the same range as SINS for the "Save-Place" file...

   My Mesh-output already truncates to 6 places (4 really, for cleaner, smaller files), but it would be for saving numbers exactly:

If I remember my CSE classes correctly, it was hotly debated which bytes should save data on which side of the decimal point, and how many bytes to devote to storing a number exactly (and where to fudge when things don't fit)

I was thinking two bytes on either side of the decimal would do it, since I only use four decimal places precision, but I could use three bytes in front so the numbers could be large enough to handle certain things...

I'm looking for a parsed format since I have to write the program to un-parse and reconstruct the numbers, so I can reload my saved-data file directly into my program...

Example: 65535.9999

   byte1=int(int(number)/256)

   byte2=int(number)-(byte1*256)

   temp=number-((byte1*256)+byte2)

   byte3=int(temp*256)

   byte4=((temp*256)-byte3)*256

 

   Something like this is what I'm looking for...

Reply #3 Top

Ahh, I see. Now, I haven't coded in quite a few years, but can't you just parse the string to isolate the number, and then typecast it into a double? Then you won't have to worry about parsing the number itself.

Reply #4 Top

Actually, I was expecting you to say "LOL, use the code you just typed"... After posting the reply, I thought, gee, that would do it!

   In converting the numbers, I can read them efficiently as they all take up 4 bytes, and I don't have to think about variable sizes in the file, or where each number begins and ends...