polygone: Function overloading is possible in C++ (the language ENIGMA is written in).

action_single_argument(var arg1)
action_single_argument(var arg1, bool argument_relative)

Or, sometimes this is written:
action_single_argument(var arg1, bool argument_relative = false)
To indicate a default value if none is provided.

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.

Personally I'm a fan of passing an argument, as long as it doesn't introduce problems with variable arguments or such. It makes sense that way, since relative is kind of an 'argument' to the DND action, and not intended as a global variable. It saves the trouble of keeping it global. And, the conversion process is intended to mostly reflect the DND look, so introducing brackets muddies it up, since that's really only supposed to be introduced by the Begin and End (resp. up and down triangle) actions.

Yes, that's exactly the way it works.
In fact, at one point I had forgotten to reset argument_relative, so we had a bug, but it has since been fixed.
Actually, the way we handle it is to *always* set argument_relative prior to any action that allows relative. Maybe not the most efficient, but I don't think DND users are going to complain about an additional variable set before some DND actions.

However, as TGMG has pointed out, using an IF action before a relative action causes a problem with this conversion method:
* If Action
* Set Motion Relative

gets converted to:

Code Select Expand

if (blah)
  argument_relative = blah;
action_set_motion(blah);

Even though action_set_motion should belong to the if statement.
Solved by either:

Code Select Expand

if (blah)
  { argument_relative = blah; action_set_motion(blah);
or

Code Select Expand

if (blah)
  action_set_motion(blah,argument_relative_value);

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.

I've created a {{review}} template. All functions undergoing peer review should include {{review}} near the top. This will automatically categorize them and add a nifty little box on the right saying that it's undergoing peer review.
http://enigma-dev.org/docs/Wiki/Template:Review

Please feel free to improve upon the template and the categorization process if you are familiar with wiki templating/categorization.

Personally it would work for me since the topic would serve as a reminder. The process could possibly even be automated/streamlined by a bot.

I suppose that would work.

Generally at this point it's pretty easy to see which functions are user functions and which are GM functions, simply by virtue of the function existing in GM or not. Otherwise, it's fine if it appears on the wiki, it would simply be marked as a user function, and if it ultimately doesn't belong there, then we can delete it and just leave it on a User Functions forum.

I don't like the "wiki can be written later" mindset. It's procrastination for something that can be easily implemented now and will save us a bunch of work later. At the very least, we should consider having each submitted review function also have a wiki page.

I can see the value of both methods.
I agree with RetroX in that it's not a problem for us Mods to move the topics.
But I'm really drawn to TGMG's suggestion of using the wiki.
Function discussion can be done on the wiki under the Discuss page.
Unfortunately my biggest concern with using the wiki is that it's not frequented in the same way that a forum is. Although we can place a timestamp with every function on a function list wiki page (I envision a table with "Category | FuncName | Status | Date"), it's still not going to get the traffic needed for a good peer review process because it's much easier to see changes when the forum topic has "1 unread post" than visiting the History page of every function or visiting the Recent Changes area.

No, I don't think relative is treated as an argument. Instead, it's treated as an internal mechanism, probably not unlike how we've implemented it as a kind of global variable.

It's codematically generated when The Plugin translates your DND to code. Immediately prior to the code it will set argument_relative to true if it's relative, or false otherwise.

That's a good point. Ok, we'll consider custom folding around #something.

That's only applicable in Definitions.

Ah, ok. We'll consider custom indentation folding. Usually this would be simply achieved by surrounding the code with curly brackets.