A long time ago there was this mod called gravitycraft. It was pretty cool, but it was for ModLoader 1.2.5. I wanted to create something similar to it, but in order to do so I need to know how to change the direction and power of gravity. Does anyone know how to do it?
It does not change the player's pitch, yaw, or roll. Not the view, but the whole player.
well. for that to work, you'd probably have to do base edits, considering the linked mod did that a lot..
(the model rotation doesn't require base edits though I believe, but the view rotation does (probably))
So, I created the tickHandler and it worked, however, my y motion was either 0 or very slow. I did not speed up when falling, and I could not jump. How would I fix this? Would I need to make a new physics engine for each type of gravity?
Another problem I'm having is that because it happens every tick, the y motion is repeatedly changing, and then that value is being used to calculate a new y motion.
EDIT: Is it possible to edit the vanilla Minecraft code without using a coremod? I don't think it would cause too many incompatibility issues because I'm modifying the gravity, something that very few mods use.
I just learned ASM and transforming bytes, and honestly, it's not as hard as most people think, atleast in my opinion. But if you're not very good at java, I'd wait a bit.
Rollback Post to RevisionRollBack
If I helped you then please press the button.
Be sure to quote my post if you want a reply.
lol @ Cameronazzi copy-pasting my sig into his
The only way would be with i think its byte injecting but thats for very advanced java programmers, i recommend just inserting some if statements in the player tick.
The problem with inserting if statements is that the player tick doesn't include the pressing of keys, nor passing through a nonsolid block. That still leaves view and model rotation though...
To change gravity speed is pretty simple, from a mathematical perspective. Gravity in computing (at least in low precision environments like games) is usually simulated by simply increasing the speed of an object by a fixed amount every step, occasionally multiplying it and stuff for fun. One approach is to ASM transform the line of code that increases the motionY of an entity, then just handle it all in your own event handler. In theory, however, you can simply counteract gravity by changing the Y speed by the same amount, but in the reverse direction. Looked at source, this would be far too convoluted inefficient after taking everything else into account.
You're going to have a lot of fun trying to change all the directions around. I personally think that you will need to overwrite several fields in EntityLivingBase, if not replace an entire method with your own rewritten version. Fun fun fun.
Onmi-directional gravity is a little bit more complicated, but still relatively straight forward if you know the maths involved.
What we first need is a normalized direction vector. Using this, we will calculate a force vector, which will then be used to change the player's velocity. Since I have no idea of the best ways to use vectors in Java, I'm just going to use generic arrays. I will also refer to a couple of custom methods, such as finding the sum of a vector's internal members, scalar multiplication, stuff like this.
Random methods that might appear in the example below;
public static double[] scale(double[] v0, double s) {return new double[](3) { v0[0] * s, v0[1] * s, v0[2] * s};}
The thingy
//First and foremost, how strong is the gravity? double GRAVITY = 0.003D; //This constant represents the strength of gravity from a source at some arbitrary distance from the location of the source. Above, I'm pretending that the the strength of the gravity is 0.003D at 16 blocks distance. This means at 8 blocks distance, it is 0.012D, and at 32 blocks distance, 0.00075D, and so on, because that's how gravity works)
//Where is the source? double[] directionVector = new double[](3) { (originX - posX), (originY - posY), (originZ - posZ) };
//Normalize to get a direction vector double len = 1/Math.sqrt(sum(multiply(directionVector, directionVector))); //inversification! directionVector = scale(directionVector, len);
//Now that we know the distance to the source, we can calculate the actual gravity. //Gravity strength is inversely proportional to distance (and our gravity here is given at 16 blocks distance) double actualGravity = GRAVITY * 16 * 16 * len * len //square the difference, (16/distance)^2
//Now we just have to calculate the applied force vector double[] forceVector = scale(directionVector, actualGravity);
//Finally, we just gotta change the entity speed by the above quantity motionX += forceVector[0]; //Pay attention to the sign you use here motionY += forceVector[1]; motionZ += forceVector[2];
//TODO: factor in mass of entity being pulled, wind resistance, etc. Might need to hack the collision engine apart to allow for friction IFF your gravity may not be applied perpendicularly to the face of a cube, etc
From the above, note that bad things will happen with non-perpendicular collisions, since the MC collision engine doesn't really support things like friction.
EDIT: It's actually painful to use the new forum... the message editor is absolutely terrible.
Is there another integer I could use, like the jump power?
Integers are whole numbers. Jump power is a double precision float (double). That aside, I still don't follow your meaning.
To simply change the power of gravity is very straight forward, and I'm sorry if my earlier post was misleading. Just recognize that when free falling, the player accelerates downwards by 0.08 per step, and then has their vertical speed multiplied by 0.98. All you have to do is, while falling (negative motionY) bring the speed closer to 0 (don't divide by 2, this will compound super fast and you basically will not move at all! multiply by about 0.96 instead), and when going up (positive motionY), increase the speed (away from zero) by something from 0 to 0.08 (+0.04 will roughly double jump height and stuff).
I was addressing DIRECTIONAL gravity (aka, side to side, up AND down, and so on). If you open up EntityLivingBase#moveEntityWithHeading, you will be able to see the things that need to be changed for such a thing to work.
One other approach, that isn't negating the motion changes, or using ASM, may be to try and replace this method with your own version, calling your own method from the event trigger, while cancelling the vanilla event... though this only works if the event can be cancelled, and gets thrown before the motion updates happen
On a different note, you could probably use a simple shader to invert the camera if you can't find another way to do it without core mods.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Integers are whole numbers. Jump power is a double precision float (double). That aside, I still don't follow your meaning.
If you open up EntityLivingBase#moveEntityWithHeading, you will be able to see the things that need to be changed.
One other approach, that isn't negating the motion changes, or using ASM, may be to try and replace this method with your own version, calling your own method from the event trigger, while cancelling the vanilla event... though this only works if the event can be cancelled, and gets thrown before the motion updates happen
On a different note, you could probably use a simple shader to invert the camera if you can't find another way to do it without core mods.
So I would use the ASM to change the method being called, then write my own physics engine?
However, a simpler way would be to counteract the speed increase made by the vanilla engine, with a speed decrease in my TickHandler that isn't strong enough to completely counteract the vanilla speed, allowing for slower gravity. Is it possible to do so, and if it is, how fast does the player accelerate? Also, I didn't think of using the flip shader, but that would mean that the player's current shader would be removed, if they were using one.
EDIT: Sorry, didn't see the falling speed of the player in your post.
@Shaders and flipping: I'm pretty sure MC probably just uses openGL or something, so you should be able to run as many shader passes as you like, or find some other simple way of flipping the screen.
ASM is a last resort. Have a look and see when the LivingUpdateEvent is fired. If it is fired before anything else happens for the actual update process, you can probably just cancel the event, and then run your own code. (I only recently thought of this; new to MC and Java lol)
@SubscribeEvent
public void doTick(LivingUpdateEvent event)
{
event.setCanceled(true);
//Do your modified method stuff here
}
As for the counteracting vanilla gravy stuff... (I edit my posts a lot, sry :P)
@SubscribeEvent
public void doTick(LivingUpdateEvent event)
{
if (!event.entityLiving.isAirBorne) return; //Important, this should fix jumping problems
if (event.entityLiving.motionY < 0)
{
event.entityLiving.motionY *= 0.96D;
}else
{
event.entityLiving.motionY += 0.041D;
}
}
EDIT: AAARRRRGH can't make code tags go in the right damn places!
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
It has no effect, when I try using > instead of <, I get the problem where it fires over and over again, causing me to fly up infinitely. I also changed LivingUpdateEvent to PlayerTickEvent, so the mobs wouldn't go flying for infinite lag if it was wrong.
Do you understand how Forge Events work? They can be pretty confusing, especially if you are new to OO languages or coding in general
The init events are for when the game loads up (when it flashes the big Mojang logo on the screen etc). This is where we do things like make new blocks and items, and register our event handlers.
Also note that tick handlers and event handlers use different declarations: by changing from LivingUpdateEvent to PlayerTickEvent, you've changed from detecting a regular event to detecting a tick event, and as such you will need to register your class again as a tick handler
A long time ago there was this mod called gravitycraft. It was pretty cool, but it was for ModLoader 1.2.5. I wanted to create something similar to it, but in order to do so I need to know how to change the direction and power of gravity. Does anyone know how to do it?
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
1: It doesn't allow you to modify the xmotion or zmotion, but I could fix that.
2: It does not change the player's pitch, yaw, or roll. Not the view, but the whole player.
Would I have to create a seperate mod to change the rotation?
EDIT: There is a mod that manipulates gravity, but it doesn't have all of the features I want it to.
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
well. for that to work, you'd probably have to do base edits, considering the linked mod did that a lot..
(the model rotation doesn't require base edits though I believe, but the view rotation does (probably))
Art by me: MrPancakeWolfie@DeviantArt
Alright, I did that, but how do I call that method? In other words, how do I make an event cause the gravity to be halfed like that?
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
Though, how would I manipulate the x and z motion without tampering with the walking speed?
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
EDIT: Is it possible to edit the vanilla Minecraft code without using a coremod? I don't think it would cause too many incompatibility issues because I'm modifying the gravity, something that very few mods use.
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
Be sure to quote my post if you want a reply.
lol @ Cameronazzi copy-pasting my sig into his
The problem with inserting if statements is that the player tick doesn't include the pressing of keys, nor passing through a nonsolid block. That still leaves view and model rotation though...
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
That doesn't work though,
the else if statement is going to keep going forever. I tried it.
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
In theory, however, you can simply counteract gravity by changing the Y speed by the same amount, but in the reverse direction.Looked at source, this would be far too convoluted inefficient after taking everything else into account.You're going to have a lot of fun trying to change all the directions around. I personally think that you will need to overwrite several fields in EntityLivingBase, if not replace an entire method with your own rewritten version. Fun fun fun.
Onmi-directional gravity is a little bit more complicated, but still relatively straight forward if you know the maths involved.
What we first need is a normalized direction vector. Using this, we will calculate a force vector, which will then be used to change the player's velocity. Since I have no idea of the best ways to use vectors in Java, I'm just going to use generic arrays. I will also refer to a couple of custom methods, such as finding the sum of a vector's internal members, scalar multiplication, stuff like this.
Random methods that might appear in the example below;
return v0[0] + v0[1] + v0[2];
}
{return new double[](3) { v0[0] * v1[0], v0[1] * v1[1], v0[2] * v1[2] };}
{return new double[](3) { v0[0] * s, v0[1] * s, v0[2] * s};}
The thingy
double GRAVITY = 0.003D;
//This constant represents the strength of gravity from a source at some arbitrary distance from the location of the source. Above, I'm pretending that the the strength of the gravity is 0.003D at 16 blocks distance. This means at 8 blocks distance, it is 0.012D, and at 32 blocks distance, 0.00075D, and so on, because that's how gravity works)
//Where is the source?
double[] directionVector = new double[](3) { (originX - posX), (originY - posY), (originZ - posZ) };
//Normalize to get a direction vector
double len = 1/Math.sqrt(sum(multiply(directionVector, directionVector))); //inversification!
directionVector = scale(directionVector, len);
//Now that we know the distance to the source, we can calculate the actual gravity.
//Gravity strength is inversely proportional to distance (and our gravity here is given at 16 blocks distance)
double actualGravity = GRAVITY * 16 * 16 * len * len //square the difference, (16/distance)^2
//Now we just have to calculate the applied force vector
double[] forceVector = scale(directionVector, actualGravity);
//Finally, we just gotta change the entity speed by the above quantity
motionX += forceVector[0]; //Pay attention to the sign you use here
motionY += forceVector[1];
motionZ += forceVector[2];
//TODO: factor in mass of entity being pulled, wind resistance, etc. Might need to hack the collision engine apart to allow for friction IFF your gravity may not be applied perpendicularly to the face of a cube, etc
EDIT: It's actually painful to use the new forum... the message editor is absolutely terrible.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
Integers are whole numbers. Jump power is a double precision float (double). That aside, I still don't follow your meaning.
To simply change the power of gravity is very straight forward, and I'm sorry if my earlier post was misleading. Just recognize that when free falling, the player accelerates downwards by 0.08 per step, and then has their vertical speed multiplied by 0.98. All you have to do is, while falling (negative motionY) bring the speed closer to 0 (don't divide by 2, this will compound super fast and you basically will not move at all! multiply by about 0.96 instead), and when going up (positive motionY), increase the speed (away from zero) by something from 0 to 0.08 (+0.04 will roughly double jump height and stuff).
I was addressing DIRECTIONAL gravity (aka, side to side, up AND down, and so on). If you open up EntityLivingBase#moveEntityWithHeading, you will be able to see the things that need to be changed for such a thing to work.
One other approach, that isn't negating the motion changes, or using ASM, may be to try and replace this method with your own version, calling your own method from the event trigger, while cancelling the vanilla event... though this only works if the event can be cancelled, and gets thrown before the motion updates happen
On a different note, you could probably use a simple shader to invert the camera if you can't find another way to do it without core mods.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
So I would use the ASM to change the method being called, then write my own physics engine?
However, a simpler way would be to counteract the speed increase made by the vanilla engine, with a speed decrease in my TickHandler that isn't strong enough to completely counteract the vanilla speed, allowing for slower gravity. Is it possible to do so, and if it is, how fast does the player accelerate? Also, I didn't think of using the flip shader, but that would mean that the player's current shader would be removed, if they were using one.
EDIT: Sorry, didn't see the falling speed of the player in your post.
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
ASM is a last resort. Have a look and see when the LivingUpdateEvent is fired. If it is fired before anything else happens for the actual update process, you can probably just cancel the event, and then run your own code. (I only recently thought of this; new to MC and Java lol)
As for the counteracting vanilla gravy stuff... (I edit my posts a lot, sry :P)
EDIT: AAARRRRGH can't make code tags go in the right damn places!
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
Also, this level of calculation will not lag any computer that can run Minecraft, just... your sheep will fly away (mod idea~)
EDIT: It works just fine for me...
EDIT: This might not work good with servers I think... Will need input of a more experienced modder on that bit
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
If it changes anything, my TickHandler is in my main mod class.
Let's do some math.
1/3 = 0.333...
1/3 * 3 = 1
0.333... * 3 = 0.999...
1 = 0.999...
1 - 0.999... = 0.999... - 0.999...
0.0...1 = 0
0.0...1 * 10... = 0 * 10...
1 = 0
The init events are for when the game loads up (when it flashes the big Mojang logo on the screen etc). This is where we do things like make new blocks and items, and register our event handlers.
Also note that tick handlers and event handlers use different declarations: by changing from LivingUpdateEvent to PlayerTickEvent, you've changed from detecting a regular event to detecting a tick event, and as such you will need to register your class again as a tick handler
Your main class should look something like this;
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.