Bulldog 1.60 steals vs active forever

[TomTom]

Figured out what was blocking my test waypoints for 2Bit's latest British Bulldog map. It was something that Crapshoot once said in a pm but did not elaborate nor explain. When using aiscript control all actions are set to active forever. Except steal actions. Now many maps have steal actions with active set to 1 and there seems to be no problem. But in this map there are multiple steals in succession for both teams so the goal tracker counts up a fair bit. What I observed was that with the steals set active forever the g_action_info goal number did not count up and therefore were deactivated when the other team successfully delivered a couple more than your team.

So my question to other waypointers or Mal is have you seen this and is there any logic to it. It seems reversed. (I ask so it can be documented).

For you non-waypointers I might post a test version later but the sled, and team doors won't be supported. Indeed I think the team doors would require too much scripting to support so I have scripted them out for now.

[the bindlestiff]

I ran into a similar situation in Transmitter. Just a single steal in that map, though. Taking the object caused the goal tracker to increment, as usual, and the goal_num of the steal action remained at the previous value (which ensures that the steal action goes inactive). If another event occurred while a player was carrying the object (say, a major construction is built or a dynamitable object is destroyed), the goal tracker increments again. So far, so good. But if the object is then recovered by the opposing team and the goal tracker decrements, it doesn't decrement far enough to match the original goal_num of the steal action so the steal never becomes active again.

The fix for this situation is to force the goal_num of the steal to the current value, like this:

action X (the steal)
{
....

if_obj_home_true X
activateAction X
....
}

Perhaps this fix can be adapted to your situation.

I also encountered a similar problem with dynamitable objects in Transmitter. I needed to know whether a gate had been blown in a conditional test used in another action, but occasionally it would tell the program that the gate was intact when in fact, it had been blown up. The problem was very similar to the one described above. If the object had been stolen, then the gate blown, the gate's goal_num would be left at the value set by the steal and the goal tracker would increment further due to the dynamite action being completed. Then if the object was recovered, decrementing the goal tracker, the goal_num of the gate would then match that of the goal tracker and the program would think that it had not been destroyed.

The fix is simple, once you know what's going on:

action Y (the dynamite action)
{
....
deactivateAction Y
}

Hope this helps!

[TomTom]

thx the bindlestiff, yes that is the problem. After more testing; steal actions follow the goal tracker regardless of whether active forever or no, as long as they are home. Oddly enough I had previously coded a reactivation but commented it out for some reason. I guess I was worried by the rare delivery zombie. If you don't know what I mean by that, well a delivery Zombie is when the bot carrying stops one node short of delivering. The delivery action is active always and seems Ok, the last node has no special node flag. I guess the bot thinks it is at the delivery point somehow. The conceivable cause would be some interaction with another event, but since it is rare it is impossible to be sure. The work around is to route to the deliver node and to get the opposite team to kill the zombies should they occur.

---
Your second idea is interesting, but what I prefer to do is to test the action explode on the targeted func_explosive for that dynamite action. Since that type of action is set goal 0 active 1 it does not have the rare problem of testing actions with goal -1. The limitation to this are those dynamite actions not linked to a func_explosive (ex. linked to a func_construct), in which case a fake one can be scripted in. (BTW for the back gate in your transmitter (in fritz2_1.00.pk3) the action explode would be action_add 34 34 1 574 1 0 0)