Add-On Gravity Boots not working with new Zero-Grav Physics

SnailsAttack

Member
Jan 8, 2017
15
2
3
28
The new zero-gravity physics that seem to have been implemented in some newer update have completely broken all gravity-enabling items and blocks from other mods.

Can you perhaps add a config option to disable the new physics? Thank you.
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
Can you be specific about which "gravity enabling items and blocks" from "other mods" you're talking about here?
 

SnailsAttack

Member
Jan 8, 2017
15
2
3
28
Can you be specific about which "gravity enabling items and blocks" from "other mods" you're talking about here?

It causes items such as the Gravity Boots from both Galaxy Space and More Planets to be completely nonfunctional, and for the Artificial Gravity Generator from Amun Ra to function in a very strange way (kind of just makes the player float downwards and unable to jump).
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
All the mods you have mentioned are sub-mods of Galacticraft. It's for the authors of those sub-mods to make sure that their items work correctly with Galacticraft. Not the other way around!

If the sub-mod authors ask me specifically to change or expose some code to help their items stay compatible with Galacticraft then of course I will try to help.

To speed this along, you should raise the issue about Gravity Boots / Gravity Generator not working with the authors of Galaxy Space / More Planets / Amun Ra.
 

pra

Member
Mar 7, 2015
328
120
43
36
Overworld
But now that you mention it, radfast, could you provide us with a unified, clean way to selectively disable zero g effects for certain entities, pretty please? :D

I admit I haven't looked at the new zero g code yet, but the old code was kinda difficult to get around...
 

SnailsAttack

Member
Jan 8, 2017
15
2
3
28
All the mods you have mentioned are sub-mods of Galacticraft. It's for the authors of those sub-mods to make sure that their items work correctly with Galacticraft. Not the other way around!

If the sub-mod authors ask me specifically to change or expose some code to help their items stay compatible with Galacticraft then of course I will try to help.

To speed this along, you should raise the issue about Gravity Boots / Gravity Generator not working with the authors of Galaxy Space / More Planets / Amun Ra.
@radfast
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
Thanks, @FirEmerald wrote:

I am contacting you and Micdoodle as per EzerArch's suggestion to ask if the IArmorGravity interface can be extended to apply to space stations, as wearing the gravity suit makes it nigh impossible to navigate space stations due to jump boost propelling you 20+ blocks into the air.

The Gravity Suit is from your Metroid Prime mod that we talked about a couple of years back? See detailed question below, is there anything else you need switched off for IArmorGravity as well as that jump boost?

@pra and others:

I need to know specifically what needs changing. There are many components to Zero G - a.k.a. "freefall" - it's not a simple subject bearing in mind we also have to interact with the vanilla game engine instead of starting from scratch! Roughly speaking the components are these:

1) Replace vanilla gravity "acceleration" of -0.08 in the Y direction with gravity specified by the IGalacticraftWorldProvider - this happens in all Galacticraft dimensions. In zero or low gravity dimensions (like Asteroids) the Galacticraft-specified gravity is low but not zero. It's because there's a lower limit due to what some parts of vanilla mechanics can handle

2) For the player entity: undo any vanilla (or modded) motion each tick, and replace it with our own physics, i.e. continue moving with the same momentum until there's an impulse or collision (Newton's 1st Law!)

3) For the player entity: control effects, acceleration from using the W/S/Sneak/Jump keys (and A/D in Creative mode)

4) For the player entity: new sneak/jump mechanics

5) For the player entity: new collision mechanics

6) Different mechanics and control effects for players who are in contact with a surface, for example a wall - this is supposed to signify an astronaut pushing themselves around inside a space station using their arms (I plan to animate the arms when I have time)

7) For all entities: similar to (2)

8) For all entities: update entity positions even if they are close to the edge of the loaded chunks (keep mobs moving with the same momentum instead of 'freezing')

9) Evolved Zombies and Evolved Skeletons: "tumbling" rotation motion if they are in freefall, this is an Easter Egg :)

10) If the dimension is spinning, extra adjustment to position and motion of all entities which are not in contact with solid blocks, so that the entity doesn't spin around with the solid blocks unless the entity is actually standing on the solid blocks [I think there's currently a minor bug for EntityItems - dropped items - which are being updated correctly only server side not client side so will "glitch" when the client receives a server update, EntityItems already glitch like this in vanilla but the change is bigger if the dimension is spinning]

11) If the dimension is spinning, extra physics adjustment for the player if he is inside the space station or in contact with solid blocks, to give the correct physics effects of the spin: centrifugal force, maybe even a Coriolis effect happens automatically here but I didn't check.


@pra I need you to be more specific about what you mean by "selectively disable zero g effects for certain entities". And maybe you really want us to test whether the player is wearing an item, like the IArmorGravity?
 
Last edited:
  • Like
Reactions: Ezer'Arch

pra

Member
Mar 7, 2015
328
120
43
36
Overworld
Well, I would want to prevent everything except 1, 10 and 11...
Ideally, I would want the area within my AGG to work like in a regular dimension, albeit with a different gravity value.
What I meant by "selectively disable..." was: I want to check if the entity is within the area of an AGG, if yes, disable all effects of IZeroGDimension on it. If no, I want them to continue to happen.
Other modders might want to check if the entity has a certain item equipped instead of the area thing.

Maybe either an entry in GCPlayerStatsClient like "boolean isFreefallDisabled", which is set to false at the end of each postVanillaMotion (it's up to the modders to set it to true in their proxies), and then it's always "if (player.worldObj.provider instanceof IZeroGDimension && !stats.isFreefallDisabled)". Or, each time something IZeroGDimension-relevant happens, a specific event is fired, which a mod author can cancel?
 
  • Like
Reactions: SnailsAttack

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
I think I prefer the GCPlayerStatsClient approach. Firing + listening for events is a performance issue, like to minimise it if possible. And I think freefallDisabled works better as a binary state - either the player is in freefall in which case all of 2-6 should happen, or the player isn't in freefall... in which case they shouldn't.

Let me think on this some more. It's also possible that we may decide to make an antigravity block in GC Core for GC4, I'm discussing with micdoodle8, though if we do it will probably be creative only or top tier treasure. Actually one reason for maybe doing that is so that I can properly figure out and test the mechanics of the discussion we are now having.

It's maybe also possible that we will make Asteroids a zero G dimension at some future time - personally I hate the gravity there as I'm always falling out of the world - or introduce some of the mechanics in (4) and (5) into low gravity worlds as well as zero G worlds.
 
  • Like
Reactions: Ezer'Arch

FirEmerald

Member
Jan 30, 2016
6
0
1
26
Thanks, @FirEmerald wrote:
The Gravity Suit is from your Metroid Prime mod that we talked about a couple of years back? See detailed question below, is there anything else you need switched off for IArmorGravity as well as that jump boost?

The jump boost is an effect of the armor itself - I just want the physics, apart from spinning, to work as if the player were on the overworld. The suits effects (gravity feature in the game I will reference) are shown to even negate the effects of air rapidly escaping a room suddenly exposed to the vacuum of space, so if that were ever implemented in the future you might want to take that into consideration as well.
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
ok, understood, I'll see what we can do. You guys need this in 1.7.10 as well as Galacticraft 4, I guess?
 

pra

Member
Mar 7, 2015
328
120
43
36
Overworld
Yes, that would be nice.

I guess I should start porting, though, it will most certainly take a long time to do so...
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
Well it took micdoodle8 around 1 year of effort to port ~300,000 lines of code to 1.8.9, and more than that to have working 1.10.2 and 1.11.2 versions as well.... Might be easier for you as you can look at Galacticraft code to see how things are done. The main hurdle is understanding the new BlockState based system which is intended to replace metadata, and also is directly linked in to rendering of block models. There's a helpful introduction to this by williewillus (co-dev of Botania and other mods), I wish we'd known about this back at the beginning of the process! The other thing which is fairly different is if you want to render existing models which are in the OBJ format though we have solved this, you can look at Galacticraft rendering code.
 
  • Like
Reactions: pra

pra

Member
Mar 7, 2015
328
120
43
36
Overworld
That new stuff sounds pretty useful. Has anyone thought about backporting it to 1.7? I think I'll either try to parse these block model jsons in 1.7 or just drop 1.7 support altogether. At least now I understand why things like Venus aren't backported to 1.7 :D
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
I've not heard of anyone backporting block model jsons! I think the effort would be disproportionate. Why not just play in 1.8.9 or 1.10.2?

Most mods - including us - are not even maintaining world save compatibility from 1.7.10 to 1.8+, it's just too complicated. Even if the blocks are the same, the metadata can be different now.

Some other general points to watch when updating your mod to 1.8+:

* The rendering - chunk rendering is cached until a block in the chunk changes. The good: if blocks don't change - so the player is just running around in a static world - the frame rate can be very high now. The bad: if your mod needs to change a lot of blocks in neighbouring chunks (like the Arc Lamp does when it changes lighting, or the Airlock, or you can imagine an explosion or similar) it makes a nasty lag spike in the client. Even worse if the blocks change server-side, because server->client block changes are sent in batches and so the client gets to have several laggy frames in succession. If your mod needs to change the appearance of a block, you need to specifically notify the client of the render update - look at Energy Storage Module block rendering (BlockMachineTiered) for an example.

* Vanilla directions (numbers 0 through 5) and Forge Direction have both been replaced with a vanilla EnumFacing. This means every piece of your code which depends on directions has to be updated. Be careful with EnumFacing.Plane.Horizontals and the HorizontalIndex() 0 through 3 - these do NOT match directions NSWE like you'd expect, instead it's NESW, therefore all your rotations can be wrong if you use this. It means the facing metadata for a lot of blocks changed, in an annoying way.

* Almost every (x, y, z) in the game is replaced with a BlockPos - this is both good and bad. The good: you only have to pass one parameter to a method to specify a position, not three. This position parameter can thus be easily passed through a chain of methods. The BlockPos also has convenient .up(), .down() etc methods and a few others, and it's an object which can easily be stored in collections. It's actually not so much different from BlockVec3 which I made for Galacticraft 2 years ago.... The bad: the performance sucks, it's badly implemented in vanilla. If you use a profiler to look at the JVM you can see it spending 3-4% of total tick time just on simple BlockPos processing. Creating and destroying all these objects also adds to JVM memory requirements and the work of the garbage collector. And handling collections of objects is usually much worse performance than simple dealings with integer arrays.
 

Share this page