ID:137140
 
Beta #38 (notes)

We plan to release this as version 311 (BYOND 3.0) later today, assuming that there are no disasters in this latest beta. This just means that we will put it on the hub so that users will be notified to upgrade. In hindsight, it was pretty silly to hold off as long as we have; even with any remaining bugs this release should be considerably more stable than the last, and with the upgrade system it is trivial to release patches.

Anyway, please test it out. It has some more fixes and a few longstanding pager requests.
Heh great ^_^ Did you find out what was casuing those strange errors on my game? I hope so, I'd hate to have people running around with -20AC equipment mods ^_^
New (or old unfixed) dmi-in-browser bug: A dynamically-created blank icon doesn't work with browse_rsc(). (Other dynamic icons do work now.) My proc to convert these to HTML checks first to see if the icon is null, so if it's becoming null, there shouldn't be a problem. However, it appears to lose its status as an icon file, too, because this simple code doesn't work:
if(ic)
fname="[name]_[x]_[y].dmi"
recip << browse_rsc(ic,fname)

There's no error message with this. However, the icon does not appear in the cache even though fname is being set and is not shown in the browser after browse() is called; a broken image shows instead. The other images work fine. The value used for ic comes directly from an obj.icon var, so it should be valid--apparently transparent icons are simply handled differently.

If /icon had an isblank() proc so I could tell if it was an empty icon before even assigning it to an obj (I could just delete the obj), I could also work around the bug that way. Might be worth a last-minute change before the release.

Lummox JR
Trying to read from undefined variables at runtime was just silently returning null. It now generates a runtime error, which is safer in the long run.

Just to be a pain in the neck -- does this mean that the undesirable behavior had been around for a long time? Or was it just introduced in a recent build? The answer is important to my mental health. :)

In response to Gughunter
Gughunter wrote:
Trying to read from undefined variables at runtime was just silently returning null. It now generates a runtime error, which is safer in the long run.

Just to be a pain in the neck -- does this mean that the undesirable behavior had been around for a long time? Or was it just introduced in a recent build? The answer is important to my mental health. :)

I'm pretty sure this caused a runtime error in the mists of time...

[edit]
To be more specific...

I think at first it didn't, then it did (maybe my fault)...then I guess it didn't but I didn't know about that phase.
In response to Gughunter
Gughunter wrote:
Just to be a pain in the neck -- does this mean that the undesirable behavior had been around for a long time? Or was it just introduced in a recent build? The answer is important to my mental health. :)

Believe it or not, it's been that way forever!
In response to Tom
Tom wrote:
Gughunter wrote:
Just to be a pain in the neck -- does this mean that the undesirable behavior had been around for a long time? Or was it just introduced in a recent build? The answer is important to my mental health. :)

Believe it or not, it's been that way forever!

Oops, that's the answer that's detrimental to my mental health. Maybe I'm actually just remembering compile-time "bad var" errors, though. Good thing I didn't wager with anyone on it!


In response to Deadron
Deadron wrote:
Gughunter wrote:
Trying to read from undefined variables at runtime was just silently returning null. It now generates a runtime error, which is safer in the long run.

Just to be a pain in the neck -- does this mean that the undesirable behavior had been around for a long time? Or was it just introduced in a recent build? The answer is important to my mental health. :)

I'm pretty sure this caused a runtime error in the mists of time...

At one time, we had a similar issue with procs. When we added a runtime warning, we got a lot of complaints at the time. I think it would now be ok to reinstate the runtime error, because the new inheritance system makes it easy to do the right thing and prototype procs across all the objects that need them.