Jump to content

[1.11.2] Can I use SimpleImpl to send a message from a client to the server to another client?


TheMattyBoy

Recommended Posts

I'm trying to create a GUI that can play sounds of type MovingSound (as opposed to a normal PositionedSoundRecords, which is what World#playSound uses) when pressed, not only to the player using the GUI, but to everyone within range. Of course, GUI's are exclusively client sided, so I decided to use SimpleImpl to send a message about the sound to the server, but since I'm using a MovingSound I then have to play it through the SoundHandler in Minecraft (which is a client class) on all receiving clients. I'm kinda new to SimpleImpl and networking in general, but from my limited experience it would appear that you have to register your client packets only on the client side and server packets on the server side (if I didn't do this either the server would crash or my client would be kicked from the server, respectively). This, however, poses a problem as I'm trying to send a package that is only registered on the client from a package that is only registered on the server, meaning that I'm effectively trying to send a package that isn't registered (at least, that's how I think it works). I believe there's something wrong with how I register my packets, but as I say I'm new to networking so I don't really know. Help would be greatly appreciated!

 

GitHub can be found here:

https://github.com/TheMattyBoy00/petri-mod-2.0/tree/master/Petri_Mod-1.11.2/src/main/java/erikalebenjamattias/petrimod

My GUI is here (it's long and messy, package is sent at line 324) (if you're wondering why I play the sound on the client and then send it to the server to play to all other clients nearby, it's to reduce latency for the person playing the piano [which is what the GUI is for if you hadn't guessed]):

https://github.com/TheMattyBoy00/petri-mod-2.0/blob/master/Petri_Mod-1.11.2/src/main/java/erikalebenjamattias/petrimod/client/gui/GuiPianoKeyboard.java#L324

Package to send to server (a quick println shows that this does in fact find all the players it should that are in range):

https://github.com/TheMattyBoy00/petri-mod-2.0/blob/master/Petri_Mod-1.11.2/src/main/java/erikalebenjamattias/petrimod/network/NotifyServerOfPianoPlayMessages.java

Package to send to clients (println in the onMessage() method shows that it does not get called what so ever, and the constructor with the println only gets called on the server where it's called in the server package, despite it being a client event):

https://github.com/TheMattyBoy00/petri-mod-2.0/blob/master/Petri_Mod-1.11.2/src/main/java/erikalebenjamattias/petrimod/network/NotifyClientOfPianoPlayMessages.java

Packet handler:

https://github.com/TheMattyBoy00/petri-mod-2.0/blob/master/Petri_Mod-1.11.2/src/main/java/erikalebenjamattias/petrimod/network/PetriPacketHandler.java

Packets registered in the client proxy and server proxy respectively. This is where I think I might be doing something wrong.

Edited by TheMattyBoy

IGN: matte006

Played Minecraft since summer 2011.

Modding is my life now.

Please check out my mod :)

https://minecraft.curseforge.com/projects/gadgets-n-goodies-mod?gameCategorySlug=mc-mods&projectID=230028

Link to comment
Share on other sites

16 minutes ago, diesieben07 said:

Stop calling packets packages. They are different things.

Oh oops, didn't even notice that... Embarrassing...

 

17 minutes ago, diesieben07 said:

This is not needed. The server knows who sent the packet.

Right, thanks.

 

17 minutes ago, diesieben07 said:

You cannot blindly trust the entity ID (pianoId in your packet) that the client sends. At least do a check that the client is within range.

Didn't I already sort of do this by doing world.getEntityByID(message.pianoId).getDistanceSqToEntity(p_apply_1_) < 900.0D in the predicate for finding the players?

 

20 minutes ago, diesieben07 said:

Packets must always be registered on both sides.

Alright, this is what I was having trouble with. If I tried to register a client packet on both sides the server would crash with a NoClassDefFoundError on whatever client-only class I was trying to access in my onMessage method in my message handler, and no amount of side checking or @SideOnly-ing would fix the error. How do I register a packet on both sides, while being able to access client only classes and methods, without the server immediately crashing with a NoClassDefFoundError or NoSuchMethodError?

IGN: matte006

Played Minecraft since summer 2011.

Modding is my life now.

Please check out my mod :)

https://minecraft.curseforge.com/projects/gadgets-n-goodies-mod?gameCategorySlug=mc-mods&projectID=230028

Link to comment
Share on other sites

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



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

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