1176 replies to this topic

[sabriath]

Metadata should never go in comments.

So you are saying that this would be horrible to do:

//$int a;
a = 10;

As I see it, it allows backward compatibility, but all forward applications will reduce size and/or increase efficiency. GM at this moment would just assign 'a' as a variant to a 'real' (double), but if this were implemented, 'a' would become strictly an 'int'.

Just going on the definition of 'metadata' itself (data that describes data). As for making things that break GM, sure..it is a bad thing...for example:

//$(int a, int b)
return a+b;

If that were to describe the scripts' arguments, it would no longer work compatibly because "a" and "b" are not necessarily assigned at the time the script is called...and...'a' and 'b' are not the argument names in current (and older) models of GM. This type of suggestion you might as well just take it out of the comments, there would be no point because the application that can understand it would be the only one to run properly.

I support metadata in the first code presented (to describe variables more strictly while maintaining bc), but not the second one.

[xot]

So you are saying that this would be horrible to do:

Comments should never have any effect on code and its execution. Comments are for humans, not computers. They are OK for support software like automatic documentation and code completion, but neither of those examples actually affect the execution of the code. They exist purely for the convenience of the human user. If the user wishes to modify or delete the comments, it shouldn't change the code in any way.


On the topic of arguments, another suggestion I made during the GM8 Beta was for an argument_count variable to report the number of arguments passed to a script. It was also dismissed.

I won't change this. If you want to make a script with a variable number of arguments the best way to do it is to supply as the first argument the number of arguments.

[sabriath]

Comments should never have any effect on code and its execution. Comments are for humans, not computers. They are OK for support software like automatic documentation and code completion, but neither of those examples actually affect the execution of the code. They exist purely for the convenience of the human user. If the user wishes to modify or delete the comments, it shouldn't change the code in any way.

Oh really? comments should never have any effect on code? If only someone told the qbasic creators before they did:

'$DYNAMIC
'$STATIC

Oh the world, the world.

Comments are things that can be easily ignored by the compiler, but if the compiler is new, it is the only place you can put things without messing older versions up. It's called reserve spacing, been used in many areas to expand things not yet known to be needed in software -- for example, "flags" in cpu/functions/protocols use this same principle by leaving an ignorable bit...but newer forms can use it to remap or alter the cpu/function/protocol. It's not so different to use it for a compiler, but at the same time, if you alter it too drastically where the older versions would break regardless, you might as well implement it as a full feature rather than a commented extension.

[henrywalton]

how about import objects from google sketch up for 3d mode?

[Revel]

On the topic of arguments, another suggestion I made during the GM8 Beta was for an argument_count variable to report the number of arguments passed to a script. It was also dismissed.

I 100% agree with this. Honestly, I think it was completely silly for Mark to ignore it. It's a very important feature.

Personally, I would prefer something more like (argument_set(argument0)) to check if the argument was passed. The current system (checking for 0 to see if an argument was passed) is ridiculous. Especially when something actually needs to pass 0.

Edit: Yes his "workaround" works fine, but is tedious and shouldn't be needed. The functionality should be built into GML.

Edited by Revel, 30 October 2010 - 11:04 PM.

[Gamer3D]

what would be really good would be if we can make 3d object on google sketch up and import them

how about import objects from google sketch up for 3d mode?

First, don't double post. Second, find a script or an extension for it. Formats change. People make extensions for them. It's actually easier and possibly more useful than having it built straight into GM.

On the topic of arguments, another suggestion I made during the GM8 Beta was for an argument_count variable to report the number of arguments passed to a script. It was also dismissed.

I 100% agree with this. Honestly, I think it was completely silly for Mark to ignore it. It's a very important feature.

Personally, I would prefer something more like (argument_set(argument0)) to check if the argument was passed. The current system (checking for 0 to see if an argument was passed) is ridiculous. Especially when something actually needs to pass 0.

Edit: Yes his "workaround" works fine, but is tedious and shouldn't be needed. The functionality should be built into GML.

argument_set is not necessary if argument_count is available, because to set argument11, you need to supply arguments 0 - 10. This means that if ANY argument is used, the previous arguments are as well. Any argument_set function is simply this:

return (argument_count > argument0);

From this, argument_set is clearly nothing but code bloat.

And yes, argument_count is worth every second of implementation time, partially because it allows overloaded functions.


Last, but not least, allowing GM to use comments to extract function descriptions from comments would be not only helpful, but also harmless unless implemented HORRIBLY. For example,

//$(argument0_name, argument1_name)

GM could check the first line for the "//$(" string, and use the arguments following it (All the way until a ")" symbol is encountered, unless there is none in the comment line) to provide function tips, just like built-in functions have.

Because it would be used ONLY for providing the aforementioned help, it would not affect the interpretation of the code at all. Any failure to find that convention could simply be ignored.

[Revel]

what would be really good would be if we can make 3d object on google sketch up and import them

how about import objects from google sketch up for 3d mode?

First, don't double post. Second, find a script or an extension for it. Formats change. People make extensions for them. It's actually easier and possibly more useful than having it built straight into GM.

On the topic of arguments, another suggestion I made during the GM8 Beta was for an argument_count variable to report the number of arguments passed to a script. It was also dismissed.

I 100% agree with this. Honestly, I think it was completely silly for Mark to ignore it. It's a very important feature.

Personally, I would prefer something more like (argument_set(argument0)) to check if the argument was passed. The current system (checking for 0 to see if an argument was passed) is ridiculous. Especially when something actually needs to pass 0.

Edit: Yes his "workaround" works fine, but is tedious and shouldn't be needed. The functionality should be built into GML.

argument_set is not necessary if argument_count is available, because to set argument11, you need to supply arguments 0 - 10. This means that if ANY argument is used, the previous arguments are as well. Any argument_set function is simply this:

return (argument_count > argument0);

Good point

Last, but not least, allowing GM to use comments to extract function descriptions from comments would be not only helpful, but also harmless unless implemented HORRIBLY. For example,

//$(argument0_name, argument1_name)

GM could check the first line for the "//$(" string, and use the arguments following it (All the way until a ")" symbol is encountered, unless there is none in the comment line) to provide function tips, just like built-in functions have.

Because it would be used ONLY for providing the aforementioned help, it would not affect the interpretation of the code at all. Any failure to find that convention could simply be ignored.

After using Visual Studio for so long, I've found that coding in GM is tedious because often I tend to forget my arguments (mainly which order they are in) and GM forces me to go open the script and read any documentation I have written on it. Also, You can't open scripts without closing the "Execute Piece of Code" window...


Come to think of it... Adding comment parsing for argument/descriptions and adding something like argument_count for overloading are huge features that might pull me back towards GM (along with the performance issues of course, but those are being worked on).

Edited by Revel, 31 October 2010 - 01:09 AM.

[TheMagicNumber]

After using Visual Studio for so long, I've found that coding in GM is tedious because often I tend to forget my arguments (mainly which order they are in) and GM forces me to go open the script and read any documentation I have written on it. Also, You can't open scripts without closing the "Execute Piece of Code" window...

Agreed.

Though the code completion in GM needs a lot of work, VS's is often annoying when it tells you that it can't help you instead of taking that opportunity to gather information to help. Hopefully GM's just stops popping up everywhere.

[IceMetalPunk]

Though the code completion in GM needs a lot of work. [...] Hopefully GM's just stops popping up everywhere.

So true. I can't tell you how many times that thing has annoyed me almost to the point of breaking my keyboard. Mostly because I often use the variable name "str", and so GM automatically assumes I want info on any of the many string_* functions.

Come to think of it, that's a hugely important suggestion: make the code completion navigable with the mouse, not the keyboard. This way, even if the menu pops up, it won't interfere with me pressing up/down to move the cursor. On the same note, if it ever does pop up unwanted, I should be able to press ESC to close it. That would save more frustration than you can possibly know (unless, of course, it's happened to you ).

-IMP

Edited by IceMetalPunk, 31 October 2010 - 03:27 AM.

[YellowAfterlife]

Add function to manipulate trigger events in-game
Triggers are good, but supported by only a single gml keyword, which is constant ev_trigger.
Since, as I may guess, triggers work faster than a horde of conditions-actions in step event, a number of functions to add\remove triggers by names would be nice to see.

Add functionality to support\change scripts
It is quite strange to be able only to get scripts name, index, and code. Since scripts are stored in memory just as everything else, yet work several times faster than execute_string and object_event_add+event_perform, it would good to see functions like script_add(code), script_delete(ind), script_set_text(ind,code), script_add_text(ind,code)^{script_append_text?}. Since I do not have reasons to believe into possibility of making new scripts callable via standart method, 'newscript()', new scripts should gain names as __scr# and be accessible through script_execute.

Allow to change script editor's background color in Preferences
It is possible to manipulate script editor's colorset, but not possible to change background color of editing area. Maybe user wishes to have a dark editor background, to not get tired because of looking at bright rectangle for a while?

Add more options into first Preferences tab
Two options on the right side of tab look lonely as they are now. My suggestions are to add a option to display a small window with list of recent files, and a list of 'favorites' - files that user may mark manually. (would work perfectly for list of current projects)

Make the 'news' window sizable
Self-explanatory, I guess.

Add more options to loading
Possibility to load (at least 1bit transparent) animated .gmspr instead of standart background & loading bar. A lot of users would be happy to be able to make a circular loading bar for their game.

Make ev_close_button work if added in-game
At the current moment, Close button event is activated only if it was added to object in editor. object_event_add(object,ev_other,ev_close_button,'game_end()') has no result.

Improve main window refreshing
Refresh the objects icon when user changes it's sprite, and (if possible) not refresh the entire treeview when two items swap places.

I guess, that's all... for now...

[Rusky]

No comment should ever affect the execution of any code. There are much better ways to tell the parser what you mean, and not even backwards compatibility is a good enough reason to choose comments instead.

On the topic of arguments, another suggestion I made during the GM8 Beta was for an argument_count variable to report the number of arguments passed to a script. It was also dismissed.

how about import objects from google sketch up for 3d mode?

Come to think of it, that's a hugely important suggestion: make the code completion navigable with the mouse, not the keyboard. This way, even if the menu pops up, it won't interfere with me pressing up/down to move the cursor. On the same note, if it ever does pop up unwanted, I should be able to press ESC to close it. That would save more frustration than you can possibly know (unless, of course, it's happened to you ).

Allow to change script editor's background color in Preferences
It is possible to manipulate script editor's colorset, but not possible to change background color of editing area. Maybe user wishes to have a dark editor background, to not get tired because of looking at bright rectangle for a while?

Add more options to loading
Possibility to load (at least 1bit transparent) animated .gmspr instead of standart background & loading bar. A lot of users would be happy to be able to make a circular loading bar for their game.

These are all already on the list. Repeat suggestions were the biggest problem with the old topic, can we not do this again please?

Add function to manipulate trigger events in-game
Triggers are good, but supported by only a single gml keyword, which is constant ev_trigger.
Since, as I may guess, triggers work faster than a horde of conditions-actions in step event, a number of functions to add\remove triggers by names would be nice to see.

This is already possible in Game Maker.

Make ev_close_button work if added in-game
At the current moment, Close button event is activated only if it was added to object in editor. object_event_add(object,ev_other,ev_close_button,'game_end()') has no result.

Improve main window refreshing
Refresh the objects icon when user changes it's sprite, and (if possible) not refresh the entire treeview when two items swap places.

Bug fixes belong on the help desk, not here.

Add functionality to support\change scripts
It is quite strange to be able only to get scripts name, index, and code. Since scripts are stored in memory just as everything else, yet work several times faster than execute_string and object_event_add+event_perform, it would good to see functions like script_add(code), script_delete(ind), script_set_text(ind,code), script_add_text(ind,code)^{script_append_text?}. Since I do not have reasons to believe into possibility of making new scripts callable via standart method, 'newscript()', new scripts should gain names as __scr# and be accessible through script_execute.

I've added script_add to the list, but script_set/add/append_text are really not good ideas. That functionality is accessible through first-class functions, which are already partially possible and on the list. Also, script_add would work by returning a script index which you could store in a variable and then call with script_execute - automatically naming them __scr# would be impossible because you wouldn't know which name to use at design time.

Edited by Rusky, 01 November 2010 - 03:33 AM.

[Gamer3D]

No comment should ever affect the execution of any code. There are much better ways to tell the parser what you mean, and not even backwards compatibility is a good enough reason to choose comments instead.

I agree. However, that is not the topic. The idea is to use comments to provide function help (I.E. Display more information to the programmer, which is the purpose of comments). Having the code EDITOR read comments is perfectly fine.

I would not object to being able to add similar metadata in a different way (such as in a properties page), but this is an excellent suggestion, even if it uses comments to store the data.

It never has been about changing execution.

On the topic of arguments, another suggestion I made during the GM8 Beta was for an argument_count variable to report the number of arguments passed to a script. It was also dismissed.

These are all already on the list. Repeat suggestions were the biggest problem with the old topic, can we not do this again please?

The one I highlighted is important enough that it might be worth repeating.

Add function to manipulate trigger events in-game
Triggers are good, but supported by only a single gml keyword, which is constant ev_trigger.
Since, as I may guess, triggers work faster than a horde of conditions-actions in step event, a number of functions to add\remove triggers by names would be nice to see.

This is already possible in Game Maker.

Very true.

[~Dannyboy~]

No comment should ever affect the execution of any code. There are much better ways to tell the parser what you mean, and not even backwards compatibility is a good enough reason to choose comments instead.

I agree. However, that is not the topic. The idea is to use comments to provide function help (I.E. Display more information to the programmer, which is the purpose of comments). Having the code EDITOR read comments is perfectly fine.

I would not object to being able to add similar metadata in a different way (such as in a properties page), but this is an excellent suggestion, even if it uses comments to store the data.

It never has been about changing execution.

I was under the opinion that parameter names would be used as identifiers in the script. As identifiers have to be available at runtime (for example in an execute_string call) the parameter names will effect the execution. Hence they should not be specified in a comment.

[Gamer3D]

I was under the opinion that parameter names would be used as identifiers in the script. As identifiers have to be available at runtime (for example in an execute_string call) the parameter names will effect the execution. Hence they should not be specified in a comment.

If that is the case, then I am in error.

As I understood it, the suggestion was allowing people to use the help bar to show scripts arguments' names. For example, typing "foo(" in the main window would show the hint: "foo(bar)". This is a worthy cause for YoYo.

If it is as you suggested, letting people use different names than argument0 etc. inside the script, then that should NEVER be in comments as it affects code compilation. This can be done without (and has been for a long time), but it's still something that might be helpful. I've noticed a lot of the more skilled people mimicking this by using var like this:

var u, v, w;
u = argument0;
v = argument1;
w = argument2;

In a nutshell, it would improve readability of scripts.

[sabriath]

I was under the opinion that parameter names would be used as identifiers in the script. As identifiers have to be available at runtime (for example in an execute_string call) the parameter names will effect the execution. Hence they should not be specified in a comment.

And I was under the impression that this was going to be a topic that allowed all viable suggestions to be entered into a central record keeping....yet it seems that we have judges at the GMC that disallow things that they are personally biased against, so it's more like a "brown-nose the keeper" topic.

Gamer3D very well answered exactly the same idea behind it as I had for comments being interpreted, but I guess no one understands the meaning. Yes, I know that comments should never have code in it that will alter, in some way, the ability for backward compatibility to break....this means...

//$int a = 10;
draw_text(0,0,a);

That will not work, and should not work. I agree with Rusky on this...but I wasn't talking about that anyway. I said it should allow declaration for specifying data types more carefully -- this would not break GM because all datatypes are variant and will work on all models anyway. Meaning:

//$int a;
a = 10;

That is my suggestion. Although making _more_ datatypes has been suggested, which YYG obviously will never implement (due to making the language too complex for rookies), this allows the more professional people to get their strict typing AND the rookies would still have their variants....absolutely no risk at the learning curve.

There would be a catch though, it would have to maintain scarce data types (char, byte, short, ushort, int, uint, float, and double)...no pointers would be allowed because then the assignments would break how the runner performs those actions in older languages. This is more for efficiency of space and time on newer versions rather than getting an entirely new area of programming style.

I also like the idea of type-sensing scripts using the first line comments of the script as Gamer3D mentions.

Another suggestion (not sure if this has been said yet):

Object's code as an editor form
Meaning instead of:

Where you click the 'Show information' button and you get this:

Information about object: Ball

Sprite: spr_ball
Solid: false
Visible: true
Depth: 0
Persistent: false
Parent: <no parent>
Mask: <same as sprite>

Create Event:
execute code:

vspeed = -10;
gravity = .1;
gravity_direction = 270;


Collision Event with object Ball:
for other object: execute code:

vspeed = other.vspeed;
other.vspeed = 0;

Where you cannot alter it at all in the textbox. I suggest that there be instead of "Advanced Mode", but an additional "Professional Edit Mode" or something, where I get the above in a simple edit like so:

[ev_create]
sprite_index = spr_ball;
solid = false;
visible = true;
depth = 0;
parent = noone;
mask_index = noone;
vspeed = -10;
gravity = .1;

[ev_collision(Ball, other)]
vspeed = other.vspeed;
other.vspeed = 0;

The GUI can interpret the ev_create area for the first assignment of each needed item so it can do its job properly (by showing the proper "sprite_index" in the room when you place it, etc.).

Maybe 1 single editor of all the code may be drastic, I could even settle for a treeview style...anything would be better than what's currently being done.

[Rusky]

As I said:

There are much better ways to tell the parser what you mean, and not even backwards compatibility is a good enough reason to choose comments instead.

Using comments for argument names in intellisense and not in the actual script is a horrid idea - naming the arguments in the first place is the better way to tell the parser what you mean. On the subject of types, the better way is by specifying the types through a built-in type system rather than by mangling comments. You cite backwards compatibility as a reason for the mangling, but if all the type system can do is restricted to comments it won't be nearly as useful as it could be.

In any case, static typing is a completely separate issue. Naming arguments and even including more/stronger types are not really related. Static typing in the form you are requesting it is absolutely useless for any reason but performance, and there are much better ways to make GM games faster. However, typed arguments and other communication variables are useful for safety and expressiveness, and those are on the list.

Your code editor suggestion has already been brought up many times and is on the list as "non-modal editors." In fact, it's even been mentioned by YoYo as something they want to do. I'm not personally biased against any of your suggestions, I'm just keeping the list usable by not including suggestions that are redundant or that aren't the best way to solve the problem. It would be great if you could try to do the same.

[Gamer3D]

As I said:

There are much better ways to tell the parser what you mean, and not even backwards compatibility is a good enough reason to choose comments instead.

Using comments for argument names in intellisense and not in the actual script is a horrid idea - naming the arguments in the first place is the better way to tell the parser what you mean. On the subject of types, the better way is by specifying the types through a built-in type system rather than by mangling comments. You cite backwards compatibility as a reason for the mangling, but if all the type system can do is restricted to comments it won't be nearly as useful as it could be.

In any case, static typing is a completely separate issue. Naming arguments and even including more/stronger types are not really related. Static typing in the form you are requesting it is absolutely useless for any reason but performance, and there are much better ways to make GM games faster. However, typed arguments and other communication variables are useful for safety and expressiveness, and those are on the list.

First, this has NEVER been about argument types. (Or at least I hope so.) sabriath's //$int a example should simply display function(int a) in the code hint window. It should not change what a is, however. For example:

//$int a
a = 10;

Is no more valid than

//$int a
a = 3.14159;

Similarly,

function(5.667);

Should work exactly as well as

function(10);

So whether comment interpretation or a script properties window is used, it does not affect execution.

Okay. I think I need to try to branch this discussion into 2 separate discussions to achieve any useful conclusions.
Topics of discussion:

• Named arguments in code hints. (This is what I have been discussing)
• Named arguments in-script.

Named arguments in scripts would be useful, as I have said before, but should NEVER be done with comments. These could be done with a script properties window, but in-script names should be kept separate from the code hints unless the programmer does not specify any names for arguments. (The reason for this should be obvious. Let the programmer use names that help him, and let her assign descriptions that help others.)

[sabriath]

First, this has NEVER been about argument types. (Or at least I hope so.) sabriath's //$int a example should simply display function(int a) in the code hint window.

Actually I was suggesting that it did alter the type of the variable within the scope it was used. Although it wouldn't change the variables _name_, just the type, and in any version of GM it would still be a variant except for the ones that understand it.

I do get the point that there are "better ways" to do these things, but I have always built my projects with backwards compatibility in mind, always....and that's how it should ALWAYS work with everything (imo). Currently as you load any GM program with an earlier version, you get a "cannot load" error because it can't understand it...comments defer the compiler's confusion, and the "version" of GM wouldn't matter at this point. In fact, if the "gmk" (or whatever they choose for their extension) were open text and sprites/resources were saved automatically in separate files, then there would be no need for future versions of GM to care about the version. Addition of '#' commands can be added which ignore to end-of-line unless that GM version understands the identifier. Since this idea would break on all previous versions of GM, they could and should implement as many things as they can and leave the comment and '#' commanding for future suggestions that may become useful.

As for Gamer3D and functions, it is important that comments be intellisensed for scripts because if we make it "more compact" and put it into a textbox underneath the name of the script...this would change the way the GMK file is arranged...which would break GM yet again. Doing it in comments you don't have to change the GMK format at all, and it would be as simple as:

//$Direction, Speed

Where the script is called 'Function'...as soon as you type, in code, 'Function' the status bar can display "Function(Direction, Speed)" as if it were a GM built-in function or extension. It could even bold the argument you are currently on just the same. Heck, it could even put it in the dropdown list when you start typing it.

Yes, you could just make an extension for it, and yes, I could just use c++ and not deal with GM at all...so I don't see the relevance of telling me to circumvent something I'm suggesting. No matter if it can "be done in a better way," it is still a suggestion that isn't without purpose.

[Gamer3D]

Actually I was suggesting that it did alter the type of the variable within the scope it was used. Although it wouldn't change the variables _name_, just the type, and in any version of GM it would still be a variant except for the ones that understand it.

I can't agree with you anymore. Comments CANNOT be allowed to change the code or the way it is compiled. That's part of the purpose of a comment. Changing the type of a variable MUST be done outside of comments.

I do get the point that there are "better ways" to do these things, but I have always built my projects with backwards compatibility in mind, always....and that's how it should ALWAYS work with everything (imo). Currently as you load any GM program with an earlier version, you get a "cannot load" error because it can't understand it...comments defer the compiler's confusion, and the "version" of GM wouldn't matter at this point. In fact, if the "gmk" (or whatever they choose for their extension) were open text and sprites/resources were saved automatically in separate files, then there would be no need for future versions of GM to care about the version. Addition of '#' commands can be added which ignore to end-of-line unless that GM version understands the identifier. Since this idea would break on all previous versions of GM, they could and should implement as many things as they can and leave the comment and '#' commanding for future suggestions that may become useful.

Later versions of GM add functions which break the file for previous versions anyway. Get over it. The reason for backwards compatibility is so that people can load their old files into new GM, not the other way around.

As for Gamer3D and functions, it is important that comments be intellisensed for scripts because if we make it "more compact" and put it into a textbox underneath the name of the script...this would change the way the GMK file is arranged...which would break GM yet again. Doing it in comments you don't have to change the GMK format at all, and it would be as simple as:

//$Direction, Speed

Where the script is called 'Function'...as soon as you type, in code, 'Function' the status bar can display "Function(Direction, Speed)" as if it were a GM built-in function or extension. It could even bold the argument you are currently on just the same. Heck, it could even put it in the dropdown list when you start typing it.

Yes, you could just make an extension for it, and yes, I could just use c++ and not deal with GM at all...so I don't see the relevance of telling me to circumvent something I'm suggesting. No matter if it can "be done in a better way," it is still a suggestion that isn't without purpose.

As I keep saying, it can be done in properties.

The GMK format can be changed. It WILL be changed. GM does not need GM11's files to work in GM7. It does need GM8's files (and preferably GM7's as well) to be able to be imported into GM9.

So go ahead, Yoyo, "break" the GMK format to give us a better product. Just remember to let us import our old projects.

[TheMagicNumber]

Comments shouldn't affect your program at all, I have no idea where that idea of yours came from. Comments providing documentation that can be used in the code completion is a serious benefit to users.