In response to Lummox JR
Lummox JR wrote:
Updating byond_version to include it definitely is not feasible. There isn't enough fidelity in the floating number point format to allow for that, and because build numbers are not necessarily fixed at 4 digits but can increase indefinitely, representing the build as major.minor in a number would not work even if the numerical format allowed for it. It has to be a separate var.

Whats wrong with adding a second variable like what was mentioned in the thread? If you ever got over build 16777216 then you have bigger problems. At that point, if we somehow ever got there, we'd likely have different types of numbers.
In response to Somepotato
Somepotato wrote:
Lummox JR wrote:
Updating byond_version to include it definitely is not feasible. There isn't enough fidelity in the floating number point format to allow for that, and because build numbers are not necessarily fixed at 4 digits but can increase indefinitely, representing the build as major.minor in a number would not work even if the numerical format allowed for it. It has to be a separate var.

Whats wrong with adding a second variable like what was mentioned in the thread? If you ever got over build 16777216 then you have bigger problems. At that point, if we somehow ever got there, we'd likely have different types of numbers.

In response to Lummox JR
Lummox JR wrote:
Updating byond_version to include it definitely is not feasible. There isn't enough fidelity in the floating number point format to allow for that, and because build numbers are not necessarily fixed at 4 digits but can increase indefinitely, representing the build as major.minor in a number would not work even if the numerical format allowed for it. It has to be a separate var.

So to clarify, is this also rejecting the proposition of creating a new var to hold the minor?
This is the old request. I think it makes way more sense to discuss the situation on the newer thread.
Lummox JR changed status to 'Open'
Oops, didn't realized these threads got merged. Never mind. I've changed this request back to Open.
what's there to discuss though? this is a necessary feature for the enhanced stability and support of servers using beta builds. users using outdated beta clients can impede on testing of beta servers.
well not even just that, knowing if a user is on stable release that has a new maintenance release that fixes a bug is helpful too.

Or did everybody forgot what happened when 509 went stable
Still waiting for this to happen at some point. It helps you be very specific to what version you want people to use. There have been many times where new big features were in a minor build, not a major.
I support the idea discussed in the OP. Lets make this happen guys.
i would like to pledge $28 dollars for this feature
Since I got merged into your thread and opened it back up, I guess I'll take part.
I'll match that pledge.
So we had a confusing bug report on /tg/ that was hard to reproduce because it turned out the user was using an out of date version of 511.

So i'm bumping this and adding $19 to pool to make it an even $75
Adding a byond_build var to world and client. Won't be available (reads as 0) for pre-512 clients or (of course) pre-512 .dmbs.
will donate $28 as soon as I get home. what about a DM macro? this is useful for telling us how the game was compiled.
the dm macro is needed, there have been #define altering changes during minor updates. Would let us better support those changes during beta testing if we can better #if behind them.
Agree with the DM macro but thanks Lummox for the byond_build var. Donated <3
i actually forgot to donate until mystery posted. so i donated just now. macro pls
Better late than never. Thank you!
Lummox JR resolved issue with message:
A byond_build var has been added for world and client. The world.byond_build var provides the build number for the server. This var is 0 if an older client is connected, since that information is not available.
Page: 1 2