PyTRG.py, Questions and bug reports Options

[poiuy_qwert Canada]

The Mojo and Artanis problem was a bug in interpreting units with subnames (the part after the <0>), and has been fixed.

The Leaderboard actions that require strings now accept the new keyword Default String to fix that problem.

Added the right-click menu to all text editors.

[bajadulce Santa Cruz, California]

I have been trying out LocUnlock today, and came across some things that are giving me troubles in PyTrg. I didn't want to post in LocUnlock because these issues appear to be PyTrg related and have nothing to do with that program. And so I modified my example in LocUnloc for trigs that appear to be working in PyTrg.

Here are my questions:
In trying to give mineral fields created by players to neutral players and so I created this:

CODE

Trigger(All Players):
    Conditions:
        Bring(Current Player, At Least, 1, Mineral Field<0>Type 3, Anywhere)
    Actions:
        GiveUnitstoPlayer(All Players, Player 8, All, Mineral Field<0>Type 3, Anywhere)
        PreserveTrigger()

And "anywhere" gets rejected by trig checker.
Parameter Error: 'Anywhere' is an invalid Location (value must be in the range 0 to 254, or the keyword Anywhere, which is Location 63)
Line 10: Bring(Current Player, At Least, 1, Mineral Field<0>Type 3, Anywhere)

So I changed it to:

CODE

Trigger(All Players):
    Conditions:
        Bring(Current Player, At Least, 1, 178, 63)
    Actions:
        GiveUnitstoPlayer(All Players, Player 8, All, Mineral Field<0>Type 3, Anywhere)
        PreserveTrigger()

And no reported errors?? huh?

Next bug/question:
My first attempt at a simple example for LocUnlock was to have All enemy SCV's lose 50% Hit points whenever a medic was created:

CODE

Trigger(All Players):
    Conditions:
        Bring(Current Player, At Least, 1, Terran Medic, Anywhere)
    Actions:
        ModifyUnitHitPoints(Foes, All, Terran SCV, Anywhere, 50%)
        PreserveTrigger()

Again I got the Anywhere error. so I changed it to:

CODE

Trigger(All Players):
    Conditions:
        Bring(Current Player, At Least, 1, Terran Medic, 63)
    Actions:
        ModifyUnitHitPoints(Foes, All, Terran SCV, Anywhere, 50%)
        PreserveTrigger()

And then got the following error:
Parameter Error: '50%' is an invalid Percentage (value must be in the range 0 to 100)
Line 12: ModifyUnitHitPoints(Foes, All, Terran SCV, Anywhere, 50%)

And this is where I appear to be stuck.. I tried just "50" without the percent and other things. What is the correct syntax? or is this a bug?

[poiuy_qwert Canada]

:X These are stupid mistakes on my part. Go into Libs\TRG.py, goto line 282 which is:

CODE

if condition == 'Anywhere':

and change it to:

CODE

if data == 'Anywhere':

For the second problem, goto line 775 which is:

CODE

if -1 < t < 101:

and change it to:

CODE

if -1 < p < 101:

Thanks for the report, i'll look into your LocUnlock problems soon.

[bajadulce Santa Cruz, California]

unit #204 is messed up.

SetDeaths(Player 1, 204, Set To, 1)

This tests ok etc. But if you return to the saved file you get:

SetDeaths(Player 1, Floor Hatch (UNUSED), Set To, 1) which isn't liked by the program.

I checked a few other units with the "unused" string such as #184 and #187, but their strings appear to have been changed. So this may be another one of those string conflicts like with raynor(vulture) raynor(marine) etc.

[poiuy_qwert Canada]

It's because of the ( and ) in the unit name, no other unit has those in its name in the default stat_txt. The ( and ) should be decompiled to TBL formatting but it doesn't seem to be doing that for those characers. For now you can either edit/change the stat_txt you use for PyTBL, use the find/replace window to replace the names with the ID when compiling, or manually put in the TBL formatting like:
SetDeaths(Player 1, Floor Hatch <40>UNUSED<41>, Set To, 1)

Sorry for the inconvenience, this has been fixed for next version, thanks.

[bajadulce Santa Cruz, California]

Sorry haven't had the opportunity to use the program much the past year. So no bug to report.. which is a bummer!

I do have a question about comments tho. I notice that the format is all comments are posted first with a string number and then referenced when needed. At least this is how my triggers constructed in map editors get decompiled in pytrg. I imagine this is so the comments are loaded first? The decompiles look like this:

CODE

String 4:
Initialize resources<0>

String 5:
Defeat<0>

String 6:
Victory<0>

Trigger(All Players):
    Conditions:
        Always()
    Actions:
        SetResources(Current Player, Set To, 50, Ore)
        Comment(String 4)

Trigger(All Players):
    Conditions:
        Command(Current Player, At Most, 0, Buildings)
    Actions:
        Defeat()
        Comment(String 5)

Trigger(All Players):
    Conditions:
        Command(Non Allied Victory Players, At Most, 0, Buildings)
    Actions:
        Victory()
        Comment(String 6)

Is there a different format one can use (when constructing or manually editing decompiled trigs) that allows these comments to be placed with their respective triggers? Or maybe at the beginning of each trigger? I'm looking for an alternative way to list the comments for ease of working with the code. And what would be the syntax for this? Guess I could experiment or maybe RTFM, but topic activity is always nice.. and fast! Go right to the source.

Maybe there's some form of this that can be used?:

CODE

Trigger(All Players):
    Conditions:
        Always()
    Actions:
        SetResources(Current Player, Set To, 50, Ore)
        Comment(Initialize Resources)

This above code is invalid, so perhaps something like this:

CODE

String 4:
Initialize resources<0>
Trigger(All Players):
    Conditions:
        Always()
    Actions:
        SetResources(Current Player, Set To, 50, Ore)
        Comment(String 4)
String 5:
Defeat<0>
Trigger(All Players):
    Conditions:
        Command(Current Player, At Most, 0, Buildings)
    Actions:
        Defeat()
        Comment(String 5)

String 6:
Victory<0>
Trigger(All Players):
    Conditions:
        Command(Non Allied Victory Players, At Most, 0, Buildings)
    Actions:
        Victory()
        Comment(String 6)

Well this last format appears to be valid. Is there a "cleaner" format you can suggest? This last one isn't too bad tho.

[poiuy_qwert Canada]

The reason its done like that is because of how triggers deal with strings, and because I didn't think about the Comment action. But text triggers should make the Comment action obsolete. The Comment action requires a string in the string table and its only use is organization in a map editor, while a code comment is just dismissed. So it would be something like:

CODE

# Initialize resources
Trigger(All Players):
    Conditions:
        Always()
    Actions:
        SetResources(Current Player, Set To, 50, Ore)

# Defeat
Trigger(All Players):
    Conditions:
        Command(Current Player, At Most, 0, Buildings)
    Actions:
        Defeat()

# Victory
Trigger(All Players):
    Conditions:
        Command(Non Allied Victory Players, At Most, 0, Buildings)
    Actions:
        Victory()

If you need to use the Comment action for some reason there is no easier/cleaner way then the ones you showed.

[bajadulce Santa Cruz, California]

I've been using PyTrg to actually build trigs for the last few evenings rather than just "convert" and it has been a great program. I'll probably never build another trigger in a map editor ever again.

I have 2 questions:
1. You've said there was no easier way to list strings, but it is quite difficult to keep track of what the last string # you've used when you start adding things in the middle of your text file. Is there no way to implement something like what was done with ProTRG? Guess that's why I prob should have kept the strings on top instead of this format seen below: :S

CODE

String 188:
Leader Board for Too Much Gold 2nd Pass<0>
Trigger(All Players):
    Conditions:
        ElapsedTime(At Least, 60)
        CountdownTimer(Exactly, 45)
    Actions:
        LeaderBoardResources(Default String, Ore)
        PreserveTrigger()
        Comment(String 188)

2. How can I modify my copy of PyTrg so that I don't have to use capital letters? What file would I have to alter? I'd like to use shorter descriptions as well. like pt(), trig(all), and et() for PreserveTrigger(), Trigger(All Players), and ElapsedTime()

[poiuy_qwert Canada]

1) No there is no way. Later down the line I plan for PyTRG be upgraded to use ProTRG once ProTRG is upgraded to compile to .trg's as well as SCMDraft triggers. You could however define constants to make it easier to remember.

CODE

String 188:
Leader Board for Too Much Gold 2nd Pass<0>
Constant TooMuchGoldComment:
String 188

....

Trigger(All Players):
    Conditions:
        ElapsedTime(At Least, 60)
        CountdownTimer(Exactly, 45)
    Actions:
        LeaderBoardResources(Default String, Ore)
        PreserveTrigger()
        Comment(TooMuchGoldComment)

2) You should only have to change Libs\TRG.py to make it work, but you'll need to edit PyTRG.pyw to get the correct hover information.

[bajadulce Santa Cruz, California]

This isn't really a bug, but a misprint in the documentation for move location:

MoveLocation(Player, Location, DestLocation, TUnit)
Looks to be:
MoveLocation(Player, TUnit, Location, DestLocation) which probably follows standard map trigger orders and most mappers prob know this order by intuition. Thank god for the nice error reporting! Or this would have taken me quite awhile to locate what I was doing wrong.

One funny thing to make a note of in terms of error reporting. In the following code, if one forgets to put the <0> at the end of a comment string, then the compiler will report something wrong with the next string (in this case string 2). Which can be a bit confusing at first. Don't know if it's possible to alert of this error?

CODE

String 1:
Move Location for computer and start AI<0>
Trigger(Player 4):
    Conditions:
        Command(Current Player, At Least, 1, 116)
    Actions:
        MoveLocation(Current Player, 116, Anywhere, Location 0)
        Wait(1000)
        RunAIScriptAtLocation(TMCx, Location 0)
        Comment(String 1)

String 2:
blaha blah
...
    Comment(String2)

Edit: I'll have to get back on the Location, DestLocation order after some game testing and confirm those areas are in the right order.

[bajadulce Santa Cruz, California]

Later down the line I plan for PyTRG be upgraded to use ProTRG once ProTRG is upgraded to compile to .trg's as well as SCMDraft triggers.

I like the ease of checking my trigs in PyTRG and the ability to compile to .trg's to import directly into editors like SCExtra is nice. Definitely having to build a separate map just to extract triggers so I can copy/paste them into my SCMDraft maps is a bit of a nuisance tho.

2) You should only have to change Libs\TRG.py to make it work, but you'll need to edit PyTRG.pyw to get the correct hover information.

All I have is the compiled .pyc files in Libs\Libs.zip?

EDIT:
I've hit a snag in PyTRG. I have a file that compiles with no errors but crashes if you try to import into Xtra Editor. Going to isolate the cause.

EDIT2:
Hmmm this is odd. If I cut the script in half and test the upper half it doesn't crash. If I test the bottom half of script it too doesn't crash? Only when the two are together. This is the fist time I've written a decent sized script without any proper comments (i.e ones that would show up in the map) as they were becoming a real pain in the ass. Am using StarEdit and XtraEdit to try and import. Prob should head back over to ProTRG as the resulting .trgs are kinda useless now that I am working almost solely with SCMDraft.

Here's my working version as well as the compiled one that will be easier to look at.
 PyTrg_trouble_00.txt ( 7.5K ) Number of downloads: 15
working version

Trigger(All Players):
Conditions:
Always()
Actions:
SetResources(Current Player, Set To, 2, Ore and Gas)
SetCountdownTimer(Set To, 60)
SetSwitch(Switch 9, Set)

Trigger(Player 1):
Conditions:
Always()
Actions:
RunAIScriptAtLocation(TL0x, Location 1)

Trigger(Player 2):
Conditions:
Always()
Actions:
RunAIScriptAtLocation(TL0x, Location 2)

Trigger(Player 3):
Conditions:
Always()
Actions:
RunAIScriptAtLocation(TL0x, Location 3)

Trigger(Player 4):
Conditions:
Always()
Actions:
RunAIScriptAtLocation(TL0x, Location 4)

Trigger(All Players):
Conditions:
Command(Current Player, At Least, 1, Terran Civilian)
Actions:
RemoveUnit(Current Player, Zerg Spawning Pool)
RemoveUnit(Current Player, Terran Science Facility)
RemoveUnit(Current Player, Terran Civilian)
SetDeaths(Current Player, Mineral Field<0>Type 1, Set To, 1)

Trigger(Player 5):
Conditions:
Command(Current Player, At Least, 1, Zerg Spawning Pool)
Actions:
RemoveUnit(All Players, Terran Control Tower)
RemoveUnit(Current Player, Zerg Spawning Pool)
SetSwitch(Switch 0, Set)

Trigger(All Players):
Conditions:
Switch(Switch 0, Set)
Deaths(Current Player, Mineral Field<0>Type 1, At Least, 1)
Actions:
MoveLocation(Current Player, Terran Science Facility, Anywhere, Location 0)
RemoveUnit(Current Player, Any Unit)
CreateUnit(Player 5, 3, Kakaru<0>Twilight, Location 0)
CreateUnit(Player 5, 1, Terran Command Center, Location 0)
CreateUnit(Player 5, 1, Terran Science Facility, Location 0)

Trigger(All Players):
Conditions:
Switch(Switch 10, Cleared)
Actions:
LeaderBoardControl(Default String, Protoss Observatory)
PreserveTrigger()

Trigger(All Players):
Conditions:
Command(Current Player, At Least, 1, Terran Control Tower)
Command(Current Player, At Least, 1, Duke Turret)
Actions:
RemoveUnit(Current Player, Terran Control Tower)
SetDeaths(All Players, Duke Turret, Add, 1)
SetScore(Current Player, Set To, 1, Custom)
RemoveUnit(Current Player, Duke Turret)

Trigger(All Players):
Conditions:
Command(Current Player, At Least, 1, Terran Control Tower)
Command(Current Player, At Least, 1, Tassadar<0>Templar)
Actions:
RemoveUnit(Current Player, Terran Control Tower)
SetDeaths(All Players, Tassadar<0>Templar, Add, 1)
SetScore(Current Player, Set To, 2, Custom)
RemoveUnit(Current Player, Tassadar<0>Templar)

Trigger(All Players):
Conditions:
Command(Current Player, At Least, 1, Terran Control Tower)
Command(Current Player, At Least, 1, Mojo<0>Scout)
Actions:
RemoveUnit(Current Player, Terran Control Tower)
SetDeaths(All Players, Mojo<0>Scout, Add, 1)
SetScore(Current Player, Set To, 3, Custom)
RemoveUnit(Current Player, Mojo<0>Scout)

Trigger(All Players):
Conditions:
Switch(Switch 9, Set)
CountdownTimer(At Most, 0)
Actions:
RemoveUnit(All Players, Zerg Spawning Pool)
SetSwitch(Switch 9, Clear)
SetSwitch(Switch 10, Set)

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Mojo<0>Scout, At Least, 4)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetSwitch(Switch 3, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Tassadar<0>Templar, At Least, 4)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 2, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Edmund Duke<0>Siege Mode, At Least, 4)
Actions:
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 1, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Mojo<0>Scout, At Least, 3)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetSwitch(Switch 3, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Tassadar<0>Templar, At Least, 3)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 2, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Edmund Duke<0>Siege Mode, At Least, 3)
Actions:
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 1, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Mojo<0>Scout, At Least, 2)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetSwitch(Switch 3, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Tassadar<0>Templar, At Least, 2)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 2, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Edmund Duke<0>Siege Mode, At Least, 2)
Actions:
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 1, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Mojo<0>Scout, At Least, 1)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetSwitch(Switch 3, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Tassadar<0>Templar, At Least, 1)
Actions:
SetDeaths(All Players, Edmund Duke<0>Siege Mode, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 2, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
Switch(Switch 10, Set)
Deaths(Current Player, Edmund Duke<0>Siege Mode, At Least, 1)
Actions:
SetDeaths(All Players, Tassadar<0>Templar, Set To, 0)
SetDeaths(All Players, Mojo<0>Scout, Set To, 0)
SetSwitch(Switch 1, Set)
PreserveTrigger()

Trigger(All Players):
Conditions:
ElapsedTime(At Least, 65)
Switch(Switch 1, Set)
Deaths(Current Player, Mineral Field<0>Type 1, At Least, 1)
Actions:
RunAIScriptAtLocation(Terran Expansion Custom Level, Location 0)

Trigger(All Players):
Conditions:
ElapsedTime(At Least, 65)
Switch(Switch 2, Set)
Deaths(Current Player, Mineral Field<0>Type 1, At Least, 1)
Actions:
RunAIScriptAtLocation(Expansion Terran Campaign Medium, Location 0)

Trigger(All Players):
Conditions:
ElapsedTime(At Least, 65)
Switch(Switch 3, Set)
Deaths(Current Player, Mineral Field<0>Type 1, At Least, 1)
Actions:
RunAIScriptAtLocation(Expansion Terran Campaign Difficult, Location 0)

Trigger(All Players):
Conditions:
ElapsedTime(At Least, 65)
Switch(Switch 1, Cleared)
Switch(Switch 2, Cleared)
Switch(Switch 3, Cleared)
Deaths(Current Player, Mineral Field<0>Type 1, At Least, 1)
Actions:
RunAIScriptAtLocation(Terran Expansion Custom Level, Location 0)

I might try and add some "comments" and see if this does anything. Almost appears to be a "size" issue. dunno. This was to be added to my PEAI trigs which are about 4x the length of this.

EDIT:
Yes, So I took about 30 minutes and went through the entire script copy/pasting a generic "comment" to every trig which was tedious as all hell. Now I get no errors in either Xtra or StarEdit. Guess I should just head back to ProTrg now... :S. Any easy way to export? lol. Will ProTRG ever get a decompiler?

here is the same script with "comments" added if you'd like to check for yourself:
 trouble.txt ( 9.41K ) Number of downloads: 11

[poiuy_qwert Canada]

This isn't really a bug, but a misprint in the documentation for move location:

MoveLocation(Player, Location, DestLocation, TUnit)
Looks to be:
MoveLocation(Player, TUnit, Location, DestLocation) which probably follows standard map trigger orders and most mappers prob know this order by intuition. Thank god for the nice error reporting! Or this would have taken me quite awhile to locate what I was doing wrong.

Ah, thanks!

One funny thing to make a note of in terms of error reporting. In the following code, if one forgets to put the <0> at the end of a comment string, then the compiler will report something wrong with the next string (in this case string 2). Which can be a bit confusing at first. Don't know if it's possible to alert of this error?

What is the error you get?

Later down the line I plan for PyTRG be upgraded to use ProTRG once ProTRG is upgraded to compile to .trg's as well as SCMDraft triggers.

I like the ease of checking my trigs in PyTRG and the ability to compile to .trg's to import directly into editors like SCExtra is nice. Definitely having to build a separate map just to extract triggers so I can copy/paste them into my SCMDraft maps is a bit of a nuisance tho.

Well I already stated I would make it compile to .trg, in fact thats already done, I just have to confim the parameters are compiled to the correct places then update the readme and release.

2) You should only have to change Libs\TRG.py to make it work, but you'll need to edit PyTRG.pyw to get the correct hover information.

All I have is the compiled .pyc files in Libs\Libs.zip?

I thought you had the source version? Only way to do it is with the source version

EDIT:
I've hit a snag in PyTRG. I have a file that compiles with no errors but crashes if you try to import into Xtra Editor. Going to isolate the cause.

EDIT2:
Hmmm this is odd. If I cut the script in half and test the upper half it doesn't crash. If I test the bottom half of script it too doesn't crash? Only when the two are together. This is the fist time I've written a decent sized script without any proper comments (i.e ones that would show up in the map) as they were becoming a real pain in the ass. Am using StarEdit and XtraEdit to try and import. Prob should head back over to ProTRG as the resulting .trgs are kinda useless now that I am working almost solely with SCMDraft.

Here's my working version as well as the compiled one that will be easier to look at.
 PyTrg_trouble_00.txt ( 7.5K ) Number of downloads: 15
working version

I might try and add some "comments" and see if this does anything. Almost appears to be a "size" issue. dunno. This was to be added to my PEAI trigs which are about 4x the length of this.

EDIT:
Yes, So I took about 30 minutes and went through the entire script copy/pasting a generic "comment" to every trig which was tedious as all hell. Now I get no errors in either Xtra or StarEdit. Guess I should just head back to ProTrg now... :S. Any easy way to export? lol. Will ProTRG ever get a decompiler?

here is the same script with "comments" added if you'd like to check for yourself:
 trouble.txt ( 9.41K ) Number of downloads: 11

Very odd, thanks for the report.

[bajadulce Santa Cruz, California]

I looked closer at this problem this morning as I was finally just too tired last night to look further into. Troubles like these are bitch to locate errors especially when after cutting the problem in half, both halves tested out ok.. But luckily for you I happen to be one of the best if not the best Trouble Shooting/Bug reporting peeps in the community.

Anywhoooo...

The error lies in
RunAIScriptAtLocation(TL0x, 1)

Both the numeral "0" and the letter "O" compile without errors as would probably any letters. ** I imagine that PyTrg is set up to allow users to import any custom script label they want. The Map editor however wants to see the Letter O not the number 0. Maybe a warning or something if PyTrg doesn't detect the standard labels?

** Yes.. just tested.

I forget how one would import a non-default labeled Ai script in StarEdit? I remember SCAIEdit3 used to make up new labels for "new" scripts and compile a stat_txt.tbl. How was that then entered into StarEdit? Would you run the modded files and then access the "campaign editor" from within the game? ... not that I have any plans to use another script, but am curious to the steps. I think SCAIEdit's tutorial script may do such a thing.

One funny thing to make a note of in terms of error reporting. In the following code, if one forgets to put the <0> at the end of a comment string, then the compiler will report something wrong with the next string (in this case string 2). Which can be a bit confusing at first. Don't know if it's possible to alert of this error?

What is the error you get?

Well since a picture is worth a thousand words, I'll spare you my ramblings:


.. now back to testing this new idea!

[poiuy_qwert Canada]

I looked closer at this problem this morning as I was finally just too tired last night to look further into. Troubles like these are bitch to locate errors especially when after cutting the problem in half, both halves tested out ok.. But luckily for you I happen to be one of the best if not the best Trouble Shooting/Bug reporting peeps in the community.

Anywhoooo...

The error lies in
RunAIScriptAtLocation(TL0x, 1)

Both the numeral "0" and the letter "O" compile without errors as would probably any letters. ** I imagine that PyTrg is set up to allow users to import any custom script label they want. The Map editor however wants to see the Letter O not the number 0. Maybe a warning or something if PyTrg doesn't detect the standard labels?

Hmm PyTRG should accept custom AI scripts but it should give a warning or possibly error if it doesn't detect the ID in the loaded aiscript.bin (in settings). I'll look into it.

I forget how one would import a non-default labeled Ai script in StarEdit? I remember SCAIEdit3 used to make up new labels for "new" scripts and compile a stat_txt.tbl. How was that then entered into StarEdit? Would you run the modded files and then access the "campaign editor" from within the game? ... not that I have any plans to use another script, but am curious to the steps. I think SCAIEdit's tutorial script may do such a thing.

You can use MPQDraft to create a StarEdit "mod", you can also use SCMDraft to load custom MPQ's. Also, if anyone didn't know, the stat_txt.tbl entry for AI scripts has no effect except being listed in the StarEdit GUI triggers instead of the AI ID.

One funny thing to make a note of in terms of error reporting. In the following code, if one forgets to put the <0> at the end of a comment string, then the compiler will report something wrong with the next string (in this case string 2). Which can be a bit confusing at first. Don't know if it's possible to alert of this error?

What is the error you get?

Well since a picture is worth a thousand words, I'll spare you my ramblings:
.. now back to testing this new idea!

Ah I see. Yeah I should implement some warnings if it detects "String #:" inside a string, though there is not much else PyTRG can do about it. ProTRG doesn't have this problem though ;P

[bajadulce Santa Cruz, California]

lol.. I'm not the most experienced mapper (obviously) so I didn't realize there was no "switch 0" in editors. So that was a bit confusing cross referencing my original with the editors.

ProTRG doesn't have this problem though ;P

Well tonight I'll convert back to ProTRG then especially since you've said you'll be including a .trg compiler even tho this is something I and most advanced mappers will have no need for as SCMDraft appears to be the main editor of choice.

... so expect to see some bug/error reporting in the ProTRG thread soon.

K, I'm through with this program. Hope I helped find the last of the bugs. Then again nobody will prob use this program much.

.... K, back to ProTRG we go!