RFTools

RFTools

74M Downloads

Compatibility/fakeplayer issue - Broken elevators -SpongeForge&GriefPrevention

rob5251 opened this issue ยท 12 comments

commented

Since the latest update (7.27) a compatibility issue has occurred where when the RFTools elevator is being used the server will get hung up and time out all players. Once this occurs then the server is stuck in a frozen state.

This issue occurs as soon as the elevator platform is set in motion.
Issue does not occur on previous version (7.26)

When this occurs the last message the server console spits out is this:
[22:31:49] [Server thread/WARN] [Sponge]: No entity type is registered for class net.minecraftforge.common.util.FakePlayer

I'm wondering if an error was made in recent changes to: https://github.com/McJty/RFTools/blob/19f938d39f9b1e5abf3200f47e7961f63d112092/src/main/java/mcjty/rftools/blocks/builder/BuilderTileEntity.java

I'm no coder so I wouldn't know, but that's my only guess as the issue only started to occur on the latest version.

I also ran some debug checks with GriefPrevention for SpongeForge but found no apparent issues on their side.

commented

If it doesn't happen without Sponge installed, then it's a Sponge issue and you should report it to them.

commented

Will do, just trying to track down the root of the issue. I'll probably just revert to the previous build for now.
It doesn't happen with Sponge itself, its when the sponge plugin "GriefPrevention" is also on the server. I've reported to them as well.

commented

I tried working through the problem with Blood over on the GriefPrevention issue tracker and he seems to have traced it back to an issue within RFTools:

https://github.com/MinecraftPortCentral/GriefPrevention/issues/587#issuecomment-362841939

commented

Ah, given that information, I was able to reproduce this without Sponge, by using a block protector to protect the platform block immediately in front of the elevator. I'll upload a fix shortly.

commented

But the elevator shouldn't consider different blocks to be part of its platform when you call it with redstone versus when you call it with a screen.

commented

@josephcsible Please pass the player interacting with ScreenTileEntity instead of a fakeplayer so GriefPrevention can protect properly.

commented

The player triggering the move should always be passed in Forge's 'BlockEvent.BreakEvent'. Only use fakeplayer when you have no player. In this case you should always have a player.

commented

It's the elevator that's doing the breaking though, not the player. When a player starts up an RFTools Builder, it's the builder that counts as breaking all of the blocks. Are there any other modded blocks that work this way?

commented

It doesn't matter what block is doing the actual breaking. What matters is what "caused" the block to break. In this case the player that interacted with the ScreenTileEntity caused the elevator to move. And yes plenty of other mods work this way. The ones that do not are doing it wrong.

commented

@bloodmc I disagree, but I'll ask @McJty to have the final say since it is his mod.

@rob5251 This will be fixed in the next release.

commented

Thanks. ๐Ÿ‘

commented

@bloodmc When elevator/builder are activated using a screen I can in principle know the player. However all machines in RFTools can also be operated using redstone logic and machines that procude redstone. In such situations I don't have a player and a fake player is required.

Actually even with a screen it is not really possible. A screen communicates with other blocks through wireless redstone logic. So eventually the redstone signal is produced by a wireless redstone receiver. That receiver has no way of knowing where the redstone signal comes from and providing that information through the wireless redstone network would be very complicated and hard to resolve given that a wireless redstone signal can be true due to several reasons. i.e. it is perfectly possible to make a setup where two players have to simultaniously press a button for an elevator to work and logic gates do an 'or' on the two redstone signals. Which player is responsible then?

In addition the redstone signal can be propogated from a wireless redstone receiver to the eventual machine using blocks from other mods or even vanilla redstone. When that happens it is even completely impossible to send along the player information to the destination machine