Wobbly Mob

Page: 1 2
Feb 5 2011, 2:43 pm
This bug is difficult to trigger in a manner reliable enough to get good information. It has been caught in the act, but catching the circumstances that cause it has proved elusive.
Feb 5 2011, 3:14 pm
This happens in Decadence all the time. Just load up the game and walk in any direction, most of the time the eye will become "desynced" from the player's mob and move at an irregular pace.

If you walk in a straight line it will look like the eye is lagging behind a tick, with the mob moving first then the eye moving ahead slightly, then the mob catching back up and passing the eye again. If you remain walking long enough the eye and mob will usually sync back up, but it doesn't always last for long.

This mostly seems to happen in games where players aren't able to move 1 tile per tick. Games which limit the player's movement speed.
Feb 5 2011, 3:59 pm
I can tell you that it emerged immediately following the gliding fix a year and a half ago.

Also, I tried making a grid to catch and measure it, but it seems as though the eye is tracking fine and the mob is what's jumping around.

As for SAx, that doesn't seem like the symptoms I've noticed. In this case, it only seems to be a pixel or two.

On another note, it acts up a lot more on a lower end computer.
Apr 4 2012, 12:54 pm (Edited on Apr 4 2012, 5:58 pm)
I've run into the same problem with my game War Brothers, it is a REALLY annoying bug. It almost ruins the game-play and smoothness of the game. After so much work into the game to realize this can't be fixed is actually quite sad.

Edit: also if i remember correctly this started happening when i first adjusted the client Move()proc.
Apr 4 2012, 1:39 pm
Also, I take back what I said to SAx. His comments are consistent with what I've seen with this bug.
Apr 4 2012, 6:19 pm
Also I realized if the Move() proc is taken out the code. The game runs just fine without this eye issue.

Here's how the code looks.
mob/var/tmp/frozen = 0
client/var/tmp/TempFrozen = 0
atom/var/movespeed = 2
client/var/tmp/moving=0
client/var/tmp/running=0
client
 Move()
  if(usr.frozen == 1)
    return
  else
   ..()



client
    Move()
        if(usr.frozen||src.TempFrozen)return

        if(!src.moving)
            if(src.running == TRUE)usr.movespeed= 1.6
            if(src.running == FALSE)
                usr.movespeed= 2
                usr.icon_state=""
            if(usr.Mounted==1)
                usr.icon_state="mount"
                usr.movespeed=1
            if(usr.BoostOn==1||usr.TeleOn==1)
                usr.movespeed=usr.boostSpeed
            if(src.running == TRUE)usr.icon_state = "running"



            ..()
            src.moving = 1
            sleep(usr.movespeed)
            if(src)src.moving = 0
            return 1
        else

            return 0



MY description of the issues is: basically at any point in time, the eye appears to be a bit behind the player's movement, so the player moves to the right, the eye stays in the center, then the eye moves to the player, like it's catching up. (So the player moves PLAYER>>>>, there is a slight DELAY then, eye moves EYE>>>>) If there is another reason for this please let me know.
Apr 4 2012, 6:47 pm
Move() doesn't have an effect on anything, you can mess around using Simple Move to test this. I don't think it matters how the mob moves, it just needs to move at a constant speed which isn't 1 tile per tick.
Apr 4 2012, 7:02 pm
In response to SuperAntx
SuperAntx wrote:
Move() doesn't have an effect on anything, you can mess around using Simple Move to test this. I don't think it matters how the mob moves, it just needs to move at a constant speed which isn't 1 tile per tick.

IF I remove the Move() from the code this ceases to happen.
Apr 5 2012, 10:28 am
Move() won't impact this. The issue, which I've seen in action, happens at the client end.

The reason this was deferred is that it's extremely difficult to document properly when it happens, and darn near impossible to tell precisely where the discrepancy is occurring. I know it has partly to do with the fact that the mob and eye gliding are done with different routines, which has some legacy reasons behind it. The routines basically do the same thing but on different info.

I believe this may be related to "acceleration" that's built into the gliding code when a movable's gliding speed is not specified. If that's correct, then a workaround is specifying the speed (glide_size).
Apr 5 2012, 11:03 am
In response to Lummox JR
Lummox JR wrote:
Move() won't impact this. The issue, which I've seen in action, happens at the client end.

The reason this was deferred is that it's extremely difficult to document properly when it happens, and darn near impossible to tell precisely where the discrepancy is occurring. I know it has partly to do with the fact that the mob and eye gliding are done with different routines, which has some legacy reasons behind it. The routines basically do the same thing but on different info.

I believe this may be related to "acceleration" that's built into the gliding code when a movable's gliding speed is not specified. If that's correct, then a workaround is specifying the speed (glide_size).

So what youre trying to say is there is nothing that can be done about this for the time being, and it will most likely stay like this for who knows how long.
Apr 5 2012, 11:12 am
Lummox JR resolved issue with message:
When using gliding, the client eye could get out of sync with the mob during stop-and-go movement even when simply leaving the default settings alone, as long as glide_size was not specified.
Apr 5 2012, 11:14 am
In response to Cubanbling
Cubanbling wrote:
So what youre trying to say is there is nothing that can be done about this for the time being, and it will most likely stay like this for who knows how long.

Actually on a fresh look I was able to pinpoint the problem by tracking the speed before and after the mob map message, and looking for discrepancies. It turned out that the eye's acceleration was always wrong because it was using a last move time different from the mob itself, due to a fix that was added to prevent movement animations from stopping when moving from one tile to another without a pause.
Apr 5 2012, 11:22 am
In response to Lummox JR
Lummox JR wrote:
Cubanbling wrote:
So what youre trying to say is there is nothing that can be done about this for the time being, and it will most likely stay like this for who knows how long.

Actually on a fresh look I was able to pinpoint the problem by tracking the speed before and after the mob map message, and looking for discrepancies. It turned out that the eye's acceleration was always wrong because it was using a last move time different from the mob itself, due to a fix that was added to prevent movement animations from stopping when moving from one tile to another without a pause.

So can we expect a fix soon? After two years I'm glad to see I was able to help in some way. It would be really helpful to fix this soon, otherwise it will ruin the game-play of War Brothers.
Apr 5 2012, 12:18 pm
It'll be in the next 494 release, but supplying a glide_size is a good workaround if you're not relying on the acceleration behavior for any reason.
Page: 1 2