Enigmatic Legacy

Enigmatic Legacy

10M Downloads

Side violation with onEntityAttacked event while wearing

noobanidus opened this issue ยท 7 comments

commented

I was, in this instance, using the Flight Scroll, the Treausure Charm, the Magic Resistance spellstone, and using an etherium sword. I was also mid-air being attacked by a shulker, which I had just killed, when this crash occurred.

Versions (Be specific, do not write "latest"):

  • Enigmatic Legacy: 1.6.2
  • Curios API: 1.0.5.3
  • Forge: 28.1.90

Logs and crash report can be found here.

I presume that something in one of your packet handlers is client-specific, but the class itself is being loaded on the server, and it's attempting to access that method. Probably just a missing @onlyin...

commented

The issue appears to be in the Eye of the Nebula effect:

			    } else if (Math.random() <= ConfigHandler.EYE_OF_NEBULA_DODGE_PROBABILITY.getValue().asMultiplier(false) && player.hurtResistantTime <= 10 && event.getSource().getTrueSource() instanceof LivingEntity) {
			    	EnigmaticLegacy.packetInstance.send(PacketDistributor.SERVER.noArg(), new PacketConfirmTeleportation(true));
			    	player.hurtResistantTime = 20;
					event.setCanceled(true);
				}

I presume the code here was copied from the client code for activating it on a keybind. Thus, it's attempting to send a client->server packet, from the server, to the client. Presumably you just need to directly trigger the code -- as you are the server, no packet is required.

commented

Your repository is also missing a large amount of code:

I presume that a simple fix would be to change the code in the EnigmaticEventHandler to as follows:

			if (SuperpositionHandler.hasCurio(player, EnigmaticLegacy.eyeOfNebula)) {
				if (EyeOfNebula.immunityList.contains(event.getSource().damageType)) {
					event.setCanceled(true);
			    } else if (Math.random() <= ConfigHandler.EYE_OF_NEBULA_DODGE_PROBABILITY.getValue().asMultiplier(false) && player.hurtResistantTime <= 10 && event.getSource().getTrueSource() instanceof LivingEntity) {
					ServerPlayerEntity playerServ = (ServerPlayerEntity) player;
		         for (int counter = 0; counter <= 32; counter++) {
		        	 if (SuperpositionHandler.validTeleportRandomly(playerServ, playerServ.world, (int) ConfigHandler.EYE_OF_NEBULA_DODGE_RANGE.getValue()))
		        		 break;
		         }
			    	player.hurtResistantTime = 20;
					event.setCanceled(true);
				}
			}

Unfortunately I'm unable to adjust the code and compile it myself, which means that my server is now out of commission until I can manually modify my curios inventory.

commented

Additionally, I'd also recommend using the runServer feature to test new code. Something like this would most likely get lost in an integrated environment as Minecraft and the client-side code is always present.

commented

Awesome, much appreciated! I'm still intending on adding my code that highlights the area of an AoE tool as well as doing shared damage textures as well, just got busy all of a sudden.

commented

Alright, let's go in order.

Thus, it's attempting to send a client->server packet, from the server, to the client. Presumably you just need to directly trigger the code -- as you are the server, no packet is required.

It's actually attempts to send packet from server to server. At the time I couldn't find other way of escaping the handler, because whenever I tried to teleport player within the handler directly or by calling any subsequent methods, it constantly spammed "[playername] moved wrongly!" into the console and prevented the position update. Who would've thought it's not a good way to do that.
I still don't know why this happens within event handler specifically, but designing better workaround won't be an issue.

Your repository is also missing a large amount of code:

image

The code on your screenshot is from much older versions of Enigmatic Legacy. Specifically from 1.2.2 and earlier, when the config was implemented in an entirely different way. You can see it when browsing the repository at that point in time, guess you know how it's done.

Additionally, I'd also recommend using the runServer feature to test new code. Something like this would most likely get lost in an integrated environment as Minecraft and the client-side code is always present.

Do you think I don't know how to run dedicated server?..

commented

It's actually attempts to send packet from server to server. At the time I couldn't find other way of escaping the handler, because whenever I tried to teleport player within the handler directly or by calling any subsequent methods, it constantly spammed "[playername] moved wrongly!" into the console and prevented the position update. Who would've thought it's not a good way to do that.
I still don't know why this happens within event handler specifically, but designing better workaround won't be an issue.

I don't think the SimpleChannel is really clever enough to handle a situation like that, especially given the fact that, when registering packets, you no longer define which side the packet is received on, instead it's defined in the actual side it's being sent to:

public static final PacketDistributor<Void> SERVER = new PacketDistributor<>(PacketDistributor::clientToServer, NetworkDirection.PLAY_TO_SERVER);

    private Consumer<IPacket<?>> clientToServer(final Supplier<Void> voidSupplier) {
        return p -> Minecraft.getInstance().getConnection().sendPacket(p);
    }

I'm not sure why it's happening like that. You could potentially defer the movement until after the event handler has finished running by putting a runnable in the main instance (I forget exactly how to do this in 1.14.4), if that is the cause.

The code on your screenshot is from much older versions of Enigmatic Legacy. Specifically from 1.2.2 and earlier, when the config was implemented in an entirely different way. You can see it when browsing the repository at that point in time, guess you know how it's done.

https://github.com/Extegral/Enigmatic-Legacy/blob/master/src/main/java/com/integral/enigmaticlegacy/config/ConfigHelper.java <-- well, the code is still in the repository and it won't compile without it, so I presume there is some disparity between your current code and what is available in the repository.

Do you think I don't know how to run dedicated server?..

My apologies, I didn't mean to sound snarky. I know many developers who don't realise how easy it is to actually test things on a dedicated server inside of a development environment -- and thus a lot of side violation bugs tend to sneak through into releases because of it.

commented

well, the code is still in the repository and it won't compile without it, so I presume there is some disparity between your current code and what is available in the repository.

My apologies. I was pretty sure I've deleted that class on repository. It actually doesn't exist in the mod as of 1.3.0.

There was another outdated class, CapabilitiesRegistrationHandler.java. I've removed them both, repository is now contains code completely identical to that in my development environment.