Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outfits not displaying correctly while using asset files #966

Open
2 of 5 tasks
AvajiOT opened this issue Nov 15, 2024 · 2 comments
Open
2 of 5 tasks

Outfits not displaying correctly while using asset files #966

AvajiOT opened this issue Nov 15, 2024 · 2 comments
Labels
bug Something isn't working Priority: Medium This issue may be impactful and needs some attention. Status: Pending Test This PR or Issue requires more testing Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors.

Comments

@AvajiOT
Copy link

AvajiOT commented Nov 15, 2024

Priority

Medium

Area

  • Data
  • Source
  • Docker
  • Other

What happened?

While using assets in OTCR, a visual bug happens when creatures of certain looktypes are moving. I personally tested with OTCR (multiple builds throughout the last two years) and TFS, 1.5 to 1.7.

Few examples;

Posted back in 2023, https://discord.com/channels/888062548082061433/1091770506253959318 I reported the issue showcasing a broken looktype, # 63. Can't upload directly to github, so here's an imgur link. Unknown what my versions were at the time, but it would've been whatever was the most recent at that time.
https://i.imgur.com/cJTwFdm.gif
This certain looktype is not the only one to be broken, but was just shown as an example. Left side of the gif shows OTCR, and the right side shows

Just today, I pulled the latest versions of OTCR (commit c3aace1) and TFS (commit 6982d66) and logged into test. I clicked through a few outfits to showcase multiple that were broken. On this image, the right side, is OTCR with assets files, and on the right side is again OTCR with the exact same asset files just converted to .dat/.spr files with the game feature GameLoadSprInsteadProtobuf enabled.
https://i.imgur.com/Rf1RE11.gif

Recently, another user on discord (_mattzon) posted having the same issue using the most recent version of Canary, OTCR (unknown build) and 1340 CIP client. Can see their post here; https://discord.com/channels/888062548082061433/1306420047853387827/1306420047853387827 The images are again too large to attach to this issue

Would love to move to assets fully if this gets corrected, as the asset files are a lot smaller then dat/spr files, and easier to update.

What OS are you seeing the problem on?

Windows

Code of Conduct

  • I agree to follow this project's Code of Conduct
@AvajiOT AvajiOT added the Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors. label Nov 15, 2024
@github-actions github-actions bot added bug Something isn't working Priority: Medium This issue may be impactful and needs some attention. Status: Pending Test This PR or Issue requires more testing labels Nov 15, 2024
@kokekanon
Copy link
Contributor

kokekanon commented Nov 15, 2024

There are several open issues on the same problem (# 828 # 875 # 914 # 961 # 966 , # 968). I think the problem is here

#914 (comment)

in: otclient/src/client/thingtype.cpp
function: void ThingType::unserializeAppearance
If :

"// correction for some sprites "

Or

does not incorporate logic:

  • bounding_square
  • bounding_box_per_direction

@AvajiOT
Copy link
Author

AvajiOT commented Nov 15, 2024

There are several open issues on the same problem (# 828 # 875 # 914 # 961). I think the problem is here

#914 (comment)

in: otclient/src/client/thingtype.cpp function: void ThingType::unserializeAppearance If :

"// correction for some sprites "

Or

does not incorporate logic:

* bounding_square

* bounding_box_per_direction

I took a loot at the assets through assets editor and realized that

  • Every sprite I looked at was a sprite that needed a 64x64 box to show since it wasn't just 32x32
  • Every sprite had some odd bounding box per direction. Ones with 32x32 are usually just 0, 0 -> 32, 32, while some that were 64x64 were like 31, 31 -> 34, 34.

I think you're correct

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Priority: Medium This issue may be impactful and needs some attention. Status: Pending Test This PR or Issue requires more testing Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors.
Projects
None yet
Development

No branches or pull requests

2 participants