Self damage (speeding, ?)

[P42C41]

All those kids have a speed by giving themself damage each few seconds.

Here is one self damage method:

public void damagePlayer() {
		if (mc.thePlayer != null) {
			for (int i = 0; i < 92.5; ++i) {
				mc.thePlayer.connection.sendPacket(new CPacketPlayer.Position(mc.thePlayer.posX,
						mc.thePlayer.posY + 0.049, mc.thePlayer.posZ, false));
				mc.thePlayer.connection.sendPacket(
						new CPacketPlayer.Position(mc.thePlayer.posX, mc.thePlayer.posY, mc.thePlayer.posZ, false));
			}
			mc.thePlayer.connection.sendPacket(
					new CPacketPlayer.Position(mc.thePlayer.posX, mc.thePlayer.posY, mc.thePlayer.posZ, false));
		}
	}

fix it please, thanks.

[ghost]

thanks for breaking my speed, Pascal.

[Janmm14]

Everyone cares dude.

[asofold]

Self damage does hurt a bit. What is it used for these days? Just speeding?

[ghost]

flying, speeding

[asofold]

I'd love to see debug logs, specifically for flying (latest NCP on Jenkins rather)...

[P42C41]

No longer flying, just speeding

[P42C41]

@Jonesdj1 Are you retarded? You need to give yourself damage(less than half a heart) and then you can speed for a long time, then damage again. No need of "spam damage" retard lol. And when you have armor you don't even notice the damage.

[asofold]

Don't type too fast people :). EDIT: this is the open ticket.

Arrows may deal more damage and are less accurate, because theyre done server side. A pre-planned course could account for arrows, but it's way more complicated to do than with other methods that work on-ground. Shooting arrows might also get cancelled if there is some networking congestion. I'd assume abusing NCP/Vanilla fall height accumulation or similar would be more efficient.

Actually the method depicted above looks like abusing vanilla fall damage, which we probably can prevent in not so difficult to do ways.

NCP will always use the maximum of the three:

• Vanilla fall height.
• NCP fall height accounting (move by move).
• Difference from maximum recorded y to here.

The NCP part deterministically will reset on-ground or with vanilla triggering fall damage events. Obviously vanilla fall damage is possible to accumulate with onground=false. This should be the direction to investigate - do (practicable) methods use vanilla fall damage only?

[P42C41]

@Jonesdj1 The autism is too strong

[asofold]

Please don't keep insulting each other (potentially, please neither use the term autism inappropriately), keep it on topic. Instead please read my post above :).

[Janmm14]

@asofold having onground=false should cause ncp to check whether the player is onground actually and change the onground flag in the packet if its wrong (still consider that onground is sent after y calculation by the client with old x and z values)

[asofold]

@Janmm14 Nope. The ongroujnd=false is received with packets, asynchronously to the primary thread. Accessing the map there may yield a different state to when the packets are processed, furthermore i wouldn't count on it being/staying thread-safe in the first place. The Bukkit methods are not thread-safe so forget about those in the first place.

We do store contents of moving packets, in theory we could try to synchronize between packets and moving events, so we get the additional information. Unfortunately the CRaftBukkit implementation doesn't put through all events (and we rely on CB doing it that way by now). So achieving precision there is problematic.

Now with less precision, we could still check past packets, e.g. on damage events or on dealing damage, so we could in theory estimate if it's been real cheating. In any case the first step should be to rather completely ignore the Bukkit/Vanilla fall height accounting rather. That would perform better and mitigate the issue (supposedly). Again this is rather protection than detection.

[Janmm14]

@Jonesdj1 I did not spend more than 15 euros on any plugin on spigotmc.
Additionally this is nothing that should be discussed here, I just suggested an easy way of fixing this bevahiour, which is additionally in my opinion the most easy way and first way you think of fixing this behaviour in my opinion.

[asofold]

It's just not possible in a direct way. The vanilla client even sometimes delivers inconsistent data, or at least data that results from whatnot many workarounds of which the packet tells us nothing.

So the simplest way of mitigating should be to ignore MC fall height, which is what i'll implement first. I'll make it configurable, activated by default. Not sure if i need to aggressively set fall damage to 0 for some cases, though :). Perhaps this even gives us a heuristic for this cheat, even without touching the packet level.

[P42C41]

Yea ignore mc nofall and calculate it by your own, best way.

[asofold]

How does this look with build 1049?

[P42C41]

Alright, it's fixed. Thanks a lot

[asofold]

Closing as fixed then. Hope nothing was overlooked.

[ghost]

Unable to reproduce on the latest build, good job! 👏

[ghost]

damage is vry big hake you can fly with it pls help

[ghost]

wait y u patch it? what if I needed to kill myself plshelp