Skip to content
This repository has been archived by the owner on Jan 18, 2023. It is now read-only.

Ships and dimension changes #319

Open
DaMatrix opened this issue Aug 31, 2019 · 8 comments
Open

Ships and dimension changes #319

DaMatrix opened this issue Aug 31, 2019 · 8 comments
Assignees

Comments

@DaMatrix
Copy link
Member

Currently ships have no way of handling dimension transfer at all. Since the ship's blocks are stored in whatever world the ship itself is in, moving the physics wrapper entity from one world to another (for example through a nether portal, see #274) causes all kinds of issues as it's suddenly referencing blocks that no longer exist.

I propose a system where airships are stored in their own dimension, separate from all actual worlds. This could be a custom dimension, inaccessible for players, or even something like a leveldb database. Ships would be allocated a global (as in dimension-independent) identifier number which would correspond to a pair of chunk coordinates, similar to the existing VWChunkClaim. When a ship is loaded, all of the chunks would be read from disk and stored independently of all worlds, and then by using some amazing hackery with Mixins we could inject these chunk instances directly into the world that the ship is in, without the chunks actually being present in said world. IBlockAccess methods would continue to allow them to be interacted with as if they were actually part of the world, however serialization would be handled separately.

When a ship is transferred to another world, the process would be as simple as dissociating the chunks with the old world and injecting them into the new one.

Of course, this would bring new issues along with it, such as how on earth to handle persistent chunk loaders. However I think that, in general, this system would be far more flexible than the existing mechanism.

pls reply with any feedback you may have before i waste tons of time implementing this

@CaptainBaconator
Copy link

is cool idea. i personally think if doing other things first wouldn't lengthen the time it takes to make said adjustments, then stabilizing/fully implementing the already existing (or non-existent but essential) features should come first.
however, i'm one dude, with no experience with this stuff, so take what i say with a grain of salt.

@Rubydesic
Copy link
Collaborator

If we want to make this type of change, it's important to make it before release 1.0, because it would break compatibility with older versions of the mod.

@xunto
Copy link

xunto commented Sep 1, 2019

This is definitely how it should work IMHO. Even if we are not talking about changing ship dimension, polluting worlds with ship data is not idea I like.

@CaptainBaconator
Copy link

i think he means take the data that already exists, then move it to the destination dimension

@xunto
Copy link

xunto commented Sep 1, 2019

I meant that mod pollutes world now and he wants to design:

a system where airships are stored in their own dimension, separate from all actual worlds.

And I don't like what mod does now. I think that this change is necessary (sorry if I confused somebody).

@Rubydesic
Copy link
Collaborator

@xunto Currently ship data is stored in coordinates the game client cannot access anyway, so it is not necessarily 'polluting the world'

@xunto
Copy link

xunto commented Sep 1, 2019

Well, yeah, but data is still there even if mod is deleted. And if it reinstalled multiple times... If I understand correctly blocks will still be there.

And also it's not only about what player can access. It just looks ugly as an implementation. Idea from this PR would be much cleaner solution. This is not that important by itself but there are other reasons why it worth implementing. This is just another argument to this issue.

@kyleo1234
Copy link

this could also potentially fix compatibility with mods such as cubic chunks where the ships disappear apon loading (maybe im no coder so cant say for shore but shrug)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants