ID:2101963
 
This week I put up two new maintenance releases for version 510. 510.1346 made a number of important fixes; unfortunately as is so often the case, one of the less important fixes ended up creating a brand new bug that was kinda bad, so I had to fix that in today's new release of 510.1347. 1347 only impacts Dream Seeker, so servers can just update to 1346 with no trouble.

One spot of really good news is that as of the 510.1346 release, the webclient is performing a heck of a lot better across the board, now that it skips drawing on animation frames between actual client ticks where nothing has updated.

Gamepad support has continued right along, with more work done on the macro UI so that setting up your own mappings should be fairly straightforward. I have a few question-mark items still on my list under this, so I've set them aside for the moment to focus on some other things. I'll button the rest up soon enough.

(I told Tom about the way gamepad foo is being mapped using the macro system. He thought it sounded cool, although that's probably because he didn't see the code, and also if he did see it it wouldn't be his problem. Remember, kids: lack of accountability is fantastic.)

Other features for 511 have been progressing nicely. Parallel animations are now a thing, and they are awesome. I wish I'd done them a long time ago. By using parallel animations, you can animate multiple vars on the same object, in different ways, all at the same time. You can even animate the same var in parallel, for some cool effects. Here's a fun little spiral I did:

// counter revolution
animate(src, transform=matrix(108,MATRIX_ROTATE), time=3, loop=3)
animate(transform=matrix(-108,MATRIX_ROTATE), time=4)
animate(transform=null, time=3)
// translation
animate(src, transform=matrix(64,0,MATRIX_TRANSLATE), time=30, flags=4)
animate(transform=null, time=10)
// revolution
animate(src, transform=matrix(-108,MATRIX_ROTATE), time=3, loop=3, flags=4)
animate(transform=matrix(108,MATRIX_ROTATE), time=4)
animate(transform=null, time=3)

The object first rotates clockwise; at the same time it moves outward from the center and quickly back in; also at the same time, it rotates counter-clockwise. Each of those transforms is interpolated like normal on its own, and all three get multiplied together. Result: the atom follows a spiral path, while keeping its orientation.

Or you could use something like this for a few explosive particles:
// calculate px,py,pz first; all are from -1 to 1 except pz is 0 to 1
animate(particle, pixel_x=px*64, pixel_y=py*64, time=pz*15)
// the first fall of the bounce easing takes up 1/2.75 (4/11) of the time
animate(particle, pixel_z=pz*16, time=pz*4, easing=QUAD_EASING|EASE_OUT, flags=ANIMATION_PARALLEL)
animate(pixel_z=0, time=pz*11, easing=BOUNCE_EASING)

People have been wanting this for a while, and it turned out to be easier than I was hoping. Yay progress!

Of course this means I'll probably have to figure out a good strategy for avoiding appearance churn when animating particles. The new mutable appearances probably won't get the job done in that department, since the issue is that so many new appearances have to be created for the animation process. I may decide to try shoehorning temporary appearances in, trading network bandwidth for CPU. Or maybe not. I may have to see how it shakes out and make a decision in 512. Also I have half a mind to create something missile-like that can be animated but won't act like a true obj.

SS13 peeps, I haven't forgotten var optimization. It's still way up high on my list.

This Sunday is Father's Day, so give your dad a hug or INSERT MANLY SPORTS THING HERE, and share some steak or ribs or something while the weather is nice. And with wedding season crashing upon us--as we speak I just got an invitation--better practice your dance moves, too. (Don't worry, folks; I won't be dancing. Nobody wants to see that.)
Great work!
How does ending an animation work? What if I only want to end one specific bit of it?
In response to Rushnut
Rushnut wrote:
How does ending an animation work? What if I only want to end one specific bit of it?

I think it effects the one that last used src and it affects only that chain of animate calls until the next src is clarified, just a guess tho.
This is almost as big as the introduction of animate() itself. Well done!
animate(src, ...

animate(...

While i understand why this syntax is used, I do say that the idea has always irked me of having anything globally state based in a OOP language.

This seems like something that should use channels (like sounds do) so you can reset or append to a certain animation without having to reset all animations on that object or only the last one or have to track rather or not some other object used the animate call.

Just food for thought, Still amazing none the less.
In response to MrStonedOne
MrStonedOne wrote:
I do say that the idea has always irked me of having anything globally state based in a OOP language.

DM's native functionality has long had an identity crisis of whether it's really OO or not. It's honestly kind of irritating.
I do say that the idea has always irked me of having anything globally state based in a OOP language.

Agreed; Javascript does something with settimeout() where it returns an ID for each timeout that can be used to cancel a callback in the queue. It's not elegeant or OO in nature, but it'd be a neat way to interact with specific animation effects. Since animate() doesn't return anything by default, it'd be a syntax-friendly way of messing with animation chains.