ID:1825978
 
Resolved
Image creation was causing premature deletion of values.
BYOND Version:507
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Chrome 41.0.2272.101
Applies to:Dream Daemon
Status: Resolved (507.1281)

This issue has been resolved.
Descriptive Problem Summary: After updating BYOND to beta 507.1280, necessitated by having to work around the 506's proc limit in updated code, sprites are not being read correctly. A number of sprites not touched by the update are being displayed as an error sprite (a sprite with no name, to which icons that fail to locate a name of the sprite in the file defined in the code for the object) or not at all - if there isn't such a sprite defined.

This causes a number of objects to lose their usability to players.

The issue is not caused by the new code - it worked well previously, and reverting the code to a state prior to the update using the 507 Dream Maker results in the identical problem, absent in the same code compiled on 506's latest release.

Error possibly related to the 506 proc limit issues.

Numbered Steps to Reproduce Problem:
1) Download the latest code of Urist McStation (https://github.com/UristMcStation/UristMcStation)
2) Compile the code in 507.1280's Dream Maker
3) Using 507.1280's Dream Daemon, set up a local server and join it.
4) Join as any human role - the Captain will have easy access to all clothing items.
5) Equip captain's jumpsuit or quartermaster's jumpsuit and marvel at 10/10 spritework
6) Equip cargo technician's jumpsuit, Captain's Formal Clothing from the Captain's Clothing locker or most other clothing in that slot, be sad that an error icon displays instead.
7) Pick up a fireaxe and use it to dual-wield it - see how the axe disappears.
8) Look at the pipe network on the station, note how some of the pipes are invisible.

Code Snippet (if applicable) to Reproduce Problem: Not applicable.


Expected Results: Sprites continue to display as they did when compiled in 506.

Actual Results: Some sprites disappear or use the error sprite of that item type.

Does the problem occur:
Every time? Or how often? No apparent pattern to items affected, consistent between reboots and recompiles.
In other games? Unknown; asking SS13 coders from other codebases indicated they do not know of the issue, but few of them use 507.
In other user accounts? Yes, in every user.
On other computers? Yes, both as above and compiled on different machines.

When does the problem NOT occur? Did not occur prior to the update from 506 to 507; unknown if present in earlier 507 releases.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.) See above, 506.1250.

Workarounds: Using 506 releases?

Hrm. So if I'm following this right, the issue occurs only with worlds compiled in 507, but not in 506, regardless of which version runs them. I bet this is related to that "bad instruction" error, but darned if I know the cause. I'm still working on that.

I'll download that code and see if maybe I can work with it in the debugger at some point to figure out what's up. SS13 is very unfriendly to the debugger and takes forever to startup, though.
Heh, I may have a bit rambl-y style. But yeah, you got it right. I compiled it on 507, checked that it doesn't work, compiled again on 506 the very same code - boom, runs.

I may try to host the 506 compile with 507 DD to see if it is perchance a DD bug, not a compiler one.
Oh, you should definitely do that. If you were only testing 506-compiled in 506 DD, that wouldn't tell us one way or the other. If it's a compiler bug, it's probably easier to narrow down.

I would also suggest, if it does not show up as a DD-only bug (where 506-compiled still shows the problem when hosted in 507), that you try compiling with some older 507 builds and narrow down when the problem appears. That would help a great deal.
I had this happen in 1280 but not after I downgraded to 1278.
In response to MisterPerson
MisterPerson wrote:
I had this happen in 1280 but not after I downgraded to 1278.

How about 1279? Also, are we talkng compiling or just running?
Clean compile each time. Not tried 1279, sorry.
One of the things I'd like to narrow down, though, is if compiling in 1278 and running in 1280 causes the problem. That'd tell me if it's in Dream Daemon or Dream Maker.
MisterPerson, I'm also curious if you were using this same source, or something different.
I know it happened with a compile in 1280 and then running and not after a compile and run in 1278. I don't believe I ever compiled in one version and ran in another. I didn't have a lot of time yesterday but I'll do some more testing today.
Okay, cool. If you can narrow down whether it's the compiler or the running version, that would help enormously. I'd also like to know where 1279 falls in the mix.

I was thinking Lexy's issue might be related, but since you've observed this when DD is hosting and DS joins locally, that wouldn't be the case.

Your tests on this are much appreciated, because SS13 as you know is a beast and the time I'd spend compiling and running various versions would take away considerably from the time I can spend on other code. The more this can be narrowed down for me beforehand, the better.
Only happens when ran in 1280. Version compiled in is irrelevant. DM->Run has worse problems than hosting with DD. For example, with Run,flick() made the sprite disappear for the duration of the animation and world << output didn't work at all. Here's a test case for the latter part.

/mob/verb/double_output()
world << "World output doesn't appear"
src << "Local output does"


The graphical bugs, however, remained even when hosted with Daemon. Basically, certain objects are getting really off icon_states. I found an image used as an overlay that was supposed to be "manifold_full" but was instead "1437", which is a number used as a variable elsewhere in the code. A section of carpet, a turf, got the state "r_arm_01". "r_arm" is used but "r_arm_01" is not, as far as I can tell. What's interesting is that every image that was supposed to get "manifold_full" got the different state, not just one. Other images were untouched.

One of the messed up images is for hair. An icon object of the same hair worked just fine, but the image got some invalid state instead. Not sure what was up with that.</<>
Running in straight DS is probably going to muddy the results of this bug because of the issue I fixed yesterday. Interesting to note this happens running in 1280 though.

So to be clear, this does not happen when running in 1278? What about 1279?
I've been looking through the diffs, and I'm not seeing any substantive differences in the code governing DS or DD between 1278 and 1280. Nor am I finding anything in Dream Maker.
I found the cause of this, in image creation.
Lummox JR resolved issue with message:
Image creation was causing premature deletion of values.
You're my hero, thanks Lummox. I spent hours earlier in the week tearing my hair out over this, looking forward to 507.1281.
Descriptive Problem Summary: On starting server on 507.1280, the server outputs "BUG: Bad ref (6:84xxx) in DecRefCount(DM _atmos_setup.dm:xxx)" repeatedly.

Numbered Steps to Reproduce Problem:
Download the repository found here, compile and run under 507.1280.

Expected Results: The server starts up and the game runs.

Actual Results: The server outputs large numbers of "Bad ref" errors.
(The mentioned _atmos_setup.dm is here.)

Does the problem occur:
Every time? Or how often? Every time
In other games? Unknown
In other user accounts? Unknown
On other computers? Unknown

When does the problem NOT occur? When I use 507.1279.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Does not occur in 507.1279.

Workarounds: Use 507.1279.


EDIT: I... posted this in a new thread... Not sure how it's got here. Can it be moved, or should I just recreate it?
Just recreate it, not a big deal.
In response to GinjaNinja32
I moved it here because it's the same issue.
Page: 1 2