User fixed res collection. [10]

[mvgulik]

General topic for discussing and collecting User-fixed resource(res) files.

- Combined fixed res collection file -
Download/mediafire: "HnH_User_Fixed_Res_Files.rar" - "[ version(rev-date)].[ files ].-"

Fixed list:

Code: Select all

## version: 2013.10.28
## res files: 10
## IMG+1: fixed by adding a additional default image. (has potential minor processing penalty)

gfx\kritter\hen\cdv            :fixes killed chickens being hidden (and kinda blocked) by blood.
gfx\terobjs\cauldron         :fixed shadow only build preview. (IMG+1)(Used for both Clay & Metal)
gfx\terobjs\crate            :fixes shadow only build preview. (ID adjustment)
gfx\terobjs\cupboard         :fixes shadow only build preview. (IMG+1)(+minor images offset adjustment)
gfx\terobjs\furniture\bed-straw   :fixes wrong layering & floor dragging element when lifted. (z adjustment)
gfx\terobjs\furniture\carpet   :fixes blank build preview. (kinda) (IMG+1)
gfx\terobjs\furniture\coffer   :fixes shadow only build preview. (IMG+1)
gfx\terobjs\furniture\wardrobe   :fixes shadow only build preview. (IMG+1)
gfx\terobjs\kilna            :fixes lit kiln versus unlit kiln position jump. (offset adjustment)
gfx\terobjs\querna            :fixes in-use quern versus not used quern position jump.


8)+ crate, carpet, coffer, wardrobe.
10)+ cauldron, cupboard.

If MediaFire or I do not screw up. The download link should remain the same across updates.

[mvgulik]

Known res files with issues:
"gfx\terobjs\plants\pumpkin" - Position kinda bugging me. Minor contribution by Ender client.
"gfx\terobjs\querna" - lighter shadow than on unused quern.

- shadow only build preview: can't, not with current/original images
gfx\terobjs\birchbasket
gfx\terobjs\furniture\bigchest
gfx\terobjs\lchest

- shadow only build preview: ... later, maybe.
gfx\kritter\wagon\wagon-N : ? (multy res object ...)
gfx\terobjs\furniture\chair : ? (rotational object ...)
gfx\terobjs\furniture\skullthrone : ? (rotational object ...)


=== Can't fix ===
Objects with sticky/lifted shadow:
- Not fixable at res level by users. As the 'nooff' setting seems to be pulled from the server.
- Additional stuff in post viewtopic.php?p=451763#p451763

[mvgulik]

Just creating this topic to see if it leads somewhere.
My bare minimum effort will be to pickup fixed res files and add them to the download file.

Consider that second post just some general todo list. That I probably can't resist updating ones in a while to.

[Xcom]

I might have something to add in here to.

It took me and a friend over a week to walk around colliding with different objects around the world to test every single hit box. We made a list of all items that were faulty and needed a hit box overwrite.

Some items have hit boxes where they shouldn't and are missing when they should have hit boxes.

Examples: Bears / Trolls have missing hit boxes when they clearly do and chanterells / logs / farming crops have hit boxes when they shouldn't. This is just a small list of items that are directly reversed.

There are also a ton more objects that clearly have a hit box that is to large or to small and some that are just 1 sub-tile offset in either x or y.

Examples: Herbalist table / gates of any kind / 50% of world ridges / village idol have a hitbox that is faulty in there hitbox colision size by 1 sub-tile in either x or y. These items often are 1 sub-tile to large. Other items like carts / small chests have a completely wrong hit box and clearly can be seen being oversized.

After weeks of testing walking around bumping into objects we found all the errors and made a list of the items. Then later made a filter to overwrite the hit box sizes.

Big issue with way the client recalculates the info goten from the res files, specifically from the neg file, and makes the neg numbers into a isometric number. About 95% of the errors happen here as allot of the isometric rounding are not matching that of the servers rounding system and it causes a miss match. The clients hit boxes and the servers don't match.

The best way to actually fix this problem would be to rewrite all the neg numbers in the res folder to actually represent the ingame sizes and not the pre isometric calculation numbers as they are right now. This would mean that Ender would have to update the client to not do the isometric conversion as well. But if done the hit boxes of all objects would be correctly represented.

I'm a bit unsure how this would best be done but if done the updated neg files could be used to make pathfinders or better hidden filters for the enders hide object filter.

[mvgulik]

Thanks for your work and info Xcom.

Mmm. Giving it some initial thoughts.
- I'm not sure if the hitbox data in the res files was included for more reasons than only as some debugging aid. (If it was only included for debugging ... it kinda puts it in a special class.)
- Changing the res hitbox coordinates to support a other calculation method ... Sound a little bit more than some simple res user fix.

Basically ... I'm not sure how to look at this either. I think some additional input from Ender or Loftar might be useful here.

Although I'm not sure yet about merging this with the other res-fixes-file (which currently only contains one single, and very lonely, res file. ). I don't have a problem putting up links to one (or both) hitbox corrected collections in the first post. And I can host them on my MediaFire space for you to, if you like.

[Xcom]

That would be really nice. But the res files have a neg folder which contains info on image size and other info besides hitbox data. The hitbox data is just incorrectly displaced and in some instances completely incorrect.

One big issue I would have is to actually change all the hitbox data manually. Maybe there is a way to automatically script it as there are alot of them. After doing the conversion from regular to isometric numbers edit the faulty ones after conversion.

Edit: If it might be possible to place all the neg files in there respective folders without the images or other info so graphic mods with other graphics could simply take the neg data and paste it over there moded graphics updating both the graphics and the neg data. This would make it so both moded and non moded grafics could have an updated hitbox data. But I'm unsure how relevant it is for anyone to have realistic hitbox data available to them.

[mvgulik]

That would be really nice. But the res files have a neg folder which contains info on image size and other info besides hitbox data. The hitbox data is just incorrectly displaced and in some instances completely incorrect.

info on image size: ? ... What data in the neg file is related to some image size data?
As far as I know the neg file has the following data: (HnH Layer util | Salem Layer util.)
Coord cc | cc(x) & cc(y) : general res position offset.
Coord bc | bc(x) & bc(y) : not sure, but at least one part of hitbox data. bc(y)
Coord bs | bs(x) & bs(y) : not sure, but at least some second part of hitbox data. bs(y)
Coord sz | sz(x) & sz(y) : purpose unknown to me.
en | en : purpose unknown to me.
epid & cn & ep..(x) & (y) : purpose unknown to me.

One big issue I would have is to actually change all the hitbox data manually. Maybe there is a way to automatically script it as there are alot of them. After doing the conversion from regular to isometric numbers edit the faulty ones.

I take it your revering to detecting, and collecting, the server enforced hitbox data. Ones you have those(per object res-name), using a simple program/script to modify the related (decoded, to keep things simple) res files should not be a problem.

there are alot of them:
Nobody is expecting that you get them all. Just having them on some of the general objects (like houses, containers and such) is a start.

PS: If the hitbox don't seems to match the on screen object. It might be the object graphics that are at fault.

[Xcom]

Best explanation I could give in short would be mechanics behind the function public Neg(byte[] buf) in the Resource.java folder.

This is where the data is handled.

cc = cdec(buf, 0);
bc = cdec(buf, 4);
bs = cdec(buf, 8);
sz = cdec(buf, 12);

These variables are taken directly out of the neg data file. The data in order from top to bottom.
cc - Some center value of the image.
bc and bs - Roughly explained, the X and Y values of the collision object.
sz - Yet some other image size value.

bc and bs are the interesting info so I'll skip cc and sz.

bc = MapView.s2m(bc);
bs = MapView.s2m(bs).add(bc.inv());

in this function the bc and bs are converted into there isometric values.

public static Coord s2m(Coord c) {
return(new Coord((c.x / 4) + (c.y / 2), (c.y / 2) - (c.x / 4)));
}

This is where the issue is. Its the damn rounding issues. The server does other rounding then the client and somehow ends up with different numbers. I have tried to use other methods to round and haven't found the correct rounding solution the server does compared to the client. In the end I just gave up and decided to go around the issue by tediously testing every single object in the game and see what object had the correct hitbox and what didn't.

I made a messy if check for every object and had every object with a incorrect hitbox be re-sized to its correct size. At the moment it was the easiest solution to the problem.

But as you made a really nice res collection making some edits to them would make it really easy. First thing I would do would be to make a script and have all the hitbox objects update there neg hit boxes from there current non isometric values to there isometric values. Would be easily done by having all the hitboxes go through that s2m function. The resulting neg collection would have the ingame hitbox displayed in them. From here the objects that needed editing would be edited and that would make the neg collection output the ingame hitbox when called.

As an example. Cauldrons have a non-isometric hitbox in the neg files with the bc (0, -10) and bs (0, 10). After the conversion the numbers look like this bc (-5, -5) and bs (10, 10). If all objects would go through that s2m function they would like the cauldron here display there ingame size instead of there non ingame size. From here it would be easy to edit the ones that have the incorrect sizes.

Lastly the Resourse.java would need an update. That would mean that in the Resourse.java the 2 functions relating to the isometric conversion "MapView.s2m( ... );" could be commented and all would be done.

I hope the explanation isn't to messy.

[mvgulik]

I hope the explanation isn't to messy.

I'll manage. If not I'll ask.

I will need some time to fully digest some stuff. (Some RL stuff limiting my speed and time.)

[mvgulik]

Erm. I'm Definitively hitting a brick wall with trying to understand the client java code.

While trying to see what that "bc = MapView.s2m(bc);" code is doing graphically I get this:

That looks kinda similar to something resembling a iso view of a grid. But if this transformation view is correct, it makes no sense to me.

The "bs = MapView.s2m(bs).add(bc.inv());" code makes no sense to me At All, at the moment.

Code: Select all

source: https://github.com/dolda2000/haven-client/blob/master/src/haven/Resource.java#L572
       bc = MapView.s2m(bc);
       bs = MapView.s2m(bs).add(bc.inv());
--- --- ---
source: https://github.com/dolda2000/haven-client/blob/master/src/haven/MapView.java#L465
    public static Coord s2m(Coord c) {
   return(new Coord((c.x / 4) + (c.y / 2), (c.y / 2) - (c.x / 4)));
    }


... Python note: Pillow (PIL fork) 2.0.0 is out, and supports Python versions: 2.6, 2.7, 3.2, 3.3 ...