Jump to content

[1.10.2] Detect creative mode during AnvilUpdateEvent


jeffryfisher

Recommended Posts

The AnvilUpdateEvent does not have a getPlayer() method. Is there any way to detect that the anvil user is in C-mode?

 

Without a way to detect creative mode, I don't think it's possible to inject new behavior for a mod and still respect creative mode privilege (or invoke any other player-dependent behavior). Here's the critical statement from the AnvilUpdateEvent class: "If the event is not canceled, but the output is not null, it will set the output and not run vanilla behavior" (emphasis added).

 

That means that if my event handler sets anvil output, then the handler is on the hook (so to speak) to emulate all bypassed behavior. I'm stumped because the bypassed behavior includes some creative-mode privilege to which the event seems to be blind (or am I blind?).

 

If this is a gap in Forge design, should I post something elsewhere?

 

PS: onAnvilRepair, which does specify a player, is not an adequate replacement event. By the time it is called (picking up from an anvil output slot), it is far too late to control what enchantments should be allowed from books or how many levels the repair will cost.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

The AnvilUpdateEvent does not have a getPlayer() method. Is there any way to detect that the anvil user is in C-mode?

 

Without a way to detect creative mode, I don't think it's possible to inject new behavior for a mod and still respect creative mode privilege (or invoke any other player-dependent behavior). Here's the critical statement from the AnvilUpdateEvent class: "If the event is not canceled, but the output is not null, it will set the output and not run vanilla behavior" (emphasis added).

 

That means that if my event handler sets anvil output, then the handler is on the hook (so to speak) to emulate all bypassed behavior. I'm stumped because the bypassed behavior includes some creative-mode privilege to which the event seems to be blind (or am I blind?).

 

If this is a gap in Forge design, should I post something elsewhere?

 

PS: onAnvilRepair, which does specify a player, is not an adequate replacement event. By the time it is called (picking up from an anvil output slot), it is far too late to control what enchantments should be allowed from books or how many levels the repair will cost.

I believe by vanilla behavior it means looking for the repair recipe. There fore you do not need to have a player variable.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

In the meantime can you replace the vanilla anvil with a custom one, or can you intercept other events for player interaction with blocks to help you make an educated guess on who's working on the anvil?

I feel as if my answer was kinda pushed to the side.... Maybe I should ask my question Why do you need the player? Are you trying to grab player information(capability data) or just to check creative mode? Or are you just going to check if Player is not creative then change the data. Because as I said vanilla behavior most likely means grab recipe for anvil.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

I should clarify:

 

When my event handler decides to change the anvil output, the change will cause a large part of vanilla anvil behavior to be skipped. My handler, not wanting to change all that behavior, then needs to do everything that the vanilla method would have done.

 

Unfortunately, there are a couple of branches in that vanilla code that respect the player being in creative mode. Imitating those special cases is the only reason my handler needs any player data. A creative-mode boolean would suffice for my current mod, but I can imagine other mods where various player conditions could affect anvil behavior for that player.

 

As it stands, when my mod's custom enchantment is applied via anvil, a creative mode player will be subject to survival-mode cost and limits, and the repair might become impossible (which interferes with my testing).

 

I've never written a pull request. How much detail do I need to provide, and where do I submit it? BTW, this issue also came up during 1.8 about a year ago. I don't know if a request was made then.

 

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

I should clarify:

 

When my event handler decides to change the anvil output, the change will cause a large part of vanilla anvil behavior to be skipped. My handler, not wanting to change all that behavior, then needs to do everything that the vanilla method would have done.

 

Unfortunately, there are a couple of branches in that vanilla code that respect the player being in creative mode. Imitating those special cases is the only reason my handler needs any player data. A creative-mode boolean would suffice for my current mod, but I can imagine other mods where various player conditions could affect anvil behavior for that player.

 

As it stands, when my mod's custom enchantment is applied via anvil, a creative mode player will be subject to survival-mode cost and limits, and the repair might become impossible (which interferes with my testing).

 

I've never written a pull request. How much detail do I need to provide, and where do I submit it? BTW, this issue also came up during 1.8 about a year ago. I don't know if a request was made then.

 

What is the behavior as im pretty sure that ContainerRepair/SlotRepair (i think that is a thing) handles the subtracting, though i do agree that the player should be passed. About the pull request i think you just need to specify what you are changing and provide the code.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

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.