ID:1888246
 
It's been a crazy week, but I'm pleased to report that the webclient DSification is at the point where I'm now testing the messages (and running into myriad failures, but that was expected) for basic map display. I took some time earlier in the week to port the view code used by Dream Daemon and Dream Seeker into the webclient, in the hopes that I'll be able to put it to use and avoid calculating view server-side at all (except for interpreting commands). No ETAs on when phase 2 of DSification will be complete, because it's still a long process. Next week promises to be painful with all the debugging I'll be doing, hence the title of this post.

Development was slightly interrupted this week by a family emergency, but there were two releases anyway. If progress seemed a little slow this week, that's why.

As of the release of 508.1292 today I finally upped the map cell limit, because I'm convinced the old limit is the actual cause of a bug report pertaining to 1290+. Memory-wise this should take only 25% more than 1289 did, which is to say +1 byte per turf. Not a bad tradeoff.

1291 included an improvement to the A* pathfinding algorithm, in the hopes that it will degrade softly instead of sucking CPU cycles when paths can't be found.

There's a big web-side fix for the pager today, too. For some reason the info for libraries was being sent back in a format that the pager didn't recognize (probably I made an ill-advised change during the last minor site overhaul), which impacted library installation. Oops. If your pager's still acting funny with libraries, just delete localhub.db (with the pager closed of course) and let it rebuild.

Although there's a lot left to look into for 508, I'm still looking ahead to 509. These are things I'd like to accomplish in 509:
  • Flags to reset color, alpha, and transform on an overlay (implementation suggestions are welcome; see id:1763636 and please share any ideas there)
  • Floating point glide_size and gliding
  • Optional linear interpolation of matrices
My idea to have a higher client-side FPS rate, different from the tick rate of the server, is still on the table. In fact I've gone so far as to add a var for it to the webclient in anticipation, but the webclient has to be fully DSified first. Also I've been thinking how it'd be nice to allow animate() to handle more complex transform transitions (e.g., being able to form a spiral), but the ideas I've had for that kind of suck. I'm sure it'll percolate. And SIDE_MAP and ISOMETRIC_MAP sorting really need to be done topologically, which I've been planning for some time and hope can be done in the medium-term.

Ban foo to benefit big games like SS13 is still on the near horizon; I've just had too many other distractions to finish it up yet. I've had a few small (read: doable without a huge overhaul) requests for the site that I can look into eventually too, hopefully sooner rather than later.

I'm not in Massachusetts getting ready to watch a lot of amateur fireworks on my favorite beach, so that's always a disappointing end to the 3rd. But I hope all my fellow Americans, and everyone else who celebrates the 4th just for the heck of it, have a happy holiday. And happy belated Canada Day to our friends from the north.
Very nice, can't wait to see how it turns out.

I've been experimenting with the webclient for library development. Still thinking about using Emscripten for some other experiments.

I don't plan to do any work tomorrow due to the fact I will also be celebrating the 4th of July. When I get back to work, I'll look into Emscripten like I said.
Hope your 4th was decent enough. I spent the day at a lake eating, drinking and blowing stuff up. Good times. Go USA.

Thanks for the update!
Lummox JR wrote:
My idea to have a higher client-side FPS rate, different from the tick rate of the server, is still on the table. In fact I've gone so far as to add a var for it to the webclient in anticipation, but the webclient has to be fully DSified first.

Is client-side FPS rate only going to be for the weblient? O.o
Is client-side FPS rate only going to be for the weblient? O.o

No, he just said he's prepped the webclient for it first. The webclient has gone through fewer hands and has the benefit of being written to serve an existing design from the ground up, so I'm sure Lummox has a much easier time navigating the internals of the web client than the C core.
Indeed, my plan is for the client-FPS to be for DS and the webclient both when the time comes.
I've gotta say, the webclient's come a long way already. Great job, Lummox.
In response to Konlet
Switch 'already' with 'finally' and you'll have my opinion on it. I don't exactly remember when development first began(as it was a 'java client' originally), but it's been a painfully long and drawn out process. The mast of the public progress has happened relatively not long past, which I'm sure Lummox being solely at-helm and not being a back-and-forth progress has done quite a bit for development.
It was a Flash client to begin with actually, and the internal code still mentions "Flash" everywhere. But it was put on the back burner a number of times to deal with other, more pressing issues.
In response to Lummox JR
I was trying to remember what it was called and couldn't quite remember, I stand corrected. I remember a summer a couple(maybe three?) years ago, where Tom posted with expectations of the 'Flash' client being released by the end of the summer. Your two's various posts on future features that've yet to come to light are probably my biggest source of woes. I actually put a few things on my back burner for thing Tom said would be coming 'soon'.
I actually put a few things on my back burner for thing Tom said would be coming 'soon'.

Tom said not to do exactly this repeatedly and loudly.
In response to Ter13
I learned not to follow that rather quickly, but I don't recall Tom every saying 'coming soon' could be 'never actually gonna happen'. I figured, at worst, I'd have to wait a few months.
Well, you also have to understand that the time when they chose to develop the Flash client happened to coincide with the death of the platform. They considered a Java client (I have a hidden for security suggestion to prove it.) and they were convinced to transition to the HTML5 client less than 2 years ago after a long private conversation on the merits of HTML5/webgl as an emerging technology in the moderator forums. Tom didn't want to do it at first, but the more he looked into the competing technologies for a no-install embeddable platform for the client, HTML5 became the only obvious choice.

The Flash client never happening was bad luck, as Tom picked a losing technology he couldn't have known was going to die on him. It was 99% penetration and then suddenly disabled by default by almost every major browser.

Same thing happened to Java. Massive market penetration and then sudden catastrophic death at the embedded end due to mismanagement by Oracle.

Tom bet on a winning horse months before better technologies and emerging trends murdered it mid-gallop. You can't blame the guy for recognizing that adopting a dying technology would lock us into that technology (Though... The fact that we're stuck on GDI and DX is still problematic, but w/e).