Jump to content

[Solved][1.15.2] Button in GUI to teleport player into other dimension


Recommended Posts

Posted (edited)

Hello,
my mod has several dimensions and I'm trying to create a system to teleport a player to those dimensions via a screen.
Here's the repo of my mod, the concerned files are DataTransferInterface (block, TE, container and screen).

The idea I wanted is when I use the DTI block, the GUI opens and let me select the dimension and the coordinates and then it would send me there. For now, the "send" button is only supposed to send to a particular dimension and coordinates.
Unfortunately, I get NPEs about the "getServer" used in the method "changeDimension" in Entity. And if I try to cast the playerEntity I stored (which I think I shouldn't) in the container to a ServerPlayerEntity, it's worse.

So I truly hope someone will be able to help me,
Thanks anyways,
Best regards,
Elsopéen

Edited by Elsopeen
Posted

Hello again,

So I managed to create the message class and the PacketHandler as shown in the SimpleImpl page of the forge documentation, but I still don't get teleported to the chosen world.
The message seems to be sent, as there are no error thrown, but it doesn't seem to be handled.

Could someone help me debug this out? The repo is the same, just updated with new classes (PacketHandler in Network.Util and DataTransferInterfaceMessage in the same package).

 

Thanks anyways,

Best regards,

Elsopéen

Posted (edited)
7 hours ago, Elsopeen said:

The message seems to be sent, as there are no error thrown, but it doesn't seem to be handled.

You are registering your message class in init() in the PacketHandler class incorrectly. You should not create an instance of your message class and register the methods of that instance. Instead, change the init method to this:

 

public static void init() {
  INSTANCE.registerMessage(nextId++, DataTransferInterfaceMessage.class, DataTransferInterfaceMessage::encode,
                           DataTransferInterfaceMessage::decode, DataTransferInterfaceMessage::handle);
}

and change the encode, decode and handle methods to be static. This should fix your problem.

 

EDIT: You should definitely add checks on the server side (in the handle method) to prevent a cheating player from freely teleporting between dimensions.

Edited by vemerion
Posted

Hello,

thanks for the tip, but unfortunately, I can't make my methods static as they use non static fields (the ints territory and coordinates). And if I make them static, they would be shared by every instance of the message, which is just wrong... This packet/message should be able to be thrown by different instances of my Screen with different parameters.

And I don't understand what you mean by checking if the player is cheating... When a player get teleported to one of my custom dimensions, no block can be placed, except with the /setblock command, so no one should be able to teleport around freely (plus a teleportation system between the territories will be implemented later).

 

So again, thanks, but that cannot do the trick...

 

Best regards,
Elsopéen

Posted (edited)

That's actually a false as


    public void encode(DataTransferInterfaceMessage msg, PacketBuffer buffer) {
        buffer.writeVarIntArray(new int[]{territory, xCoord, yCoord, zCoord});
    }

    public DataTransferInterfaceMessage decode(PacketBuffer buffer) {
        int[] array = buffer.readVarIntArray();
        if(array.length!=4)
            return new DataTransferInterfaceMessage(0,0,80,0);
        return new DataTransferInterfaceMessage(array[0], array[1], array[2], array[3]);
    }

they does not reference any data outside the method, hence they can be static

 

Quote

{territory, xCoord, yCoord, zCoord}

These data should be gained from the msg

Edited by poopoodice
Posted

Thanks, I wasn't thinking correctly on how this Packet system worked, it works fine now !

Thanks a lot, sorry for being a bit too stubborn ^^'

 

Best regards,

Elsopéen

Posted
2 hours ago, Elsopeen said:

And I don't understand what you mean by checking if the player is cheating... When a player get teleported to one of my custom dimensions, no block can be placed, except with the /setblock command, so no one should be able to teleport around freely (plus a teleportation system between the territories will be implemented later).

Well, every time you create a new custom packet type that will be sent from the client to the server, you have to ask yourself: Can a cheater utilize this?

 

Think about this scenario: A player is being chased by zombies, and is close do dying. That player can then simply send a DataTransferInterfaceMessage to teleport to an arbitrary dimension and escape death. Also, it does not matter that the player can not place blocks in the custom dimensions, since a hacked client would not need the DataTransferBlock to send the messages.

Posted

I understand the concern, but that cheater would kinda deserve to be able to change dimension through my custom message... I mean, they would need to know about how the message is built, and when it's normally thrown to understand its mechanisms.
Plus, that cheater would only be able to travel from custom dim to custom dim inside my mod as my code only allow travel to my custom dims.

Moreover a cheater would rather use some kind of fly rather than teleport to another dimension filled with things that could kill him even faster.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.