Action functions plugin writing

[TGMG]

Currently a few issues are caused by the way the enigma plugin write the actions into gml. Mostly due to the handling of "argument_relative" and possibly the writing of with statements.

Currently the lgm plugin will transform an action that has a relative checkbox into:
argument_relative=true
action_something()

Which causes a problem when the action_if is used without the block actions as it will produce:
if(false)
argument_relative=true
action_something()

So it will always call action_something even when the expression is false.
One way to solve this is to make the plugin automatically put both statements in a block which works fine apart from if statements that use the relative checkbox.
Since some if actions use relative the resulting code for alot of nested if statements would be:
if(action_if())
argument_relative=true
if(action_if_something())
argument_relative=false
if (action_if_something())

Which clearly doesn't work without the block actions.

The action_if_something is just any if action which has a relative checkbox.

So I propose the easiest solution to this would be taking in the argument_relative as an optional parameter for all the action functions, like so:
if(action_if())
if(action_if_something(arguments,true)) //true for relative
if (action_if_something(arguments,false))

You have to implement the action_if actions in order to see this effect otherwise enigma will complain about the functions not existing.

[polygone]

Why is argument_relative not passed as a function parameter from actions?

[RetroX]

I believe that it's done that way because of how the GML format is stored.  Otherwise, it probably would have been passed as a parameter.

[polygone]

Why are the argument_* global variables a different scope to the rest of the global variables? I can't use them inside function definitions...

[IsmAvatar]

polygone: Try to stay on topic here. Your question isn't really relevant. To answer your question, though, you should be able to use it. However it may not be defined in enigma, so it may be necessary to define it as a bool argument_relative in Definitions in order to use it.

[TGMG]

You can use it if you add it to the globals file, which I have done but deliberately not added to svn because of the problem I mention in this topic. The way to implement action functions may change as a result of this.

Does anyone have any objections to implementing the action functions like so:
void action_func( int required, bool argument_relative = false ) {}

Which means you can still call the function without the argument_relative parameter and it will fix the issue without having to figure out where the ending '}''s go with lots of nested action_ifs with argument_relatives.

[IsmAvatar]

What is int required?

As I said in the other topic, I'm fine with it as long as it doesn't introduce problems with variable arguments and such.

[Josh @ Dreamland]

If I may bud in, we have plenty of solutions to this issue.

1. Encase everything in {}.
{ argument_relative = true; action_do_shit(); }
2. Comma.
argument_relative = true, action_do_shit();
3. Parentheses and comma. This will solve if().
if((argument_relative=true, action_if(fuck_you)))
  ;

You'll find this more accurately mimics GM's behavior. Particularly the last one. (argument_relative = false, do_shit()) is rather form-fitting, syntactically.

IsmAvatar: `int required` is the required parameter. Int was an example. He was implying that the function would be backwards compatible, but would allow LGM to set an argument relative. I object because the additional stack push and assignment is baloney.

[IsmAvatar]

if((argument_relative=true, action_if(fuck_you)))
  ;

That really works? Done.

[Josh @ Dreamland]

Indeed. Even if it didn't, we could use && instead of the comma for true, and || instead of it for false, in the case of if().

[polygone]

I don't get? Isn't it just better to pass it as an argument anyway? It seems preferable for function calling.

[TGMG]

I would love that solution if it wasn't for the problem of GM conversion. The plugin only writes gml which is then passes to the enigma parser, which means that any system which maps = to == in expressions would fail.
It wouldn't matter but the huge number of gm games I have looked at use = in expression when they actually mean ==, the compile only picks up some of these as many of them are valid c++ which leads to logic errors which are a pain to debug.
But if the plugin is now passing an actual assignment in an expression how will this system work?

[RetroX]

Hey, TGMG.  Please inline functions in actions.h by prefixing them with the word "inline."  The one-line ones, anyways.

[TGMG]

Ah yes thanks RetroX, fixed now