ProTRG v1.1 (Topic)

PyMS and ProTRG developer

Very nice Cecil, and thanks for posting some of your experience with ProTRG, im a very glad! One thing that I thought you might want to know is an easier way to do the loops you showed. It doesn't make a big difference other then how many lines of code it is, but less lines of code to type is always nice. Its a combination of a for loop and the built in range() function:

Code

def Hyper():
#This line just defines the word Hyper as a function. Here is the function Hyper:

Trigger(1)
Always()
for Timer in range(63): # Timer will loop through the numbers 0,1,2...,61,62 (which is 63 numbers in total, so it loops 63 times)
Wait(0)
#The above 2 lines writes out Wait(0) 63 times

PreserveTrigger()

# The loop below is pretty much the same as the above for loop but demonstrates that you don't have to start at the loop at 0. The variable Loop will loop through the values 1,2,3 (3 numbers)
# Actually this line is equivalent to doing "for Loop in (1,2,3):"
for Loop in range(1,4):
Hyper()
#The above 2 lines fires the function hyper three times

Another thing is using a parameter in the Hyper function to say how many times to add the trigger would make it a little easier to use the Hyper function in new trigger files:

Code

def Hyper(times):
for Loop in range(times):
Trigger(1)
Always()
for Timer in range(63):
Wait(0)
PreserveTrigger()

Hyper(3)

Anyway, you're code is perfectly fine, these are just suggestions to help you be more efficient by having to type less. Thanks again for showing your experiments with it!

Can you use x--, instead of saying x = x-1?

None.

Ah, that looks much simpler poiuy. I've never seen the for in range loop before

And Falk, I don't think so. I just tried it out and kept getting compilation errors.

[Edit]I hope you get that update out soon to allow collapsibles, that way I can start on another mapping project here soon

Post has been edited 1 time(s), last time on Jan 18 2010, 6:11 pm by CecilSunkure.

None.

PyMS and ProTRG developer

There is no -- and ++ in Python. You could do it the way you showed, but also every mathematical operator can be used in assignment: x-=1

Ah, okay, so there is a -= += *= /= and %=, mmkay, thanks for that

None.

Quote from

poiuy_qwert

Not only that, but Trigger and all conditions and actions are actually Python Classes, and can be treated as such. For example, this results in the same thing as the first valid trigger above, just in a different way (and technically useless way. this is just for demonstration):

the_trigger = Trigger(1, 2, add=False)
Always(add=the_trigger)
preserve = PreserveTrigger(add=False)
the_trigger.add(preserve)
the_trigger.addTrigger()

This also demonstrates the "add" keyword parameter. It must always come last in the parameters, but can be useful. For Trigger's the add keyword parameter can be either True (1) or False (0) which defines if the Trigger is automatically added to the end of the internal trigger list or not. In the example above we chose to add the trigger later with the addTrigger method on our Trigger object. For conditions or actions, the add keyword can either be True (1) or False (0) to decide if the condition/action should be automatically added to the last trigger or not. If you supply a trigger object, like what the example does for the Always condition, the condition/action is added to that trigger. Another thing you can do since the Trigger's/conditions/actions are basic Python classes, is add them multiple times and to multiple triggers.

I'm really not understanding this. I'm unsure of what the things in red are meaning. For the orange text, why must it always be last in the parameters? Is the add keyword just a boolean variable, if so, why is it called add, that makes no sense. For the yellow text, what does that mean, could you elaborate more?

Maybe you could add in comments to the code explaining what each part does, because I can't understand the bulk of your last paragraph in my quote, and I don't understand the advantages of doing what you are doing.

None.

PyMS and ProTRG developer

Quote from

Falkoner

Ah, okay, so there is a -= += *= /= and %=, mmkay, thanks for that

Yep, in total there is: +=, -=, *=, /=, //=, %=, **=, <<=, >>=, &=, ^=, |=

Quote from

CecilSunkure

Quote from

poiuy_qwert

...

I'm really not understanding this. I'm unsure of what the things in red are meaning. For the orange text, why must it always be last in the parameters? Is the add keyword just a boolean variable, if so, why is it called add, that makes no sense. For the yellow text, what does that mean, could you elaborate more?

Maybe you could add in comments to the code explaining what each part does, because I can't understand the bulk of your last paragraph in my quote, and I don't understand the advantages of doing what you are doing.

I'll start with the internal and technical stuff, you might be able to understand by just reading the commented code below, i dunno. ProTRG works by keeping an internal list of Trigger's, at the end of the script it goes through the list and prints them out. Trigger, and all the conditions and actions are Python classes. When you do something like "Trigger(1)", you are creating and initializing a new Trigger instance. The __init__ method takes in an arbitrary arg list (any amount of Players) and keyword args (in this case only 1 keyword arg, "add" is accepted). In Python, keyword args must come after any "non-keyword" args. The "add" keyword arg decides whether the Trigger instance will be added to the end of ProTRG's internal trigger list (True, the default) or not (False). For conditions and actions, when their __init__ method is called they also take in an arbitrary arg list (in this case it doesn't just take players) and the add keyword arg. The add keyword arg decides whether the condition or action is added to the last trigger added to the trigger list (True, the default), not added (False), or if you pass a Trigger instance, it will be added to that Trigger instance.
Ok, now with all the technical details out of the way, i'll do your suggestion and comment the code to help a little more:

# Create a new Trigger instance, don't add it to the internal trigger list but set it to the variable "the_trigger"
the_trigger = Trigger(1, 2, add=False)

# Create a new Always instance, dont add it to the internal trigger list, add it to the Trigger instance in the variable "the_trigger"
Always(add=the_trigger)

# Create a new PreserveTrigger instance, dont add it to any Trigger instance but set it to the variable "preserve"
preserve = PreserveTrigger(add=False)

# Add the PreserveTrigger instance in the "preserve" variable to the Trigger instance in the variable "the_trigger" using the Trigger method "add"
the_trigger.add(preserve)

# Add the Trigger instance in the variable "the_trigger" to the internal trigger list using the Trigger method "addTrigger"
the_trigger.addTrigger()

There is no advantage in this case, its just an example to introduce the topic. Another example is given after that part in the readme which shows creating hyper triggers in a similar method and has an advantage (not that big of a advantage since its a small example) in how much memory is used.

Post has been edited 1 time(s), last time on Jan 18 2010, 10:54 pm by poiuy_qwert.

Oh I understand. That allows you to construct triggers out of trigger objects, and reuse those objects. The comments really helped a lot, especially the color coding. Perfect! I'll have to mess around with this soon, should I post up what I come up with again?

This is looking spectacular, I can't wait for that update to allow collapsible text. I want to try finishing up my RPG with this

(I get lost in my triggers, I don't know how Kaias manages with all his triggers).

Post has been edited 1 time(s), last time on Jan 19 2010, 6:28 pm by CecilSunkure.

None.

PyMS and ProTRG developer

Sure post up what you make, I wouldn't mind seeing!

If i have a chance when I get home I'll write up some steps so you can add the collapsable text manually until the next update (its just a fairly simple change in Notepad++'s user defined languages dialog).

The next update will be out soon, currently I only have to test .trg compiling and other new features, then update the readme.

Edit: Ok .trg compiling is working, I just have to check with staredit to see if the conditions/action parameters are compiled to the correct places, then do the hard part, update the readme :S and the update will be released

Post has been edited 1 time(s), last time on Jan 19 2010, 11:14 pm by poiuy_qwert.

When I get mafia v1.2 finished, I want to start porting some of my modules. Think you'll have those updates any time soon?

None.

PyMS and ProTRG developer

A couple days since i don't have access to a windows machine till then.

Well I'm not going to start porting for at least another few days anyway, so meh.

Isn't Python supposed to be cross platform or something, though?

Post has been edited 1 time(s), last time on Jan 24 2010, 5:18 pm by Tuxedo-Templar.

None.

PyMS and ProTRG developer

Yeah, I've been doing all my coding on my Mac, and I can of course update the readme on it too. I can't confirm the condition/action arguments are being compiled to the correct place in the .trg without testing them in StarEdit (need windows for that), and I can't compile a windows EXE without being on windows. If I had a trusted way to check my .trg's without StarEdit I could release the source version but I would still need a windows computer for the EXE release.

Now, I'm still trying to figure Python. Am I able to simply run those source files with a Python interpreter the same as I can run that executable?

None.

PyMS and ProTRG developer

The source version readme explains how to use it. The two real differences to a normal user is having to download+install Python, and having to put "python ProTRG.py" anywhere that an exe user would put "ProTRG.exe" (like in the command line or Notepad++ macro's). The benefit of having the source version is I can offer bug fixes between updates.

Edit: Well I've just gotten sick so I wont be able to get access to a windows computer till i get better probably. I have been updating the readme (Its now an html document) and doing some testing/more work on ProTRG until I get better.

Post has been edited 1 time(s), last time on Jan 26 2010, 2:53 am by poiuy_qwert.

I'm getting compile errors when I try to use the SetDeaths action. Here is my action: DC = SetDeaths(CurrentPlayer, Terran Marine, 8, dcamount). Here is my error file:

Code

Traceback (most recent call last):
File "C:\Documents and Settings\HP_Owner\Desktop\Junk\ProTRG\Tests\Test1.protrg", line 5
DC = SetDeaths(CurrentPlayer, Terran Marine, 8, dcamount)
^
SyntaxError: invalid syntax

Any idea why this error is popping up?

[Edit]Terran Marine needed to be a string: 'Terran Marine'.

[Edit]Oh, you posted while I was editing. Yeah, that was it. Thanks.

Post has been edited 2 time(s), last time on Jan 26 2010, 3:38 am by CecilSunkure.

None.

PyMS and ProTRG developer

I think its because of "Terran Marine", this is invalid even if Terran was a variable name. The correct ways to reference the marine are:
Marine
"Terran Marine"
0

Wait wait wait, you can name units based on unit ID? You, my friend, are a genius!

None.

Here is what I came up with for something to convert waits into death counts by inputing milliseconds, deaths of which player to manipulate, which type of unit to use as the DC, and the initiation trigger modifer (add, subtract, set to).

The output is three triggers. The first trigger is the trigger that starts the deathcount timer. The default condition is Always(), so you will need to configure your own condition. You can do this by adding in more conditions//actions to specific triggers, as shown below. The second trigger just constantly adds one death to the DC. The third trigger has a condition of the amount of DCs, converted from milliseconds, and sets the DC back to 0 to end the DC timer. Here is the code:

So basically, you modify the bottom 5 lines of code, then go in and make necessary change to the output triggers (or, if you know python, change all the code accordingly).

Code

#-->What players do you want these triggers to apply to? Change the numbers to the appropriate values.
Trigger1 = Trigger(1, 2, 3, 4, 5, 6, 7, 8, add=False)
Trigger2 = Trigger(1, 2, 3, 4, 5, 6, 7, 8, add=False)
Trigger3 = Trigger(1, 2, 3, 4, 5, 6, 7, 8, add=False)

#-->You can add more conditions to each trigger by following this format. Coondition1 is for a condition in trigger 1. Action2 is for an action in trigger 2.
Condition1 = Always(add=Trigger1)
Action1 = PreserveTrigger(add=Trigger1)

Condition2 = Always(add=Trigger2)
Action2 = PreserveTrigger(add=Trigger2)

Action3 = PreserveTrigger(add=Trigger3)

#This function takes the values input for manipulating the DC triggers and sets them to a couple global variables, as well as creating DC as a global variable to use in the next function.
def SetDC (player, dctype, modifier, dcamount):
global DC
global player1
global dctype1
player1 = player
dctype1 = dctype
DC = SetDeaths(player, dctype, modifier, dcamount, add=False)

#This function simply outputs all the triggers. Should be self explanatory.
def WaitDC (milliseconds):
dcamount = milliseconds // 83.3
Trigger1.addTrigger()
Trigger1.add(DC)
Trigger2.addTrigger()
SetDeaths(player1, dctype1, 8, 1, add=Trigger2)
Trigger3.addTrigger()
Deaths(player1, dctype1, 0, dcamount, add=Trigger3)
SetDeaths(player1, dctype1, 7, 0)

#-->Input here your parameters for your death count manipulating triggers (player, dc type, modifier, dc amount)
SetDC(1, 'Terran Marine', 8, 1)

#-->Input here your milliseconds.
WaitDC(1000)

I realize that this is pretty useless. Whatever

I'm not exactly sure how to make this more user friendly, due to the fact that in order for it to be re-usable, the user will have to modify their own conditions for the first trigger and last trigger. This can be done within this code, or by hand on directly in the output triggers.

Post has been edited 4 time(s), last time on Jan 26 2010, 6:32 am by CecilSunkure. Reason: Changing comments.

None.

Now that I think about, I'm starting to think .trg exporting will be pretty useless, actually. SCMdraft uses string recycling, so I just couldn't see myself wanting to use a Staredit-based option for trigger editing.

Plus didn't Staredit have problems importing/exporting locations with triggers?

None.