An idea for seamless world wrapping

Discussion in 'Plugin Development' started by yajtheman, Oct 17, 2013.

Thread Status:
Not open for further replies.
  1. Offline

    yajtheman

    (Note: this is not a plugin request. I'm just wondering if my logic is correct.)

    It seems to me that you could implement seamless world wrap around (i.e. you come to the edge of the world and the other side is right there. Not just emptiness and a teleport barrier.) by intercepting chunk packets and changing the location information for them (using ProtocolLib for example). When a player reaches the edge of the map, you teleport them to the other side. But you also intercept the player packets and add the location offset to them. This way, the client believes itself to be past the end of the world, but as far as bukkit is concerned the player is still in the map bounds and still gets sent the correct chunks (modified by the plugin with the location offset).

    Assuming you modify the edges of the world line up correctly, would this work?
     
  2. Offline

    _Filip

    How would client side coordinates work?
     
  3. Offline

    yajtheman

    As far as the client is aware, the player would just keep moving. Say the world ends at X:100. When the player crosses that the client would just keep going X:101, 102, etc. Bukkit would see the player as back at the other side of the map, X:-100 for example, and the plugin would intercept the packets and change the location.

    Potential problem: Bukkit doesn't know to send the chunks from the other side of the map as the player approaches the edge. Can it be forced to send the chunks?
     
  4. Offline

    ase34

  5. Offline

    Garris0n

  6. Offline

    yajtheman

    Yeah, that's what I was thinking too. I assume one would want to test for a player nearing the border, then find the chunks that would be in there view radius (set by view-distance in server.properties?). Package them into a few chunk packets and send them to the client. Does anyone know if the client having chunk information not sent by the server itself would cause problems?

    Garris0n I'm not sure if that is relevant, I was just thinking of it as a tiled map...
     
  7. Sounds like a creative idea with thought behind it, I like those ;)
    Possible things that might be a challenge:

    * The respawn packet is normally used for a world change. This contains world information like it's dimension, difficulty and stuff. A change of dimension would probably be only relevant one that couldn't be accomplished without the packet, but you might live with that.
    The packet is followed by all kinds of chunk data packets for the new world. Those have to be cancelled as well, as the client should already be aware of them at the point of crossing the line.
    However, the server-side logic of moving the player to a different world still has to remain functional.

    * Since the client's coordinates will be shifted, the vast majority of packets will have to be intercepted in both directions to modify the coordinates. Apart from the implementation effort, it could affect performance.

    * Sending a chunk of a different world on the border would most likely be terribly inefficient at packet-level, since the data for the chunk that would be at the location needs to be generated first and then replaced by the custom one. So you probably have to dig deeper than that, just a thought, though ;)


    It sounds like a cool idea, even though I can't think of any huge benefit over just having the stuff in one world in the first place :D Performance probably wouldn't increase if it's really supposed to feel flawless because of all the quirks and interceptions necessary to make the client play with you.
     
  8. Offline

    yajtheman

    I'm not sure that is important, I'm just interested in wrapping the same world around. Not putting another one next to it.
    Again, I'm not interested in a different world, just the same one wrapping around to the other side. However, I see your point with the chunks generation... Would I need a custom world generator (one that just generates air blocks) to prevent the generation of outer chunks as the player approaches? Once the outer chunks are originally generated this might not be a problem though, just a performance enhancement if bukkit compiling a chunk column full of air is more efficient the a regular one.
     
  9. Offline

    Garris0n

    Also, there could be issues with floating point errors when you get too far out (farlands bugs).
     
  10. yajtheman
    OOooooh, now I got your idea :D I totally misread the part about a world wrapping around, I thought it should be a seamless transition between a single world.
    (Actually, I read the title as "seamless word wrapping" at first and only realized halfway through your first post that you weren't talking about chat messages after all :p)

    Okay, now that makes everything a lot simpler and more useful :D

    I was more thinking about the packet data that is rewritten whenever the "border" chunks have to be sent to a player.
    Creating the packet for the chunk transfer looks pretty costly, creating a snapshot of the entire data while constructing. When capturing those packets as they are sent and rewriting their data, it effectively has to be generated twice.
    I dunno, it might be premature optimization and neglectible, I haven't tested anything.
    If the overriden chunks are empty, the packet generation cost could also greatly decrease, just a thought.

    The packet-flood bottleneck probably comes down to the efficency of ProtocolLib while intercepting tons of packets. I trust its creator to have done a very decent job at that, so that could work, too.

    Actually sounds like a possible idea worth creating a proof of concept for.
     
  11. Offline

    ase34

    Another approach:

    When the player is near the border, tp him to another world but suppress the teleport-packet so the coordinates keep unchanged at the client. Then you just have to adjust the chunk coordinates in the chunk-packet, the blocks are calculated by bukkit.
     
Thread Status:
Not open for further replies.

Share This Page