133 replies to this topic

[ragarnak]

But execute_file gives you possibility to change everything in game in real time by injecting code - you can even create new objects, and gameplay in someone game!

Same for "execute_string(...)". Removing the other only means that some dumb*ss now using a single command to create his most excelent saving-and-loading system now first needs to read the contents of that whole file into a string, to only than have it executed. End-result: nothing changes.

[Rusky]

Agree on dual syntax/semicolons, mplay, game information, built-in globals like health and score, deprecated features, simple mode, uninitialized as 0, MCI/cd_*, action_* and execute_* in their present form.

Disagree on triggers- they're not just checks in the step event- they can be named, individually executed and most of all inherited. It's much more painful to do that without them. In fact, some of the built-in events could/should be converted to trigger events as this would simplify GM's internals as well as potentially allow them to be moved into extensions.

However, most of these would need to be done with care so as not to make things worse. The syntax of old projects could be trivially upgraded to whatever the new version uses, but in some cases there's no clear consensus on which syntax is better or more widely used. Health and score actions would need to be converted to work with regular globals or even locals (which would be extremely useful for health).

The execute_* functions are useful, but also broken. Workarounds are generally painful or not generally applicable. The best way to replace them would be to find primary use cases and introduce new ways to do those things- looking up resources by name, external scripting, callbacks and closures (yes, sorry Mike ) are a few.

[ragarnak]

I just thought of a few I would really want to have gone :

#1 : the "keyboard_check_direct(...)" command (and other methods behaving like it). A game should not be able to see what another other programs input is. Maybe the addition of an "Abort now key" would than be neccessary though ...

#2 : the "sleep" command (D&D & GML). Freezing an event-driven program is not the idea.

#3 : the "splash_show_web(...)" command (D&D & GML). Its little more than a dumbed-down version of "execute_program(...)" and "execute_shell(...)" commands, simply displaying a full webpage (whatever it might be, even some porn-site) in IE (even when you have FF as default browser) with its default security-settings. Not really to my liking. Remove please.

[Nocturne]

Sorry Mike, but that uninitialized variables thing is NOT a good thing for beginners... Honestly I have thousands of posts in the Novice section here and I see a LOT of users who can´t solve their problems due to this. It just masks small errors until they get so big that it´s almost impossible to say where to begin to fix the problem. I think it´s better to teach people right from the start to code in a logical, clean and ordered way as well as teaching them how to debug their own code. Something that function makes very difficult...

EDIT: Oh, and I don´t use the printer options ever...

Edited by Mark13673, 27 January 2011 - 07:28 PM.

[Erik Leppen]

Timelines should stay becuase they are a clear way of scheduling things like cutscenes, animations, or anything time-based that is predefined by the programmer (like when enemies appear). Doing this another way requires GML, which makes it less accessible to novices.

Triggers should definitely stay. I use these quite a lot in my GM8 games because they clear up the code a lot. I find this very important: clean code. Trigger events help with this.

Health and score should stay. Beginners use these a lot. Especially score, since the highscore list is based around it.

I even think execute_string should stay, because it does things no other GML function does. At least I have used execute_string in a game that would've been a lot harder to code (if even possible) without (the game was about placing items on sensor platforms to change their value in such a way that a given math equation would turn true. I used execute_string to evaluate the equations. If I didn't have execute_string, I would have to either write my own equation parser, or hard-code all equations and their solutions which means I can easily forget solutions.)

Anyhow. Things mentioned by others earlier that I support for removal:
simple mode
The first thing that newbies are getting as advice when can't find something, is usually Go to advanced mode. Doing this, the GM IDE will look the same for everybody, which makes helping each other find things a lot easier.

treat uninitialized variables as 0
All this does is hiding the most useful error message you can get. If you use an unitialized variable, your code is wrong. It's that simple. An no, beginners don't need it. They need the unknown variable error to fix their coding.

Program priority setting
Explained already by NakedPaultoast in post #34. I have never seen it do anything good and it can make other processes unresponsive. Also as far as I know almost any game that lags takes 99% CPU anyway, so this won't do much.

deprecated functions like image_single, part_type_color, file_eof, font_name, ...
I mean...

image_single was deprecated and replaced with image_speed/image_index years ago. V4 maybe V5. But it's still hanging around.

It's even worse: I still sometimes see people recommend others to use image_single.

[ragarnak]

uninitialised variables to 0. Stays. Beginners need this. It's just easier for them if it's there.

Sorry my saying so, but beginners need that like a hole in their heads.

It just makes it easier for them to make all kinds of spelling-mistakes and think there is no problem. The end-result often is that they than post on this forum with the mess their program has become to ask us to figure out what went wrong ...

Ofcourse, this mess is only possible because GM (still) uses a resource-system in which Zero is a valid ID. (and yes, thats a hint. )

One even more evil setting is the possibility to disable the showing of errors. Misteriously failing programs galore. End yes, I had the displeasure to have tried to figure out how to help members to recuperate something of their (often) hard work.

I'm in favour of a more localized approach, where a few lines can be excluded from throwing errors (and than checked with the normal error-variables afterwards).

[edit]

I still sometimes see people recommend others to use image_single.

Its a one-stop setting of a certain sub-image and telling the instance not to animate: one command instead of two. Sounds like a good decision to me.

Edited by ragarnak, 27 January 2011 - 07:59 PM.

[Joebra]

There are some things I would like to say, but I will just bring this up right now since I'm short of time right now.

Treat uninitialized variables as 0
In my opinion this is bad, even for beginners. Why? Well, simply because it makes it harder to debug your program. If you've missed to initialize a variable somewhere in your code (even if your code is fairly clean) it can get extremely irritating and time consuming to find that tiny mistake. It may now cause horrible bugs, but it's possible that it causes hard found bugs and that's one thing that you want to avoid. If you want your variables to initialize to 0, then write it on your code yourself. Write "variable_name = 0;" instead of just "variable_name;". The latter is just bad practice and shouldn't be allowed. It's better if beginners learn from the start of to initialize their variables and it will also prevent lots of unnecessary bugs caused by a variable that you missed to initialize.

This is just my opinion and I agree with the others that have said that this should "go". As I mentioned before, you shouldn't learn beginners something that is just bad practice. It may (I don't say it will) make it harder for them to continue on with some other language like C, C++, C#, Java, etc. Well, I'm not going to say more about this, I've already said enough. I'll probably give my thoughts about some other things at a later point, but not now.

[Chronic]

I would agree to remove registry functions, and to remove program priority all together (from editor and functions).

CD and Printer functions could be moved to there own extensions.

[Nehacoo]

#2 : the "sleep" command (D&D & GML). Freezing an event-driven program is not the idea.

I find it very useful for debugging loops though.

As for "Treat uninitialized variables as 0", I remember it only confusing me further when I was new to Game Maker.. I can't speak for everyone else but I don't think it's much help.

Edited by Nehacoo, 27 January 2011 - 07:55 PM.

[ragarnak]

I find it very useful for debugging loops though.

Thats the only thing I can remember I've ever used it for. For loops that visually did something.

Ofcourse, I only used it as a replacement for the "show_message(...)" box I had there earlier, as that gave me the possibility to single-step (and keeping a button down also is a kind of slow sleep ).

[Chronic]

Sleep is also useful when adding a pause button to your game, however using the de/activate instance functions can give you the same effect.

io_clear();
while !keyboard_check_pressed(vk_anykey) sleep(100);

instance_deactivate_all(true);

[IceMetalPunk]

io_clear();
while !keyboard_check_pressed(vk_anykey) sleep(100);

Is that not identical to:

io_clear();
keyboard_wait();

?

-IMP

[FredFredrickson]

How about removing the Game Maker "game UI" (the UI of the boxes like show_message() produces) and make the default message boxes whatever is native to the OS you create your game for? That would make GM games seem much more "legit", I think (plus I can't stand those ugly black boxes).

[IceMetalPunk]

How about removing the Game Maker "game UI" (the UI of the boxes like show_message() produces) and make the default message boxes whatever is native to the OS you create your game for? That would make GM games seem much more "legit", I think (plus I can't stand those ugly black boxes).

Seconded. There's no need to have a separate, verbose extension to replicate exactly the same things as the default functions, but with a recognizable interface.

-IMP

[commander of games]

score, health etc. all stay. Beginners use them.

Beginners should be able to get along without score and health. All they need to do is create a global variable called health or score... Maybe(I know this isn't the place to suggest features)have a setting the Global Game Settings that will allow you to choose if these are 'pre-defined' or not?

[FredFredrickson]

score, health etc. all stay. Beginners use them.

Beginners should be able to get along without score and health. All they need to do is create a global variable called health or score... Maybe(I know this isn't the place to suggest features)have a setting the Global Game Settings that will allow you to choose if these are 'pre-defined' or not?

Thing is, these things make it easier for beginners, and don't affect advanced users at all. There's no point in getting rid of them just for the sake of getting rid of them.

Maybe it'd be more useful if in Advanced or Pro mode you could disable some of the default globals like these. I'm not really sure how that would help, other than to make sure that your game throws errors if you accidentally use one of those var names or something, but hey, just a suggestion.

[Erik Leppen]

One even more evil setting is the possibility to disable the showing of errors. Misteriously failing programs galore. End yes, I had the displeasure to have tried to figure out how to help members to recuperate something of their (often) hard work.

I disagree. The hide errors function has actually a purpose - on a finished product one might want to hide error message and instead replace them with their own error handling system (using a Trigger event with error_occurred in it ). In fact I have done this on a GM program. This way you can style your error message the way you want and e.g. write on the error message "please report this to [...]". This can look much more professional than the default GM error message. When writing large programs, never automatically assume it is error-free. Especially not if it has to handle a lot of user-generated content. So if you want a polished product, the ability to create a polished error handling system for it, for just in case, is, to me, a very big plus.

So, Hide error messages should stay.

And also I think I have encountered a bug in the error system twice, that I could find only by looking at the error in game_errors.log, because both bugs gave a normal error message followed by a series of access violations (yes, GM is not bug free as we all know). Although of course the solution to this is to fix the error system (assuming it is the cause of the two bugs). Those bugs have been reported to YYG's bug system a while ago already by the way.

ts a one-stop setting of a certain sub-image and telling the instance not to animate: one command instead of two. Sounds like a good decision to me

I don't think it's a good idea to recommend a deprecated (and undocumented) function, because sooner or later this will be removed from the program. I think it's much better to learn the right way, even if it's one line longer. (Woo. One whole line. Disaster. )

But I don't really care either way.

[Revel]

Built in variables: You already said beginners use them, so maybe have an option to disable them.
Treat uninitialized variables as 0: This is TERRIBLE programming practice and should be removed. Beginners need to learn that programming involves careful variable declaration and usage. Otherwise, if this feature wasn't removed, whenever a variable was initialized via this system, it could have a "flag" on it saying it was declared via the system and could produce a warning to the programmer saying that it hasn't been declared manually.

Registry - WILL go. It's a massive security hole that needs nuked as quickly as possible.

[FunnyGames]

to commander of games:
You're wrong, when I first start using Game Maker, I had no programming experience at all, and I did used the health and score, I used D&D of course, but still when moving to GML, I used the health and score, so removing it will create beginners many problems.
And I do agree with the other posts here. (About game help, treating unknown variables as 0, etc).