ID:1882875
 
As with my last report, I plan to release the next beta build, 508.1291, early next week. Probably Monday. The main reason for that is that I'm chasing down a couple of issues, one of them a bug in 508.1290 that apparently relates to the animation fixes. The fix for the output scrolling "jumping" when removing old lines will finally be in 1291; it was planned for 1290 but didn't get checked in by mistake.

The DSification of the webclient is still progressing, though it's what I like to call a slog. There's just so much code to bring over. I'm saving myself a few headaches (mostly on an abstract level, because as I type this I have a literal headache) by copying the Dream Daemon to Dream Seeker messages as much as possible.

Gliding is implemented, in theory, with the exception that map gliding isn't hooked up yet. Gliding turned out to be really tricky and will likely prove a source of grief once I get to testing. Every time I've messed with the glide code in Dream Seeker, especially as gliding relates to the player's eye, it's bitten me in the butt. As I go along I'm trying to organize things a little better in the webclient than they are in DS for this reason.

Turf block and change messages, the area message, and the change to the movables list have all been implemented. A server-side animation message comes next, as does a message for screen objects. I've still stuck with a concept where I'm using some webclient-specific info on the server end rather than the exact same data structures used for a Dream Seeker player, because for now it's just plain simpler. (For example, the server keeps separate lists of updated objs and mobs for DS clients, and sends separate messages about them both. The webclient won't do this, lumping everything into a single list and a single message and therefore also looping through turfs in view less often.)

I still haven't made up my mind about increasing the number of unique map cells from 65,535, but at this point I guess it seems stupid not to. The memory hit for games with huge maps really isn't that horrible in the grand scheme of things.

Speaking of things I haven't made up my mind about: Ter13 recently suggested that glide_size should support floats, not just integers, and I'm starting to think he's right. I think the whole glide system could really benefit from floats, actually. And I also think it'd be beneficial to have some kind of flag specifying that X and Y should both glide at the normal rate, rather than trying to move by glide_size in the exact direction. (I.e., it should be possible to make a diagonal glide go as fast as a cardinal one.) How to do that without risking var soup, I don't know, but I'm open to suggestions. Neither of those changes look to be horrible, but they would have to be implemented in 509.

(On the other hand, I just remembered I said that every time I've screwed with the glide code it's bitten me in the butt. Bring on the eye sync issues!)

I mentioned last week I'd be working on some changes to help improve the ban system, so big games like SS13 could see a benefit. Those are underway but need more work. I think I'm mostly set with that, but need to do some testing.
The glide_size improvements would be awesome. The current setup really only works well if you're creating a game in which every single player has the same movement speed.

Also, about a month ago you brought up the possibility of having client frame rates be independent of the server frame rate. Any news on that front? I would *kill* to have the world running at 10 or 20fps while the client animates at 40. That feature by itself would be a total game changer; I can't even imagine how incredible it would be if it came bundled with support for using floats for gliding.
The DSification of the webclient has to be completed before I can begin looking into a separate client frame rate. This wouldn't be possible with the server-heavy webclient.
Speaking of things I haven't made up my mind about: Ter13 recently suggested that glide_size should support floats, not just integers, and I'm starting to think he's right. I think the whole glide system could really benefit from floats, actually. And I also think it'd be beneficial to have some kind of flag specifying that X and Y should both glide at the normal rate, rather than trying to move by glide_size in the exact direction. (I.e., it should be possible to make a diagonal glide go as fast as a cardinal one.) How to do that without risking var soup, I don't know, but I'm open to suggestions. Neither of those changes look to be horrible, but they would have to be implemented in 509.

Well, animate_movement has been deprecated for what, a hundred releases or so now?

Why not hijack it and reinstate it as a bitflag?

animate_movement:

NO_STEPS(0)
FACE_STEPS (1) //no need to have slide/forward steps, they are inverses of one another, so a single flag on/off will suffice.
SYNC_STEPS (2) //left in for legacy, but value changed
SQUARE_STEPS (4) //new value for new gliding behavior
animate_movement isn't deprecated (although I doubt anyone uses SYNC_STEPS now that proper big mobs are available).
508.1291 was going to come out tonight, but unfortunately a family situation has come up. Expect 1291 tomorrow.
What does DSification mean?
In response to Sir Quizalot
"Dream Seeker-ification." Lummox JR means he's implementing features in the webclient to make it 1:1 parity with Dream Seeker.
Well to clarify that a little further, it's not so much about 1:1 parity as altering the very style of the webclient. The original design (back when this was meant for Flash) was for the server to handle all the map building and the client merely to get a list of icons. Hence it's a "thin" client.

That worked really well in small tests, but in large view sizes and large player counts we found it did not scale well. So what I'm doing is making the server handle these connections more like it does for DS, by telling it info about the atoms and appearances but letting the client do the work of converting those appearances to icons, sorting them, etc.

Stage 1 of DSification offloaded map sorting to the client, and achieved a big improvement in server performance. I'm in the middle of stage 2, which is a much, much bigger process.