Old timers here might remember a script checking tool called Antero, which I released about 10 years ago. The basic purpose of Antero was to look for common errors in scripts, such as failing to activate actions or referencing deleted actions or units, in addition to checking for a bunch of bugs that you had to look out for in Myth 2 1.3 (most of which are long fixed now).
Anyway, I was looking at quickly writing a new version of this program, but I don't have the sourcecode of the original and can't remember half of what it did.
Would anyone find an updated Antero useful? If so, what features would you like it to have?
Script Verification Tool
Re: Script Verification Tool
i am sure you have this, but here's some of what Antero did.
======================== HELP! ==========================
Antero works with exported map action files.
To create one of these, open your map in Loathing, and choose
Export Map Actions from the Mesh menu.
Before describing what problems Antero will find for you, there are some
scripting limitations that it cannot check, as they are not limited to the
actions alone. These are known to cause of map crashes, so you would do
well to avoid them. They include:
Before describing what problems Antero will find for you, there are some
scripting limitations that it cannot check, as they are not limited to the
actions alone. These are known to cause of map crashes, so you would do
well to avoid them. They include:
* Do not have more than 400 units visible at one time. Antero does try
to warn you when this happens, but it can't know about units on your mesh
that aren't scripted.
* More than 700 map actions is a bad idea. Myth will run low on resources, and
strange things may begin to happen such as units stopping in their tracks, and
action trigger-times being ignored.
* More than 13 unit collections will cause problems. On some maps the
limit seems to be 12. This will result in the same problems as having too many
actions.
* Too many map action types can lead to trouble.
* Avoid MUNG like the plague, unless you really know what you're doing, or
unless you're only using it to Deactivate or Delete Actions. Deleting
should be used for actions that (a) are no longer active, and (b) will
never be activated again, as that will cause crashes. Used properly,
MUNG deleting can free memory and avoid the too-many-actions problems
mentioned above.
Ok, that done lets look in detail at what Antero tells you. Antero will
reference actual line-numbers in the map action file, so it may be a good
idea to have the file opened in an editor like BBEdit that can display
line numbers...
* EMPTY STATEMENTS. Such as "Activates on Success" but no values.
At the very least this shows where your script is incomplete.
At worst, the value could be a needed one (like Facing in a Platoon)
that could cause real problems if not fixed.
* ONE VALUE EXPECTED, and none or more than one provided.
* TWO VALUES EXPECTED, and other than 2 provided. For example, Radii
in a PLMO will work fine with zero values or 2 values, but not anything
else.
* ACTION LINKED TO ITSELF. Linked as in any statement (like Link)
that references other map actions. Pretty self explanatory eh?
* MOVT statement with more than 4 waypoints. A common newbie mistake,
as with more than 4 waypoints, the MOVT will not work.
* SQUA IMPROPERLY REFERENCED (POSSIBLY). Mostly, Squad actions
should only be linked from Initial Squad statements in platoons,
and potentially from Munger statements too. I've seen them used
as unit container actions, but any other context is bound to be wrong.
* INITIAL SQUADS STATEMENT. Antero will tell you if you use anything
other than a Squad action here.
* PLMO/PLSC. Antero will warn you if you reference one of these from
anywhere other than a Platoon's Initial State. It will also tell you
if you use anything other than a PLMO or PLSC in an Initial State.
* PLAT NEEDS INITIAL DELAY ONLY. If you put a trigger time on a PLAT action
it will pause for this period at every interpolate point, and you'll end
up with a very slow platoon. Setting Initial Delay Only will prevent this
from happening.
* UNNECESSARY DEACTIVATION. A contentious one perhaps. Where an action
that by definition will execute immediately & not hang around, and this
action is deactivated, Antero will tell you about it.
* RESULTS ACTION & GROUP UNIT CONTAINER ARRAY. These statements should
link to NONE-type actions.
* LINKS TO DELETED ACTIONS. Yes, Antero will warn you about these.
* DELETED MONSTERS. Ditto.
* SQUAD FACING NOT ZERO. This will cause trouble if not fixed.
* GEOM Actions that deactivate on execution. I've known of several
instances where this will fail to populate the Results Action
Identifier. Use deactivate on successful execution instead.
* GEOM Links with more than 25 members in the list. This was reported
as causing problems, hence Antero will tell you about it.
* UNIT LISTS WITH MORE THAN 32 MEMBERS. Another contentious one. Some
believe this directly responsible for crashes, while others think its
harmless. I belong to the former category, but its up to you to decide...
* ACTION DEFINED MORE THAN ONCE. This is allowable in Loathing, but whatever
you do, don't re-import your map-actions script as it will get it wrong.
* ACTION NEVER ACTIVATED. Pretty obvious what this means.
* UNKNOWN STATEMENT. There is something in your script that Antero doesn't
know about. If you find one of these, please report it to IronDuke at
andrewsumner at yahoo.com. The same goes for anything you think Antero
should be checking for, and currently isn't
==============================================================================
======================== HELP! ==========================
Antero works with exported map action files.
To create one of these, open your map in Loathing, and choose
Export Map Actions from the Mesh menu.
Before describing what problems Antero will find for you, there are some
scripting limitations that it cannot check, as they are not limited to the
actions alone. These are known to cause of map crashes, so you would do
well to avoid them. They include:
Before describing what problems Antero will find for you, there are some
scripting limitations that it cannot check, as they are not limited to the
actions alone. These are known to cause of map crashes, so you would do
well to avoid them. They include:
* Do not have more than 400 units visible at one time. Antero does try
to warn you when this happens, but it can't know about units on your mesh
that aren't scripted.
* More than 700 map actions is a bad idea. Myth will run low on resources, and
strange things may begin to happen such as units stopping in their tracks, and
action trigger-times being ignored.
* More than 13 unit collections will cause problems. On some maps the
limit seems to be 12. This will result in the same problems as having too many
actions.
* Too many map action types can lead to trouble.
* Avoid MUNG like the plague, unless you really know what you're doing, or
unless you're only using it to Deactivate or Delete Actions. Deleting
should be used for actions that (a) are no longer active, and (b) will
never be activated again, as that will cause crashes. Used properly,
MUNG deleting can free memory and avoid the too-many-actions problems
mentioned above.
Ok, that done lets look in detail at what Antero tells you. Antero will
reference actual line-numbers in the map action file, so it may be a good
idea to have the file opened in an editor like BBEdit that can display
line numbers...
* EMPTY STATEMENTS. Such as "Activates on Success" but no values.
At the very least this shows where your script is incomplete.
At worst, the value could be a needed one (like Facing in a Platoon)
that could cause real problems if not fixed.
* ONE VALUE EXPECTED, and none or more than one provided.
* TWO VALUES EXPECTED, and other than 2 provided. For example, Radii
in a PLMO will work fine with zero values or 2 values, but not anything
else.
* ACTION LINKED TO ITSELF. Linked as in any statement (like Link)
that references other map actions. Pretty self explanatory eh?
* MOVT statement with more than 4 waypoints. A common newbie mistake,
as with more than 4 waypoints, the MOVT will not work.
* SQUA IMPROPERLY REFERENCED (POSSIBLY). Mostly, Squad actions
should only be linked from Initial Squad statements in platoons,
and potentially from Munger statements too. I've seen them used
as unit container actions, but any other context is bound to be wrong.
* INITIAL SQUADS STATEMENT. Antero will tell you if you use anything
other than a Squad action here.
* PLMO/PLSC. Antero will warn you if you reference one of these from
anywhere other than a Platoon's Initial State. It will also tell you
if you use anything other than a PLMO or PLSC in an Initial State.
* PLAT NEEDS INITIAL DELAY ONLY. If you put a trigger time on a PLAT action
it will pause for this period at every interpolate point, and you'll end
up with a very slow platoon. Setting Initial Delay Only will prevent this
from happening.
* UNNECESSARY DEACTIVATION. A contentious one perhaps. Where an action
that by definition will execute immediately & not hang around, and this
action is deactivated, Antero will tell you about it.
* RESULTS ACTION & GROUP UNIT CONTAINER ARRAY. These statements should
link to NONE-type actions.
* LINKS TO DELETED ACTIONS. Yes, Antero will warn you about these.
* DELETED MONSTERS. Ditto.
* SQUAD FACING NOT ZERO. This will cause trouble if not fixed.
* GEOM Actions that deactivate on execution. I've known of several
instances where this will fail to populate the Results Action
Identifier. Use deactivate on successful execution instead.
* GEOM Links with more than 25 members in the list. This was reported
as causing problems, hence Antero will tell you about it.
* UNIT LISTS WITH MORE THAN 32 MEMBERS. Another contentious one. Some
believe this directly responsible for crashes, while others think its
harmless. I belong to the former category, but its up to you to decide...
* ACTION DEFINED MORE THAN ONCE. This is allowable in Loathing, but whatever
you do, don't re-import your map-actions script as it will get it wrong.
* ACTION NEVER ACTIVATED. Pretty obvious what this means.
* UNKNOWN STATEMENT. There is something in your script that Antero doesn't
know about. If you find one of these, please report it to IronDuke at
andrewsumner at yahoo.com. The same goes for anything you think Antero
should be checking for, and currently isn't
==============================================================================
Re: Script Verification Tool
Ive used antero a ton. Its a great program, I could use it for sure if it was updated to 1.7
Re: Script Verification Tool
Didn't know it existed until now. Via my method of scripting which is script a group and check to see if it works I probably wouldn't use this program, But I think it is a good thing for people who don't do it my way or newcomers to the mapping world.
Re: Script Verification Tool
I'd love an updated version of Antero. I had to stop using it when I got my intel mac. It'd be great if it had all the same useful information the original did, with the updated limits and stuff that 1.7(.2) has, so that you're not getting inaccurate errors. For example, unit containers with more than X units will cause antero to spit out warnings, when in fact in modern mythmaking unit containers dont seem to have limits anymore. I recall recently Jon God telling me he got something like 800 listed units in a single attack action, and it works (as the units are being controlled visible, any of them in that attack container would attack as expected). Otherwise, it was a pretty perfect program, I can't think of 'extra' features it never had that would be useful, but I'm sure someone else will think of some.
-
iron
- Site Admin
- Posts: 2006
- Joined: Thu Feb 26, 2004 1:21 am
- Location: diving out of the Sun at 10 o'clock high!
- Contact:
Re: Script Verification Tool
Thanks for that everyone, it really does help 
Man I wish I still had the sourcecode of the original Antero, hack program that it was.
I'll try to re-implement the original features at least, taking out the unit limitations, and perhaps putting a rudimentary user interface together (though someone else will have to do that for a Mac version).
Man I wish I still had the sourcecode of the original Antero, hack program that it was.I'll try to re-implement the original features at least, taking out the unit limitations, and perhaps putting a rudimentary user interface together (though someone else will have to do that for a Mac version).
Re: Script Verification Tool
you could always write it in something like PHP so it would be web-based. upload your file and it gives you a nice report suitable for printing, downloading, framing.iron wrote:I'll try to re-implement the original features at least, taking out the unit limitations, and perhaps putting a rudimentary user interface together (though someone else will have to do that for a Mac version).
online is a little less convenient, but it could be hosted by multiple people/sites and would be _completely_ platform independant.
-
iron
- Site Admin
- Posts: 2006
- Joined: Thu Feb 26, 2004 1:21 am
- Location: diving out of the Sun at 10 o'clock high!
- Contact:
Re: Script Verification Tool
For that I would need to learn this new-fangled PHP scripting toy language, and at my advanced years that's far from likely
(the last scripting languages I learned, and still use, are bash & AWK)
(the last scripting languages I learned, and still use, are bash & AWK)
Re: Script Verification Tool
Yes! Yes yes yes!
I can't think of new feature requests off the top of my head. Mostly it would be wonderful just to not get all the non-error error messages.
I can't think of new feature requests off the top of my head. Mostly it would be wonderful just to not get all the non-error error messages.
Re: Script Verification Tool
ok fair enough, what language are you planning on programming it in?iron wrote:For that I would need to learn this new-fangled PHP scripting toy language, and at my advanced years that's far from likely
(the last scripting languages I learned, and still use, are bash & AWK)
-
iron
- Site Admin
- Posts: 2006
- Joined: Thu Feb 26, 2004 1:21 am
- Location: diving out of the Sun at 10 o'clock high!
- Contact:
Re: Script Verification Tool
The original Antero was crunched out very quickly in C, and iirc the code was a total mess to look at, but I didn't care much as it was a bit of a throwaway proggy.
Now I've thrown it away, I wish I hadn't
I'd probably write it in C++ now, or do an AWK version & dig up my old AWK to C converter to make an executable...
Now I've thrown it away, I wish I hadn't
I'd probably write it in C++ now, or do an AWK version & dig up my old AWK to C converter to make an executable...
Re: Script Verification Tool
iron, you would *love* PHP. Seriously.
I'm a vintage programmer as well and loved programming C/C++ in a *nix environment for a long time. Then was heavily into Borland C++ and Delphi on Windows for years, but took all my favorite *nix tools with me (vi editor, awk, grep, etc.).
PHP is heavily based on C and adds lots of wonderful oo stuff (in the 5.3.x version) without all the cryptic syntax of C++ (which I slowly began to loathe over time). I've grown to love what PHP can do primarily because it is so easy to write code that follows your design without ever having to wrestle with syntax BS on the way.
I'm still going to dust off my Sanity/Ferret app one of these days(tm), which analyzes plugins not only for data (to mine out all the good stuff to toss in a db), but does some really nice mapmaker checks to be sure everything is proper (all the map settings you cannot verify easily via Fear/Loathing).
I wrote the original core to Sanity/Ferret back in the day in Perl. Then re-wrote it in Python, but found there were some aspects of Python that simply drove me nuts (it seems like 3/4ths of a language to me). Re-writing it in PHP was not only MUCH simpler, it was actually FUN, the way programming used to be back in the day (at least for me).
The only thing PHP doesn't do well is a stand-alone UI for desktops, although I believe there are some cross-platform ones floating around these days.
Anyway, just had to plop down my two cents on PHP.
I'm a vintage programmer as well and loved programming C/C++ in a *nix environment for a long time. Then was heavily into Borland C++ and Delphi on Windows for years, but took all my favorite *nix tools with me (vi editor, awk, grep, etc.).
PHP is heavily based on C and adds lots of wonderful oo stuff (in the 5.3.x version) without all the cryptic syntax of C++ (which I slowly began to loathe over time). I've grown to love what PHP can do primarily because it is so easy to write code that follows your design without ever having to wrestle with syntax BS on the way.
I'm still going to dust off my Sanity/Ferret app one of these days(tm), which analyzes plugins not only for data (to mine out all the good stuff to toss in a db), but does some really nice mapmaker checks to be sure everything is proper (all the map settings you cannot verify easily via Fear/Loathing).
I wrote the original core to Sanity/Ferret back in the day in Perl. Then re-wrote it in Python, but found there were some aspects of Python that simply drove me nuts (it seems like 3/4ths of a language to me). Re-writing it in PHP was not only MUCH simpler, it was actually FUN, the way programming used to be back in the day (at least for me).
The only thing PHP doesn't do well is a stand-alone UI for desktops, although I believe there are some cross-platform ones floating around these days.
Anyway, just had to plop down my two cents on PHP.
Re: Script Verification Tool
Please post this Sanity/Ferret app
Re: Script Verification Tool
good luck, i've been trying to prod Baak into releasing this for years.GodzFire wrote:Please post this Sanity/Ferret app
<prod><prod>
ps. it's an amazing thing btw. i've been dreaming about it since i first heard of it.