ID:2710095
 
So, this was supposed to be the week 514.1562 became the new stable build. It isn't out yet. And you're wondering: what happened?

Well, I started off the week actually doing some work toward 515, which began on the weekend. A bit of awesome news for 515 is that pointers, an amazing new language feature I used to think was impossible, are implemented, documented, ready to go. I'm really psyched to see where this will take projects in the future.

For 514, I was working on last-minute bug reports to close it up, and a late development on an old bug made it suddenly possible to diagnose the problem. The new test case came in Wednesday night, I spent a lot of yesterday during the day debugging, and then I worked furiously through the night and even so far today to work on a fix. That fix is not ready and needs more testing, especially alongside situations where a newer client connects to an older server or vice-versa. However, I'm delighted to report that I think this new setup is actually much, much better than the old and it's allowed me to simplify some code, which tells me I'm approaching the "correct" design.

Because of that need for testing, I'm also thinking 1562 probably won't be the new stable build. However I still want to aim for next week to make 514 the new stable version if possible, and maybe sneak in one more fix to bump to 1563. I may change my mind on this and just go with 1562, and deal with any bugs if they arise. There are going to be maintenance releases anyway, so no big deal there. Plus, next week I expect to be Fairly occupied.

Now on to other 515 stuff, one of the SS13 servers is looking to do something with filters that requires them to act in ways they currently either can't, or can't do performantly, or both. I've identified two major tasks I need to do for the renderer that are entirely separate from the overhaul I want to take on. First, I need for plane masters that are used as render sources to be usable for render_source in the alpha masking and displacement filters. Second, I'd like to streamline filter application so it doesn't automatically require a single icon to be rendered to a temporary surface, if said filter is a simple one-pass deal. These issues have been fast-tracked to the top of the list.

Thanks everyone who's contributed to BYOND so far to keep the fundometer healthy(ish) this month. I really appreciate your support. And for those on Patreon and SubscribeStar, I know your support doesn't show on the fundometer but you have my great thanks also.

The Great New York State Fair starts today! After an unfortunate but understandable absence, it's back in action. It'll be a little weird this year, but I still plan to go. Today was originally off the table but a few things have changed; however the weather is still looking iffy, so I'll probably hold off. But whatever your end-of-summer fun looks like, get out and make the most of it.
Not sure what pointers means for DM, but what are the odds of pushing for a real C API? Interface could be something like Python's with opaque structs, e.g.:
extern "C" __declspec(dllexport) DMObject *foo(int argc, DMObject **argv);

// or

// args here would reference a DM /list
extern "C" __declspec(dllexport) DMObject *bar(DMObject *args);
As great as this news seems to be.

Just imagine all the people that read about this "amazing new language feature", that is totally "awesome news", and thought to be "impossible", to implement before and yet not told anything of what it can be used for...

If your update reports are going to be text-only, you should provide some game design use cases to drive excitement, Lummox JR.