Traps

[Aceking]

So I have been playing around with traps lately using the ground item packet (1101) on patch 5065.

Not really getting the results I was expecting.

So I am able to display a trap, using either subtype 10 or 11. Its there on the ground, I can see it etc.

Now, I was under the impression that the client would then send a packet to the server when a trap is stood on or 'activated'. However, I have not had this happen yet.
Am I correct in this assumption? Am I just doing something wrong so the client doesn't really know its a trap?
Or am I going to have to check for traps manually on each location change.

Lastly, I am unable to remove the trap. It will disappear if you go off screen, but I cannot make it disappear while on screen.
I have tried sending subtype 12, with the trap info to remove it.
I have also tried sending subtype 2 (DeleteItem).
I even tried sending the GeneralData packet with the remove entity subtype.
All of the above had no luck.

I was using the UID between 900,000 and 999999. All with no luck

Does anyone have any idea how traps work?
I know there is a way to remove them, since TQ does it with squamas, I just haven't figured out how...

And I also can't really imagine having to check for a trap every location change. I know you will have to validate that there is a trap, but checking for a trap every jump seems quite inefficient, even for TQ.

[Naestra18]

not really sure, what kind of traps ur looking for...
but for spawn traps, just place hidden portals..*(just thinking out of the box)

probabaly uselless but hey goodluck xD

[Aceking]

Yeah, not really helpful there sorry.

Traps as in squamas, mine portals, and any other ground effect that activates when stepped on.

And some indication of how they work.

[.Ocularis]

The client doesn't send a "pick up" to the server because a method like that could be exploited. Place your trap in your map objects collection, proximity check each character server-side, if a character comes close you can remove the trap and activate the effect associated.

[Aceking]

And I was half expecting that to be the case, just needed confirmation.

But still need to be able to remove the trap, and from everything I have read and seen. Subtype 10 sets the trap, and subtype 12 removes it.

Subtype 10 works fine, but so far I have had no luck with subtype 12.

[Aceking]

So out of curiosity I loaded up a 5518 server.

Send packet 1101 with subtype 10 to create the trap.
Worked fine and the trap displayed.

Sent packet 1101 again with subtype 12, and voila, trap disappeared!

I go back to my 5065 version, do everything exactly the same.
Nope, trap stays where it is.
Is there a different way of removing these in lower patches?
Does anyone have some kind of clue.

[Y u k i]

He made me do it on 5018.

Same result. It spawns, but can't be removed anymore.

[Aceking]

Does anyone have some kind of an idea?

Trying alot of things without any success....

[Super Aids]

You validate things server side, not client side. You should validate trap coordinates on the server. Store the traps in some sort of collection and check whether the coords match the players.

Ex. use a point struct.

struct Point
{
    public int X;
    public int Y;

    public Point(int x, int y)
    {
        X = x;
        Y = y;
    }
}

ConcurrentDictionary<Point, Trap> Traps; // var trap = Traps[new Point(100, 150)];

[Aceking]

Originally Posted by Super Aids

You validate things server side, not client side. You should validate trap coordinates on the server. Store the traps in some sort of collection and check whether the coords match the players.

Ex. use a point struct.

struct Point
{
    public int X;
    public int Y;

    public Point(int x, int y)
    {
        X = x;
        Y = y;
    }
}

ConcurrentDictionary<Point, Trap> Traps; // var trap = Traps[new Point(100, 150)];

I fully intend to validate server side.
But right now that is pretty useless if they cannot be removed

[Spirited]

According to TQ's source code, you also have to specify the location and type of the trap. This is the method they use for creating the removal packet (using subtype 12):

//////////////////////////////////////////////////////////////////////
BOOL CMsgMapItem::Create(int nAction, CMapItem* pMapItem)
{
	CHECKF(pMapItem && nAction);

	// init
	this->Init();

	// fill info now
	m_pInfo->nAction	= nAction;
	m_pInfo->id			= pMapItem->GetID();
	m_pInfo->idType		= pMapItem->GetType();
	m_pInfo->nPosX		= pMapItem->GetPosX();
	m_pInfo->nPosY		= pMapItem->GetPosY();
	ItemInfoStruct* pInfo	= pMapItem->GetInfo();
	if (strlen(pInfo->szName)>0)
		m_StrPacker.AddString(pInfo->szName);

	// hide id
	m_pInfo->idType		= CItem::HideTypeQuality(m_pInfo->idType);

	m_unMsgType	=_MSG_MAPITEM;
	m_unMsgSize	=sizeof(MSG_Info)-1+m_StrPacker.GetSize();

	return true;
}

[Y u k i]

Nope, still not disappearing :3

[Spirited]

The identity range for a normal trap (called a magic trap for TQ) should be 900001 - 989999. The identity range for a synchro trap (I haven't tested with this) should be 990001 - 999999. be sure that you're using that identity range. I haven't tested traps this low of a patch, so it's possible that you might have to reverse engineer the client a bit to see what inputs it's expecting.

[Aceking]

Any idea what the type of traps would be?
Those offsets look different too.

Wonder if later patches they made it easier to remove them.
Will have to test it later when I get access to my source again

[Spirited]

Ignore the offsets. That's not what I was trying to show, and they're not assigning things in the order of the offsets in the packet structure.