ID:77493
 
Resolved
Fixed in 448
BYOND Version:447
Operating System:Windows XP Pro
Web Browser:Firefox 3.5.1
Status: Resolved (448)

This issue has been resolved.
Duplicates:id:78495
This is my fade-in/fade-out proc for map changing. It's not completely broken either; it only fades 1 out of 5 times anymore.

client
proc
fast_fade_in()
for(var/obj/O in screen) if(O.tag == "fast_fade_out")
screen -= O
del O
var/obj/O = new
O.layer = MOB_LAYER+12
O.screen_loc = "1,1 to 17,17"
screen += O
O.icon = 'fade.dmi'
flick("in_fast", O)
spawn()
sleep(10)
screen -= O
del O

fast_fade_out()
var/obj/O = new
O.tag = "fast_fade_out"
O.layer = MOB_LAYER+12
O.screen_loc = "1,1 to 17,17"
screen += O
O.icon = 'fade.dmi'
flick("out_fast", O)


I would be very happy if anyone could explain why these recent BYOND updates broke these procs which have worked fine before, and how it can be fixed without using a mix of BYOND versions?
The first bug is most likely due to the new multi-map parsing (introduced in 444), which uses the ":" to distinguish the control, getting confused with the ":" used for pixel-offsets. It should be handling this correctly but there may be an oversight here.

The second bug is probably related to the new garbage-collection of client appearance data (introduced in 447). This was made to allow new instances of objects that had been recently deleted on the map to properly re-initialize instead of inheriting the properties of the old deleted objects (mostly evident in new objects set to "animate once" not doing so). Your code looks to be performing this exact task, so a change in behavior isn't shocking. I haven't investigated in depth to see if there is an issue with your code, but at a glance it looks like it should be working and we indeed have a bug here.

Lummox JR implemented both of these features so I'm sure he'll weigh in and investigate the situation.
Tom wrote:
The first bug is most likely due to the new multi-map parsing (introduced in 444), which uses the ":" to distinguish the control, getting confused with the ":" used for pixel-offsets. It should be handling this correctly but there may be an oversight here.
The second bug is probably related to the new garbage-collection of client appearance data (introduced in 447). This was made to allow new instances of objects that had been recently deleted on the map to properly re-initialize instead of inheriting the properties of the old deleted objects (mostly evident in new objects set to "animate once" not doing so). Your code looks to be performing this exact task, so a change in behavior isn't shocking. I haven't investigated in depth to see if there is an issue with your code, but at a glance it looks like it should be working and we indeed have a bug here.
Lummox JR implemented both of these features so I'm sure he'll weigh in and investigate the situation.


Okay, thank you for your reply.

I managed to fix that first problem by the way (the screen_portrait proc). It had something to do with using halves (e.g. 6.5) for y-values in screen_loc (this still works fine for x-values, though)

The fade proc problem remains a question to me, too.
Update: that second bug seems to be a flick-specific bug, as it happens only and to all of my procs that use flick.
I'm glad to know problem #1 is not an issue after all. To be clear, decimal values are not supported as pixel offsets, so code that fills in screen_loc with values that don't conform to the specifications is inherently unstable. If the behavior is unchanged for situations where screen_loc is in any of its supported formats, then there isn't a bug there.

For issue #2, it's hard to tell how to reproduce the issue without a test case, since I'm not sure how your icons are set up. Garthor's comments on that forum thread are quite correct that this is improper use of the tag var. I suspect though there may well be an issue, in that flick() may be sent before the client is aware of an object ID being recycled, and the client might think the flick goes with the old object instead of the new. If you can get a test case together I can use to see what this is supposed to be doing, that'll help, and until then I can see if my theory holds water.
Lummox JR wrote:
I'm glad to know problem #1 is not an issue after all. To be clear, decimal values are not supported as pixel offsets, so code that fills in screen_loc with values that don't conform to the specifications is inherently unstable. If the behavior is unchanged for situations where screen_loc is in any of its supported formats, then there isn't a bug there.
For issue #2, it's hard to tell how to reproduce the issue without a test case, since I'm not sure how your icons are set up. Garthor's comments on that forum thread are quite correct that this is improper use of the tag var. I suspect though there may well be an issue, in that flick() may be sent before the client is aware of an object ID being recycled, and the client might think the flick goes with the old object instead of the new. If you can get a test case together I can use to see what this is supposed to be doing, that'll help, and until then I can see if my theory holds water.

As suggested by Garthor, it now uses the name var to identify the objects in stead of the tag var, but I hadn't updated the code snippet in my post.

I'll try to make a little demonstration verb of the fade proc.
Bug fix: New method of detecting recycled object IDs in build 447 caused flick() to sometimes fail to display in these situations. The flick will now display if both the server and client are running version 448 or higher.
Thanks! That was fast. :D

Too bad I just finished that demo for nothing, though. :)
I appreciate the effort regardless.
I see that 448 hasn't been released yet and this topic hasn't been mentioned in the Fixes and Features forum. Are we expecting 448 soon?
It'll be released tonight.
Hiro the Dragon King wrote:
I see that 448 hasn't been released yet and this topic hasn't been mentioned in the Fixes and Features forum. Are we expecting 448 soon?

I don't think the fixes and features forum is used anymore.