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 · 3 comments
Open
2 of 5 tasks

Outfits not displaying correctly while using asset files #966

AvajiOT opened this issue Nov 15, 2024 · 3 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
Collaborator

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

maybe new things are missing in the protobuf

message SpriteInfo {
	optional uint32 pattern_width = 1;
	optional uint32 pattern_height = 2;
	optional uint32 pattern_depth = 3;
	optional uint32 layers = 4;
	repeated uint32 sprite_id = 5;
	optional uint32 bounding_square = 7;
	optional SpriteAnimation animation = 6;
	optional bool is_opaque = 8;
	repeated Box bounding_box_per_direction = 9;
+  optional uint32 pattern_size = 10;
+  optional uint32 pattern_layers = 11;
+  optional uint32 pattern_x = 12;
+  optional uint32 pattern_y = 13;
+  optional uint32 pattern_z = 14;
+  optional uint32 pattern_frames = 15;
+  optional bool is_animation  = 16;
}

image

Example outfit : demon skeleton[id = 37] 13.32( good) vs 13.40 ( bad)

image

m_numPatternX = spriteInfo.pattern_width();
m_numPatternY = spriteInfo.pattern_height();
m_numPatternZ = spriteInfo.pattern_depth();
m_layers = spriteInfo.layers();
m_opaque = spriteInfo.is_opaque();

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

13.40 check box is 64 + variable bounding box per direction
image
vs
13.32 check box is 32
image

I think this is the problem, variant values + square >32 :
asdasd

For Example :
if I delete this, it's a little better

  • walking work
  • idler no work

Without if:

if (sizes.size() > 1) {
// correction for some sprites
for (const auto& s : sizes) {
m_size.setWidth(std::max<int>(m_size.width(), s.width()));
m_size.setHeight(std::max<int>(m_size.height(), s.height()));
}
const size_t expectedSize = m_size.area() * m_layers * m_numPatternX * m_numPatternY * m_numPatternZ * m_animationPhases;
if (expectedSize != m_spritesIndex.size()) {
const std::vector sprites(std::move(m_spritesIndex));
m_spritesIndex.clear();
m_spritesIndex.reserve(expectedSize);
for (size_t i = 0, idx = 0; i < sizes.size(); ++i) {
const int totalSprites = total_sprites[i];
if (m_size == sizes[i]) {
for (int j = 0; j < totalSprites; ++j) {
m_spritesIndex.push_back(sprites[idx++]);
}
continue;
}
const size_t patterns = (totalSprites / sizes[i].area());
for (size_t p = 0; p < patterns; ++p) {
for (int x = 0; x < m_size.width(); ++x) {
for (int y = 0; y < m_size.height(); ++y) {
if (x < sizes[i].width() && y < sizes[i].height()) {
m_spritesIndex.push_back(sprites[idx++]);
continue;
}
m_spritesIndex.push_back(0);
}
}
}
}
}

caca

With if; looktype invisible

336

@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

@InnerCircleTFS
Copy link
Contributor

@nekiro as the provider of the protobuf, do you know how to fix this problem ?

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

3 participants