playertouchsme called, but player not touching
 

This is creating problems for Classic's new damage system.

Ex. put an NPC 1/8th a tile into a wall, and when you walk toward it, the playertouchsme event is still called.

It's hard to script a server if you can't trust the scripting language. It's hard to script a good server when you can't move objects dynamically at all serverside (yea, I've suggested adding a new movement function with trig and acceleration options) It's hard to script a good server when you can't always detect when a moving object comes into contact with the player. This is driving me nuts. I just want to make something that players can enjoy.

The engine cannot do everything for you. You are sure the player is not touching the npc? Does it happen in each walking direction?
On zone there is pixel-exact movement and if you stop 1 pixel before the npc then its not invoking the playertouchsme-event.

Well, at times it behaves more strangely than others. Player's logon and say the hit detection suddenly became better or suddenly became worse.
I'll upload a test level specifically for it.

In this test level, it's seeming that a distance of 0.5 from the player is sufficient. Also 0.75 is sufficient. Also 0.85 is sufficient. Also, 15/16 is sufficient.
Classic: test_playertouchsme.nw

It seems as though if the player comes within less than one tile away from the NPC... which would mean that hit detection is affecting all players that come within one extra tile of it. It might have something to do with how the movement system works, though.

But that wouldn't make so much sense anyway, because it still happens with gravity boots on. Yea, and I just made a test, so I know it doesn't have to do with how the movement works (unless NPC-induced false movement has nothing in common with NPCW-induced false movement).
false movement (I made this up): changing your coords to one thing and back in a single iteration.

I'm guessing on playertouchsme tests the area (x,y,width,height): (player.x+0.5 + vecx(player.dir), player.y+1 + vecy(player.dir),2,2)

This includes testing for level links. It's not so nice for the Opposite Boots NPCW either because in that case movement isn't based on player.dir (however this touching area is being treated as such. Same is true for any directional changing NPC. Direction changing is making playertouchsme be called again too (probably a very good thing unless the player is twirling around on top of an NPC with that event).

It would also be quite nice if the area was tested for when NPCs move at the player too. That would make a lot of problems disappear.

And I just went on Zone and it does the same thing there... Maybe there just needs to be a new event handler?

What is the Zone movement doing? Some time ago it was bugged and was not moving enough (stopped 1 pixel in front of the wall), which made the doors stopping from opening

Hmm, well, if you came on Classic you could have looked at this (the attachment).

There's no problems with Zone, it's just that Classic's damage system requires the playertouchsme event so that it can run out on a timer. Moving NPCs aren't so nuts to make damage fields for, but they'd be a lot more efficient if they could move along with the NPC (make the NPC itself a damage field and still have playertouchsme called when the player isn't moving).

Classic's damage system is assuming that playertouchsme is when the player's 2x2 shape overlaps the WxH (or at least borders). That's the only serious issue I'm having with it.

Right now it's testing if it's overlapping the front 1x2 of the player's 2x2 shape and the 1x2 area in front of it.

Because it's doing the front 1x2 area, this is also creating problems with another un(re)released NPCW. The Opposite Boots (where you move backwards). In that case you'd be wanting the 1x2 area behind the player to mimic how it's currently working. However, doing that wouldn't solve the damage question.

Oh, yea, Classic uses pixel exact movement too.

Ok I have checked how the playertouchsme event is working:
- on serverside it is basicly doing a findareanpcs(player.x+0.5+vecx(player.dir), player.y+1+vecy(player.dir),2,2) each time a player is moving, and is invoking a playertouchsme event on those npcs; it is also verifying that abs(npc.z-player.z)<=3

- on clientside it is checking two points in front of the player, and is invoking the playertouchsme event on npcs that are on those points; it is marking the npc as touched so that it doesn't happen again until the player moves away again.

Although these checks are not very accurate the question is if it's really a problem, I think it's more important that the event is actually happening and not that the player is touching it pixel-wise; by getting the playertouchsme event before the player is actually touching it fully you can avoid some lag

Well Stefan, what's bothering me the most is that direction is even a factor. The player can be moving sideways or backwards and there would still be cases where you would want playertouchsme to be called. It is apparent that the purpose of playertouchsme is for simple scripts such as opening doors, reading signs, or anything that would require you to use your hands (which would explain why you would want the event to occur early).

abs(npc.z-player.z)<=3: which I just happened to know from trying to learn how projectiles work (I wish it were relevant)

If there would be a playertouchsme event for this only purpose, then I would suggest for an alternate but similar event to occur onto the area:
findareanpcs(player.x+0.5-1/16, player.y+1-1/16, 2+1/8, 2+1/8);

The problem is that the functionality that I'm looking for to build a lot of systems is close to playertouchsme, but playertouchsme isn't defined correctly for me to use it in the way that I would want to use it.

Such an alternate event would probably be the same definition you might want to use for level links, while viewing signs/entering doors would probably require a player to be facing forward. It would be most useful for detecting if the player is entering an area of x,y,w,h that is defined by an npc's x,y,w,h.

Or another idea would be to somehow allow redefinition of playertouchsme for servers (however, don't know how you'd go around implementing that)

Or another idea would be to take the direction change from the last set of coords and use that, but that would probably lead to a few problems.

Okay, I have an expansion of this idea now that my mind's eye wandered across when in another thread.

new event handlers:
onPlayerEntersMyShape
onPlayerLeavesMyShape

These would offer extraordinary functionality.
First things first. It would solve the hit detection problem on Classic simply with onPlayerEntersMyShape().

However, that is not where it ends.
Say you have a sparring arena inside of a level. You want weapons to be disabled outside of the sparring area but not inside of the sparring area.

So... You could place an NPC over the entire sparring area and define it as such:
In essence it would be like having onPlayerEnters and onPlayerLeaves but on a scale that isn't the level (would be simply awesome for dealing with a GMAP). Treating it like such, it would make sense that if the player were on the NPC's shape and left the level, that onPlayerLeavesMyShape be called on that NPC, and then on the level's level onPlayerLeaves would be called.