1. Hello Guest! It's with a heavy heart that we must announce the removal of the Legacy GMC Archive. If you wish to save anything from it, now's the time! Please see this topic for more information.
    Dismiss Notice

OFFICIAL GML Consistency in GMS2 v2.2.2

Discussion in 'Announcements' started by rmanthorp, Feb 20, 2019.

  1. kraifpatrik

    kraifpatrik Member

    Joined:
    Jun 23, 2016
    Posts:
    132
    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?

    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).

    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.
     
  2. YellowAfterlife

    YellowAfterlife ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    2,439
    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
     
  3. immortalx

    immortalx Member

    Joined:
    Sep 6, 2018
    Posts:
    295
    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.
     
  4. Pfap

    Pfap Member

    Joined:
    Apr 30, 2017
    Posts:
    551
    Yes, while this is kind of off topic I just looked in the manual and saw this about ds_map_add():
    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: Mar 1, 2019
  5. immortalx

    immortalx Member

    Joined:
    Sep 6, 2018
    Posts:
    295
    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.
     
  6. Dmi7ry

    Dmi7ry Member

    Joined:
    Jun 24, 2016
    Posts:
    481
    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.

    YellowAfterlife already replied this.

    GML changes is the first thing I follow in GMS.

    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.

    I never said that GML should be strongly typed. I said that evaluations between different types (string and number) should throw errors.
     
  7. Pfap

    Pfap Member

    Joined:
    Apr 30, 2017
    Posts:
    551
    Just that it is frustrating if you are expecting one thing and another happens.
     
    immortalx likes this.
  8. kraifpatrik

    kraifpatrik Member

    Joined:
    Jun 23, 2016
    Posts:
    132
    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.
     
    8BitWarrior and immortalx like this.
  9. curato

    curato Member

    Joined:
    Jun 30, 2016
    Posts:
    424
    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.
     
  10. samspade

    samspade Member

    Joined:
    Feb 26, 2017
    Posts:
    2,117
    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.
     
    Gradius and 8BitWarrior like this.
  11. jonjons

    jonjons Member

    Joined:
    May 10, 2017
    Posts:
    298
    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
     
  12. jackquake

    jackquake Member

    Joined:
    Aug 17, 2016
    Posts:
    87
    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!
     
  13. Smiechu

    Smiechu Member

    Joined:
    Jul 14, 2017
    Posts:
    626
    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...
     
  14. Dmi7ry

    Dmi7ry Member

    Joined:
    Jun 24, 2016
    Posts:
    481
    No.
     
  15. 8BitWarrior

    8BitWarrior Member

    Joined:
    Jun 20, 2016
    Posts:
    43
    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: Mar 5, 2019
    Gradius, TrunX and JeffJ like this.
  16. curato

    curato Member

    Joined:
    Jun 30, 2016
    Posts:
    424
    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.
     
  17. YellowAfterlife

    YellowAfterlife ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    2,439
    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?
     
    Pfap, Dmi7ry and JeffJ like this.
  18. gnysek

    gnysek Member

    Joined:
    Jun 20, 2016
    Posts:
    1,313
    ha!

    So, 7 years ago, on 2012-03-01 I've reported a bug:

    And the answer from YoYoGames was:
    .

    Interesting, that a feature which was removed came back at some point... great to see it again.
     
    Fanatrick likes this.
  19. Dmi7ry

    Dmi7ry Member

    Joined:
    Jun 24, 2016
    Posts:
    481
    Where is now that wise man?
    [​IMG]
     
    Last edited: Mar 7, 2019
  20. gnysek

    gnysek Member

    Joined:
    Jun 20, 2016
    Posts:
    1,313
    It was Mike ;)
     
  21. Dmi7ry

    Dmi7ry Member

    Joined:
    Jun 24, 2016
    Posts:
    481
    There is no hope...
     
  22. JeffJ

    JeffJ Member

    Joined:
    Jun 20, 2016
    Posts:
    342
    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.
     
  23. Gradius

    Gradius Member

    Joined:
    Jun 21, 2016
    Posts:
    72
    Changelog:
    Fixed bug causing excess performance.

    o_O
     
    8BitWarrior likes this.
  24. 8BitWarrior

    8BitWarrior Member

    Joined:
    Jun 20, 2016
    Posts:
    43
    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.
     
  25. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,470
    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: Mar 7, 2019
    nacho_chicken and JeffJ like this.
  26. nacho_chicken

    nacho_chicken Member

    Joined:
    Jun 21, 2016
    Posts:
    427
    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.
     
    JeffJ likes this.
  27. Nocturne

    Nocturne Friendly Tyrant Forum Staff Admin

    Joined:
    Apr 13, 2016
    Posts:
    7,044
    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.
     
  28. JeffJ

    JeffJ Member

    Joined:
    Jun 20, 2016
    Posts:
    342
    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.
     
    kumitassu and immortalx like this.
  29. Nocturne

    Nocturne Friendly Tyrant Forum Staff Admin

    Joined:
    Apr 13, 2016
    Posts:
    7,044
    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.
     
  30. JeffJ

    JeffJ Member

    Joined:
    Jun 20, 2016
    Posts:
    342
    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.
     
  31. Dmi7ry

    Dmi7ry Member

    Joined:
    Jun 24, 2016
    Posts:
    481
    If it always threw errors (instead of continue to work with wrong values) it would also be consistent.
     
    JeffJ likes this.
  32. gnysek

    gnysek Member

    Joined:
    Jun 20, 2016
    Posts:
    1,313
    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?).
     
  33. rmanthorp

    rmanthorp YoYo Games Staff Admin YYG Staff

    Joined:
    Apr 15, 2016
    Posts:
    309
    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.
     
    jackquake, hippyman, Gradius and 10 others like this.
  34. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,698
    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.
     
    kagamma, curato, Amon and 1 other person like this.
  35. rmanthorp

    rmanthorp YoYo Games Staff Admin YYG Staff

    Joined:
    Apr 15, 2016
    Posts:
    309
    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.
     
  36. Tsa05

    Tsa05 Member

    Joined:
    Jun 21, 2016
    Posts:
    560
    @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
     
  37. Samuel Venable

    Samuel Venable Time Killer

    Joined:
    Sep 13, 2016
    Posts:
    1,299
    Honestly I find it sad that YoYoGames actually thought this would be received well and then look at every comment in this topic lel
     
  38. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,470
    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.)
     
  39. Dmi7ry

    Dmi7ry Member

    Joined:
    Jun 24, 2016
    Posts:
    481
    Most of people just don't understand (because they're had no such experience) what this change threatens.

    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.
     
  40. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,698
    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.
     
    Samuel Venable likes this.
  41. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,470
    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.
     
  42. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,698
    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.
     
    thaaks, gnysek, nacho_chicken and 3 others like this.
  43. gnysek

    gnysek Member

    Joined:
    Jun 20, 2016
    Posts:
    1,313
    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: Mar 10, 2019
    SnoutUp, Vallo92, GMWolf and 2 others like this.
  44. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,698
    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:
    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
    
     
  45. gnysek

    gnysek Member

    Joined:
    Jun 20, 2016
    Posts:
    1,313
    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
     
  46. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,698
    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.
     
  47. XanthorXIII

    XanthorXIII Member

    Joined:
    Jun 20, 2016
    Posts:
    184
    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.
     
  48. gnysek

    gnysek Member

    Joined:
    Jun 20, 2016
    Posts:
    1,313
    Yep, 1+ real("2") heave more sense, and number + string should just always throw errors on both YYC and non-YYS.
     
    Dmi7ry likes this.
  49. TrunX

    TrunX Member

    Joined:
    Jun 30, 2016
    Posts:
    143
    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.
     
    JeffJ likes this.
  50. psyke

    psyke Member

    Joined:
    Jun 21, 2016
    Posts:
    223
    I'm no expert, but this is like:

    Code:
    Code:
    var RandomStuff = make_color_rgb(255, 0, 0) + "green";
    show_debug_message(RandomStuff);
    Output:
    Code:
    "yellow"
    This is insane.
     
    Ludo Design, Cloaked Games and GMWolf like this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice