Best way for me to explain it would be to show an example.
This is the neg info found using boshaw's layer util. I extracted the info from the haven-res.jar and then opened the neg_0.data of a random res that have a hitbox, in this case a cauldron.
- Code: Select all
#NEG LAYER FOR RES: out///gfx\terobjs\cauldron.res
#Coord cc
36
52
#Coord bc
0
-10
#Coord bs
0
10
#Coord sz
583
65
#Byte en
0
What I call the non edited hitbox data can be seen here to be bc = (0,-10); bs = (0,10).
To me this makes no sense other then some random numbers. They look to start at 0,0 and end at -10,10. I just know they are the hitbox data before the isometric conversion done inside the Resourse.java converting them from what ever these numbers are to the numbers that are useful in being able to use them as rectangles. These numbers get very confusing when things get a bit more complicated like in some ridges.
I also found that its impossible to make any edits to these numbers as rounding errors skips accuracy causing even more issues trying to fix the hitboxes of some rare objects with faulty hitbox data.
When I was editing the faulty hitboxes I basically took the bc and bs of the ingame numbers (not the data found in the neg but the data after the data had been converted using that s2m function) and added or subtracted numbers to get the proper hitboxes. I also found that it was impossible to edit the original neg data to get a proper hitbox after the s2m function as the s2m function does rounding to the numbers causing it to become inaccurate.
In short. All these non edited or rather, original neg bc and bs numbers, are just useless. They need to be converted to the isometric number system used inside the game. Then you can edit them with ease and skip that conversion algorithm done inside Resource.java.
This is what the cauldron looks like after the conversion using the s2m function.
- Code: Select all
#NEG LAYER FOR RES: out///gfx\terobjs\cauldron.res
#Coord cc
36
52
#Coord bc
-5
-5
#Coord bs
10
10
#Coord sz
583
65
#Byte en
0
Now this is useful info.
The bc = (-5,-5) is the offset and bs = (10,10) the size.
When the server send the info to the client they are received as a bunch of coordinates and a resname to go along with them. The client take the resname of each object and designates a bunch of info to the objects. One of the info is neg info it attaches to the object. To make a hitbox rectangle of the object you need to designate it start point so thats where bc comes in. If you take the object coord and add the bc to it you get the start location of the rectangle. The size of the rectangle is then the bs completing the data to make a Java Rectangle.
What was needed to make the jobb easier to edit the faulty hitboxes was to edit all res files to convert from the original neg data to the converted s2m data. Then you could easily edit the neg data where it was needed by editing the bs and bc. Then remove the conversion needed in the Resource.java to skip that step and get the data directly. It would be impossible to make some hitboxes match by editing the bc and bs if it was in its original form.
