ID:2239168
 
Greetings BYONDers!

Version 511 has finally moved into the stable release phase, so no more endless rounds of betas. That doesn't however mean it's finished: While I'm developing 512, I plan to keep on top of bugs and do occasional maintenance releases. In fact, there's a new maintenance release out today.

One of the things I'd actually still like to work into 511, which will require me taking some time away from the 512 project, is XInput for controllers. Yut Put reminded me this week that we still need that, so I'll be looking into it.

However I'm excited to announce that work on 512 features has not only officially begun, but I have one of them already "in the can". For ages now, users have been asking for ways of chaining proc calls and lists like this:

mylist[2].name = "Fred"
FindMonster().Kill()

This is actually going to be possible in 512. The only reason I didn't include it in this new 511 maintenance release--it doesn't use any new instructions that would require a version bump--is that it's a big enough syntax change that I think it deserves to go through the rounds in beta testing, even though it's withstood anything I've thrown at it so far.

With chained procs and list lookups, there is a pretty big caveat: The . operator from that point on will act like the : operator. That's because there's no way at all to really know what type you'll get as a result of a proc call or a list lookup. DM does not support typed lists or proc return types, so the concept is meaningless. If support for them is ever added in the future, my expectation is that the current (that is, new) behavior will be kept for untyped lists and procs, but typed lists/procs will throw errors. At that point I'll probably need to make : handle this new chaining behavior too, but one issue at a time. (With : there's the issue that some old code like a?b():c might not behave the same.)

As long as I'm screwing around with the compiler, next on my list is raw string literals. The idea of a raw literal is that escape codes and embedded bracket expressions are not processed, and newlines are left intact. Currently, the proposed formats look like this:

// I'm thinking this one might actually be better breaking on a newline.
@"This is a string literal and this is a backslash \ that I didn't have to escape."

@{"This is another proposed "string literal" format, but it would let me use quotes."}

@(XYZYX)This is yet another string literal format being considered, with an arbitrary delimiter.XYZYX

In theory this raw string thing should be simple to add to the parser (except that the arbitrary delimiter thing will require some look-ahead logic), so it's only a matter of 1) deciding on formats, and 2) updating the syntax highlighters in DM, the site, and JavaScript.

After that, I'm probably going to turn my attention to some HUD improvements Ter13 suggested, that would make positioning elements a heck of a lot easier. Right now everything is interface-agnostic, but some of the new suggestions would require the HUD to update based on map control size.

Site foo hasn't been forgotten, though. I still have a number of requests regarding subscriptions that I want to deal with, and those are very important. The main reason I got started on 512 features was from merely trying to figure out how feasible they'd be, which got me locked onto that mini-project.

Don't forget to hit up the donation page to help BYOND out, or better yet become a Member if you haven't yet. You keep the development running. And now that spring is here, come back indoors away from the incessant rain and pollen and play some games! Better yet, make some games.
Lummox JR wrote:
After that, I'm probably going to turn my attention to some HUD improvements Ter13 suggested, that would make positioning elements a heck of a lot easier. Right now everything is interface-agnostic, but some of the new suggestions would require the HUD to update based on map control size.

++
If you returned a list of mobs to a proc does it run for everything in the list?

FindMonsterList().Kill()
In response to Kumorii
Kumorii wrote:
If you returned a list of mobs to a proc does it run for everything in the list?

FindMonsterList().Kill()

No, because it's running on the return value of the proc. It's literally like doing this:

var/a = FindMonsterList()
a:Kill()

If a is a list, Kill() is not a list proc and will therefore fail.
In response to Kumorii
You would want a functional-style list.ForEach(proc). I wouldn't expect DM to adopt any functional language features ever.

inb4 lambdas
Ayy modernizing one step at a time
List.ForEach() might be a worthwhile idea.
In response to Kaiochao
Kaiochao wrote:
You would want a functional-style list.ForEach(proc). I wouldn't expect DM to adopt any functional language features ever.

inb4 lambdas


Make da request! I've wanted this forever too, and Lummox already said it's worthwhile, go go go.
I'm learning! Hooray!
Good Work! I was wondering how much of a heavier load is ":" over "."
Aw man, this is awesome. Thanks Lummox! List.ForEach() would be great.
In response to Zagros5000
Zagros5000 wrote:
Ayy modernizing one step at a time

Frfr. Gotta respect the work ethic if nothing else...
@{"This is another proposed "string literal" format,
but it would let me use quotes."}


[eDiT]
Please don't make us wait 3 more years :c
Sounds like some great progress! Some of this code stuff is a bit beyond me, right now, but it sounds like should be easy to use and experiment with to do some really cool things, once it gets implemented!
In this case, atom.transform = matrix() * 2 works.
Just another reason (well, the primary reason) for operator overloading.
Yut Put wrote:
finally we can write atom.transform = matrix().Scale(2)

atom.transform = matrix(2,MATRIX_SCALE)

http://www.byond.com/forum/?post=1881375
In response to Ter13
Ter13 wrote:
Yut Put wrote:
finally we can write atom.transform = matrix().Scale(2)

atom.transform = matrix(2,MATRIX_SCALE)

http://www.byond.com/forum/?post=1881375

atom.transform *= 2
icon.Scale(2)

(^88
In response to Kumorii
Kumorii wrote:
icon.Scale(2)

(^88

var/icon/I = new('icon.dmi')
I.Scale(I.Width()*2,I.Height()*2)
usr.icon = I
Page: 1 2