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

Crash/Kick with Slime Blocks and Iron Golem morph (caused by exponential gravity) #206

Closed
James103 opened this issue Mar 25, 2020 · 5 comments

Comments

@James103
Copy link

When you are morphed as an Iron Golem, some weird things happen in regards to gravity and motion:

  1. If you start bouncing on a Slime Block from high enough (about 20 blocks), you will bounce exponentially higher with each subsequent bounce. This reaches a point where you will lag very severely at the end of each bounce (as in several seconds per frame) and eventually crash and/or kick.

  2. To fall from 10,000 blocks only takes twice as long as to fall from 100 blocks for you, compared to 10x longer for others. To fall from 100 million blocks only takes four times as long as to fall from just 100 blocks, compared to 1000x longer for others. This does not make sense at all.

Both of those things are caused by the following code below, which, multiplies the motion instead of adding to it every tick. A possible solution may be to change the gravity back to quadratic (like all other morphs have it), but increase the strength of the gravity (and possibly jump strength as well)

if (target.motionY > 0)
{
target.motionY *= 0.9;
}
else
{
target.motionX *= 0.5;
target.motionZ *= 0.5;
target.motionY *= 1.3;

@mchorse
Copy link
Owner

mchorse commented Apr 5, 2020

Hello, @James103! Thank you for bringing up this issue, what do you think will be a good value for addition instead of *= 1.3?

@James103
Copy link
Author

James103 commented Apr 5, 2020

Here is what I'm thinking should ideally replace the current solution:

if (target.motionY < 5)
{
    target.motionY *= (1.1 - target.motionY / 50.0);
}

This means that exponential gravity still applies, but only until a specified terminal velocity is reached. In addition, the exponential gravity weakens as you go faster, eventually having no effect after 100 m/s (or some other value based on what you're thinking).

If you really want to have normal gravity and no exponential gravity, then I don't know what the ideal max value for gravity is, but I've seen someone use a gravity value of 0.10 meters per tick squared and still be able to jump 1 meter. This would imply multiplying the standard gravity (which is 0.08 meters per tick squared) by 1.25 or adding 0.02 meters per tick squared (target.motionY += 0.02) to the standard gravity.

I'm still waiting on feedback from @asanetargoss, the author of a fork of Metamorph called Changeling, before I truly decide on a solution to this problem.

@mchorse
Copy link
Owner

mchorse commented Apr 5, 2020

That looks perfect IMO, but yeah, let's wait for @asanetargoss! 🙂

Also, I apologize for a delayed response, I rarely have a mood to look through any suggestions/reports concerning Metamorph as they usually contradict my interests. 😓

@asanetargoss
Copy link
Contributor

asanetargoss commented Apr 6, 2020

Good enough.

Since this is the first time we may be receiving a code contribution which applies to both Metamorph and Changeling, we should probably decide how that works...

I think, any PRs related to survival should be submitted to the Changeling repository. If it's machinima-related, then the Metamorph repository. Of course, generally McHorse has been pretty happy accepting pull requests (I submit pull requests to him and this allows us to keep our mods in sync), but if we're accepting the same changes, possibly with subtle code differences, it could get really messy while we're using git sorcery to get our mods back in sync.

Thoughts on this, @mchorse ?

@mchorse
Copy link
Owner

mchorse commented Apr 6, 2020

Yeah, I agree. If you don't mind, @James103, it should be submitted to Changelings to avoid any potential git merge conflicts for @asanetargoss, and if @asanetargoss has time, he could PR those changes to my repo.

@mchorse mchorse closed this as completed Apr 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants