[HELP] spawn protection triggersOnActionRequest() for VoicedCommands

[Amilius]

Hi all, I am a l2 developer and ive a doubt on how prevent the /unstuck command from interrupting your spawn protection.

The problem is that the VoicedCommands are in the DP project, separated from the l2core, so I can't use this:

	@Override
protected boolean triggersOnActionRequest()
{
	return false;
}

that in the l2core prevents the spawn protection from being stopped.

Any suggestion?

Thanks in advance

[B1ggBoss]

whenever you send a voiced command, the server recive a CreatureSay packet. You can manage the triggersOnActionRequest of such packet basing on the incoming content

[Tryskell]

The fact handlers are in DP doesn't mean at all you can't use java. It's currently the versus. Handlers ARE .java so I don't get how you managed to think you couldn't use java.

 

You surely can already see java errors on your DP. If not, check it out: http://l2jserver.com/forum/viewtopic.php?f=40&t=10726

 

---

 

Anyway your problem is another. Goal of triggersOnActionRequest() is to check which packet is sent, and to react accordingly.

 

Understand you must send a certain packet in order to activate content using it. The main problem of unstuck is it's using a skill. So basically (and you surely don't know it) you are casting a skill when using a SoE, or using /unstuck.

 

So you have to allow (at least) to launch a skill. You can use L2PHX to see which packets you need to allow. But care, you have to know there aren't "special cases". All those packets will be allowed.

 

Exemple, let's say escape use following packets : target (yourself), cast a skill. If you authorize those packets, that means EVEN a mage which teleports and is in spawn protection CAN ATTACK UNDER THE PROTECTION (as he can target and launch skills as he wants without making react the system) !

 

I hope my answer is kinda full for you.

 

About which packets to "add" in the current system, it's simple. You have 2 choices :

 

- use of L2PHX to sniff which packets you send, and correct them without doing them 1 by 1 via test.

- use the "debug" option of L2J. An information is sent with packet name when you break the protection. Problem of that choice is you have to correct packets 1 by 1, so you have to recompile, relog, retest, correct, recompile, relog, retest, correct...