PyTRG.py

[poiuy_qwert]

[quote name='bajadulce' post='9080' date='Jan 22 2010, 02:51 AM']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.[/quote]
Ah, thanks!

[quote name='bajadulce' post='9080' date='Jan 22 2010, 02:51 AM']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?[/quote]
What is the error you get?

[quote name='bajadulce' post='9094' date='Jan 24 2010, 03:13 AM'][quote name='poiuy_qwert' post='8982' date='Jan 12 2010, 08:09 PM']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.[/quote]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.[/quote]
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.

[quote name='bajadulce' post='9094' date='Jan 24 2010, 03:13 AM']

2) You should only have to change LibsTRG.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 LibsLibs.zip?[/quote]
I thought you had the source version? Only way to do it is with the source version

[quote name='bajadulce' post='9094' date='Jan 24 2010, 03:13 AM']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.
[attachment=2629:PyTrg_trouble_00.txt]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:
[attachment=2631:trouble.txt][/quote]
Very odd, thanks for the report.

[poiuy_qwert]

[quote name='bajadulce' post='9096' date='Jan 24 2010, 12:19 PM']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?[/quote]
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.

[quote name='bajadulce' post='9096' date='Jan 24 2010, 12:19 PM']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.[/quote]
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.

[quote name='bajadulce' post='9096' date='Jan 24 2010, 12:19 PM'][quote name='poiuy_qwert' post='9095' date='Jan 24 2010, 08:02 AM'][quote name='bajadulce' post='9080' date='Jan 22 2010, 02:51 AM']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?[/quote]
What is the error you get?[/quote]Well since a picture is worth a thousand words, I'll spare you my ramblings:
.. now back to testing this new idea!
[/quote]
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