It's hard to believe it, but build 512.1442 seems to have finally gotten us off the roller coaster of never-ending bug fixes. The previous issues with the ongoing movement overhaul have been ironed out, which leaves room to create a whole bunch of new issues in bringing that project to the finish line.

Because nothing is imminent, this is the first Friday in quite a while I haven't had to do another release. So no more taunting the Friday release curse!

The last stage of the movement overhaul is going on now, and as predicted it's a big one, impacting a lot of code. I am so, so glad I did the preliminary work of moving a lot of things into structs that weren't before, and simplifying routines that compared bounds. That simplified a lot of this process, which would have been ten times worse otherwise.

Currently where I'm at with the movement overhaul involves changing up the routines that handle turf overhangs. An overhanger is an obj or mob whose step offsets and/or bounds have it covering another turf besides its official loc. Internally, step_x/y get "normalized" in certain conditions so that the movable should always be covering its official loc. (I could, and should, improve on that normalization.) But its bounds hang it over any other turfs, those end up in obj.locs as well and likewise it appears in their contents. That overhang logic was all based on integers, so it needs to be changed to support floating point. Anything over about 0.001 (actually 1/1024) away from an integer will be considered valid; anything within that bounds will snap to an integer, just to avoid headaches.

The client of course will know nothing of floating point offsets. It isn't worth the hassle to throw that logic in there, so as far as the client is concerned objects all have integer steps and step sizes. I may decide to change that in the future if it turns out games using a higher client.fps benefit from additional precision, but for now it stays as-is.

I'm still thinking ahead to 513 features, trying to come up with some ideas for that. But I'd also like to sneak more filters into 512 while the proverbial iron is hot, like perhaps a bloom filter which has been requested already, and also I'd love to add radial blur, conical blur, and ripples. I have an idea how to tackle bloom filters, but I need to get some feedback on what approach to take. I'll discuss that more on today's Patreon post, but because it's not under-the-hood stuff it's open to non-Patrons to view as well. (Comments are welcome on either post: that one or this one.)

Thanks everyone who's contributed to BYOND this month as a Member, donor, or Patron. I love you guys and deeply appreciate the support! All this feature work I keep doing, along with projects to optimize and keep making things better, is for you.
I recalled something about alpha masks not to long back. Is that something intended for 513?
It's something I'm open to considering (and forgot to mention in my Patreon post), but I want to give it a little more thought.
I'd say go for it. It opens up a lot of potential. Of course, if it's not feasible then it's understandable. You're doing a great job regardless!
Why not include the meta header tag for browsers so that we don't have to constantly include a single line of HTML to enable the browser to work as intended.

Are the defines for TRUE/FALSE ever going to be changed from const to actual defines?
The reason edge mode isn't enabled by default is because developers don't always want to introduce massive inconsistencies between clients. If a client has IE9 installed their experience is going to be vastly different than someone with IE10 installed.

Developers tend to do it on a case by case basis if the consistency thing isn't a big deal.
In response to Kozuma3
Kozuma3 wrote:
Are the defines for TRUE/FALSE ever going to be changed from const to actual defines?

There's an open issue about this (id:2371109) and it's something I'd like to do. I'll actually look into that right now. The main open question for me is how this stuff gets handled in savefiles.

I strongly suspect for any of the built-in consts I'm not going to see a situation where the var const names get preserved, but I do believe that is the case for some other situations.

It actually looks like savefiles aren't impacted at all (I thought they would be because of some previous experience with Incursion, but that might have been an associative-list thing), but now I'm wondering what happens if those constants appear in a map file. Generally speaking I don't think that should be the case except where manual edits are concerned, but it'd be a good idea to handle that somehow.