[SOLVED] Pseudo Worlds?
#1
Hello,

I'm trying to create a "pseudo world", for lack of a better term, in which multiple worlds are created, yet all of them read from one world file.

From what I can tell, there is no way to hook into sending a chunk to a player, so using it alongside CreateAndInitializeWorld would be worthless.

If anyone has a solution to this, that world be wonderful, as it is essential to something I am attempting to do.

Thanks,
Nathan


P.S. I do understand that a distributed MCServer will not be implemented, but I believe this is a bit different.
P.P.S. I don't need to write to the world, only read the data and send it to the players.
Reply
Thanks given by:
#2
It would be useful to have a bit more detail about what you're doing. At the moment the only hook we have that's at all relevant is HOOK_CHUNK_GENERATING, but I suspect thats not what you want. Are you trying to load multiple different chunks a the same location? Because that would involve significant modification to how we store chunks, but it might be achievable.
Reply
Thanks given by:
#3
@worktycho - I'm attempting to utilize MCServer for a mini games server. I'm creating a method of linking and sending data between servers (similar to BungeeCord, but much more flexible). However, I'd like to have a server for the main hub and one for each individual mini game.

However, I'd like to be able to generate and delete lobbies on the fly. So creating servers by hand would be very ineffectual.

I'm not sure I explained that well enough. If you that made absolutely no sense, I'll try and explain it again.

Thanks,
Nathan

P.S. What I mean by "there is no way to hook into sending a chunk to a player" is a hook named something like "HOOK_CHUNK_SENT_TO_CLIENT".
Reply
Thanks given by:
#4
I'm not sure if I understand what you want to do exactly, but I think this might help: It is possible to create multiple worlds that share the world data (the .MCA files), although it is highly advisable that only one such world writes the data, the others should only read. This is exactly what the world storage schema Forgetful does - it loads data from the disk, but doesn't save. This way you can have a world which is read-write and only admins are allowed there, and another world(s) that is read-only and reads the data from the first world. In order to set this up, you need to be able to do hardlinks in your filesystem, though, to point the second world's "region" folder to the first world's "region" folder.
Still, the set of worlds is static. There is an experimental function CreateAndInitializeWorld(), but its use is dangerous as it quite often causes a deadlock in the server. And there's no way to delete a world while the server is running - the API just doesn't support that model, it is expected that a cWorld object that you get is valid for the lifetime of the server.
Reply
Thanks given by:
#5
A safe way of creating and deleting worlds on the fly is probably the best way of doing it under MCServer's structure. I can't rember what the deadlocks we had with CreateAndInitialize were, but fixing them would be simpler than hooking chunk sending to do this.
Reply
Thanks given by:
#6
Yes, but it will be a lot of work and a rather big change in the API. Again, it would need the object lifetime rewrite; right now plugins expect all cWorld instances to be valid throughout their life.
Reply
Thanks given by:
#7
Its still simpler than reimplementing half the server core which you would have to do to get this to work by hooking into chunk sending.
Reply
Thanks given by:
#8
And if it's done now, we might have around 10 plugins that need a change, but if it's done later who knows how many plugins have to change.
Reply
Thanks given by:
#9
I'm just saying even the lifetime change is such a huge change that I don't think it's gonna happen in any foreseeable future. Basically it would mean throwing ToLua out and implementing all bindings manually.
Reply
Thanks given by:
#10
@xoft - I think that's most of what I want. Is there any existing samples of this that exists already?

Thanks,
Nathan
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)