Scripting problem
 

I've encountered a scripting problem where the script WILL NOT activate a set of actions. It's been very frustrating trying to make it work -- I've tried may different variations, checked and rechecked the action parameters and the script formatting, but nothing works.

The situation is this: in my map (mp_zion) it is possible to grab the "secret" documents BEFORE the dynamite action has been completed. If that happens, the Goal Tracker ends up at 1 when it should be 2, and the Group 2 escape actions don't get activated. To fix this, the escape actions must be controlled via scripting. If I allow the Goal Tracker to handle the Group 0 and Group 1 actions and I use the script for the Group 2 actions, the situation arises where the Group 1 and Group 2 actions are both active at the same time after the docs are taken. This spreads out and weakens the defense at a critical time.

To fix this, I want to use scripting for BOTH Group 1 and Group 2 actions, switching off Group 1 and switching on Group 2 when the docs are taken (and vice versa when they're recaptured). When the docs are retaken, this approach leaves me with Group 0 and Group 1 actions running at the same time (because the Goal Tracker reverts to 0 when the docs are recovered). This is not optimum but is better than diluting the defense when the docs are stolen.

The problem is that the three Group 1 actions DO NOT activate when the docs are recovered (whether the docs are taken first or the dynamiting occurs first). I am well within the 64-keyword limit per action and the 128-keyword limit per script. Strangely, the Group 2 actions activate and deactivate as they should! Here is a copy of the script (edited to remove most of the Group 2 actions for brevity):

MAPTYPE 0 //Single-objective map

action 0 // If the door has been DYNAMITED, then
{
// Connect the nodes through the door
node_connect 72 42 true

// Activate the Close-in Defense if docs haven't been stolen (Group 1)
if_action_false 2
activateAction 17
if_action_false 2
activateAction 18
if_action_false 2
activateAction 28
}

action 2 // Documents
{
// Toggle off/on the Close-in Defense (Group 1)
If_obj_home_false 2
deactivateAction 17
if_obj_home_true 2
activateAction 17
if_obj_home_false 2
deactivateAction 18
if_obj_home_true 2
activateAction 18
if_obj_home_false 2
deactivateAction 28
if_obj_home_true 2
activateAction 28

// Toggle on/off the Escape actions (Group 2)
if_obj_home_false 2
activateAction 4
if_obj_home_true 2
deactivateAction 4
if_obj_home_false 2
activateAction 26
if_obj_home_true 2
deactivateAction 26
if_obj_home_false 2
activateAction 34
if_obj_home_true 2
deactivateAction 34
// remainder of Group 2 actions omitted (8 more)
}
#EOF

I've carefully checked the action parameters and can find nothing wrong. The Group 1 and Group 2 actions look the same: action_group = -1, action_active = 0, action_allies/axis as required (most are roam or camp actions). When the docs are recovered, the Group 1 actions just do not activate (and I've confirmed this with may different tests). The Group 1 roams do not get visited after doc recovery or, in the case when the door is dynamited first, the defender bots wind up with "no valid goals."

Am I overlooking some limitation that I'm not aware of? Suggestions gladly welcomed. . .

Re: Scripting problem
 

From the sounds of it, all the actions other than the steal actions aren't active forever (i'm sure the steal actions aren't active forever, but you catch my drift i hope and in order for the following method to work you may have to make those active forever too). You should set those up if you want them to be active even if the docs are taken and just toggle them on/off in the script. It's not a problem with you're script per say, but if you want actions to be active across group numbers even under goal tracker altering conditions you have to make them active forever and then just disable/enable them in the script as you wish.

You can also deactivate active forever actions completely, say a dynamite objective is destroyed and you don't want the bots around there anymore. Again that can be done from within the script.

Hope that fixes the problem. :chinese:

Re: Scripting problem
 

Maybe try this for the dynamite action:

action 0 // If the door has been DYNAMITED, then
{
// Connect the nodes through the door
node_connect 72 42 true

// Activate the Close-in Defense (Group 1), these are toggled on / off in action 2's tests
activateAction 17
activateAction 18
activateAction 28
}

I have a suspicion that the if_action_XXX test is only working for dynamite actions (possibly causing other problems if used for anything but) and that the if_obj_home test in action 2 is only working after the first doc grab.

Re: Scripting problem
 

Thanks for the tips, guys, but I'm afraid that they didn't work.:thumbdown:

Crapshoot, I tried your suggestion about the dynamite actions, but the Close-in Defense actions still do not get reactivated when the docs are returned, leaving my axis bots to go insane without any valid goals.

Denny, I made the Close-in Defense actions "active forever" and changed their Group numbers from "-1" to "1." I also made the Steal action "active forever". But the Close-in actions still do not get reactivated when the docs are returned.

In all cases, the Escape actions in the script activate/deactivate properly with changes in the status of the Steal action. These actions are in the same script, use the same conditionals, and have the same properties as the Close-in Defense actions. But they work and the others do not. Doesn't make sense! :cursing:

I've dissected the scripts of several other maps where the same possibility of grabbing the documents ahead of the dynamite action exists. The script conditionals therein do not look any different from mine. If ALL the actions in the script didn't work, that would make some kind of sense. But if eleven of them work and three don't???

Re: Scripting problem
 

Shit, i didn't even think of that. Never make the actual objective actions (the one's linked to the actual objective say the docs or a door that needs to be blown up) active forever or you're gonna have problems (i.e. bots trying to take docs already transmitted, bots trying to plant dyno even after the objective is destroyed, etc.) it just doesn't work and besides the actual objectives carry over into the next group number until they are destroyed/completed.

So say you got 2 doors, and they are both group 0 if you destroy door A before door B then door B will carry over to group 1 and still be an active objective. If an objective is carried over into a group like this, it cannot increase the goal tracker after being destroyed. So say after the above happened with door B, if you destroyed it shortly after it moved to group 1 it won't increase the goal tracker to group 2.

In any case, you would make Camp, Alt Roam, Roam/Patrol and other actions active forever in this scenario and deactivate/activate those in the script. Aim actions i'd leave active forever regardless because a bot won't use an Aim action if it isn't linked for a camp action so those usually don't need to be activated/deactivated in the script unless you want to have the bot look in a different area after a certain objective is completed.

For you're situation i'd just keep all the actual objective actions at group 0 and just have the rest active forever. It should work because i've done similar stuff before, if you need help hands on, feel free to send me you're nav and aiscript to my e-mail and i'll set it up for you.

Re: Scripting problem
 

Hit the nail on the head - all of what you described is exactly what it would take to make zion work. :)

Re: Scripting problem
 

I've always had my Alt Roam and Aim actions "active forever." I had all my objective actions at Group 0 until I "thought" your tip indicated that I might have to make the steal action active forever (actually, I tried it both ways).

I have left the "Allied Escape / Axis Attack" actions at "-1" because they seem to work perfectly well that way. No problems with the script turning them on and off.

The "Close-in Axis Defense" actions are the trouble-makers. I have set them to "active forever," two in Group 0 and three in Group 1. They turn on initially via the Goal Tracker. The script turns them off when the docs are taken. BUT THE SCRIPT WON'T TURN THEM BACK ON AGAIN when the docs are recovered. Active forever or not, they just do not re-activate.

My original configuration used the Goal Tracker to control both the Forward Axis Defense (Group 0) and the Close-in Axis Defense (Group 1) actions. The script controlled the Allied Escape actions. The problem with this simpler approach is that if the docs are taken before the door is dynamited, the Forward Defense actions get turned on the same time as the Escape actions, leading to a fragmented Axis effort in recovering the documents.

That's why I'm endeavoring to use the script for the Close-in actions -- so they can be turned off when the Escape is in progress. Trouble is, they won't turn back on when required! Method looks good on paper, though. . .

Denny, I'll send you my stuff if I can figure out how to get the forum e-mail to accept atachments.


A few minutes later:

Ah -- you've got your email set up to "no emails" so I'll just post the waypoint files here. Anyone's welcome to solve my problem!

Re: Scripting problem
 

I think those actions that are causing problems need to be set at group -1 initially. I thought you had mentioned that they were?

If i'm not mistaken, actions that need to be toggled on and off should be set in group -1, although you can turn off any action with the script.

In any case, it will probably help to have someone like Denny to take a look.

Re: Scripting problem
 

Yeah, they were set to "-1" initially and were activated by the dynamite action, then turned off by the script when the docs were stolen and supposedly turned on again by the script when the docs were recovered. But they wouldn't turn on again! So now I'm trying the "active forever" thing.

My interpretation of "active forever" is an action that, once turned on, is forevermore immune to the state of the Goal Tracker. Once active, however, the action can be turned on/off by the script.

Is this correct?

Re: Scripting problem
 

I looked at it. Seems like a bug to me related to if_obj_home true and activateAction.

Re: Scripting problem
 

Crapshoot, thanks for taking the time to check it out. Seems like we've been through this before with the pathfinding bug.

Looks like my little "entry" map has its share of bugs! I must be good at attracting them -- maybe I should take a shower?

Re: Scripting problem
 

Need some deet really :p

There was another unexpected thing happening. The goal tracker was increasing to 2 on the doc grab after the door was blown. But, because both objective actions are in group 0, I thought that this wouldn't happen. I know that with 2 dynamite actions in group 0, it doesn't add to the goal tracker each time they are completed (only on the first one).

With the way things are set up with this particular map, in theory it shouldn't matter. But I thought i'd mention it for Mal...

Re: Scripting problem
 

My limited experience is that with two dynamite objs in group 0, only the first one to blow will increment the goal tracker. The other will not, as you mentioned. BUT with a steal obj, it WILL increment the GT even if it started in Group 0 and follows the dynamite plant. I think that there are different rules for dynamite and steal objectives.

Re: Scripting problem
 

I've been doing some testing since my last post. What I've found (and I don't understand why) is that three of the Close-In actions will reactivate correctly via the script, but four will not. Doesn't matter which two of the five actions are commented out. Doesn't matter how many of the Escape actions are being switched at the same time - two or ten.

It definitely has something to do with those actions. They are Roam and Camp actions, just the same type as the Escape actions which work flawlessly. Am I bumping up against some kind of limt?

My buddy the f0x just called -- we're going to play some more, so I'm off the forum for a few hours. Give the rest of ya time to think!

Re: Scripting problem
 

Hmm, Crapshoot may be right here about the bug because the script looks fine to me. Also to note, i believe the group number is ignored on Active Forever actions so i don't think you can set them to be active forever once the tracker reaches a certain goal number (i'm refering to those group 1 AF actions you have). I may be wrong on that though and if so please mal let me know because i would like to know that, i always thought AF actions are active no matter what and the goal number is ignored on AF actions. I do know you can turn them on/off within the script though, i asked mal to add that feature and he did awhile back so i do know you can do that.

I'll take another look at it here in a bit. Also when doing toggles in the script, you should put the activateAction toggle before the deactivateAction toggle (or the true before false), i'm not sure that's a problem but you never know.

Like for example you have...

If_obj_home_false 2
deactivateAction 6
if_obj_home_true 2
activateAction 6

I would have it like....

if_obj_home_true 2
activateAction 6
If_obj_home_false 2
deactivateAction 6

Well for some things anyway, worth a shot i guess. I'll look still, try not to get discouraged by the bugs and problems though, consider it the learning curve. :cowboy:

Re: Scripting problem
 

Steal actions will still advance the goal tracker, even if it was inherited, just because its a major game event. Dynamite will not. I may change this if it becomes a problem, especially for ET maps.

Re: Scripting problem
 

Yes, if turned on as "active forever", it stays on forever.

Re: Scripting problem
 

I'm glad my learning curve has been on a small compact map. I really don't mind finding problems and fixing them -- it's just that I don't know all the rules yet, so I never know if I've hit a bug or if I'm just breaking a rule somewhere.

I'll redo the scripts to make the "true/activate" conditionals come before the "false/deactivate" ones and try that out. What takes priority for the cases of "true/deactivate" and "false/activate"

I'm taking a short break while the f0x is milking his dwarf goats, but then we'll be playing again. We've just spent an hour playing zion -- it's a tough map to win (as allies) because the axis have a very small area to defend. We get killed a LOT, but have managed to win most of the rounds, sooner or later. I'm definitely having fun, both playing and waypointing!

Re: Scripting problem
 

Mal, is this a correct interpretation of the Active Forever flag?

Re: Scripting problem
 

Yes. I also found a bug with the return docs code: they won't run the scripts properly. They seem to run it fine when the docs are stolen tho.

Before you do anything else, give me some time to find the solution.

Re: Scripting problem
 

Knowing that there really is a bug in the works is half the battle in fixing it!

Yes, I've found that the "steal" works fine. I hope I've given you enough clues to help in tracking down why only a few of the "return" actions don't run while most of them work fine. I'll not make any more attempts to fix the script until I hear from you. Happy hunting again!!

Re: Scripting problem
 

Done - will be uploading the fix in a few moments. In about 10 minutes, go download the 53c .zip file and it should work for you now.


EDIT: its up right now!

Re: Scripting problem
 

Looks like it works. Nice job.

Re: Scripting problem
 

Great! The patch has fixed my puzzling script problem. Everything works properly now. Thanks for fixing it so promptly, Mal.

A few more tweaks and I'll have the map ready for public testing. Watch these pages for further announcements. . .