Yes, really. It was snowing this morning, and we got a few inches of the stuff over last weekend.
Version 510 is chugging along and nearing its finalized public release. I'm just checking into a few more things here and there, but for the most part it looks like it's in pretty good shape. Finally. (I did get a crash report from Kumorii the other day that traced into one of the new map chunk routines, but it looks like heap corruption, and not necessarily an issue with the map chunks at all. Since it hasn't shown up again, I'll worry about it more if it resurfaces. Odds are it's not a chunk issue.)
The other day Ter13 brought up an old idea about chaining assignment operators together with side effects like you can in C and a lot of other languages. This struck me as a darned good idea and maybe possible to attempt at this point, so I got to work trying something out and found out I was able to do it. It needed a little more work for some edge cases, but I think it's solid. (Implementation details: The expression x=y has the value of y, not x, and x+=y and similar operators have the value of x, post-assignment.) Because there's a possibility of a compiler change this big impacting old code in some unforeseen way, I'm postponing the feature till 511. The good news is this long-hoped-for but pie-in-the-sky feature is finally coming; the better news is, this means I've officially started working on 511 features.
Space Station 13 and its cries for faster var access are on my mind, too, and I'm thinking that that will most likely be addressed in 511. With all the other upheaval 510 has had, this is probably a stupid time to rock that particular boat, so I'll rock the next boat instead. Flattening the var definition tree definitely had an impact, so I'm hoping that changing the way runtime vars are stored from linked lists to CPU-cache-friendly flat arrays will have an even better impact.
A new 510 release will be on the way pretty soon, but there's only one bug fix in the can for 1338 so I'll wait and see what else I can tack on there first. Expect the next release next week; 1337 is pretty darn stable at this point, so hammer away at your games with all the new features.
Don't forget to hit up the donation box or become a Member, if you haven't already. Our users' contributions have made all the difference in keeping development going.
ID:2066689
 Apr 8 2016, 12:28 pm
|
|
The code is semi-centralized, which for BYOND isn't bad. The problem is that these sorts of changes historically have a way of going south in unexpected ways, and that's not something I want to attempt just before 510 hits the point where it can be the new stable release.
| |
One day it's 16 degrees out the next it's -12.such Canada
| |
I'm just understandably frustrated because this means we are another 5 to 9 months away from datum var improvements. 1-2 months for 510 to go stable, 1-2 months of 511 coding, 2 to 4 months of bug fixes before you even get to datum var improvements as you fix bugs with assignment chaining and get your head stuck in the compiler (I've been there, I know), and maybe, just maybe, you won't decide its too close to stable, and will get to datum var improvements, and then 0.5-1 month of bug fixes for that before we can try it on production.
At the earliest (if made a priority) it's still 3 or 4 months away. But such is life I guess. | |
Happy to hear that Space Station 13 is being considered a priority in 511.
| |
Rockdtben wrote:
Happy to hear that Space Station 13 is being considered a priority in 511. Well, it is the main reason most people come to BYOND these days, besides the DBZ-Related Games | |
list[id]:proc_name("pls lummox")
| |
Lummox JR wrote:
The code is semi-centralized, which for BYOND isn't bad. The problem is that these sorts of changes historically have a way of going south in unexpected ways, and that's not something I want to attempt just before 510 hits the point where it can be the new stable release. I agree, the size of a change is much more than just the LOC involved. | |
I disagree, that's a change that should really be a 5 line change. given it might be more since i wouldn't be shocked if nothing around that was centralized, but 25 lines at the max. and its not like its hard to find everything that works with that data, you just comment it out, compile, and go after compiler errors.
Edit: actually everything around accessing that data would have to be centralized, because of how complex it is. So ya, 5, maybe 10 lines of code change, to change from linked list to array, delete the old linked list struct/class, and fix any compile errors, i don't really see what's so ground breaking and bug potential about that change.