Jump to content


Photo

Uninitialised "things"


  • This topic is locked This topic is locked
49 replies to this topic

#1 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4735 posts
  • Version:GM:Studio

Posted 08 April 2011 - 03:08 PM

So, here's today's topic. We've been putting in code to force you to pass the correct number of arguments because aside from being a bad habit to get into, it's also a performance and "bug waiting to happen" issue. So in 8.1 you will now get an error if you call a script with the incorrect number of arguments.

   myScript()
Would be wrong if you use argument0 through argument15 in your code. You must now provide the correct number. Currently, it would initialise the variable to 0 (or false) if you hadn't passed it in. We consider this bad. It's an undocumented thing which should be avoided. if you mean 0, you should pass 0 in.

Now... this also got us looking at other issues. We have problems with folk creating arrays and touching element (say) 15, but then reading element 5. Again, this would be initialised to 0. This is again bad... but it would mean you have to "initialise the whole array.

So I'm currently looking to see if it's possible to throw an error in this case.


Now here's the question. What do you think should happen in these cases? The argument one is a no-brainer to me. It's dangerous, and it's a source of many a bug if you don't know what your doing. It's also a performance issue, as we need to clear 16 arguments every time we enter a function in case it accesses them. Now however, if you don't use args, we can detect that... and not clear anything, making script->script calling, faster (well.. a tiny bit).

The array access is different. We currently set the LAST element first to "size" the array, and know that our code will fill it all in first, but many folk I suspect will depend on the fact it'll be 0. What I'd prefer is for you to use some kind of DIM() command that would WIPE it if you needed 0, but if you didn't, you would get an error if you accessed an uninitialised element.

What do you think?


EDIT: Just been pointed out that printf() style calls would no longer work. So we'll make it so that argument[x] types are not effected by calling limits. Basically we'll assume you know what your doing if you access arguments via arrays.
  • 2

#2 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 24487 posts
  • Version:GM:Studio

Posted 08 April 2011 - 03:17 PM

The argument business sounds good to me... any performance boost is a good thing, and if it enforces good programming habits then I´m all for it! As for the arrays, what does DIM() mean? At the moment it´s quite useful to do

array[15]=0;

and know that the whole array is initialised to 0... are you suggesting that we do this but in some way choose the initial value? Or havit so that that code throws an error and we have to use

var i;
i=0;
repeat(15)
{
array[i]=0;
i+=1;
}

to create the whole array? Sorry if I´m being dumb, but I only know how to program in GM...

Edited by Nocturne, 08 April 2011 - 03:17 PM.

  • 0

lz6lxdC.pngd7ZQQ3F.gifFlvJzyf.png

40799.png


#3 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4735 posts
  • Version:GM:Studio

Posted 08 April 2011 - 03:24 PM

At the moment yes. You would have to "clear" the array yourself. However, if we added a DIM command, then it could initialise an array to the size you wanted.


   Dim(myarray,16);

This would create/resize an array to 16 initialised elements. meaning you don't need to manually do it. We've seen a lot of bugs where someone simply hasn't filled in a variable, then read from it and it's worked "by chance" really.

I guess we could also make it optional that this could be expanded, allowing for "bounds" checking. Theres no way to protect going outside the array at the moment as it just expands.....?
  • 1

#4 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 24487 posts
  • Version:GM:Studio

Posted 08 April 2011 - 03:26 PM

Thanks for the info, Mike... seems like a sensible move and easy to adjust my coding style to!
  • 0

lz6lxdC.pngd7ZQQ3F.gifFlvJzyf.png

40799.png


#5 GameGeisha

GameGeisha

    GameGeisha

  • GMC Member
  • 5275 posts
  • Version:GM:Studio

Posted 08 April 2011 - 03:58 PM

Dim(myarray,16);
This would create/resize an array to 16 initialised elements. meaning you don't need to manually do it. We've seen a lot of bugs where someone simply hasn't filled in a variable, then read from it and it's worked "by chance" really.

I like this. Would it be possible to expand this to initialize all the values to a user-specified value (e.g. noone), or even generate common sequences (like range() from Python). That would definitely cut down on the time spent writing FOR loops for the purpose.

Also, will this be a special syntax, or just a new function? If it really is a function, that would mean passing arrays as arguments would be permitted. This function can be really powerful and would reduce the number of arguments per script (e.g. if min() implements this, it can take just one argument).

GameGeisha
  • 0

Latest Releases:

Due to a recent project failure, I will be taking a leave until the end of July for further self-study. If you have questions regarding content in my posts, please contact me through email.


#6 paul23

paul23

    GMC Member

  • Global Moderators
  • 4083 posts
  • Version:GM:Studio

Posted 08 April 2011 - 04:07 PM

Well I'm always in favour of getting things done explicitelly and do as little as possible implicetelly.. So I shared your opinion that initializing elements 0-x when setting array[x+1] is bad.

That said: did you also consider the value of optional arguments? - Optional arguments allow for much more flexibility & faster programming (no longer do you have to create a seperate script for each different number of arguments).. From what I read optional arguments will be impossible in gm 8.1?
  • 0

#7 BlueMoonProductions

BlueMoonProductions

    BlueMoonProductions

  • GMC Member
  • 241 posts
  • Version:GM:Studio

Posted 08 April 2011 - 04:21 PM

I'm not sure wether that's a good idea. For example, in my game, I use a sound system: FMOD. There's a script FMODSound_Play(sound), which calls an external function and plays it.
I edited the script from:
external_call(argument0,and,some,other,stuff)
.. to ..
if (argument1 == false)
 {
  if (global.setting_sfx == true)
   {
    external_call(argument0,and,some,other,stuff)
   }
 }else{
  if (global.setting_music == true)
   {
    external_call(argument0,and,some,other,stuff)
   }
 }
The second argument I added tells wether the played sound is music or SFX. I edited at the time I already used this script a lot, so argument1 would be set to false > it is SFX.

So I use it in 2 ways: FMODSound_Play(sound) and FMODSound_Play(sound,type).

So, I hope you'll at least consider an option to allow a "random" number of arguments? Because there are way more possibilities

Eg: script(numberofarguments, argument1[, argument2[, argument3[, ..]]]):
n = argument0
var i;
for ( i = 1; i <= n; i += 1)
 {
  do_something_with( argument[i])
 }

I think the whole thing is a bad idea, but at least consider an option for a random number of arguments.

Edited by BlueMoonProductions, 08 April 2011 - 04:21 PM.

  • 0

#8 LSnK

LSnK

    NaN

  • GMC Member
  • 1188 posts

Posted 08 April 2011 - 04:59 PM

So we'll make it so that argument[x] types are not effected by calling limits. Basically we'll assume you know what your doing if you access arguments via arrays.

Does that also mean the array would be zeroed? If not I don't like the outcome: no variadic scripts, or variadic scripts with no means of determining the argument count. That would be a very painful change. Maybe something best left to a major revision than a point release.

A function to initialise arrays would be welcome, as would error-reporting for accessing [technically] uninitialised elements.

It'd also be nice to have a means of getting the size of arrays. It's simpler and less error-prone than storing it yourself.

Edited by LSnK, 08 April 2011 - 05:00 PM.

  • 0

#9 JAk HAk

JAk HAk

    sepius fidelis

  • New Member
  • 713 posts
  • Version:GM:HTML5

Posted 08 April 2011 - 06:35 PM

I'd prefer it if scripts defaulted to no arguments and every one you added had to be given a name. Currently, to avoid confusion, I end up making scripts like this:

var id, amount, direction;
id = argument0;
amount = argument1;
direction = argument2;

...

That way, I can refer to variables by a human name, rather than the easily confusable argumentx.


For arrays, I tend to initialize them either sequentially or in a for loop. Considering arrays in GM are basically unparameterized Vectors, this has always worked fine, but it sounds to me like you're wanting to make them more like traditional arrays. As long as the functionality to dynamically resize the array is left in (or Vectors are introduced) I'm fine with what you do.
  • 0

Posted Image


#10 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4735 posts
  • Version:GM:Studio

Posted 08 April 2011 - 07:56 PM

GameGeisha: Its would just be a new function... nothing special other than it'll clear the array quicker since it's native.

paul23: Named arguments is definitely on the list of things we WANT to add, but it's just not possible with 8.1. Well... anything is obviously possible, but it's not worth the effort in 8.1, probably the next version.

BlueMoonProductions: The current idea, is that if you use argument[x], then it'll be as normal. So no checking. But most folk will use argument0, argument1 etc. All you'd have to do is rewrite your function to use argument[0] and argument[1] instead.

The idea being that is you use array access, then you know the issues and accept the risk, where as most newbies will use the normal syntax and get better protection.

I also think adding a new function/variable argc to give you the number of arguments, would be a damn fine idea.... This would in fact make your function far better!


var i;
for ( i = 0; i <= argc; i += 1)
{
  do_something_with( argument[i] )
}

Anything outside the argc range could then be deemed invalid - it "could" throw an error I guess, where as just now you simply don't know how many args you have, so they HAVE to be 0. Even your first function would be better, as you could now almost have default arguments.... you'd have to code them yourself, but you COULD do it.

JAk HAk: They would clear them in the same way, and yes... currently they would still be expandable - although I think an option to be able to LOCK them into a standard array (complete with bounds checking) would be highly beneficial to beginners.
  • 2

#11 GameGeisha

GameGeisha

    GameGeisha

  • GMC Member
  • 5275 posts
  • Version:GM:Studio

Posted 08 April 2011 - 08:43 PM

GameGeisha: Its would just be a new function... nothing special other than it'll clear the array quicker since it's native.

I understand that it's a new function, but what about the syntax?

Consider this example:
foo[0] = "Foo";
foo[1] = "Bar";
foo[2] = "Foobar";
show_message(bar(foo)); //show "Bar"
/* bar(array_here) */
return argument0[1];
If the example code is run in GM8.0, you will always get "Foo", not "Bar". Changing bar to "return argument0[2]" will still return "Foo", not "Foobar". Clearly passing entire arrays by reference is not permitted in GM8.0 --- will this be permitted in GM8.1 now that we have dim()?

GameGeisha

PS: In debug mode, will all the contents of an array be displayed (i.e. through "Show local variables"), or will only the first entry be visible like now? Also, having bounds for arrays now should allow for returning arrays and passing them by reference, wouldn't it?
  • 0

Latest Releases:

Due to a recent project failure, I will be taking a leave until the end of July for further self-study. If you have questions regarding content in my posts, please contact me through email.


#12 mcoot

mcoot

    GMC Member

  • New Member
  • 387 posts

Posted 08 April 2011 - 08:44 PM

I agree that the argumentn variables shouldn't initialise to 0. As long as optional arguments are still possible with the argument[n] array, then that's fine with me.

As for the arrays, that sounds fine to me, just so long as we have this dim() function so we don't have to initialise it manually.
  • 0

Ultimate Healthbars - Easy healthbars in shapes from circular to sine wave

The obligatory (anti)religious signature message: Irreducible complexity is a stupid argument - what seems absurd is not a valid guide in science


#13 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 08 April 2011 - 09:08 PM

At the moment yes. You would have to "clear" the array yourself. However, if we added a DIM command, then it could initialise an array to the size you wanted.

   Dim(myarray,16);

This would create/resize an array to 16 initialised elements. meaning you don't need to manually do it. We've seen a lot of bugs where someone simply hasn't filled in a variable, then read from it and it's worked "by chance" really.

If you're going that way, would you mind adding a parameter that specifies a value / string to initialize it with?

With regard to the arguments: I was wondering if you were going to preserve the little known fact that to scripts, arguments are actually local variables rather than constants - you can't just read them, you can store new values in them too. I use it as a shorthand for not having to initialize private variables in scripts, e.g.:

if (argument1==0) argument1=1;
return argument0/argument1;

Edit: I also wonder how you intend to make this interact with the (horrible) "Treat initialized variables as value 0" setting for a game. If arrays throw an error when not DIMmed, that basically goes against that setting. But if they do not throw an error, you're back with arrays without bounds checks.

Edited by Smarty, 08 April 2011 - 09:11 PM.

  • 0

#14 Medusar

Medusar

    GMC Member

  • GMC Member
  • 1228 posts
  • Version:GM:Studio

Posted 08 April 2011 - 09:12 PM

Always wondered why having the "treat uninitialized variables as 0" option turned off still produced this behaviour for unset script arguments and array values... has been a slight annoyance. Not as big however as the lack of argument_count.

As for the dim() function, I suggest that it should follow GM's current syntax of variable_local/global_set/get(), that is, passing the variable by name. Not that it's the way I like to see this kind of thing, but at least it's consistent.
Unless, of course, you're going to properly allow passing arrays by reference... but I don't expect that for now.

Anyway... I don't see your current way of handling script arguments as the proper way to do it... Yes it's better than it is done currently, but at some point you're going to want to have named arguments and default values for them (instead of forcing the user to use an "unsafe" method and filling every uninitialised "thing" with 0). If you're going to adapt the script system anyway, why not do it properly straight away? I know it's probably a lot of extra work but if you're not careful you end up supporting two old versions and the "proper" version all at the same time... It's not what I'd want.
That's my opinion anyway.
  • 0

Posted Image

Q: Why do programmers always get Christmas and Halloween mixed up?
A: Because DEC 25 = OCT 31

#15 paul23

paul23

    GMC Member

  • Global Moderators
  • 4083 posts
  • Version:GM:Studio

Posted 08 April 2011 - 09:17 PM

paul23: Named arguments is definitely on the list of things we WANT to add, but it's just not possible with 8.1. Well... anything is obviously possible, but it's not worth the effort in 8.1, probably the next version.


I think I didn't make myself clear/you didn't understand my post:

I meant optional arguments, in the sense that you give them and "initial" value:
void foo(int i, bool b = true); //"b" is optional and when not given that argument is initialized at "true"

But I didn't read your post very well either, I just realize you can still keep the "old" behaviour (of considering the value 0 being an not included argument) by treating arguments as arrays.

ow and not entirelly on topic: is there any indication that the (arbitrary) limit of 16 maximum number of arguments will be lifted some day?

Edited by paul23, 08 April 2011 - 09:19 PM.

  • 0

#16 JonathanPzone

JonathanPzone

    GMC Member

  • GMC Member
  • 1215 posts
  • Version:GM:Studio

Posted 08 April 2011 - 10:11 PM

Yea.

I never realized it behaved this way anyway. :mellow:
  • 0

BRB 3 years for University


#17 Maarten Baert

Maarten Baert

    GMC Member

  • GMC Member
  • 750 posts
  • Version:GM8.1

Posted 08 April 2011 - 11:08 PM

I like the 'Dim' approach, I think it's far better than resizing arrays automatically. This would also mean we can finally delete huge global arrays to save some memory, instead of just forgetting them.

argc sounds good too, however I think the name is confusing. Since the arguments are called argumentN or argument[N], the number of arguments should be called argument_count or similar.

I'd also prefer 'dim' instead of 'Dim', but that's just a detail.

While we're talking about varargs, could you please fix external_define? Currently it requires entering the type of all external arguments (ty_real/ty_string), even though functions with more than 4 arguments can't use strings. If I don't add ty_real for every single argument, the function will display an error message. This also means the number of arguments for external functions is limited to 11 instead of the claimed 16, since external_define uses 5 arguments already and doesn't accept more than 16 arguments either. I know it's not really a big issue since extensions are easier and faster anyway, but I use external_define/external_call all the time during development (especially for ExtremePhysics). I don't want to create a new GEX, install it, create a new EXE, and run it with the Visual Studio debugger every time I change something to the DLL.

It would be even better if you could remove the 4 argument limit for strings (without a huge number of if/else statements). Maybe with some inline assembly? Or some hackery :P.

For example:
double myfunction(double x, const char* y, double z) {
    printf("x = %f\n", x);
    printf("y = %s\n", y);
    printf("z = %f\n", z);
    return 0.0;
}

You can call it like this:
struct memblock {
    char mem[sizeof(double)*16];
    inline unsigned int write_real(double x, unsigned int pos) {
        *((double*)(mem+pos)) = x;
        return pos+sizeof(double);
    }
    inline unsigned int write_string(const char* x, unsigned int pos) {
        *((const char**)(mem+pos)) = x;
        return pos+sizeof(const char*);
    }
};

double (*funcptr)(memblock) = (double (*)(memblock))(&myfunction); // horrible hack but it will work (for cdecl at least)

memblock m;
unsigned int pos = 0;
double res;

// call function
pos = m.write_real(5.0, pos);
pos = m.write_string("hello world", pos);
pos = m.write_real(42.0, pos);
res = (*funcptr)(m);
It works for cdecl. For stdcall you have to add some inline assembly to fix the stack pointer:
unsigned int stack;
__asm {
    mov stack, esp;
}
res = (*funcptr)(m);
__asm {
    mov esp, stack;
}
It does result in a 'Runtime Check Failure' in Debug Mode, but it works :). I'm not sure whether this is possible in Delphi though. If it's possible, you won't need the calling convention anymore.
  • 0
Posted Image

#18 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 09 April 2011 - 12:07 AM

It would be even better if you could remove the 4 argument limit for strings (without a huge number of if/else statements). Maybe with some inline assembly? Or some hackery

I actually provided the code involved in the suggestion topic for the string limit ability of GM....not sure why YYG team hadn't thought of it before. The code would actually go something like this:
void external_call(void far* f, gmvar* v, short c)
{
  for(register short i = c - 1; i >= 0; i--)
  {
    switch(v[i]->type)
    {
      case ty_string:
        asm(v[i]->str){push %0}
        break;
      case ty_real:
        asm(v[i]->real){push %0}
        break;
    }
  }
  asm(f){callf %0}
}

A better way is to actually write the 'for' and 'switch' as actual assembly so that the stack is guaranteed to not be used by the compiler during the 'push' sequences. For 'cdecl' you would create a separate function that would save the stack pointer prior to pushing values and restore it after the call (similar to a frame push/pop).



Ontopic:

Dim functionality sounds good, but I would rather see it either using string naming or as an actual statement, using parenthesis makes it feel like the result is what you are dimming. For example:

var i[10]; //dims 'i' as a 10 element array set to '0'
dim i[20]; //redims 'i' as a 20 element array, set the new elements to '0'
redim("i",30); //redims 'i' as a 30 element array, set the new elements to '0'

looks a lot better than:

dim(i, 20);

because "dim" is a statement, not a function call, while 'redim' can be used as a function call so that the name can be referenced rather than evaluated. Other notes: variable_local_dim, variable_global_dim for those that are not strict-scoped in 'var' context.


Arguments:

Never understood why GM does arguments the way it does....but if it'll make it faster, go ahead, it's still wrong though (they should be stack-implemented, position reference saved, and boundary checked when 'argument' is used...keeps everything in a single reference frame for recursion purposes and maintains speed of operation, and "freeing memory" is simply popping the stack pointer out of the frame).

Edited by sabriath, 09 April 2011 - 12:08 AM.

  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#19 IceMetalPunk

IceMetalPunk

    InfiniteIMPerfection

  • GMC Elder
  • 9603 posts
  • Version:GM:Studio

Posted 09 April 2011 - 12:41 AM

As long as we have an argc variable (or, to keep with GM's naming conventions, argument_count), that should be all we need. A double-check for unpassed parameters could also be useful for new users, but the argument_count is really all that's needed if you program correctly.

Instead of throwing errors, though, if you simply add in a NULL type, you can set the unpassed arguments to NULL and be done with it all.

-IMP ;) :)
  • 0

:GM123: Are you an artist who likes creating original creature designs? Maybe you can help out with Elementa here! Give it a look; you might like the idea :)

:bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny:


#20 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 09 April 2011 - 10:15 AM

I know that some begginer users write:

var i;
for (i=0; i<10; i+=1) {
    tab[i] = 1;
}

and then to access tab[0] they writing:

tab = 15;

This should also give error.
  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#21 BlueMoonProductions

BlueMoonProductions

    BlueMoonProductions

  • GMC Member
  • 241 posts
  • Version:GM:Studio

Posted 09 April 2011 - 10:20 AM

This should also give error.

You mean: variable and variable[0] should be separated.
  • 0

#22 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4735 posts
  • Version:GM:Studio

Posted 09 April 2011 - 10:39 AM

GameGeisha: No. There will be no change to the general mechanic. Dim just has better access to variable structures.

Smarty: Possibly... I'm not sure how GM would handle this. It would probably have to be a compulsory paramater if we do that. They are still variables, you can still assign things to them. However, if you only need 4 arguments, and assign to argument12, then GM wull assume you need 13 arguments because argument12 is used.

I'm not sure about "Treat initialized variables as value 0" yet. We might be able to allow that on array expansion, I dont know.

Medusar: We're not adding the named paramter thing. It'll get rewritten for the next version, so we're not spending ages changing it now.

paul23: Ah. sorry yes. Missunderstood. No, can't do that just yet. But if we add an argc you could assign defaults yourself.

Maarten Baert: argument_count - agreed. We're not changig any extern stuff in this version.

sabriath: Not sure about DIM syntax yet. Whatever is easiest to do I suspect. Lets not kid ourselves, its a fudge. Because we're going to rewrite it all, we're not going to spend too long fixing this one.

IceMetalPunk: No, won't be adding nulls. You shouldn't access arguments that haven't been assigned.

gnysek: Thats just the way its written. Won't change that just now.

Also, if we have an argument_count, we could throw an error if you access ourside the argument array as well. probably should.
  • 1

#23 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 09 April 2011 - 11:04 AM

The current idea, is that if you use argument[x], then it'll be as normal. So no checking. But most folk will use argument0, argument1 etc. All you'd have to do is rewrite your function to use argument[0] and argument[1] instead


I'm thinking about this dim... because now when I write script:
//myScript
if (argument3) draw_set_color(argument3) else draw_set_color(c_white);
draw_text(argument0, argument1, argument2);

I need to call it by myScript('text',0,0,0) in 8.1 (in 8.0 it can be myScript('text');).

You said, that argument[x] will be not checked in this case. But, since we use dim, If I'll write:
if (argument[3]) draw_set_color(argument[3]) else draw_set_color(c_white);
draw_text(argument[0], argument[1], argument[2]);
then use it as myScript('text');, argument[1..3] will be not set and give me error, because I need to use dim(argument,4), before right?

Edited by gnysek, 09 April 2011 - 11:05 AM.

  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#24 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 09 April 2011 - 12:29 PM

@gnysek, your coding is terribly implemented. You are checking if an argument is '0' in order to check the boundary....Mike just stated that "argument_count" is a good idea, so you should be checking that instead.

if(argument_count > 1)
{
  //do stuff with argument[]
}

From reading what Mike is putting here, it seems that anytime 'argument' is used in this way, then it will allow variable argument assignment, where otherwise the highest value 'argument#' is used as the last parameter strictly. This means that it will be done at parsing and compile time, not runtime....it's as simple as doing a search of your scripts:

parsing:
-for each script
--does it use 'argument[]'...if so, mark this script as 'any number of arguments allowed'
--otherwise, look for all 'argument#', what's the highest '#', mark this script as 'requiring N arguments' where 'N' is #+1

compiling:
-when 'ident' is reached at any point and it is a script call
--if 'any number of arguments allowed' is marked, compile without errors
--otherwise if 'requiring N arguments', make sure 'N' arguments are supplied, give error if not


It's a pretty simple concept...so I don't see how a lot of you are not understanding.
  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#25 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 09 April 2011 - 01:53 PM

It was just the shortest example ;) But yes, with argument_count it's no longer a problem.
  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#26 NakedPaulToast

NakedPaulToast

    GM Studio/Mac/Win

  • GMC Member
  • 8588 posts
  • Version:GM:Studio

Posted 09 April 2011 - 02:55 PM

Dim(myarray,16);

OK

What about a two dimensional array?

Dim(myarray,16,16);

Oops.

I'm thinking:
dim(myarray[16]);
dim(myarray[16,16]);
  • 1

keep_crap_150_zpsd7af69c5.png


#27 TheMagicNumber

TheMagicNumber

    GMC Member

  • GMC Member
  • 5247 posts
  • Version:Unknown

Posted 09 April 2011 - 03:39 PM

If you're going to have a function to create arrays, don't name it dim.

@NPT: Although that would be nice, it doesn't really fit into GML.
  • 2

#28 Shadowrend

Shadowrend

    Master of Shadows

  • GMC Member
  • 3054 posts
  • Version:GM8

Posted 09 April 2011 - 03:42 PM

The "dim()", function would be cool, but it would also be nice that it has no capital letters ("dim" not "Dim"), for easier typing.

As for the script arguments, I sometimes don't type them on purpose.
For example, in my drop down menus, I have a script add_menu(NAME,SHORTCUT,SPRITE), If for example the script has no sprite, I would just type add_menu("Button","Ctrl+B"), and if it has, I'd add a ", spr_button" as argument3.

Also, I agree on the argument_count function, as it can be handy at some times.

PS: I also have one request. It is not about this one, but about the image editor. Could you instead of having, for example Blur, we have Small, Medium and Large, could we type a number instead (0-100).
  • 0

#29 paul23

paul23

    GMC Member

  • Global Moderators
  • 4083 posts
  • Version:GM:Studio

Posted 09 April 2011 - 04:06 PM

As for the script arguments, I sometimes don't type them on purpose.
For example, in my drop down menus, I have a script add_menu(NAME,SHORTCUT,SPRITE), If for example the script has no sprite, I would just type add_menu("Button","Ctrl+B"), and if it has, I'd add a ", spr_button" as argument3.

You notice that by doing this (I assume you hence check for "if argument3 == 0" or something?) you have a huge (potential) bug in your code? - The first sprite you create in a project has always index "0"...

On top of that, the current syntax is preserved by using argument[x], requires just a small rewrite of your scripts.

Edited by paul23, 09 April 2011 - 04:09 PM.

  • 0

#30 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts
  • Version:Unknown

Posted 09 April 2011 - 04:09 PM

You say you're going to rewrite all this, but wouldn't it be better to just put in the effort in the first place? It would be rather useless to have more ad-hoc implementations of the functionality you want only to remove it all in the next version.

The ideal solution would be to support arrays as first-class values (preferably dynamically resizable like in other dynamic languages):
var array = [ "some value" ]
show_message(array[3]) // error
array[3] = "hello world"
show_message(array[3]) // "hello world"
show_message(array[1]) // error

This way you could solve the arguments problem much more nicely, with an arguments array and then named arguments that refer to its elements:
// some_script(a, b, c)
do_stuff_with(a, b, c)
for (var i = 0; i < arguments.count; i += 1)
    do_other_stuff_with(arguments[i])
show_message(arguments[5]) // error

Optional arguments could be set up in the script editor to have default values the same way you name them:
// assume some_script(a, b = 3)
some_script(3)
some_script(4, 5)
some_script(6, 7, 8) // error

Finally, variadic arguments could also be set up in the script editor:
// some_script(a, *b)
// arguments is an array of [a, [stuff, in, b]]
// called as some_script(1, 2, 3, 4, 5, 6)

show_message(a)
for (var i = 0; i < b.count; i += 1)
    show_message(b[i])

It would be especially nice to support dictionaries/hashes/associative arrays/maps for keyword arguments:
// some_script(a, **b)
// arguments is an array of [a, {stuff = in, argument = b}]
// called as some_script("foo", bar = "baz", quux = "quux")

show_message(a)
for (var key : b)
    show_message(key + " => " + b[key])

Note that I'm not suggesting that everything be exactly this way, just that it have this functionality- the syntax could be very different and everything else would still be perfectly fine.

Edited by Rusky, 09 April 2011 - 04:13 PM.

  • 0

#31 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2687 posts
  • Version:GM:Studio

Posted 09 April 2011 - 04:42 PM

I don't like this entire argument thing. The first reason: you sacrifice backwards compatibility to GM8.0. Code that works in 8.0 could now be erroneous in 8.1 because not all arguments are used. So given this, this is more of a 9.0 thing than a 8.1 thing.

Also I think this makes things a lot less intuitive. Right now it's just argument0 to argument15 or argument[0] to argument[15] and they will always work and is very straightforward to understand. What you propose is that Game Maker secretly guesses the number of arguments from the code, and I hate computer programs secretly guessing what I mean by things. I much much prefer the ability to explicitly set the number of arguments myself. So what I would much prefer to this, is what the Extension Maker does. Every extension function has a setting "number of arguments" that can be set to 0, 1, 2, ..., 13, 14, 15, 16 or Arbitrary. Add the same setting to the script editor. Arbitrary is the default, this will be the same behavior as GM 8.0. A programmer that wants this can set the number of arguments to a fixed value himself. This way it is always optional, without having to change argument3 to argument[3] in every script, and as a bonus you keep backwards compatibility.

I also think adding a new function/variable argc to give you the number of arguments, would be a damn fine idea...

Please call this argument_count or argument_number. argc is just some a meaningless string of symbols, and one of the reasons I like GM is that it doesn't come with loads of meaningless names for functions and variables. Please conform to the current naming system. argument_count and argument_number are logical and meaningful names. argc isn't.

Edit: typo

Edited by Erik Leppen, 09 April 2011 - 05:52 PM.

  • 4

promo_briquidmini_500x150.png


#32 IsmAvatar

IsmAvatar

    Good Samaritan

  • GMC Member
  • 2411 posts
  • Version:GM8

Posted 09 April 2011 - 05:43 PM

Could we make it lowercase d dim, rather than breaking convention and starting with a capital letter?

Or frankly, even array_init would be great. That keeps to convention pretty well and avoids breaking things where people use "dim" as a variable.

Could you also make an array_free - or some method of freeing an array?

Edited by IsmAvatar, 09 April 2011 - 05:44 PM.

  • 3
Posted Image LateralGM is an IDE for editing GM files on Linux, Mac, and Windows.
We also house the GM File Format Documentation and other projects of that nature.
IsmAvatar.com | Examples | Scripts | Particles | DLLs | Credit Me
Email | Registered

#33 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2687 posts
  • Version:GM:Studio

Posted 09 April 2011 - 05:51 PM

Or frankly, even array_init would be great.

Note that this is not a normal GM function. I mean if this were a normal function,
array_init(myarray, etc.)
would try to read the value from the variable myarray and then execute the function on its value. However what is meant is using the name myarray. Actually, it is more like
variable_local_array_set("myarray", etc.)

Edit: What I'd like to see for this dim thing, is
dim myarray[2..10] = 1
which sets myarray[2] up to myarray[10] to value 1. And actually, the dim keyword could be omitted if two dots becomes a GML keyword denoting a range. Then we can simply have
myarray[2..10] = 1
and suddenly it looks a lot like just declaring a normal variable.

Edited by Erik Leppen, 09 April 2011 - 05:54 PM.

  • 3

promo_briquidmini_500x150.png


#34 Josh @ Dreamland

Josh @ Dreamland

    GMC Member

  • New Member
  • 455 posts
  • Version:GM8

Posted 09 April 2011 - 06:03 PM

Note that this is not a normal GM function. I mean if this were a normal function,

array_init(myarray, etc.)


would try to read the value from the variable myarray and then execute the function on its value. However what is meant is using the name myarray. Actually, it is more like


Ism was merely using the same parameter format forwarded by Mike with dim(i,20). It's clear that either he intends to change that behavior to accept references (which would be rather interesting), or he was speaking in a less literal sense.

I'd like to second the notion of array_init; Dim() breaks a long-standing convention, most people don't live long enough to type variable_local_array_set every time they want something done, and `dim' shadows a BASIC instruction.

That said, I'm also with Rusky on the proposal to allow i = [1, 2, 3], or for that matter, shamelessly steal from MATLAB and allow i = [1..20], or, though I can't imagine it, i[0..20] = 0. I'm not fond of the latter proposal, but i = array(20,0) would be fine. The first issue I believe you'll run into is that GM doesn't have default parameters, so the 0 must be explicit or the system must be modified. It also doesn't allow setting arrays... perhaps you could consider defining a new operator for array copy. Really, I'm just throwing out some ideas.

As for your script parameters, what I have done is this:
1) Move argument0 and co. into the script scope, as you seem to have already taken for granted,
2) Allow an unlimited number of parameters (any reference to argument# will be accounted for),
3) Default all used arguments to zero (so if they are passed, only necessary copying is done, while if they are not, no unused variables are set).

That introduces one vulnerability, namely, if you use only argument0 and argument256, you will end up with 256 parameters of useless slag. Considering how queer a scenario that is, I choose to ignore it completely and assume no one will ever notice.
  • 0

#35 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4735 posts
  • Version:GM:Studio

Posted 09 April 2011 - 07:09 PM

argument[ ] does not need to be "dim()'d", as it's already implicitly setup by the calling function and has filled in all the values for you. My preference would be to have accessing argument[argument_count+1] throw an error, because once you have access to the number of arguments there is no excuse to go outside them. Anyone got a valid reason?

Unfortunately, all this is RUNTIME, not compile time. This means you'll get a runtime error. Not my preference, but it's the simplest way of implementing it. If I did it any other way, it would take for ever to write; so runtime it is. Sorry.
Aside from that; yes. If you access only one argument; say argument12, then I'll expect 13 arguments to be passed. If you use argument[x] instead, then it simply won't bother checking argument counts.

dim(blah,16,16) - yes. Good point. I'll have to check, but I think I can have variable numbers of args in system functions.

dim is a well known BASIC function. It's also short, and easy to remember. I see no reason to call it array_init(). I'm happy to keep it lower case, and happy to rename argc (which, in C means argument count) to argument_count.

I've already said this. If you WANT to drop arguments, you'll be able to use the syntax argument[x].

I'm currently making no further changes to the image editor.

Rusky, this is a quick fix. We have countless issues with this kind of error. It's bad practice, and it's a bug waiting to happen for most folk. Everyone will simply forget to type the right number of parameters in now and then. So we're going to fix it now. The better and cleaner the code, the more we can do with it later.
I've also already said we won't be doing named arguments in this version.

Erik Leppen: I don't really care about backwards compatibility when the thing I'm breaking is bad coding and bugs. :)
LOL - it's hardly a GUESS!! You've accessed up to argument3 in your script, so you NEED to pass 4 arguments. Hows that a secret guess? You've already dictate how many arguments you'll be using by... well... using them in your script!

argument_count it is. I have no problem calling it that. (That said. Programming is FULL of abbreviation and funny names, you really should get used to them. If you want a fright, look up the SIMD instruction set, now there's a set of scary command names.) :)

I'll look into a way to free an array. I agree, it would be nice! Of course... we could make dim() resize it down as well.... dim(1) would be the smallest.

I would love to have one of these...

var arr[x][x]
dim arr[x][x]
dim array[x][x], 0


array[1..10]=?? could be interesting too.


However, all these would take significant work, not the least making sure we haven't broken everything else!! They modify the base syntax, where as dim() is just another command. So for this version, dim() it is. Sorry.

I've also already said we won't be adding extra parameters. We'd like to, but there are big issues with that. You'll only get that once we rewrite it all.

I agree. If some one only uses argument0 and argument3, then I say that's a bug, as clearly they'd have to pass 4 arguments for that code to work correctly! As I said before... not forcing this is a bug waiting to happen. Also consider newbies using argument1 instead of argument0, simply because they think it starts at 1.
  • 0

#36 paul23

paul23

    GMC Member

  • Global Moderators
  • 4083 posts
  • Version:GM:Studio

Posted 09 April 2011 - 08:49 PM

There's another thing I'm afraid happens here:

you make it sound like the error happens during script execution (script uses more arguments than caller provided). However the caller is in my eyes the one responsible to give the script the desired amount of arguments. I'm just hoping the error message makes this clear (that you made a mistake when calling the script not a fault in the script itself).
  • 0

#37 GameGeisha

GameGeisha

    GameGeisha

  • GMC Member
  • 5275 posts
  • Version:GM:Studio

Posted 09 April 2011 - 08:56 PM

I agree. If some one only uses argument0 and argument3, then I say that's a bug, as clearly they'd have to pass 4 arguments for that code to work correctly! As I said before... not forcing this is a bug waiting to happen. Also consider newbies using argument1 instead of argument0, simply because they think it starts at 1.

Is there anything wrong with teaching the newbies that numbering in programming usually starts at 0?

GameGeisha
  • 0

Latest Releases:

Due to a recent project failure, I will be taking a leave until the end of July for further self-study. If you have questions regarding content in my posts, please contact me through email.


#38 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2687 posts
  • Version:GM:Studio

Posted 09 April 2011 - 09:17 PM

What I am a bit worried about is that this argument behavior silently changes along with changes within the script. I mean, if the script changes, this can make all calls to it erroneous in one go. I mean, if I have a script with four arguments, that looks like this:
//function(a0, a1, a2, a3)
repeat argument3
{
  //do something with argument0, argument1 and argument2 only
}
Commenting out variable parts and replacing them by fixed numbers is a viable way of debugging things. So I could want to comment out the argument3 from the repeat statement and replace it with a fixed number, to see if it does what I want it to do. However when I do this, argument3 disappears from the code (as it's in a comment), making all calls to this script erroneous.

In GM8.0 everything keeps working as usual. However in GM8.1 the number of arguments has silently changed (yes, silently, unless GM's IDE shows me the argument count somewhere and I can see that it changes. It's obvious now, but it isn't in a 200 line script). Running the game would generate errors in the script call. This can be confusing, as I didn't even make changes to the script call. Also, to fix the problem, I don't need to fix the script call (as that is not the problem), but I need to change the argument count of this script back to 4. This can only be done by introducing argument3 into the code, e.g. like this:
var unused; unused = argument3
//rest of the script here
I think this is a very weird and counter-intuitive way of setting the number of arguments, may the need arise.

I'm perfectly happy with scripts having a fixed number of arguments. I'm just not very happy with Game Maker determining this argument count itself. If I, the programmer, can set the number of arguments, I'm perfectly fine with this, in fact I'd like it a lot. The only thing I don't like is that the argument count is implied, rather than explicit. I understand it's probably too much work to add an input field for that in the script editor, but I'm still not perfectly happy with the current approach.

 
Also, do I understand correctly that whenever the script contains argument[n], the number of arguments in the call is arbitrary? So can I do this:
return instance_create(argument0, argument1, argument[2]) //note the [2] here
and still call the script with any number of arguments, that could differ throughout the game? And what does argument1 give when I call it with one argument or fewer?
  • 1

promo_briquidmini_500x150.png


#39 Drara

Drara

    GMC Member

  • GMC Member
  • 325 posts

Posted 09 April 2011 - 09:32 PM

I can't realy stay behind all this thing. I use myself scripts with not fixed numbers of arguments too and I presume that when I don't give one or more arguments (out of lazyness), those arguments give 0.
Now we should switch to the array arguments instead, it's ok, but: As far as I know, accessing arrays is slower then accessing variables. So you would loose the speed up you may get at calling the thing by accessing the array...
I can't help but GM 8.1 is something like an update. It should be fully compatible with old projects in my oppinion without changes...
  • 0

#40 LSnK

LSnK

    NaN

  • GMC Member
  • 1188 posts

Posted 09 April 2011 - 09:47 PM

dim is a well known BASIC function. It's also short, and easy to remember. I see no reason to call it array_init(). I'm happy to keep it lower case, and happy to rename argc (which, in C means argument count) to argument_count.

Isn't fitting in with the existing functions reason enough? It's easier to learn a verbose naming scheme than a homogenueous one, and that ease of acclimatisation should be at the forefront when considering names for new features.

I'm guessing you grew up with a C64, but bear in mind that most GM users have no such exposure. If they've ever seen that syntax at all, odds are it was part of a GOTO joke. :p


Now we should switch to the array arguments instead, it's ok, but: As far as I know, accessing arrays is slower then accessing variables. So you would loose the speed up you may get at calling the thing by accessing the array...

It's technically slower, but the difference is so miniscule it's not even worth talking about.
  • 0

#41 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 09 April 2011 - 10:16 PM

If you want a fright, look up the SIMD instruction set, now there's a set of scary command names

Those aren't so scary....
pack
unpack
signed saturation
unsigned saturation
byte
word
double word
low
high
packed...
..add
..multilply
..subtract
..multiply then add
etc.

odds are it was part of a GOTO joke

Why does everyone hate 'goto' so much? How else do you break out of a second/third/Nth tier nested switch/for/otherloop block efficiently?



As for arguments in scripts...I just thought of something, what if you had:

execute_string("somevar = argument12;");

Obviously GM wouldn't know that "argument12" is being used...this severely breaks a vital piece of GM's coding ability, and what makes it versatile. Although I do agree that a boundary should be made, it should be left up to the programmer instead of automatic (Erik gives another example of such a failure in GM if used automatically).
  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#42 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1981 posts
  • Version:GM:Studio

Posted 10 April 2011 - 12:20 AM

If you want a fright, look up the SIMD instruction set, now there's a set of scary command names

Those aren't so scary....
pack
unpack
signed saturation
unsigned saturation
byte
word
double word
low
high
packed...
..add
..multilply
..subtract
..multiply then add
etc.

odds are it was part of a GOTO joke

Why does everyone hate 'goto' so much? How else do you break out of a second/third/Nth tier nested switch/for/otherloop block efficiently?



As for arguments in scripts...I just thought of something, what if you had:

execute_string("somevar = argument12;");

Obviously GM wouldn't know that "argument12" is being used...this severely breaks a vital piece of GM's coding ability, and what makes it versatile. Although I do agree that a boundary should be made, it should be left up to the programmer instead of automatic (Erik gives another example of such a failure in GM if used automatically).


About GOTO, as far as I know, its like a singleton. It is supposedly not recommended, but yet it is known to be useful and simply works. And I'm guessing because of how known that story is, it got turned into joke material, similar to Chuck Norris.

About execute_string, that would suck to lose that function. I'd rather risk GM not being able to detect arguments being used in strings than to lose that function. But that's just me. Sadly enough, execute_string somewhat falls into the same category I mentioned above about GOTO and the singleton.
  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#43 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9421 posts
  • Version:Unknown

Posted 10 April 2011 - 02:57 AM

Is there anything wrong with teaching the newbies that numbering in programming usually starts at 0?

While we're here, are we making character positions in strings start at 0? If we are teaching them numbering starts at 0, let's keep it consistent.
  • 0

#44 Desert Dog

Desert Dog

    GMC Member

  • GMC Elder
  • 6409 posts
  • Version:Unknown

Posted 10 April 2011 - 04:03 AM

After some thought, I give the array error thing a check.

I'm a bit more tentative about the fixed script argument thing, it reduces flexibility a touch, but the speed increase is worth it for me, so check that, too.

I am wondering about backwards compatability, though.
  • 0
HTML5 games for mobile:
HexDogs Bugz Burn! Captain George Golfing Block Memory

Games for Androids
*NEW* Word Dog - Published by Dangerous_Dave


Code: General Array Functions - GM-S friendly. sorting, shuffling. Includes a quicksort.
Use the quicksort to sort ds_lists 10-18 times faster than ds_list_sort()!

#45 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9421 posts
  • Version:Unknown

Posted 10 April 2011 - 04:24 AM

The fixed script arguments aren't reduced in flexibility, as anything you could do before can still be done but you will need to use the argument array (argument[x]) instead of the argument variables (argument0, argument1...).

As far as backwards compatibility goes, there are very few reasons why people should be having an unknown number of arguments, so almost no one should be doing anything that will now cause errors. Those that are can simply change argument0 to argument[0] and all is fixed.
  • 0

#46 TheMagicNumber

TheMagicNumber

    GMC Member

  • GMC Member
  • 5247 posts
  • Version:Unknown

Posted 10 April 2011 - 05:18 AM

var realOrStr;
dim(array, 10, 0);
Why not be consistent and have:
var realOrStr;
var array[10];
variable_array_clear("array", 0);
You could always have the var statement accept initial values, and assume the initial value for an array is for all elements.

GM is already C and Pascal style, don't add on crap from BASIC now.

Edited by TheMagicNumber, 10 April 2011 - 05:18 AM.

  • 4

#47 Manuel777

Manuel777

    InvaderGames

  • GMC Member
  • 3554 posts
  • Version:GM:Studio

Posted 10 April 2011 - 04:05 PM

GM is already C and Pascal style, don't add on crap from BASIC now.

Sometimes we can aaall agree with you TMN, sometimes :)

going back to the arguments stuff, i really liked the argc and dim() implementations.. but letme get this straight; calling a script:
MyScriptName(value,x,y,"Hello");
will have four arguments, so the argc will be four, and thats it.. you dont need to go trough all the 15 arguments to initialize them as zero.. i really never saw the point on that since no other languaje does it and it may turn buggy (as mike stated)
So, an error when you try to access argument[5] in the function above would be a nice idea, something like "Uninitialized argument [5] on function MyScriptName [blah blah]"
An here is where dim() comes in, in case you want to define initialized arguments as zero? Am-i-rite?? (if so i like it a lot)
  • 0

#48 broadsword

broadsword

    GMC Member

  • New Member
  • 345 posts

Posted 10 April 2011 - 04:20 PM

My only concern with the argument change is that I currently use it to overload scripts in GM. For example consider this function/script:

show_dialog(x,y,string,width,height,txt_speed,skip_key);

by adding the following to that script:

var width, height; //,etc...
width = 200;
height = 100;

if (argument3) width = argument3;
if (argument4) height = argument4;
//etc...

I can call show_dialog like this to use default values:

show_dialog(x,y,string);

Will this new error handling remove this functionality and if so, will there be any other way to overload a script in GM?
  • 0

#49 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1981 posts
  • Version:GM:Studio

Posted 10 April 2011 - 06:22 PM

My only concern with the argument change is that I currently use it to overload scripts in GM. For example consider this function/script:

show_dialog(x,y,string,width,height,txt_speed,skip_key);

by adding the following to that script:

var width, height; //,etc...
width = 200;
height = 100;

if (argument3) width = argument3;
if (argument4) height = argument4;
//etc...

I can call show_dialog like this to use default values:

show_dialog(x,y,string);

Will this new error handling remove this functionality and if so, will there be any other way to overload a script in GM?


It has already been stated that using the array method to access arguments(like argument[5]) would keep the old functionality.
  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#50 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4735 posts
  • Version:GM:Studio

Posted 11 April 2011 - 09:15 AM

okay... closing this one down now.

The rules are;

  • if you use argument0 to argument15, then you MUST supply up to that number in the argument list. So if you use argument2, you must supply 3 arguments - exactly.
  • If you use the argument array (argument[x]) then you are free to supply as many or as few arguments as you wish.
  • If you use both argumentX and argument[x], then you MUST supply up to argumentX, but are free to supply more if you wish. So if you use argument1 and argument[x], then you must supply at LEAST 2 arguments, but can then use any optional ones that have been passed in.
  • argument_count will hold the number of arguments passed. (0 is for no arguments passed)
  • accessing argument[argument_count] or higher, will throw an error.


If/When I come to do arrays (Prob won't get into 8.1, but not sure yet), I'll post those rules as well.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users