Issue with characters bouncing slightly - emotes interupted

[noudess]

This has had me curious for a long time, and I love emotes in game between players, so it has always bothered me that often a /dance or a /clap looks fine on my screen (I'm the one doing it) but if often truncated on the other person's screen.

I started doing some digging.

1) I tried all the stuff on the dual core/quad core thread. None had any impact.

2) I turned off my 2nd core.. No impact.

3) Played with a ton of various nvidia settings for no impact.

then... I noticed something really weird. On the side that is _watching_ the animation, I clicked the mouse outside of the EQ window. From that point forward, all the animations work perfectly until I click inside the window again.

I then learned from some web browsing that newer versions of the EQ GUI (I use Titanium) have an active window FPS and an inactive window FPS setting. So I tried lowering FPS in the EQ display settings. At 10FPS its perfect. At 25 its ok. Much above that the hopping characters syndrome appears again, and those odd hops interrupt animations. This explains why clicking outside teh windows helps - EQ client is automatically dropping the frame rate.

I don't relish playing at 25FPS.. so no solution there.

Another interesting observation. This does not happen at all locations. It happens in a ton of spots., but not all. On the patio in Tox outside Erudin, it does not happen. Step into the grass and it does. Maybe more interesting, I can #dbspawn any NPC I want at a problem location. None of them bounce. Only the PC. I also noticed that PCs _seem_ to be a few pixels higher off the ground. Does that matter? Why do only PCs bounce? How is the PC I am watching different to the viewing client? PC $z coordinates messed up maybe?

Can any of you gurus come up with anything I can try?

Does anyone know if PC movement is tracked by the GUI or the client? I would assume when I walk somewhere, any initial x.y.z coordinates I got from the server at login would correct them selves.

I've looked at this for hours today, I'd really like to find this.

To duplicate (I'm on Titanium - be interested to know if its the client):

- take 2 chars on diff screens or machines to a similar location. I do it right outside Erudin but I have to be on grass.
- Find a spot where looking at the other character - you see him/her bounce just a little every second or so. Your cursor must be in the window viewing the other char. If you see the bouncing, drop the FPS down to 10. The bouncing goes away.
- If you can duplicate, try some emotes. This is tricky, you'll need a macro - or two people on diff machines, as you need to start the emotes on once screen and quickly activate the other screen to watch the issue.

$50 to someone that helps me resolve it

[noudess]

Interesting.

If I do #goto x, y, z with a character. Then have another character come look at me, I do not bounce. As soon as I turn or move after the goto, I start bouncing again on the other screen.

I'd like to think that's server x rounding or something, but I don't think that information is sent back/forth, or am I wrong.

[noudess]

Levitated characters doing emotes always work, regardless of where they are standing. The same character unlevitated on tegh grass outside Erudin bounces and screws up emotes on remove viewign clients. That character levitated can stand anywhere.

So, something to do with standing on grass - maybe uneven surfaces? But levitate moves you all about, I expected it to make it worse, but its perfect.

[Uleat]

On bouncing...


I do know that not having maps installed will cause 'falling' issues while mobs are moving.

I have noticed what you are referring to..but, only on the RoF client. I may not have been as observant with older clients since I only solo one
instance when I play.

I had previously spoken with the dev that implemented RoF and he thought it might be the same..but, I don't believe anyone has looked into it
with any great detail.

(If you walk into an elevated building, the observed bouncing toon should remain on the ground instead of stepping up..such as in Katta Castellum)

[noudess]

Thanks for the reply. This is different (or at least I think) than the mob issue. This is 100% reproducible when one character views another on the grass outside of Erudin (and basically half of Norrath). It goes away at low FPS settings. It goes away with levitate on the character being watched. It does not occur on your own screen (watching yourself always works).

Kicker: it works on P1999 and never fails, same Titanium client on my end.

Being a software person myself, it bugs me that I can't narrow this down to a component. Since it works on P1999, it seems to be a problem with my server. But, what the heck is my server doing when a char is standing still and someone else is watching it? Maybe my server is sending updates too often? The wrong z?

[Drajor]

You probably want to have a close look at what packets are being sent. Animation is handled by spawn appearance (type=animation,value=animation id). Sorry I can't be more specific right now, at work :/

From memory client first sends emote packet followed by a spawn appearance packet which the server just sends on to nearby clients.

[Uleat]

These 'bouncing' issues are non-inclusive to the no maps issue.


It might have something to do with the position update packet that started with SoF..the one that is sent like every two seconds at a minimum.


You can watch it live by adding client->Message() to the packet handler for connected opcodes.

The packet size is always the same for static clients..then changes based on movement actions - it spams A LOT!

[noudess]

Originally Posted by Uleat

These 'bouncing' issues are non-inclusive to the no maps issue.


It might have something to do with the position update packet that started with SoF..the one that is sent like every two seconds at a minimum.

SoF is before or after Titanium?

That's a packet that the EQ client sends? I'm using Titanium so if SoF is later, I guess we'd not get them? I'll add what you suggested and see what I see.

I think a key fact is that the bug only happens in some locations and never with levitate. In the locations it fails, there is a bouncing happening without the emotes. This bouncing is what interrupts the emote I believe.

So maybe it is what you're talking about.

If so, P1999 must have patched something.

[Uleat]

Yes, Ti -> SoF -> SoD


You wouldn't see the messages like an SoF+ would, as it will only report your packets back..though, I guess, you could add
some code to monitor other client updates... Ti- still sends them..just not methodically.


I suspect that this bouncing will occur anywhere there is a zone object that is not calculated into the terrain map, and the
z-axis is of the object is higher than the map's best-z..or something like that... (texels are not my forte...)


Falling interrupts animations client-side since it needs to 'animate' the fall.


Since it only affects clients, this is the only thing that popped into my head from that previous dev conversation...


EDIT: I was thinking about this whilst I was out smoking... If you want to try fixing this, you're more than welcome to take
a shot at it. Otherwise, I may take another look.

I was thinking of finding the size of the incoming 'no-movement' position update packets and shunting those packets
to see if the bouncing stops.

I 'think' there is also an issue with npcs showing as in-the-ground with this problem..so, it might take more than
shunting unused packets. (npcs, maybe..at least my bots appeared to be in the floor in Katta Castellum shops)

[Drajor]

It would surprise me if the p99 source was still close to eqemu source.

[noudess]

Gonna try and take a look at packets this AM.

What bothers me is turning down EQ FPS to 25 eliminates the problem. I don't see how server packets coming in relates to FPS. At 25 FPS, the animations seem to actually take longer, yet work. And the bouncing is greatly reduced.

[noudess]

My code is at least a year off the main trunk. Is updatemgr.cpp even used anymore? I don't see it in the git repo. Maybe I am looking at the wrong place.

I added instrumentation to entity::QueueClients and entity::QueueCloseClients.

I ran the test watching a char standing on the grass. I repeated the test with her standing on the patio. Both just ouitside Erudin n Tox.

Both cases look identical in packets from her (there are tons of other packets from mobs all over), On the grass the anim is interrupted. On the patio it is not.

If she levitates, it always works.

Example instrumentation output:

[Fri Aug 15 11:52:37 2014] Felinicity Don't worry -  Be Happy.
[Fri Aug 15 11:52:37 2014] (close)packet OP_Emote(133) from Felinicity
[Fri Aug 15 11:52:37 2014] (close)packet OP_Animation(186) from Felinicity
[Fri Aug 15 11:52:37 2014] (close)packet OP_ClientUpdate(10) from a_kobold_runt032
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_decaying_skeleton010
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_kobold_scout004
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_kobold_runt000
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_kobold_sentry003
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_fire_beetle005
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_decaying_skeleton012
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from Felinicity
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_skunk009
[Fri Aug 15 11:52:38 2014] (close)packet OP_ClientUpdate(10) from a_fire_beetle011
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from a_fire_beetle022
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from a_kobold_watcher006
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from a_kobold_runt044
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from a_skunk022
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from Felinicity
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from a_kobold_runt044
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from a_kobold_watcher008
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from a_kobold_runt037
[Fri Aug 15 11:52:39 2014] (close)packet OP_ClientUpdate(10) from #Veisha_Fathomwalker000

[noudess]

Ok, I fixed it.

Completely related to client position updates.

Two issues.

The main one (heading was updated BEFORE it is checked to see if it differs below, hence, it always differs.. because the check below does NOT use EQ19toFloat() and compares the converted value to the one passed in).

Inside Client::Handle_OP_ClientUpdate

@@ -1268,7 +1269,6 @@
 	delta_y			= ppu->delta_y;
 	delta_z			= ppu->delta_z;
 	delta_heading	= ppu->delta_heading;
-	heading			= EQ19toFloat(ppu->heading);
 
 	if(IsTracking() && ((x_pos!=ppu->x_pos) || (y_pos!=ppu->y_pos))){
 		if(MakeRandomFloat(0, 100) < 70)//should be good

Then below that, same function: (I check the old vs the new, both using the converted values). Previous to this change, every call to this function was sending an update. It always thougth heading was diff from new heading.

It also looks like there is no z comparision? Maybe with my changes the Z component could be added? Might fix some z related issues?

I also added code to use a better float compare. I don't know that its needed, but in general I've foudn that checking for differences smaller than the machine's EPSILON is best. as some FPPs can have rounding errors. I put them both in together and it works. I think they both had impact. The heading was causing every single update to get pushed, even with no change in location. The fact that the bug only happens on uneven ground makes me believe that the rounding issue with floats caused the problem as well.

I use this macro for that:

#define FCMP(a,b) (fabs(a - b) < FLT_EPSILON)

 	// Outgoing client packet
-	if (ppu->y_pos != y_pos || ppu->x_pos != x_pos || ppu->heading != heading || ppu->animation != animation)
+	float tmpheading=EQ19toFloat(ppu->heading);
+	if (!FCMP(ppu->y_pos,y_pos) || !FCMP(ppu->x_pos,x_pos) || !FCMP(tmpheading,heading) || ppu->animation != animation)
 	{
 		x_pos			= ppu->x_pos;
 		y_pos			= ppu->y_pos;
 		z_pos			= ppu->z_pos;
 		animation		= ppu->animation;
-
+		heading			= tmpheading;
+		
 		EQApplicationPacket* outapp = new EQApplicationPacket(OP_ClientUpdate, sizeof(PlayerPositionUpdateServer_Struct));
 		PlayerPositionUpdateServer_Struct* ppu = (PlayerPositionUpdateServer_Struct*)outapp->pBuffer;
 		MakeSpawnUpdate(ppu);

The # of updates for a character not moving goes from 1 per second to zero.

[noudess]

I'm not a contributor so far and I don't really know the process. If the devs like the fix, feel free to grab it. If you want me to apply it to GIT, I can learn how, but I don't run the same code base, so I have no means to test it with the full latest code.

This should reduce the client packets quite a bit.

[Uleat]

I'll take a look at it tonight.


I added that packet message line and was trying to duplicate the issue last night..the only time I saw it was when my Vah Shir bot was sitting in the floor...

I was mistaken on the continous spam... I though it started at SoF..but, Ti showed it as well. OP_ClientUpdate and OP_SomeFloatList are the two
that get sent constantly on a ~1-second interval.


But, yeah, if it fixes an issue in the current code base we'll definitely look at adding it. (It's small enough not to worry about a diff.)