ID:2109265
 
Happy Canada Day to our friends in the Great White North. The timing this year means this is a three-day weekend not just for them, but for us here in the USA. Our turn for fireworks will come soon enough. And for all of us 'Mericans: happy Independence Day. (But not happy Independence Day: Resurgence, apparently. I heard that was a bomb.)

I've made some really good strides on version 511 this week. Mutable appearances are in. I kinda hate the type path /mutable_appearance, so I'm still trying to figure out if I have any good alternatives. I had some doubts at first about how to go about this implementation; the easiest way seemed to be making them a special type like /list or /savefile, but then I thought: No, that's stupid. I want to move away from that direction. In the end I decided they should derive from either an atom type or /image for easy access to all the vars, and I went with /image.

As part of that, I did look a little bit into the notion of eventually moving /list into a datum realm, so they could have user-defined vars and procs--even overridden procs. The short answer on that is I'm still not sure how it'd work. I don't see it as a 511 thing, but I'll keep an open mind.

Independent client-side FPS is in. You can now set client.fps to something higher than world.fps, and you'll get smoother results for animations and gliding while keeping the server ticking along at a lower rate for performance. Setting client.fps or client.tick_lag to 0 will tie it to the server's FPS, like it always was before. (Edit: One thing I still have to do here is add a glide for pixel-movement environments, so that when sliding it doesn't get all jumpy.)

I've also done some work on an age-old thorny problem that SS13 has in which verbs that are exposed to the client, then removed, cause problems for statpanel displays and right clicks. Basically when trying to build a statpanel verb list, verbs that the client knows about but have been completely removed from accessibility still get checked--on every stat tick. This accessibility check gets slower the more objects are on the screen, and the more verbs it can't find. My new concept includes a var that says the verb may be accessible, and if no object on the client is found to have it at all, the verb is marked as not in use, and won't be rechecked until a map update that has an appearance using that verb. Result: removed verbs should only cause a slight slowdown one time, rather than on every single stat tick.

Per the ongoing discussion in the last news thread, it's clear that filters are still way too much in flux syntax-wise; I don't think they're going to be viable for 511, not with the goal of getting it out at a good time. It's actually time I start pruning down the list of potential features and start saving more of them for 512, although quite a number of them are doable after the first beta and can still go into the 511 series. One of the ones I still want to target for the first release, though, is 200% map zoom. There are also a few bugs on the list I still want to look at in the hopes of incorporating those into the first beta.

As things stand right now, I need to get back to the task of buttoning up gamepad foo. I'd like to setup some kind of rudimentary mapping interface that people can use for their gamepads, and during the beta I'll solicit results from people on their different gamepads to build up a default map file.

Ideally, I want to get the first 511 beta out this month. I think that's a reasonable goal, especially with the inevitable shunting of some issues off to 512. SS13 is waiting on a number of upgrades, and I know EPΘCH and Lux are pining for gamepad support. So the sooner I can get those in, the better. And I think going with a smaller set of new features than 510 had is probably a good idea all around for stability's sake--there's still plenty of new feature goodness.

Here's hoping everyone has a great weekend. Get your fill of fireworks and barbecue, and while you're avoiding your extended family be sure to get your game on. If you get any good fireworks pics, share 'em here.
Independent client-side FPS is in.

Very nice.

I appreciate your work ethic. Even with all of the engine's flaws, you keep moving forward in efforts of salvaging what was left in your hands when many of us would have went an entirely different route. That is a very honorable characteristic.

I don't have any extra to donate at the moment since most of my funds go toward investing in my project. But believe that Byond will see a piece of the return when we release.
Nearly flipped out when I saw independent client-side FPS is in, and 200% map zoom mentioned. The whole update is all kinds of great news really, but so happy about those.

I wonder though... I do recall the gamepad support method having some relation to interface macros, so any chance of support for multi-button macros working its way in too? I know there are ways to do that ourselves when we make our own keyboard handling, so I am not too concerned about it, but it would be nice if it's a simple improvement to do.

My wording there is questionable, so just in case I am referring to something like say... X to attack, C to strong attack, X+C to special attack.
Independent client-side FPS

How does this interact with command rate?

In games, there are 3 rates to consider:

Tick Rate (how often does game state tick along)
Command Rate (how often are clients notified of changes)
Draw Rate (fps, how often are new frames drawn on screen)

I was wondering how these now interact with clients having higher (or lower) fpses.
Once client-side FPS has pixel-movement gliding, my BYOND life is one step closer to complete. Matter of fact, it could be complete at that moment.
After client-side FPS, all I wanted was better client-side UI (which could be done now with the webclient) and shadowcasting for multiplayer (which could be done with soft-code, though I'm not sure if it is worth it yet, still testing the fastest ways to go about that). Hurray!
Lummox JR wrote:

Independent client-side FPS is in.
Ideally, I want to get the first 511 beta out this month.

Best Canada day ever, looking forward to seeing what you can give to us dev's by the end of July. Keep up the good work.
In response to Toddab503
Toddab503 wrote:
I wonder though... I do recall the gamepad support method having some relation to interface macros, so any chance of support for multi-button macros working its way in too? I know there are ways to do that ourselves when we make our own keyboard handling, so I am not too concerned about it, but it would be nice if it's a simple improvement to do.

Two-key no, and key+button no, but two-button should be supported in this system.

My wording there is questionable, so just in case I am referring to something like say... X to attack, C to strong attack, X+C to special attack.

There is of course a downside to that: The button-down on X would be considered a separate event. It may be preferable to implement something on the server side to catch button presses within a short time of each other.
In response to MrStonedOne
MrStonedOne wrote:
Independent client-side FPS

How does this interact with command rate?

In games, there are 3 rates to consider:

Tick Rate (how often does game state tick along)
Command Rate (how often are clients notified of changes)
Draw Rate (fps, how often are new frames drawn on screen)

I was wondering how these now interact with clients having higher (or lower) fpses.

Actually "command rate" isn't a thing in BYOND.

Basically, there's just server tick rate and client tick rate.

Map updates are sent every server tick, and that's also when verbs are processed. The map is redrawn (if necessary) every client tick, which is when animations get updated.
Mutable appearances, clientside fps, and a possible fix for right click latency?! It's like literally all my long held wishes are being fulfilled.
How does this work with animate() though, doesn't animate() pregenerate all appearances? Is animate() appearance generation now clientside?
doesn't animate() pregenerate all appearances?

Point. How ever infinite looping animate()tions fair well when fps changes, so i'd assume the appearance generation has been client side for a while now.
On this note, how does glide_size fair? if clients have different fps they would see different gliding, and that might not be desirable.

(all the more reason to change it to glide_time =P)
In response to MrStonedOne
MrStonedOne wrote:
On this note, how does glide_size fair? if clients have different fps they would see different gliding, and that might not be desirable.

(all the more reason to change it to glide_time =P)

glide_size is in server ticks, and therefore is scaled on the client as appropriate.
while you're in there, It might make sense to let us detect cases where the client isn't rendering on time, and lower their fps, as i've noticed that on slower computers, putting fps higher than the client can do causes it to do much worst than what they can handle. (ie, if they have shutter at 40fps, it ends up dropping to like 11fps, but 35fps renders fine)
In response to Clusterfack
Clusterfack wrote:
Mutable appearances, clientside fps, and a possible fix for right click latency?! It's like literally all my long held wishes are being fulfilled.

Now if we can just be good little boys and girls until Christmas, maybe Santa Lummox will leave us client-side effect processing under our Christmas trees!

I'll believe in Santa for as long as I need to. I've been a good girl all year, I pwomise!
Lummox JR wrote:
/mutable_appearance

Could always shorten it to /mutapp or something like that.
In response to LordAndrew
LordAndrew wrote:
Lummox JR wrote:
/mutable_appearance

Could always shorten it to /mutapp or something like that.

Ter13 talked me out of /mutappearance on very sensible grounds.
Any chance of implementation of libcurl so that we can communicate over ssl?
Libcurl is on my list to look at, but I'm aiming for later in the 511 series so that I can focus on getting the stuff out that needs to be in the first release (for syntax and network protocol reasons).
In response to Lummox JR
Lummox JR wrote:
Libcurl is on my list to look at, but I'm aiming for later in the 511 series so that I can focus on getting the stuff out that needs to be in the first release (for syntax and network protocol reasons).

Awesome, thanks!