Whenever I relog, I can't remove the overlays

ID:2085279
 
May 16 2016, 8:51 pm (Edited on May 16 2016, 10:44 pm)
Resolved
BYOND Version:510.1342
Operating System:Windows 8
Web Browser:Chrome 50.0.2661.102
Applies to:DM Language
Status: Resolved (510.1344)
This issue has been resolved.
Descriptive Problem Summary:
Reloging makes the mob overlays to get stuck in the player
Numbered Steps to Reproduce Problem:
Add an overlay, reconect and try to remove it
Code Snippet (if applicable) to Reproduce Problem:
mob/verb
    Train()
        set name = "Train"
        set category = "Skills"
        if(usr.training || usr.sleeping)
            usr.overlays -= usr.Emotion
            usr.Emotion = null
        else
            usr.Emotion = 'bubbles2.dmi'
            usr.overlays += usr.Emotion

/mob
    Move()
        if(Moveing || KO || Frozen || Stun)
            return
        ..()

        if(src.Emotion != null)
            src.overlays -= src.Emotion
            src.Emotion = null
            src<<"You canceled the Training!"


Expected Results:
The bubble icon should disappear whenever the player moves, even after a logout
Actual Results:
The overlays stacks as you logout
Does the problem occur:
Every time? Or how often?Yes
In other games?Idk
In other user accounts?Yes
On other computers?Idk

When does the problem NOT occur?Before updating to the latest beta

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? It was fine at 510.1341

Workarounds:
removing every overlays
May 16 2016, 9:02 pm
This isn't a bug. It's common knowledge that you shouldn't be saving overlays, as they'll merge with your mob. Instead, add them to a list that references said overlays, and add that list to your overlays on Load().
May 16 2016, 9:03 pm
Wait, this worked for over 3 years with no problem at all, suddenly it stops working and it isn't a bug?
x.x
Btw,
How it would work different? I am already using a reference, no?
May 16 2016, 9:05 pm
In response to Inutaishos
I'm pretty sure this has always been the case.

EDIT: BTW, your code is completely irrelevant. That has nothing to do with relogging.
May 16 2016, 9:12 pm
Compile and run this on BYOND ver 1334. If it works there, something new in the way appearances are being removed from overlays has changed.

It's common knowledge that you shouldn't be saving overlays, as they'll merge with your mob.

This isn't entirely true. You shouldn't be saving overlays. That much is true. But the merging thing.
May 16 2016, 9:20 pm
In response to Ter13
I've experienced the icon flattening itself and making no distinctions between overlays/underlays and the actual mob. Merging might not be the appropriate term here.
May 16 2016, 10:05 pm
In response to Ter13
Did you mean 1343? Yeah I did and its not working;
but if you meant 1334, wellp, I don't know where to download an oldest version, can you link me?
May 16 2016, 10:15 pm
In response to Inutaishos
May 16 2016, 10:25 pm
In response to FKI
Thx <3
And yeah it works fine at 1334, (Just had to remove the overlays and test again, it works)
May 16 2016, 10:29 pm (Edited on May 16 2016, 10:47 pm)
Alright, I'll get to work.

EDIT:

Issue does not appear in 1341.

Attempting in 1342.
May 16 2016, 11:01 pm
Another user mentioned this same issue to me, although there was nothing like a reliable test case for me to try out.

The weird thing is, I don't know what could have possibly changed here. The fixes in 1342 were totally unrelated to any of this.
May 16 2016, 11:06 pm
http://files.byondhome.com/Ter13/OverlayBug_src.zip

Here you go. My test case conclusively proves that loading appearances from savefiles creates a new appearance in 1342 only. Zasif wasn't wrong. He just couldn't narrow it down.

It works fine in 1341.

Boot up the test case, click addoverlay, and then save. Now click checkoverlays. This will dump the refs of all overlays on the mob.

Then click dumpsave to look at the raw text of the savefile.

Then click load to load the mob.

Attempt to remove the overlay. It will fail.

Now click checkoverlays again, and you'll see why it fails.
May 16 2016, 11:08 pm
In response to Ter13
Ter13 wrote:

Zasif wasn't wrong

Zasif? *Cries*
May 16 2016, 11:12 pm
I'm pretty sure I know what's happening now--it's because of FLOAT_PLANE. The appearances being read back from the savefile don't have the same plane, because plane doesn't save with them.
May 16 2016, 11:15 pm
Zasif? *Cries*

He reported this issue earlier. I'm not calling you him. I sort of said some things. Some things about his ability to diagnose bugs. They weren't polite. For once though, he did find one. I was wrong.
May 16 2016, 11:17 pm
In response to Ter13
oh lol.
Thx btw for your help <3
May 16 2016, 11:51 pm
It appears that savefiles have not been saving a lot of appearance properties properly, and that's something I very much need to change in 511.

Because of the way savefiles work, I don't think I can fix the lack of saved info until then--although once I do, the new-version savefiles will be incompatible with old servers. However I should be able to fix this particular bug by setting plane = FLOAT_PLANE on all loaded appearances.
May 17 2016, 9:31 am
Lummox JR resolved issue