1. I tried initially to setup steal operation for the flag entities. After a while into the gameplay the steal actions would appear with incorrect goal numbers and the bots would stop attempts to capture flags. So I had to replace the steal actions with roams to get around it. My question here is there a way to disable the goal tracker (via the .script perhaps?)

2. Using roams it becomes difficult to focus the bots to the flags. When no team steals a flag only a couple of defensive roam actions are active to give a chance to the bots to do capture attempts. I tried to channel these attempts using routes but for some reason I get mixed effects. Check routes 4,5, place near the CP to redirect bots to different areas for the objectives. Seems they don't work. Also the goal number of all the alt roams (although initially setup to -1) is set to 69 by fritzbot right from the start. I do not understand this. Where the 69 is coming from?

Never played this one before but getting killed at the gasoline/petrol pump is very familiar to me these days .

(1) I am pretty certain you came across the same problem as I did in Bulldog and the bindlestiff did in other maps. To be safe steal actions should be re-activated when ever they test if_obj_home_true. It has to do with the goal tracker remaining connected to the logic of what is active and what is not. Even though you and I may choose to not use goaltracker activation/deactivation (except 0) it is still used to calculate the on/off state. I think the bindlestiff explains it best in his post.

(2) Action_active 1 makes the action's g_action_info goal track the current goaltracker goal_num IF THE ACTION IS ACTIVE. Steals are special in that they track it when home, but not when carried. I suggest you read CrapShoot's wiki article Fritzbot_Goal_Tracker .

I think when you have got the steal actions back in and the node_ents set and some resetnodeFlag etc. in the aiscript for flags already delivered, you may want to turn your attention to where the flag carrier should go while waiting for the barrier to the truck is in place. You can direct the carrier to a safe spot to camp with what we call a fake delivery. Then when the barrier is gone deactivate the fake delivery and enable the real one. The fake delivery(s) require NO script changes. The bot will remain there knowing the flag delivery is incomplete. Alternately you can have no delivery active when the barrier is in place in which case the carrier is free to roam.
OH AND A HEADS-UP TO ANYONE TRYING THESE WAYPOINTS, THEY REQUIRE THAT THE KEYWORD FIX BETA BE INSTALLED.

Hi Tom, I am not sure how to do the if statements. I am not sure if fritzbot will accommodate it. Not sure if you did download the map and tried it yet in any case there're 7 flags for each team a total of 14.

Where action 11 is the axis capture (but only a possible one)
Actions 1-7 are the ally captures, 11-17 the axis captures. In order to know which is the last action valid for each group you need to check and activate the correct one. That is 7 keywords only for activate (without the conditionals which are needed as you don't want to activate actions that cannot be reached) for a single action. Now add the conditionals and multiply this by 14 (needed for each action) and you most likely run out of keywords.

I have the initial nav file that includes the steal actions and the flag entities. I can include it if you want, let me know. It was an initial phase to check the actions so not all nodes are present.

I like the concept of the fake delivery though I am going to try it. Also let me know if you need the darji2 pk3 file to post a link.

17 *12 + 9 * 2 = 222 plus default and command posts and optional fake deliver lines. It is tight but using your event explodes you save another 36-48 so likely do able. I would drop the activateAction_groups in default { } and use action_goal 0 (BTW the wait only affects the activateAction_group 0 in your default). Total action tests would then be 14 steals + 12 explodes + optional 3 = 29 which is ok. You should still have space to do fake deliveries in some of the flag tests. And that way sometimes they would roam and sometimes they would camp and wait. (Are logicals OR / AND counted as keywords? I don't know)

Hi Tom, perhaps I'm missing something. The way I see it I need several passes for the actions to set them up properly.

We need to check disable/activate the proper actions for allies and axis every time if I understand correctly. If we activate any passed actions there will be problems. (also you can omit the node connect they're not necessary if the steal operations work... so

Such that the activate events run first. That is 24 conditionals to deactivate and 24 to activate (x2 for the OR operator??) per action. (24+48=72 minimum?)

If it was possible to have a higher number of keywords per action maybe I could set a another entity to trigger the entire set once (instead of repeating the whole thing 14 times) I could setup another construct basically that will trigger every time an objective returns or it's captured and will test the whole thing setting up the actions accordingly.

But I see the problem is exceeding the number of keywords in a single action.

When you say a leak what do you mean? I see it every time here even during warmup. It gets stuck to this number and the alt-roams don't work.

Oops my bad skip the noderesetFlags stuff (the flags are steals not checkflags). That will save another 24 keywords. And yes you can skip the node_connects. In fact you can set the action_closenode to the node outside the barriers.

So 12*14 + 2*12 + 12*1 = 168 + 24 + 12 = 204 in 26 action tests including fake delivers. Well within the limits on the keyword fix beta and 6 action tests blocks still available for CP etc..

Yes you could use a fake entity to trigger whenever something happened to any flag but I don't think it is worth the trouble. You should be able to do this map minimally without the extra fuss of func_explodes now. 12*16 + 2*12 = 216 keywords in 14 action tests is possible.

The leak is a guess since I don't see how this map could go to 69 on the goaltracker. I run with com_hunkMegs 128 on 1GB of ram and don't see your symptoms.

---Upate: missed seeing your barrier toi fake constructs. That makes it simpler since the deliver / fake deliver logic can go there. I am testing that out right now. Things are going ok but I just hit an issue. With both teams carrying flags a fake deliver means a predictable location for the carrier waiting to deliver and no fake deliver may slow down the match since the bots are anywhere on the map.
BTW minehunts don't go on mineplants. Minehunts should only be needed if you want a covert op to search a distant area that the covert op won't be passing through. A minehunt is like a camp, you give it an aim action. Look at my v1rocket near the initial allied spawn, the covert op may search the area beyond the bridge regardless of whether the bridge is built.

If tests go ok I'll attach the files tomorrow or sooner.

Last edited by TomTom; 24-04-2008 at 07:31..
Reason: not a bug I get it now.

Also the goal number of all the alt roams (although initially setup to -1) is set to 69 by fritzbot right from the start. I do not understand this. Where the 69 is coming from?

It is a Maleficus added 'feature'. He explained it to me once, but I've forgotten the reasoning behind it. It doesn't matter though as once you set them to active they should inherit the current game states goal number.

Yes now I remember CrapShoot mentioning something along that line once. And I do see it now (was looking at the wrong actions). But since I use very few alt-roams with goal -1 I may have only seen it once in my waypoints (trenches05). Oddly I don't see it in my group 0 goal -1 alt-roam in bremen_b1. Anyway it is just a workaround Mal used for alt-roams that are inactive.

- - -
OK here is how I would change it to use steals. Tests are basically OK but lots more tests should be done. The only zombies I saw are those I expect (bots just about to steal pause when the other team steals, so the steal goes to the next bot to come along, and I may have seen one of those bot stopping 1 node from deliver point. These I see in lots of steal deliver maps, they are reasonably rare and throw in enough bots and attack at the delivers and alls well. Did not see any steal - goal tracker bugs).

Hi all, ok I read the new posts just now after making some changes. Ok for the steal obj code Tom posted it will not always work. I tried several combinations. The main problem is the 2 conditionals

if_obj_home_false
if_obj_captured

You need combinations of the 2 but is not reliable. I wish there was a keyword like if_obj_not_captured. But there isn't. So basically the code Tom posted cannot reactivate the action when a flag is stolen but not captured. In this scenario the opponent may also steal a flag and mess the goal number of the previous team.

So to get around it I had to rearrange the .script file such that the func_explosive is called (via the alertentity) after a new construct which triggers the events. Here is the code from the .aiscript, I tested multiple times and works with the goal tracker being maintained always for both teams at the same time no matter of the combination (steals/returns and so forth):

Several of my attempts are in comments within the .aiscript file. I added a new TOI that points to a construct and is called when either team steals, returns or captures a flag. Ok now there 2 passes through all flag actions to ensure no matter which flag is stolen or returned their equivalent actions are re-activated and any others disabled.

The first pass activates the actions based on whether a flag is stolen but not captured. In order to determine if it is captured the 2nd pass deactivates the actions. This method is used in conjunction with the func_explosive that is loaded at the end of a capture operation to disable the previous and enable the new action for the specific team (the one who did the capture). The rest is taken care from the code above. This way you could save keywords significantly from the .aiscript.

I updated the code under the original link with this. I have the old code too.

I also updated the alt roams, not sure why by the bots would rarely follow them originally. I set them up with goal 0, group 0 and always active and got rid of the 69. These are the good news. The bad news is that I am getting a G_Spawn error that ET could not create entities. I see it when I deploy 32 bots and it is not due to heavy fighting during gameplay but it's intemittent. Something else is going on and started, I suspect, since I added the 5th TOI for the construct to invoke the code above.

Few other comments. I tried the delivery disable/enable, Tom mentioned earlier on but the bots do not behave well. The one that has the flag may go to camp say position but will not respond to enemy fire. Also bots that target the steal operations do not respond, sometimes they would pass each other (and I am talking groups of them) without a single shot fired. This is not the case with the original code.

Thanks
CK-Chaos

Tom, I just read the comments in purple above yes I removed the minehunt operations. I may simply change the steal back to roam actions just to see how the bots will behave.