Jump to content

Recommended Posts

Posted

I just came across an oddity in events that I could use some advice on how to solve.

 

Basically I have a custom End Portal for my multi-dimension mod.  Got everything working right except for one thing.  When the portal frame is clicked, it deposits the ender eye and it launches it in sky to track.

 

In the serverside event (yes, I'm sure this is happening only serverside), the rightclick event fires twice.  The first time through the event reports the block that was rightclicked was my portal frame.  I successfully cancel the event.  But then, the event runs a second time and it reports back a different block.  Usually this is bedrock, but occasionally something else.  I'm up at a y of 100 or so. 

 

I played around with it a bit and looked at the original frame/eye code, but not really seeing any gracefull way to solve this. 

 

I could come up with some tracking system to know that the two are related and cancel on the same tick, but that is just going to be ugly.

 

Any advice?

Long time Bukkit & Forge Programmer

Happy to try and help

Posted

Only thing I can think of is that the action packet got sent twice - this happens sometimes, since when the player right clicks, if it is held down a little bit it continuously tries to right-click action on the block. No idea why it would give you bedrock, though.

 

Try printing out the BlockPos in addition to the Block name, or activate your portal while in debug mode to get a better idea of what exactly is going on.

 

Do you really need to use the event, though? Why not use Block#onBlockActivated instead? It's your block, after all, right?

Posted

I don't think its from click being held down to long.  It happens each and everytime without fail.

 

I'll add the blockpos tonight to check.

 

On the block activated idea, I didn't explain well enough.  I'm fine on the block.  Everything works there.  I'm trying to stop the ender eye from flying out in the blue yonder when I use it on the block.  I'm consuming it on the block, not wanting it to be used to find another block.  Unfortunately since the cancel isn't working for the 2nd event, both happen.

 

 

Long time Bukkit & Forge Programmer

Happy to try and help

Posted

Simply returning true from

Block#onBlockActivated

should prevent the Eye of Ender from spawning.

 

I just wrote this simple example and it works without issue.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted

Ah,

I didn't realize that before.  I didn't realize the status of blockactivated impacted the items own rightclicked code.  I should have traced that out.

 

I'll give that a shot tonight.  Thanks guys.

 

 

 

If it was a vanilla block and I wanted to cancel the ender eye, can you think of any way to do it on the 2nd round of the event other than what I posted above?

Long time Bukkit & Forge Programmer

Happy to try and help

Posted

The thing is, if you cancel the RIGHT_CLICK_BLOCK event, it sets 'useBlock' to false, so the #onBlockActivated method gets skipped and returns false, allowing the Item's (Eye of Ender) #onItemRightClick function to be called, spawning in the entity.

 

Since you are concerned about vanilla blocks, one solution would be to focus instead on the client-side and subscribe to MouseEvent and KeyInputEvent, check for keyUseItem, and do some preprocessing before allowing the click to proceed.

 

As mentioned earlier, the event is literally fired constantly while right-click is pressed, so you WILL be getting the event firing potentially dozens of times, though usually only once or twice. Stopping the client-side key input that triggers this would allow you to limit this to once per click (i.e. by unsetting the key after it is pressed, so continuing to hold it down does not send any further input).

 

We could probably better assist you if you provided some actual details on what exactly you are trying to accomplish, as in your first post it sounded like you were interested in handling interactions with your block.

 

What exact interaction are you trying to prevent? Just spawning eyes of ender? Use EntityJoinWorldEvent and cancel for any EntityEnderEye that you encounter. If it's something else, please elaborate.

Posted

So what I have done is dynamically from a config file created any number of world sets specified.    Basically you can have as many overworld, nether, end combinations with a long list of specifications you want.  It also spawns some other set worlds with them that I wanted too, but that is another story.

 

The question was around enderframes and portals.  I needed to intercept when a player found one in a non original overworld and change up what was happening.

 

I got it to work.

 

Basically I changed my customenderframe to be like what was suggested.  then for the event, I let it happen but record in a list to revisit the area a tick later and change anything over to my blocks and determine to take action on portal based upon findings.  Works like a charm.

 

I realize there are other ways to do this, but its how I had everything setup.  It all worked before except for the ender eye flying off as a bonus.  Now it is seamless.

 

 

Long time Bukkit & Forge Programmer

Happy to try and help

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.