Despite coming down with a nasty cold this week, I've actually made pretty good progress on version 510, and I think we're on track for a release next week.
The new KEEP_TOGETHER and PLANE_MASTER flags are in place, as is another new one called KEEP_APART. It turned out that being able to split off overlays that didn't belong with the group was kind of a big deal, and so I had to implement it. More testing is needed in this area, but it's looking good. I posted a screenshot of an early test on PLANE_MASTER recently, and it's attracted a lot of interest.
At the moment I'm working on getting those features to work as best they can in software mode. BLEND_MULTIPLY is very much not supported, which rules out fancy lighting for people using software rendering, but there's really no reason this concept of KEEP_TOGETHER can't work at least.
One of the things I'm considering changing is making a virtual KEEP_TOGETHER whenever maptext and an icon are used at the same time. My reasoning here is simple: they've always been meant to stay together. This does require a change that would probably be welcomed by a lot of users: full transforms would now be available for all text, not just translations but also rotations and (though I think it'd look horrible) scaling. This part's still in the consideration phase, and I'll probably shelve it till later in the 510 series.
Testing on a million little things is still needed, but on the whole that, and the aforementioned software mode rendering, are the main obstacles left. The webclient as I mentioned before will have to wait for 510's new rendering features, but they'll come along in good time; mostly I want to get 510 out in beta first.
This week I also added world.tick_usage, to help worlds that do a lot of complex, processor-intensive tasks to hopefully plan a little better. I've also been working with MrStonedOne on an issue impacting Space Station 13 when lots of players are on, and it seems like there's a very very ancient bug in the tick code that can cause serious map delays when the server is under stress. An initial fix for that will go in the first 510 release, and it may merit tweaking as new data comes in.
Keep the donations coming, and if you haven't become a Member yet, I hope you consider doing so soon. If you like the looks of all of 510's new features, ransacking the couch can help keep this kind of thing coming.
ID:2022649
 Jan 22 2016, 10:12 am
|
|
MrStonedOne wrote:
tl;dr: If world.cpu hits above 120, byond stops client map updates for 1.6*world.fps ticks (basically 1.6 seconds worth of ticks) causing the appearance of lag. if more ticks over run during this time frame, it would extend the lag. No, they won't extend the lag, but they'll keep the rolling average high which can cause the lag to recur once the countdown expires. The countdown, once set, grinds down to zero and is not increased. | |
It would extend the effective time frame of the lag, as it would cause ticks to fire less often.
so 1.6 seconds of ticks becomes 3.2 seconds if say every tick overran for double. | |
MrStonedOne wrote:
I've also been working with MrStonedOne on an issue impacting Space Station 13 when lots of players are on, and it seems like there's a very very ancient bug in the tick code that can cause serious map delays when the server is under stress. Interesting, this fix might actually address the lag I've been seeing myself. Happens when switching rooms in Lux, where the CPU often hits above 100. Only happens on large room loading as well, and does last approximately 1.6 seconds every time it happens. The game actually runs and processes before that, but the client doesn't show it until that delay finishes. Yet another reason to be hyped for 510. =D | |
Any chance of seeing another beta build today? Most things I want to do are blocked on the current bugs.
| |
Yes, I'm planning to release today. I would have done a release yesterday but it got too late; fortunately one of the outstanding bugs has a demo case now for me to look into.
| |
tl;dr: If world.cpu hits above 120, byond stops client map updates for 1.6*world.fps ticks (basically 1.6 seconds worth of ticks) causing the appearance of lag. if more ticks over run during this time frame, it would extend the lag.
This was apparently supposed to scale, only getting to 1.6 seconds under really bad load, but a bug cause it to only do 1.6 seconds, on light overloading and heavy overloading alike.