126 replies to this topic

[xXNeoREXx]

The original script execute a statement ONCE in a alltime event, like draw and does not repeat it...
and so you can set a variable and when you change it for a second it wont return to the first value...
+what paul23 said isn't that similar to my example...

Fine, making a difference between not defined, 0 and 1 is important to you. But why can't you use an array or a list and use 3 values for these states?

Because an "array name" can't be defined by a string: like variable[stringinvar]...
Imagine, defineing new varaibles by arguments given by executing a script, I don't want to have anything to do with the variable name, I want it to be automaticly defined.
And a function like what paul23 gave is not what I need becuase it makes the programber define the variable name.
(I want the program to define multiple variables in one shot, without my interaction... and it is possible with the "variable_local" functions...)

[Smarty]

Because an "array name" can't be defined by a string: like variable[stringinvar]...
Imagine, defineing new varaibles by arguments given by executing a script, I don't want to have anything to do with the variable name, I want it to be automaticly defined.
And a function like what paul23 gave is not what I need becuase it makes the programber define the variable name.
(I want the program to define multiple variables in one shot, without my interaction... and it is possible with the "variable_local" functions..

You're defining completely random variable names. The only way you can find them back is by assuming that your randomization might hit them again, so you can pick them up with variable_local_get. You do realize they're pretty much useless because you can't use them programatically, right? Unlike arrays, for that matter. And how exactly is newvar_14 more difficult to use than newvar[14]?

But if you mean that you really, really, really want to randomize both the name and the number, and you need a way to store completely random variable names with a value, then the map data structure would be able to do exactly the same thing for you.

[xXNeoREXx]

Because an "array name" can't be defined by a string: like variable[stringinvar]...
Imagine, defineing new varaibles by arguments given by executing a script, I don't want to have anything to do with the variable name, I want it to be automaticly defined.
And a function like what paul23 gave is not what I need becuase it makes the programber define the variable name.
(I want the program to define multiple variables in one shot, without my interaction... and it is possible with the "variable_local" functions..

You're defining completely random variable names. The only way you can find them back is by assuming that your randomization might hit them again, so you can pick them up with variable_local_get. You do realize they're pretty much useless because you can't use them programatically, right? Unlike arrays, for that matter. And how exactly is newvar_14 more difficult to use than newvar[14]?

But if you mean that you really, really, really want to randomize both the name and the number, and you need a way to store completely random variable names with a value, then the map data structure would be able to do exactly the same thing for you.

I don't think that you understand what I want to do...
Ill explain it with detail and give an example...
I want to make ONE script with ONE function that will create multiple variables with different names.

Draw Event:
script_execute(scr_test,"generated_variable1");
script_execute(scr_test,"generated_variable2");

draw_text(mouse_x,mouse_y,string(generated_variable1)+"-"+string(generated_variable2));

scr_test:
if !(variable_local_exists(argument0))
    {
    variable_local_set(argument0,false);
    }

if keyboard_check(vk_space) {variable_local_set(argument0,true);}
// If this script form if you press SPACE the variable wont return to be false.
// The problem you can't do this without the "variable_..." functions.

You will see at the debug of the object the new "generated_variable" showing up, a variable name that I generated from a string.
As Smarty said, I can use arrays too but to generate a new variable from a string I think you also need variable_local_array_set, which is obsolete too.

Now, can you find a way to do this without the "variable_..." functions? (EXACTLY THE SAME)

And also at the same topic, the execute_string function was declared obsolete too, which I used to create a string calculation into a result.
Does anyone knows how to calculate a string? without execute_string("return "+calstring)

[Smarty]

I'm trying to figure out why you're doing what you need to do. The only thing I can conclude is that you're trying to circumvent having to initialize variables, so that you don't have to spend an event on that (even though you consider it no problem to throw in an extra script for this). That is akin to wanting to be able to treat uninitialized variables as value 0.

The variables you're creating with your script are spelled out as static variables in the same script. This just doesn't make sense, you said you wanted to have 'randomly generated variables'. But if you know the draw event is going to use variables with specific names, then there is an excellent event where you can initialize them. It's cleaner in code and faster in execution. You're just making unreasonable demands for the sake of your particular coding wishes, and you're hurting yourself along the way. Your game will only work better without it.

And also at the same topic, the execute_string function was declared obsolete too, which I used to create a string calculation into a result. Does anyone knows how to calculate a string? without execute_string("return "+calstring)

GameMaker is a game engine, to have an expression parser built in wouldn't be very useful. However, it's not impossible to create a custom expression parser yourself. It's also much safer, because executing a user input string can break and even modify your game at runtime.

Edited by Smarty, 02 May 2012 - 02:54 PM.

[paul23]

And also at the same topic, the execute_string function was declared obsolete too, which I used to create a string calculation into a result.
Does anyone knows how to calculate a string? without execute_string("return "+calstring)

One of my engines in the extending forums section does exactly that - parse expressions given by a string. - It's also completely safe as unlike the execute_string it doesn't allow anything else than what you did allow (as programmer). - Only problem is that for calculations currently it uses variable_local_get/set -not to parse the expression, as the engine uses its internal map for this- but as a reference so it can change those.

When the dust settles & studio is released I will probably update those scripts to require all variables to be inside a map.

[xXNeoREXx]

I'm trying to figure out why you're doing what you need to do. The only thing I can conclude is that you're trying to circumvent having to initialize variables, so that you don't have to spend an event on that (even though you consider it no problem to throw in an extra script for this). That is akin to wanting to be able to treat uninitialized variables as value 0.

The variables you're creating with your script are spelled out as static variables in the same script. This just doesn't make sense, you said you wanted to have 'randomly generated variables'. But if you know the draw event is going to use variables with specific names, then there is an excellent event where you can initialize them. It's cleaner in code and faster in execution. You're just making unreasonable demands for the sake of your particular coding wishes, and you're hurting yourself along the way. Your game will only work better without it.

And also at the same topic, the execute_string function was declared obsolete too, which I used to create a string calculation into a result. Does anyone knows how to calculate a string? without execute_string("return "+calstring)

GameMaker is a game engine, to have an expression parser built in wouldn't be very useful. However, it's not impossible to create a custom expression parser yourself. It's also much safer, because executing a user input string can break and even modify your game at runtime.

It's just annoys me that I need to read the same comment every time... I want it the way I did it, if you can't find a way just say so... (That's my way of scripting, accept it)

And also at the same topic, the execute_string function was declared obsolete too, which I used to create a string calculation into a result.
Does anyone knows how to calculate a string? without execute_string("return "+calstring)

One of my engines in the extending forums section does exactly that - parse expressions given by a string. - It's also completely safe as unlike the execute_string it doesn't allow anything else than what you did allow (as programmer). - Only problem is that for calculations currently it uses variable_local_get/set -not to parse the expression, as the engine uses its internal map for this- but as a reference so it can change those.

When the dust settles & studio is released I will probably update those scripts to require all variables to be inside a map.

Thanks very much for clearing that up, your solution extension is acceptable, although I don't get why its "safer".

[Smarty]

It's just annoys me that I need to read the same comment every time...

Maybe you should take the hint then.

I want it the way I did it, if you can't find a way just say so... (That's my way of scripting, accept it)

You'll have to do things differently. Accept it.

[xXNeoREXx]

It's just annoys me that I need to read the same comment every time...

Maybe you should take the hint then.

I want it the way I did it, if you can't find a way just say so... (That's my way of scripting, accept it)

You'll have to do things differently. Accept it.

That made me laugh.
Okay then Ill let go and "wait for a extension" with the obsolete functions included.
And here's a thing to think about; what about instead of defining the variable name your self, let the player do it... how can you do that, Mr Accept it (lol)

[alexandervrs]

I am okay with most of them, since they can be recreated using an Extension pretty easily.

Although,

set_synchronization

should not be obsoleted. Maybe moved under a more categorized name like display_set_vsync() but not removed.

Reason is that sometimes vsync causes unnecessary lag and even worse input lag depending on the monitor or graphics card.
I usually load and apply that setting from an options.ini file, so I'd like to be able to change this at runtime instead of having to distribute 2 executables (not pretty).

Many Windows games usually let the player turn vsync on and off from the options screen or an utility.

Edited by alexandervrs, 03 June 2012 - 01:44 PM.

[kburkhart84]

It's just annoys me that I need to read the same comment every time...

Maybe you should take the hint then.

I want it the way I did it, if you can't find a way just say so... (That's my way of scripting, accept it)

You'll have to do things differently. Accept it.

That made me laugh.
Okay then Ill let go and "wait for a extension" with the obsolete functions included.
And here's a thing to think about; what about instead of defining the variable name your self, let the player do it... how can you do that, Mr Accept it (lol)

If you want the player to define the name, use a dictionary to do it. Each line holds two things, the "name", which would be the index, and the "value" which would be the contents. So if the player decides to name it "variableIWant" you would add an index to the dictionary, with "variableIWant" as the index and whatever you need for the value. Then, later, you can access through the ds_* functions the contents of the "variableIWant" variable via that index.

***Side Note

You really need to grow up a little. What matters is the end result, not that you did it "your" way. What has been suggested to you by the other posters works fine to get the end result, so just because it isn't "your" way doesn't mean its wrong. In fact, by forcing things to be the way you want it, you will either end up having to code workarounds, or be stuck on an older version of Game Maker. Most programming languages(and other game making tools) don't have an actual compiler included with the final executables like GM has had in the past. GM was the exception to the rule in this instance. C++ won't let you run C++ code from strings. That doesn't mean you couldn't create an "interpreter" for it, which would generally use switch statements to call predefined functions based on what is in the string, but that isn't the same thing as compiling code.

Final Verdict...Get used to it, or stay with older versions of the software. All over the industry, things change, sometimes breaking compatibility, and you either upgrade to get the new features, or stay with the old version. No one is forcing you to go away from version 8.x, or even older versions if you had bought them. Also, in almost all cases, when things get broken from updates, it is for the better anyway. By removing the compiler from GM's runner, the file size is smaller. It also makes it that much easier to go to fully compiled code eventually, which is a real winner, for size and speed, making GM far more capable of certain things that right now lag. Full compilation also makes it much harder to get at the original code. From a fully compiled executable it is next to impossible to attempt to get gml scripts from, because they no longer exist as GML, rather as compiled code. But, if Yoyo were to try to keep the compiler in, making dynamic code easy, they would never get all of these benefits. In fact, if I'm understanding correctly, it would be impossible for them to have a manner to create games for iOS(and maybe Android too) because Apple doesn't allow such "dynamic" code. In fact, the Unity devs were possibly going to have trouble with that. I'm not sure how they got around it, but I'm guessing it is because they don't have code changing at runtime.

[makerofthegames]

I want it the way I did it, if you can't find a way just say so... (That's my way of scripting, accept it)

You'll have to do things differently. Accept it.

That made me laugh.

Why? Is it funny to you that you're in denial?

[not_patrick]

You will be missed, cd_open_door().

[faissialoo]

Not if use a bit of vbs!

[Shadow10]

How can I use the Message Functions: text_type, button_type and input_type?

[Desert Dog]

Possibly worth noting, that recursion now only has a depth of 32.

So iterative it is!

[paul23]

hmm 32 is quite feasible to reach with any standard algorithm :/

[Snail_Man]

Hm. Nothing I really rely on is on there, and the stuff I do use have easy workarounds.

Do surfaces still work? They seem like just the kind of thing that wouldn't...

Edited by Snail_Man, 05 June 2012 - 01:00 PM.

[Nocturne]

Surfaces do work, yes... BUT (there had to be one) they should now be drawn to in the draw event, contrary to all previous GM versions, and screen_redraw/screen_refresh are no longer supported.

[Mike.Dailly]

hmm 32 is quite feasible to reach with any standard algorithm :/

If your going as deep as (or deeper) 32, then I'd suggest finding another way. You shouldn't really have to go that deep. It'll be hard to debug/follow and probably really slow.

You really shouldn't have to go that deep - or anywhere close to it.

[JuurianChi]

But the deeper it goes, doesn't it get easier? Or what?