ID:2289489
 
Welcome to September! Today marks my BYONDiversary, and tomorrow Labor Day weekend begins.

512 development has continued this week, mostly along the lines of buttoning things up to prepare for a release. We're not quite there yet, but I've gotten documentation in for the new features and done a little more testing; further testing still needs to be done, and even then I'm sure some stuff will shake out in beta. I rather accidentally discovered that I wanted to be able to assign vars while passing them as arguments to a proc call, and there was no way to do that without it being interpreted as a named argument, so I had to dive into the parser once more to make that feasible.

I still didn't quite get in the new screen_loc stuff I'd intended yet, and I'd like to take another look at that before release. Some of it is partially done, but partial of course isn't quite good enough. It would be nice to make developers' lives a little easier in this area.

I also still need to close up a few bug reports that have been sitting around, and there may be one or two small features I can squeak in. Lexy has a request open, and it's hard to say no to Lexy when she's back in development mode.

Filters are, I think, just about closed unless someone has more last-minute ideas. More likely, we'll see an explosion of suggestions after the first beta, but the good news is the new byond_build var actually allows me way more flexibility on that.

Thanks to everyone who helped support BYOND this past month with their Memberships and donations. As we get into fall, this is what I always think of as prime BYOND season when all the best development takes place. If you haven't made a mark with a game of your own yet, this is the best time to learn. And remember, many of the greatest BYOND games of all time were not big RPGs, but smaller-scale games you could play with friends. So start brewing up your ideas!
I rather accidentally discovered that I wanted to be able to assign vars while passing them as arguments to a proc call, and there was no way to do that without it being interpreted as a named argument, so I had to dive into the parser once more to make that feasible.

So how does disambiguation work?
In response to MrStonedOne
MrStonedOne wrote:
So how does disambiguation work?

Using parentheses around the assignment expression will treat it like an assignment instead of an associative list value.

list((x=2), 4)  // assigns 2 to x, result is list(2,4)
list(x=2, 4) // result is list("x",4) where list["x"] is 2
well that sure is an elegant way to do it.
"512"

When will we have the visual contents?
In response to Lummox JR
Lummox JR wrote:
MrStonedOne wrote:
So how does disambiguation work?

Using parentheses around the assignment expression will treat it like an assignment instead of an associative list value.

list((x=2), 4)  // assigns 2 to x, result is list(2,4)
> list(x=2, 4) // result is list("x",4) where list["x"] is 2


In response to Kozuma3
Kozuma3 wrote:
"512"


In response to Lummox JR
Lummox JR wrote:
MrStonedOne wrote:
So how does disambiguation work?

Using parentheses around the assignment expression will treat it like an assignment instead of an associative list value.

list((x=2), 4)  // assigns 2 to x, result is list(2,4)
> list(x=2, 4) // result is list("x",4) where list["x"] is 2


Does this mean that list(x=(x=2),4) works too?
In response to Mr_Goober
Mr_Goober wrote:
list((x=2), 4)  // assigns 2 to x, result is list(2,4)
> list(x=2, 4) // result is list("x",4) where list["x"] is 2

Does this mean that list(x=(x=2),4) works too?

I'd say yes as it sets x to 2 and then continues as a named argument.