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

Fix granito bugs #2797

Open
wants to merge 30 commits into
base: master
Choose a base branch
from
Open

Fix granito bugs #2797

wants to merge 30 commits into from

Conversation

MatusGuy
Copy link
Member

@MatusGuy MatusGuy commented Feb 22, 2024

closes #2796

TODO:

  • Tux cannot unduck in front of Granito
  • Rock Rolling and Granito don't mix (gets force pushed out of Granito hitbox)
  • Tux falls off Granito when going up (and maybe down?) a slope
  • Granito becomes a conveyor belt
  • Plays walking animation when landing/staying on a slope
  • Granito set to type "Standing" when pushed by bomb explosion never resets speed (might be better to not have them be push-able at all)
  • Big Tux jittering on Granito while standing on them
  • Granito can walks/falls through bricks+heavy bricks+rocks
  • Sitting Granito waves at player and remains standing afterwards (should not wave at all when sitting)

@MatusGuy MatusGuy marked this pull request as draft February 22, 2024 23:39
@mrkubax10 mrkubax10 added involves:functionality status:in-progress Progress has been done, but more is intended be done category:code type:bugfix Pull Requests that fix bugs. labels Feb 23, 2024
@Rusty-Box
Copy link
Member

This feels forgotten about. What was the status on this?

@Rusty-Box Rusty-Box added this to the 0.7.0 milestone Apr 13, 2024
@Rusty-Box
Copy link
Member

Just so we don't forget to fix this bug - Granito can walk through bricks+heavy bricks which is not good.
They also walk/fall through rocks.

MatusGuy and others added 7 commits June 26, 2024 11:15
…3032)

The `Screen` abstract class now provides virtual methods for SDL and window resize events. The `Editor` and `PartcleEditor` classes now `override` the `event(const SDL_Event& ev)` method and `Editor` `override`s `on_window_resize()`.

Resize events in `ScreenManager` are now handled by all `Screen`s in the stack. SDL events are only handled by the current (top) screen.

Additionally, `OptionsMenu` now calls `ScreenManager::on_window_resize()` on video setting changes, instead of just calling `MenuManager::on_window_resize()`. This fixes a bug where the editor crashes on changing the "Video Resolution" and "Magnification" settings from the in-editor "Options" menu.
The add-on **Revenge in Redmond** updated for the upcoming version of SuperTux.

**Update includes**
- Small intro and outro (text crawl)
- Old title theme + retro themed menu level
- Major changes to the levels "Late Office Nights", "Get to da Choppa!"
- Completely reworked "Where Is My Super Cape!?" level
- Minor tweaks to all other levels

---

- [x] Set `menu_retro.stl` as menu level for RiR Add-On
@MatusGuy
Copy link
Member Author

Plays walking animation when landing/staying on a slope

Can't reproduce this one for whatever reason

Rock Rolling and Granito don't mix (gets force pushed out of Granito hitbox)

This one is really hard to pinpoint. Seems to be an object unisolid hitbox issue. I've been using giant granito to test this. Things to note:

  • collision is not called in GiantGranito. Can't confirm if it is in Player (but it probably isn't)
  • The rock rolling is implemented in a very strange way. When an enemy hits the top of the hitbox while rolling it slowly sinks down until just randomly dying. I don't see anywhere in the code where it says "if rock and going at high speed then kill enemy"
  • Despite the collision event not being called, CollisionSystem::collision_static/CollisionSystem::collision_static_constraints and CollisionSystem::collision_object both change tux's position in some way.

@MatusGuy
Copy link
Member Author

Big Tux jittering on Granito while standing on them

Very inconsistent bug. Feels like a floating point error.

@Brockengespenst
Copy link
Contributor

  • The rock rolling is implemented in a very strange way. When an enemy hits the top of the hitbox while rolling it slowly sinks down until just randomly dying. I don't see anywhere in the code where it says "if rock and going at high speed then kill enemy"

Could this be the line you are looking for?

badguy.kill_fall();

The flag for „rock rolling“ is m_stone.

@MatusGuy
Copy link
Member Author

Could this be the line you are looking for?

In theory this only kills enemies from below. I'll try playing around with that.

The flag for „rock rolling“ is m_stone.

I know that.

@MatusGuy
Copy link
Member Author

Big Tux jittering on Granito while standing on them

According to my tests this has been magically fixed in this PR?

@MatusGuy MatusGuy marked this pull request as ready for review August 10, 2024 19:30
Narre and others added 11 commits August 11, 2024 01:08
* make "[DISABLED]" translatable

* remove pointless _() function call

* make "{} *UPDATE*", "{} [DISABLED] *UPDATE*" and "{} [DISABLED]" translatable as single strings

* remove unnecessary fmt::runtime() calls
…rTux#3031)

Fixes a bug in simplesquirrel, which caused exposed class member variables to be inaccessible from Squirrel.

Additionally:

* Simplesquirrel now supports custom getters and setters for class member variables. Because of this, more `get_` and `set_` functions of objects now have an alternative variable, which can also be used.
* All `get_` and `set_` functions which were made obsolete by member variables are now un-deprecated, because of a noticeable preference amongst scripters to keep both options available for convenience.
Makes the error handler print fatal exceptions to the command line, as well as reverts commits eacdc11 and 2d92941, which make the exception message not print out on the dialog.
…uperTux#2963)" (SuperTux#3040)

This reverts commit 7302e4b.

RelWithDebInfo include debug data separately from the executable, which needs
a debugger to be interpreted properly. The debug data does not affect stack
traces generated by the program itself, but increases the executable by more
than 100Mb, which is wasted if the user does not intent to run the exectuable
inside a debugger.

Co-authored-by: Semphris <[email protected]>
@@ -566,16 +566,17 @@ Sector::is_free_of_statics(float left, float top, float right, float bottom,
}

bool
Sector::is_free_of_movingstatics(const Rectf& rect, const MovingObject* ignore_object) const
Sector::is_free_of_movingstatics(const Rectf& rect, const MovingObject* ignore_object, const bool ignoreUnisolid) const
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code style: Please name the variable ignore_unisolid

@Rusty-Box
Copy link
Member

Looking better and better. Found a few more things though:

  • Larger Rock push Granito (Big and Small) into the ground. This is actually an issue big rocks have in general with objects smaller their scale, even small rocks. This might also affect Granito stacking in that a Granito with a bigger hitbox will phase through a Granito with a smaller hitbox
  • Small Granito does no longer look up when you stand on them.
  • Walking Small Granito does not play fall animation when they fall off platforms
  • Granito (Big and Small) can still walk through small rocks for some reason

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:code involves:functionality status:in-progress Progress has been done, but more is intended be done type:bugfix Pull Requests that fix bugs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Issues with Granitos
9 participants