A little question about Module System script.

[pjm2493]

I don't know what do (try_begin), and (try_end), . What is their fuction on the script?

Thanks.

 

[WookieWarlord]

Hmmmm.


It's like an 'if' statement, if all the conditions after (try_begin), are true, it will do the actions after it (you can use else_try as well).

(try_begin),
(eq, ":this", 1),
(neq, ":wookie_is_stupid", 2),
do this
do this
(else_try),
(eq, ":this", 2),
(eq, ":wookie_is_stupid", 1),
do this instead
(else_try),
do this 
(try_end),

The last part means if none of the 'try sections' meets the condition, do this instead.


I hope this helps at all?

 

[pjm2493]

Hmmmm.


It's like an 'if' statement, if all the conditions after (try_begin), are true, it will do the actions after it (you can use else_try as well).

(try_begin),
(eq, ":this", 1),
(neq, ":wookie_is_stupid", 2),
do this
do this
(else_try),
(eq, ":this", 2),
(eq, ":wookie_is_stupid", 1),
do this instead
(else_try),
do this 
(try_end),

The last part means if none of the 'try sections' meets the condition, do this instead.


I hope this helps at all?

Yes, you help me a lot ! I know how to use If, else, else if , etc but if you use (try_begin), what is the equal to if(something) then { } to the module system?

Thanks Wookie!

 

[WookieWarlord]

Yea I see how it could be confusing at first.
Instead of:

 if (condition) {
    action }

It is:

(try_begin),
condition
action
(try_end),

If you don't meet the condition it will just skip to below the (try_end),.

 

[pjm2493]

Yea I see how it could be confusing at first.
Instead of:

 if (condition) {
    action }

It is:

(try_begin),
condition
action
(try_end),

If you don't meet the condition it will just skip to below the (try_end),.

Thanks , and how can I make a lot of conditions?

 

[WookieWarlord]

You just add more conditions.

(try_begin),
condition1
condition2
condition3
action1
action2
(try_end), OR ELSE_TRY!

You can have however many actions and conditions you want, when the game gets to a condition that isn't met, it will go down to the next 'try_end' or 'else_try'.


EDIT: you don't actually need to have conditions, then actions in that order., it will just stop reading the try block any further when it gets to a condition that is not returned true.

 

[Caba`drin]

Important to note, the module system, in a way, treats all operations as an if-then. If you have code beginning with (eq, 1, 1), because that is true, it goes on to the next line. However, if the line reads (eq, 1, 0), NOTHING beyond that point will be read in the code because of the failure of that statement, UNLESS you have used a try block. A failure within a try block will kick you out of that block, but then code will continue to be read after the (try_end) regardless of whether or not it fails.

For example, take a look at this same question, posted a few days ago, in the Q&A thread and the answer:

This has been bugging me for a while now and, based on what I've tried and seen in the module system, I haven't been able to figure it out on my own.
I also haven't been able to find anything that explains this type of thing in any guides.

How exactly do the equality tests get handled? I've seen some stuff in the module system that, based on my experience and knowledge, seems to suggest one thing but in fact works in an opposite manner.

Does a check, for instance (eq, ":foo", ":bar"), that evaluates to false mean that nothing below it in the same scope, within the same (try_begin) (try_end), or whatever, will work?

("example",
   [
      (eq, ":foo", ":bar"),                # assume evaluates to false
         ... bunch of stuff down here ...  # none of this gets looked at, regardless of what it is, because the check above was false?
   ]
),

Is it only the next check/instruction?

("example",
   [
      (eq, ":foo", ":bar"),                # assume evaluates to false
         ... do one thing here ...         # doesn't get done because above check is false
      ... bunch of stuff down here ...     # this does gets looked at, even though that initial check was false?
   ]
),

Also, what determines whether to use the (else_try) block in a (try_begin), (else_try), (try_end) setup? How does the engine decide when it's appropriate to jump out of the initial (try_begin) block and take a look in the (else_try)? Assuming the second example above is what is indeed happening.

Chris_B, equality tests work as you demonstrate in "Example Script 1."

So, the usefulness of try blocks is you can have an equality test with a set of things to be done depending on the result of the test, but then after the (try_end), the script will continue regardless of the test.

("example",
   [
      (agent_is_alive),                  # unless true, nothing below happens
      (try_begin),
          (eq, ":foo", ":bar"),                # assume evaluates to false
         ... bunch of stuff down here ...  # none of this gets looked at, regardless of what it is, because the check above was false.
      (try_end),
      ... bunch more stuff            # this does get looked at, regardless of the eq test of foo-bar, but only if the agent is alive
   ]
),

As Wookie Warlord demonstrated "AND" is essentially just listing a number of conditions If _ AND _, Then ...is as he describes.

"OR" is accomplished by using (this_or_next|operation), followed by a normal operation...or another this_or_next if you wish multiple "OR"s

 

[WookieWarlord]

Thanks Caba'drin, I wasn't sure If I'd made that clear or not.
Feel free to ask any more questions here CTCCoco, I'll try and answer them all. (Note I am by no means an advanced coder, but I can help you with most basics).

 

[pjm2493]

Thanks for all, now I know how conditions work but what means this?

(eq, "$g_mt_mode", ctm_melee),
      (assign, ":total_difficulty", 0),
      (try_for_range, ":i", 0, ":training_param"),

What is that things? How I can use them?

Thanks.

 

[WookieWarlord]

":local_variable"

"$global_variable"

You can assign any value into these variables.
(assign, ":blah", "blah"),
(assign, "$blah, 2),
Anything like that,

Local variables can only be used in the script/trigger/whatever they are in, while global variables can be called from other scripts, in any file.

 

[Somebody]

Thanks for all, now I know how conditions work but what means this?

(eq, "$g_mt_mode", ctm_melee),
      (assign, ":total_difficulty", 0),
      (try_for_range, ":i", 0, ":training_param"),

"$g_mt_mode" is a global variable, assigned so the mission template knows which triggers to activate.
ctm_melee is a constant for the value that variable can take for its original purposes, although that doesn't restrict the value of the variable. Notice the lack of quotation marks. It gets changed to just a number defined in module_constants after you compile it.
":total_difficulty" is a local variable used within the scope of that script/condition/consequence/trigger. Here it is initialized to 0 - a standard practice if you are using it for incremental purposes.
":i" is a local loop variable - when you use try_for_range, ":i" starts off at the lower bounds, and while you can access (and change) this variable inside the loop, it will be set to the next value between the lower bound and upper bound after the loop's completion.
":training_param" is another local variable - here it is used for the upper bound for ":i". Since you can't break out of a loop by changing ":i", you can do so by lowering the upper bound, although its use here does not necessitate that.
Also, the compiler will complain if your global variable has the same name as your local. So $blah and :blah should not be used in the same scope - which is always true since $blah is a global.

 

[pjm2493]

Thanks, now I can understand how to create variables and conditions.

And now , If I create a map, how I can make some dynamic the map, I mean, for buy some things, for destroy things,etc?

 

[WookieWarlord]

I believe you are talking about scene props. You can add triggers to them that activate at such times as they 'initialise', are 'hit', are 'destroyed' or 'on use' (f button).
They are actually pretty darn useful!

 

[pjm2493]

I believe you are talking about scene props. You can add triggers to them that activate at such times as they 'initialise', are 'hit', are 'destroyed' or 'on use' (f button).
They are actually pretty darn useful!

Thanks Wookie! I will start do something now!

 

[Lumos]

I believe you are talking about scene props. You can add triggers to them that activate at such times as they 'initialise', are 'hit', are 'destroyed' or 'on use' (f E button).
They are actually pretty darn useful!

 

[havoc]

I'm 94.5% sure it's F.

 

[N0ught]

By default, yes - but us FPS veterans tend to remap the use key to E.

It just feels more natural.

I also bind kick to the middle mouse button.

 

[Lumos]

Yep.

 

[Berthout]

This thread is extremely useful!

Finally I understand what I'm doing. 
I sort of did before, but it still involved too much guessing.