OFFICIAL GML Consistency in GMS2 v2.2.2

kraifpatrik

(edited)
GameMaker Dev.
You know only if you write new code. But you can't know what exactly may be broken in projects you written some years ago (or someone else from your team, or especially in third-party code).
Ok so now when YoYo is actually having a look at years old broken code and they are fixing it, all you do is whine about it?

About the last 7 years I mostly use D, C#, Lua, and GML.
Then you sure know both C# and Lua allow for string and number concatenation without casting. I wonder why it's not a problem there (rhetorically, of course I don't really care).

I want GMS and GML became better, not worse.
We all want that. The fact that you can't see that YoYo is working on that is just baffling to me. Making GML behave the same accross the board definitely is a step towards better. Given your many-year experience I would expect you to know that making GML strongly typed is not just an on/off switch, especially not from a business standpoint, since GM has always been presented as easy to learn for newbies, hence the "forgiveness" (which is actually just a common feature of many weakly, dynamically typed languages). And I simply don't agree that such switch should be made. Maybe introducing a new language would be cool, but definitely not drastically changing the nature of GML.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Then you sure know both C# and Lua allow for string and number concatenation without casting. I wonder why it's not a problem there (rhetorically, of course I don't really care).
C# is strictly typed - adding a number to a string has the result strictly typed as a string, and the compiler simply won't let you assign that to any other type.
Lua has an explicit concatenation operator, to save the end user from that exact mistake. You cannot just do "1" + 1 - that's a runtime error.
A rare language that does both implicit concatenation via + and implicit conversion from string to number is JavaScript, but you know how that goes (1:30 and forward), and I had already described exactly what this results in
 
I

immortalx

Guest
Given your many-year experience I would expect you to know that making GML strongly typed is not just an on/off switch, especially not from a business standpoint, since GM has always been presented as easy to learn for newbies, hence the "forgiveness" (which is actually just a common feature of many weakly, dynamically typed languages).
Since there are languages that do have (in a loose sense) an on/off switch for that (visual basic), or gdscript with optional typing, I can't see why it wouldn't be a welcome feature for GML.
And I never really understood how the easier languages, like the ones mentioned, help beginners by being "forgiving". Well maybe at the baby-step level, but after that, its a constant source of frustration rather than a holding hand.
 

Pfap

Member
Since there are languages that do have (in a loose sense) an on/off switch for that (visual basic), or gdscript with optional typing, I can't see why it wouldn't be a welcome feature for GML.
And I never really understood how the easier languages, like the ones mentioned, help beginners by being "forgiving". Well maybe at the baby-step level, but after that, its a constant source of frustration rather than a holding hand.
Yes, while this is kind of off topic I just looked in the manual and saw this about ds_map_add():
This function should be used to add sets of key/value pairs into the specified ds_map. You can check this function to see if it was successful or not, as it may fail if there already exists the same key in the ds_map or you specify a non-existent ds_map as the id of the map to add to. Both keys and values can be made up of either integers or strings, so all of the following are acceptable:
It returns a Boolean true or false depending on whether successful or not.

I had written code that worked dependent upon ds_map_add() overwriting existing keys with new values. It was some frustrating debugging until I somehow discovered my error.

If the above is desired behavior it seems counter intuitive to me to return false and silently fail... why not just crash? I mean I get that there is probably a reason the map structure keys are not designed to be updated, but what's the use of returning false as opposed to crashing when someone tries to write to existing keys?



Edit:

Hours gone and simply calling ds_map_clear() before adding solved it.
 
Last edited:
I

immortalx

Guest
That's a different thing @Pfap , and it doesn't seem to me a matter of consistency. It was chosen for the function to return a boolean so that you can do basic error-checking. Sorry if it is something that I'm failing to understand.
 

Dmi7ry

Member
Ok so now when YoYo is actually having a look at years old broken code and they are fixing it, all you do is whine about it?
It wasn't broken. Inconsistent but not broken. And I happy that YoYo working on it. But I cry about their decision of silent conversion instead of to throw errors.

Then you sure know both C# and Lua allow for string and number concatenation without casting. I wonder why it's not a problem there (rhetorically, of course I don't really care).
YellowAfterlife already replied this.

The fact that you can't see that YoYo is working on that
GML changes is the first thing I follow in GMS.

Making GML behave the same accross the board definitely is a step towards better.
Sure. But silent conversion is wrong decision. I never will agree that 10 + "2DFnsjDFgd" should be 12.
@rwkay please, hear us. At least add a GMS option for us to disable such behaviour. I.e. always throw errors instead of silent converting.

And I simply don't agree that such switch should be made.
I never said that GML should be strongly typed. I said that evaluations between different types (string and number) should throw errors.
 

Pfap

Member
That's a different thing @Pfap , and it doesn't seem to me a matter of consistency. It was chosen for the function to return a boolean so that you can do basic error-checking. Sorry if it is something that I'm failing to understand.
Just that it is frustrating if you are expecting one thing and another happens.
 

kraifpatrik

(edited)
GameMaker Dev.
I never said that GML should be strongly typed. I said that evaluations between different types (string and number) should throw errors.
Maybe I'm wrong, but I think that is the definiton of strongly typed.

Well, I'm going to stop here. I don't need to make anyone embrace my opinions, I was just speaking out of my experience in which I don't remember getting into noticeable issues caused by types, rather than my own error. We all have different perspectives and I see that ours are just not going to meet in this topic, so I don't think we need to continue babbling. No offense intended or taken.
 

curato

Member
Also I want to point out that I have always found it odd that such dynamic casting is allowed but if I want to pass a variable to show_debug_message or similar function you better put string() around or you will almost certainly give an error when it is obvious here what you meant to do.
 

samspade

Member
As a relatively new coder (2 years) and a hobby coder with no formal training I'm probably close GMS main demographic. So for what its worth, allowing a variable to be a string or a number and to switch between (e.g. test = 5; test = "Hello") and not requiring defining different types of numbers such as int and float is great. It made a world of difference when I was starting and was a primary reason I chose GMS over another system (that and I wanted to do 2d). I don't think this should be changed (and I don't think anyone is seriously suggesting that it should be).

However, this idea that you could do 1 + “2” is crazy. I'm glad I didn't know about that when I started coding as it makes no sense, and if I had tried to do anything like that it would have caused more problems than solutions. Even if this is here primarily for backwards compatibility as Nocturn says, I'd rather that they removed it. Or if not removed it, at least didn't spend time working on it compared to all the other far more helpful things that are on the timeline.

That said, it probably won't affect me either way as I'm unlikely to work on group projects in the near future and so am completely in charge of my own code (except for assets from the market place). And overall YoYo makes a great product I'm very happy with so I'm not going to complain too much.
 

jonjons

Member
So for what its worth, allowing a variable to be a string or a number and to switch between (e.g. test = 5; test = "Hello") and not requiring defining different types of numbers such as int and float is great.
For me is also good
I was cheating on the ds_grids setting the field to "" then to 0 or 1..2..3..:D
In an inventory so the player couldnt see the items amount number text on screen
now using
var ThisGrid = ds_grid_get( gridNm, inv_scroll, 2 );
if ( ThisGrid > 0 )

returns an error " unable to convert string "" to int64 "

i had to change the "" to -1

iam using the beta, but some things are better now, then engine now trows an exclamation mark when a variable is not being used... witch is great for not letting variables lying around
 

jackquake

Member
Also I want to point out that I have always found it odd that such dynamic casting is allowed but if I want to pass a variable to show_debug_message or similar function you better put string() around or you will almost certainly give an error when it is obvious here what you meant to do.
For sure! I'm willing to bet several of us have a custom script like sdm(text,value) that casts the value to text to save typing. I know I do!
 

Smiechu

Member
What a hypocrisy... peaple mumbling how this issue is "unproffesional" but on the same time, without any shame or doubt they exploit i.e. the fact that under boolean values hide numbers 0,1 and mix them with other real numbers...
I would like to know what other languages allow these level of "proffesionality"?

I think that as long as the users have detail information and overview how things work under the hood, everything is OK. It's good that we are informed and don't have to guess what is going on...
 

8BitWarrior

Member
There is also a possible performance implication to be considered. The first value evaluated by an expression could determine the value types for the remaining variables in the expression.

For a time, there was a trick to achieve this with the YYC exports. By supplying a hard coded number into an expression as the first evaluated number, the outputted C++ code would be optimised to directly return a number type for all variables in the expression. A simple example looked like this....

x = 0+a+b-c+d-e;

The (0+) gives a hint to the compiler that we are dealing with numbers so, at compile time, it adapts the variables to directly return numbers instead of checking what type they are at runtime. Great!

This increased performance significantly. If I remember correctly, this gave one of my marketplace extensions a 25-30% boost (maybe more?) in overall performance. I was later informed that this was a bug. It was patched out with an eventual update.

Now I can see why it was removed. If you have the possibility for strings to be added like numbers (1+"1"), you can't have this optimisation. The trick above would cause an error when trying to get a number from a string. But, I'm going to argue that an error should occur.
 
Last edited:

curato

Member
I code a lot in VB for work. In that language I have the option of explicitly declaring a variable with a data type or I can use a variant on the fly that can be basically any data type I need it to be. Even then I almost always declare a specific type. About the only time I use a variant, it is called temp and I am just using it temporary storage for function or something it never escapes the immediate use. It may be a good idea to allow explicit declarations for the more experienced programmers and leave the use of variant variables in for the non programmers making games.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
i.e. the fact that under boolean values hide numbers 0,1 and mix them with other real numbers...
I would like to know what other languages allow these level of "proffesionality"?
You mean, like C/C++, Objective-C, D (...and most other C-like languages), PHP, JavaScript, etc.? Yeah, I guess you could say so. And pretty much every single low-level language, since, unless you are doing literal hardware design in VHDL/etc., boolean values aren't real - the smallest container size is 1 byte.

Would you mayhaps desire to attempt any research before calling hypocrisy in future?
 

gnysek

Member
ha!

I should call out at this time that there is a little-known quirk in GameMaker that the * operator performs a little differently when an integer is multiplied by a string. Then, the string is concatenated to itself times the value of the integer - so 3 * “9” results in “999”.
So, 7 years ago, on 2012-03-01 I've reported a bug:

Summary: multiplying string doesn't work in C++ runner
Description:
that code works in delphi runner:
6 * '-'
and it returns '------'
in c++ it sometimes works, sometimes crashes game
And the answer from YoYoGames was:
This is no longer supported.
It's a pretty stupid way to replicate a string, so it won't be fixed.
.

Interesting, that a feature which was removed came back at some point... great to see it again.
 

JeffJ

Member
Let's not derail the topic with such nonsense. He also made some incredibly unfortunate decisions - such as the skull fiasco, the marketplace reliance and many more.

As long as YoYoGames actually listens to our feedback, we will be fine.
 

Gradius

Member
The (0+) gives a hint to the compiler that we are dealing with numbers so, at compile time, it adapts the variables to directly return numbers instead of checking what type they are at runtime. Great!

This increased performance significantly. If I remember correctly, this gave one of my marketplace extensions a 25-30% boost (maybe more?) in overall performance. I was later informed that this was a bug. It was patched out with an eventual update.
Changelog:
Fixed bug causing excess performance.

o_O
 

8BitWarrior

Member
Changelog:
Fixed bug causing excess performance.

o_O
My thoughts exactly! xD
This has made it apparent how much performance is left on the table for YYC exports.
Now, I'm a big fan of having varying types as the default. There are plenty of times that I conveniently switch a variable's type between a number and string. But, having the option to declare types for select variables would be amazing. This could help enforce code consistency and improve performance. At the very least, I'd be happy with some sort of compile-time hint to let an expression know what type we are dealing with.

Just a quick example off the top of my head... ( This might be a bad idea! ^.^ )
num = 0;
(real) num = a + b + c;

Now, 'x' could still be a varying type and changed to a string later. But, for at least this expression, we've explicitly enforced what type we are dealing with. We can get performance gains AND guarantee what type we are dealing with.

I also want to add that although we don't always agree with YoYo's decisions, I believe they've done a good job of maintaining the vision set by Mark Overmars. It hasn't been perfect, but in the course of of GM's life, other engines have come and gone. Anyone remember Torque? Should YoYo listen to us? Sure! But, the product could just as easily fail if they try to please every voice they listen to.
 

GMWolf

aka fel666
Don't get me wrong, increasing consistency across exports is a GREST step forward.
However, A lot of people in this thread seem to be ignorant to the issues that come from mixing types in operators haphazardly.

Let's take an example:
We read in 2 text files from two different places using some mechanism or another (perhaps we are using JSON files and getting ds_maps).
We them sum those numbers together:
var value = map0[? "A"] + map1[? "A"];

Let's assume that because of the file format we chose, or loading method, the values in map0 are all Integers, but in map1, our values are strings.

Now variable 'value' is an integer, and gets to be used to index arrays, change an objects position, etc.

Now as we keep developing our game, and testing it with our files, we see no issue as map0 produces integers and map1 produces strings.


Now later in the project, we choose to change one of our files, and instead of having map0 be integers, map0 now produces strings.
Worst! Lest assume we shipped the game and a client decided to change the values.

Now rather than our variable being an integer, it's a string, and as it gets passed through the project it's converts a bunch of other variables to strings !
Horror! We could get a string related issue that is now very hard to debug, as the actual string "Misuse" could be very far away from our file parsing.

Worst again; it cod even not show up as an error, but absolutely tank performance!
The string could get passed around, and GM could be doing checks to see if its Integer-Like every time we use it. In a tight loop, that could grind our game to a halt.
Just changing that one file could do that, and boy or boy are you in for a debug session when you are apparently doing he exact same operations as before, but with a different file, and yet your performance gets slashed in half.
 
Last edited:
I'm just going to throw my two cents here and say I think this is a horrible decision. When I originally bought GMS2, with all the code editor/GML improvements, I assumed typing was going to be made more strict - not less. At least, that seemed to be the way things were headed originally. @gnysek's quote assures me I'm not just going batty and that was, in fact, the original direction for GML. If I would've known this was where GML was headed, I wouldn't've bought GMS2. It doesn't look like I'll be moving to GMS3 at this rate. Very disappointed in this.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
GML has not been made more nor less strict than it has been since at least GM7... It has simply been made consistent! Please understand, that this behaviour has been a part of the language for a long time.
 

JeffJ

Member
I think we all understand that. That doesn't change the fact that steps are actively being made towards what it seems that the general user base here considers a worse result - for many reasons stated in this very topic.

At this point I think it would be worth listening to what people are saying in here, rather than just going for consistency for consistency's sake. There's no need to go further down a bad road if it can be avoided.

I would love to see some counter arguments from core tech besides consistency - because a lot of very good and compelling arguments have been made in here.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
You are being listened to, but before actions can be taken, things have to work as they should. GML will be getting some pretty major updates in the future, as has been mentioned in the roadmap I believe, but before that can happen, the current iteration of the language has to work correctly and consistently. All I'm saying is that there seems to be a lot of "this is terrible" going on here, and a lot of people talking as if this was a new feature and a major change to the language, when it's not. It's simply making it consistent and preparing the ground for future features to come.
 

JeffJ

Member
They're not just "this is terrible" posts, though. They're real examples of how this can and will definitely cause issues in many different areas, especially debugging and even performance. Take your pick from any of the more detailed posts in here.

And given the current discussion, the upcoming GML changes you mention can be read as even more worrying, given that the current topic is evidently not very positively received. Perhaps if we had more transparency as to what kinds of changes this groundwork is laid to accommodate, it would be easier to accept something rather negative as a necessary evil. But without such information, we can only react to what we have now - which is what you're seeing.
 

gnysek

Member
GML will be getting some pretty major updates in the future, as has been mentioned in the roadmap I believe
If it's for garbage collector and resource types instead of ids - then I'm in.

But, at beginning of GMS1.0, there was a lot of language features about which YYG said "we're not gonna do it this way", and hey, now they're in or back (lot of those issues were reported on Mantis, but all those tickets either vanished or are private, and there's same amount on helpdesk). Also, some were mentioned 2-3 years ago as "YYG gonna add it" and they seems to be forgotten now.

So... maybe GMS2 is going to be consistent, but not according to GameMaker as whole, but to some latest roadmap as it seems company is changing it's mind every several months. This "consistency" seems to change too often to be consistent.

I understand that this change was dictated by easier code management (as generally all runners are based on some kind of C/C++ languages, or at least very similar implementation of "atof"), and it have sense, but as it's a "first step" to some bigger changes, it gonna only provide some mess for now, until those "bigger changes" also apply (in 1/2/3 years?).
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
Hey folks, we are watching and listening. With this, we have our larger picture for GML and we will be looking to communicate that better before it all lands. After GDC (as this is always a busy time for the team) we will sit down and lay out some of our plans for GML and why this change came upfront. We will then use that plan as a jumping off point for discussions and an AMA on the GMC with Russell. Hopefully, that will clear up why we are here and why we believe this is best for GML going forward. So please prepare some questions for Russell! As always, we really value your feedback. Thanks.
 

FrostyCat

Redemption Seeker
Hey folks, we are watching and listening. With this, we have our larger picture for GML and we will be looking to communicate that better before it all lands. After GDC (as this is always a busy time for the team) we will sit down and lay out some of our plans for GML and why this change came upfront. We will then use that plan as a jumping off point for discussions and an AMA on the GMC with Russell. Hopefully, that will clear up why we are here and why we believe this is best for GML going forward. So please prepare some questions for Russell! As always, we really value your feedback. Thanks.
If you are looking to communicate this better, release the test suite you're using to verify the new typecasting behaviours. And if there isn't one, I won't buy into any salesman talk about it being "well-tested" or "consistent" until there is one, and neither will most objectors on this topic.

I recently read Mike's post on why he quit YoYo, and in it he described how the primary means of testing GM is just running a library of existing games. This is an abject failure in terms of testing since game projects don't typically cover the entirety of the GM engine (or even a specific section of it), and human error and reflexes give bugs even more room to hide. No wonder YoYo misses a whole host of valid use cases whenever it releases a new runtime.

On a slightly unrelated note, just the other day I was preparing an argument against a book author about using self, and noticed this inconsistent handling in GMS 2:
Code:
show_debug_message(self);
show_debug_message("self: " + string(self));
The first showed an instance ID (unexpected new behaviour), while the second showed -1 (expected legacy behaviour). This is one area that YoYo developers have said they've "made more consistent" in the past, but now turns out to be completely inconsistent.

It's these kinds of oddities that objectors here are concerned about, and when you ask for our understanding and peace of mind, we need specific, targeted code-based evidence of what your reassurances are based on.
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
Looks like you've got your question sorted!

Mike said a lot of things. :D We have always had more than simply running projects to test GameMaker but this full comp test suite somewhat new and once it's cleaned up and slightly more presentable we fully plan to release it publicly and accept community modifications.
 

Tsa05

Member
@rmanthorp glad to hear there's a test suite of sorts, but I encourage YYGs to have a look at the engine linked in my signature (should be free to all of you--it's on your marketplace ;D)
I mention it simply because through the process of developing this system of presenting a visual interface and storing/loading information about GMS assets, I uncovered several dozen bugs over the last couple of years, mostly appearing in your Mantis system as being filed by yyg employees. Some of the bugs I uncovered were fixed, then re-emerged in similar forms, even on the same built-in functions.

I think what I've made is actually weirdly important from a target audience point of view--I'm not a well-trained programmer, but have used Game Maker since 2003, making me a sort of ideal blend of "playing frequently and deeply in GMS" mixed with "no clue whether I'm doing this in a technically right manner." As consequence, I've produced a hybrid engine and editing tool that uses an alarming percentage of GMS functionality, and in ways perhaps unexpected or unintended. In every build of gms in the past 3 years, I've been able to launch my project in Windows and HTML5 and immediately encounter differences in behavior or outright bugs. Consider it a free test suite ;D
 
S

Sam (Deleted User)

Guest
Honestly I find it sad that YoYoGames actually thought this would be received well and then look at every comment in this topic lel
 

GMWolf

aka fel666
Honestly I find it sad that YoYoGames actually thought this would be received well and then look at every comment in this topic lel
I think it was mostly received well.
Most people seem to agree that making exports more consistent is a good thing.

What people are expressing is how terrible the current operators are and how they should be changed. (Perhaps even that rather than making it consistent by having all exports support that functionality, they should have made it more consistent by not supporting it).

They are pointing out how fund this GML feature is in hopes it will be deprecated, and eventually removed.
(I would recommend deprecating it next update, and wait untill a major revision (akin to 1.4) to outright remove it.)
 

Dmi7ry

Member
I think it was mostly received well.
Most of people just don't understand (because they're had no such experience) what this change threatens.

Most people seem to agree that making exports more consistent is a good thing.
None of us are against consistency. We are against silent conversion instead of throwing errors. Personally I am (and some other people) also against of 3*"10" behaviour.
 

FrostyCat

Redemption Seeker
I think it was mostly received well.
Most people seem to agree that making exports more consistent is a good thing.
It has been and will be received well by inexperienced users and monolinguals. A common characteristic of objectors on this topic is that they all have experience with at least one other language where similar attempts to forgive type mismatches have backfired, most notably Javascript. It's tyranny of the majority.
 

GMWolf

aka fel666
It has been and will be received well by inexperienced users and monolinguals. A common characteristic of objectors on this topic is that they all have experience with at least one other language where similar attempts to forgive type mismatches have backfired, most notably Javascript. It's tyranny of the majority.
I think you are missing my point;
I don't think anyone is saying that making things more consistent is a bad thing.
And I think even experienced users will agree that having GML act the way it is designed to with each export is better than having those features in the language, but only have them supported in some exports.
This topic was about how these features where made more consistent.

What isn't well received is what this topic was NOT originally about; the GML features.
 

FrostyCat

Redemption Seeker
I think you are missing my point;
I don't think anyone is saying that making things more consistent is a bad thing.
And I think even experienced users will agree that having GML act the way it is designed to with each export is better than having those features in the language, but only have them supported in some exports.
This topic was about how these features where made more consistent.

What isn't well received is what this topic was NOT originally about; the GML features.
What isn't well received is the approach YoYo took to make things more consistent. They could have done the consistency in a way that points out bad code and improper states of execution, but instead they did it in a way that tries to forgive bad code, does it badly and turns it into a potential landmine.
 

gnysek

Member
So, but about this "consistency"... are strings typecasted to integers or reals ? cause it seems to convert in two different ways depending on there's a string added to number or real() function. What's fun, real() throws fatal error on disallowed characters, while string conversion just skips them.

upload_2019-3-10_23-43-5.png

I'm not a native English speaker, but this doesn't seem to be "consistency" from what I learned. It's definitely far away from what this word should mean.

(* I've already checked using comma instead dot as decimal part separator, as this was always a common issue in GameMakerStudio, that every new feature used "regional settings" of Windows instead of dot only...).

and this is "consistency" table ;)
upload_2019-3-11_0-54-12.png

not sure with last one, for now blog post says it still should be an error, but if we go to typecasting way, I think it should return rather "1.01.1" string than error to be consistent in both ways, not only one (as in javascript for example).
 
Last edited:

FrostyCat

Redemption Seeker
So, but about this "consistency"... are strings typecasted to integers or reals ? cause it seems to convert in two different ways depending on there's a string added to number or real() function. What's fun, real() throws fatal error on disallowed characters, while string conversion just skips them.

View attachment 23584

I'm not a native English speaker, but this doesn't seem to be "consistency" from what I learned. It's definitely far away from what this word should mean.

(* I've already checked using comma instead dot as decimal part separator, as this was always a common issue in GameMakerStudio, that every new feature used "regional settings" of Windows instead of dot only...).
This is exactly the kind of counter-evidence I'm looking for. I'm virtually a native speaker, and this is not my sense of "consistency" neither.

For posterity, here is the rule that YoYo is purportedly using:
A string will be converted to a number at runtime IF it starts with a valid number i.e. begins with a digit or ‘+’ or ‘-‘. The number is then parsed up until the last non-number character. NOTE: number conversion is treated as floating point number conversions and follow the rules for the C runtime function “atof”, which is documented as “A valid floating point number for atof using the "C" locale is formed by an optional sign character (+ or -), followed by a sequence of digits, optionally containing a decimal-point character (.), optionally followed by an exponent part (an e or E character followed by an optional sign and a sequence of digits).”
The decimal point has clearly been treated as the "last non-number character", even though such treatment directly contradicts the atof definition that the "consistency" scheme is supposed to follow. If this was in the test suite, then someone would have to ignore it out of malice or haste for the build to have gone live.

So that others can easily replicate the result, here's gnysek's counter-example in copy-and-paste form:
Code:
show_debug_message("Consistency - the truth");
show_debug_message(1 + "2.2");
show_debug_message(1.0 + "2.2");
show_debug_message(1.1 + "2.2");
show_debug_message(1 + real("2.2"));
And the result on Runtime 2.2.2.314 (latest Beta as of the time of writing):
Code:
Consistency - the truth
3
3
3.10
3.20
 

gnysek

Member
The decimal point has clearly been treated as the "last non-number character"
That's probably because latest beta is converting to integer, not real:

upload_2019-3-11_1-0-21.png

So... maybe it's not included in beta, or they changed their mind since blog post ? :D
 

FrostyCat

Redemption Seeker
That's probably because latest beta is converting to integer, not real:

View attachment 23588
I wouldn't arrive at that conclusion. My take is that the "consistency" scheme would start by assuming an integer, but change to real if it finds evidence later in the string that suggests otherwise (i.e. a decimal point or an exponent). If this changeover doesn't happen, then that will explain the outcome of your counter-example.
 

XanthorXIII

Member
I think YoYo Games just needs to dump the old baggage, stop encouraging bad programming practices which is what this is doing and move on to enhance GML with stuff we actually need. Being able to do 1 + "2" is non-sense and I don't see why anyone would want to do that or need that. The old versions of GameMaker are dead, stop trying to make Zombie's out of them.
 

gnysek

Member
I think YoYo Games just needs to dump the old baggage, stop encouraging bad programming practices which is what this is doing and move on to enhance GML with stuff we actually need. Being able to do 1 + "2" is non-sense and I don't see why anyone would want to do that or need that. The old versions of GameMaker are dead, stop trying to make Zombie's out of them.
Yep, 1+ real("2") heave more sense, and number + string should just always throw errors on both YYC and non-YYS.
 

TrunX

Member
Thats also an example how an error (missing decimals) could be overseen during short gameplay tests and only much later after working on something completely unrelated the effects could become visible to the developer and he will spend a lot of time to find the cause starting with analyzing the code he has implemented recently but has nothing to do with the rounding errors.
 
Top