You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
0.7 Nighties
Expected Behavior -
Spring will apply the texture given in the editor to the spring in-game.
Actual Behavior -
Spring will automatically revert back to the default sprite depending on object type, AKA the sprite change does not apply in game.
The text was updated successfully, but these errors were encountered:
std::string custom_sprite { };
if (mapping.get("sprite", custom_sprite))
{
if (!custom_sprite.empty())
{
change_sprite(custom_sprite);
}
}
to the constructor that takes the mapping as argument, right after parse_type(mapping);, but this does work for the constructor that just takes the Vector and a type. I have not yet figured out in which cases the latter one is called, so in a first basic test, the solution above did its job. But I assume there might exist a cleaner solution.
The issue is actually a result of a bad quirk in the MovingSprite code, which #2646 fixes. Such custom sprite validity checks are already performed in MovingSprite initializers.
0.7 Nighties
Expected Behavior -
Spring will apply the texture given in the editor to the spring in-game.
Actual Behavior -
Spring will automatically revert back to the default sprite depending on object type, AKA the sprite change does not apply in game.
The text was updated successfully, but these errors were encountered: