ID:2080426
 
Since the release of 510.1341, things are looking really good for 510, so I think 1342 will be the stable release, and my aim for that is sometime next week. At this point I'm just looking for things I can tweak or minor fixes to throw in for the last 511 release, and while I'm waiting I'm getting started on 511.

Although I have a lot of plans on my plate for 511 already, recently Ter13 convinced me that I really need to add mutable appearances. It'll be a boon to high-performance games like Epoch and Severed World, and to (usually) regular-performance but super-complex games like Space Station 13 that need to eke out all the clock cycles they can get. So I've been working on that quite a lot today, planning ahead.

Var access optimization is still #1 on my to-do list, although it's not a new feature so much as a tune-up under the hood. I'm keeping that first because it's also really important to the Space Station 13 guys.

The other top feature is gamepads, of course. I'm still working out all the details for that. We had a lot of discussion on that this week, mostly with questions about how things will work and what kind of support there will be. My design goals here are to have a basic level of support that fits as many games as possible without a lot of fuss, and some more advanced stuff available for games like Lux that may want to put analog sticks to good use.

The biggest priority feature besides those is looking into libcurl and whether I can easily integrate that into the code. I really want BYOND to have HTTPS support under the hood. Users setting that up for the webclient will have all kinds of arcane joys dealing with that, but if I can get it working that's really a big deal. However I want to caution everyone that I've barely had any time to look into this yet, and I have no idea what I'm getting into with it, so if things start to look dicey I may back away. Chances are it'll work, but the question is with how much effort and what will have to change under the hood. (That said, libcurl is NOT going to be important to implement for the early stages of 511, since it's completely on the backend. It's totally possible, I think, to add it without a major version upgrade, and so it can probably be done at any point in a beta series.)

I still want to come up with some kind of filter concept for things like blurs, alpha masking, drop shadows, etc., but I'm having a lot of trouble nailing down a good syntax and structure for that kind of thing. If I can't come up with something fairly soon, I may save that for a future release. 511's getting kinda crowded as it is.

My big wish list at the moment looks like this, and it's going to need some pruning:

- Var access improvement
- Mutable appearances
- Gamepad support
- libcurl
- Chaining assignment operators, e.g. a = b += c (DONE!)
- pixel_w
- Enhanced client-side frame rate
- Parallel animations
- Filters
- flick() for images (id:116655)
- Look into id:2012158 for mouse cursors
- for(key,value in associative list), id:2078529
- Sound fallbacks (implement in DS and document; webclient already has them)
- id:688906, background-color in maptext
- id:2068547, warn on repeated switch() cases
- Improve preload_rsc handling
- id:2059063, game-specific mute
- Icon info routines
- Finally get to topological sort for isometric and side-view modes
- Verb origin info: id:2077911

That's a lot of stuff, and I think a number of those features may have to wait--either for later in the beta or for 512. Anything that I feel confident about implementing that requires a network protocol or language change will end up going into the initial 511 release. Features that can be done at any time may come along later in the beta series, as usual.

I haven't discussed parallel animations in this space before (I think), but a lot of developers want them and it seems like it might be approachable. Awful, but approachable. The basic concept there is to allow for different variables to be animated by separate animations at once on the same object, and quite possibly to allow additive changes to the same variables. This is a wish-list item but I think it's really worth doing.

Whew! So you see I have my work cut out for me. Help me along by putting in a donation or becoming a BYOND Member if you haven't yet. Your support makes all the difference.
Lummox JR wrote:
Anything that I feel confident about implementing that requires a network protocol or language change will end up going into the initial 511 release.

Does that potentially include the client-side frame rate foo? Because that'd be awfully exciting.

Good stuff as always, Lummox.
If you're going to be doing site work any time soon, I'd like to bring up this feature request again. I'm still very interested in doing more math tutorials, as it's something else to keep me occupied while I (fruitlessly) search for work.
What do you mean by mutable appearances? Does this mean that appearance datatypes are no longer black boxes that we can't modify directly?

For parallel animations, how about adding a new parameter to animate() called track or animationNumber.
So that to animate something jumping, like in a platformer
animate(O) //clear all animations

//put the pixel_y animation on track 1
animate(O, pixel_y = 0, track = 1, time = 0)
animate(pixel_y = 10, track = 1, easing = QUAD_EASING|EASE_OUT, time = 1)
animate(pixel_y = 0, track = 1, easing = QUAD_EASING|EASE_IN, time = 2)

//then put the pixel_x animation on track 2
animate(O, pixel_x = 0, track = 2, time = 0)
animate(pixel_x = 10, track = 2, easing = LINEAR_EASING, time = 2)

This would make the object, O, jump upwards up to a height of 10 and with horizontal speed of 5 pixels per tick.

On another note, it might be useful to also have quadratic easing. :P

I have no idea how this should behave if two different animation tracks are modifying the same variable.
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
I have no idea how this should behave if two different animation tracks are modifying the same variable.

Maybe have the newest one always override control over the same variable.
In response to D4RK3 54B3R
On another note, it might be useful to also have quadratic easing. :P

We do. I added it a while back.
- Var access improvement
- Mutable appearances
- Gamepad support
- Enhanced client-side frame rate
- Parallel animations
- flick() for images (id:116655)
- Look into id:2012158 for mouse cursors

The hype is real.

BYOND about to get some really developer friendly shit.
I have to admit all these planned features together will make Byond extremely robust for larger scale games.
I could work on libcurl support as a library for BYOND, if this will help?
In response to NullQuery
It's in response to this issue, which can't be remedied by a library unfortunately.
In response to Popisfizzy
Popisfizzy wrote:
It's in response to this issue, which can't be remedied by a library unfortunately.

It's also in response to the fact that world.Export() can't hit https websites...or do post.
Generally the fact that the software can't establish secure HTTP connections in general really, POST support alone wouldn't require libcurl but it was always one of those 'if you do one you may as well just go all the way' things when I'd talk to Tom about it.
I'm so excited for the future of BYOND. Honestly, Lummox, you are amazing doing this on your own, especially for how little you currently get in return. Thank you so much!
I just want to say thanks because many of those features are super great
I'm loving Lummox giving a wishlist for a future release. Keep it up!