intel_center waypoints

[enigma1]

Hello,

Here is the fritzbot waypoints/scripts for the intel_center map. Let me know what you think.

http://www.asymmetrics.com/tmp/fritz...tel_center.zip

I used 6 func_explosive for the triggers. When I tried to utilize the existing func_explosives the events were not always triggered. Not sure why perhaps there're bugs in the main .script file, if you came across this before it would be good to know.

CK-Chaos

[TomTom]

I have sometimes found problems with maps having entities that don't communicate that they have been blown. Very very rarely do I find the func_explosives associated with the toi don't work. More commonly it is something like a dynamite once entity is actually a func_constructible with NO way to reconstruct it. Example the door to the corridor above the main gate in bremen_b1/b2, or the generator in glider, or gen b in Caha tavern.

First thing if an event_explode does not work is to double check the entity number. Did you enter the trigger_objective_info entity number by mistake rather than the func_explosive number ?(I do this mistake often even though I know better). Did the mapper put multiple func_explosives at that spot but only trigger one of them (follow the logic in the bsp)? Then if you just can not figure out what the mapper/map did that won't communicate to the aiscript, do add a fake func_explosive to create an event that you know will work.

[enigma1]

Hi Tom, basically I could not use the existing func_explosives. I know the entity numbers were correct and all they do in the aiscript will connect the nodes to the radio room. So I saw the nodes connecting sometimes but not always, really weird had to do with the gameplay. So I was forced to add the extra func_explosives and those work just fine.

In the .script the difference was that the ones I added are using the alertentity as documented in wiki in the tank splines. The original func_explosives are those that suppose to be called when the tank approaches the radio room. I also saw once the nodes would be double connected (when I tried to utilize the originals). I am almost certain that something is going on with the .script rather than anything else but with the additional ones seems to be good.

I doubled checked that all entities were func_explosive not tois.

CK-Chaos

[420Blunt]

I don't know if this has anything to do with the func_explosives not triggering, but the goal number of action 119 is set to -1.

[TomTom]

And action 113. But he is activating action group 0 so that compensates. This is a style error. Since group 0 is default we do not normally use it for group control. Rather any actions that are controlled by the goal tracker or by individual aiscript activateaction X are generally left in group 0. Should I assume you are using a different action group for these cases, enigma1?

[enigma1]

Hi 420Blunt, the func_explosives do trigger without problem using the extra func_explosives. I was getting the problem initially when I tried to use the original ones. And it was intermittent. From the results sometimes the action will be invoked as expected in the .aiscript some other times it wouldn't and the nodes would not connect. And there was one instance where the nodes ended up double-connected.

Once I added the extra ones I did not see an issue. Let me know if you see a problem during gameplay. The only other thing I missed was action 114 the goal should been -1 too. But there is no major obj before the final dynamite, so it shouldn't matter (group for the exploads is 0 so they should be called always).

Tom, I always used 0 as the group for the exploads

CK-Chaos

[TomTom]

Yes but I/we normally use goal 0 on the event_explodes since they are one time only and we do not depend on an activateaction_group 0. Because of the rare if_action.. goal -1 bug, the event_explode is safe BECAUSE it can be action_goal 0, action_active 1 and sit in whatever action_group that never gets disabled (e.g. 0). In your case a couple of the event explodes are goal -1, and then activated by the aiscript default block. Safe only so long as no if_action_... 113 occurs before that activate.

Anyway mea culpa when I first started I stuck to activating group 0 as part of a debug strategy until CrapShoot explained a number of goal tracker issues to me. Since then I have left group 0 out of the aiscript and use it for goal zero activated or individually activate/deactivate actions only. I kept groups 1-3 for debug and generally have the first stage of actions in group 5 always, some of which are goal 0 and some of which are activated by an activateAction_group 5 a few seconds into the game in the default block. Opposing team gets group 6 if needed, and the next stage gets group 7 and so on. Then anything else gets high numbered action groups. I find by sticking to this style I can look back at any of my later waypoints and guess at what the group is for.

Hopefully when I get through re-writing Denny's tutorial there will be less confusion

P.S. I am not saying you should follow my numbering, You could make group 1 your stage 1 group and group 11 stage one for the opposing team or whatever. But I am saying that defining a grouping style will help you in the long term. And use action_goal 0 for anything that can be left on from the start, like most aim actions, most alt-roams, and ALL event_explodes, event_expires.

[enigma1]

Hi Tom, there are action types that rely on the goal number. I figured that out the hard way like the alt roams. When I made the alt roam with goal -1, I would get a warning during gameplay no matter how many different ways I was trying to activate it (via group etc) in the .aiscript.

Roams seem to follow the same pattern. When all actions had goal -1, at the very beginning of this map the allies bots would escort the tank and ignore the camp actions (till they respawn the 2nd time?). Then I made one roam action with goal 0 and the alt roams with goal 0 and seems ok. The aim actions have no issues, a goal of -1 seem ok. Same for the expload type. I still not sure if it was the alt roam or the roam that changed this behavior.

The reason I wanted to have always
Active 1, Goal -1, Group <group>
was to be able to control everything from the .aiscript using groups in a similar manner as you explained. Seems the goal tracker is still something I haven't fully understood. And the problem is with maps where the goal tracker will increase (due to major objectives) what will happen with actions that have assigned an initial goal? (other than -1). I don't want them to get deactivated/activated all of a sudden, because I would have to activate/deactivate additional groups in the .aiscript and that limits the number of keywords for absolutely no reason.

CK-Chaos

[TomTom]

I am not saying let the goal tracker enable actions when it increments, that is best left in the RTCW version. But goal zero will activate actions before the first bots spawn while default{activateaction_...} activates actions at a fraction of a second later. The latter results in bots spamming that they have no goals at the start but then going out and playing normally. It is mainly nuisance and spam.

And yes I start by having a roam in every action_group with the first one goal 0 mainly to kill nuisance error messages. This ensures that there are always some roams in what is a camping style of waypointing (I guess you know by now I am a camper).

The other 2 values i use for action_goal are -1 and 999. The latter is because while we chose to not use goaltracker stepped control, the value of goal_num is involved in some aiscript test commands. CrapShoot told me about this a year ago+. Basically if an if_action_true/false tests an action that is goal -1 and not yet activated the results are not certain and may rarely screw with your aiscript logic. Using a very high action_goal of 999 avoids the problem. Now actions with non -1 action_goals may let the goal_tracker increment but that is OK because all our actions are action_active 1 and action_goal -1, 0 or 999 only (or they should be). BTW the bug apparently may also involve if_construct... tests too. (but I can only attest so far to seeing it with if_action... tests in debugging).

[enigma1]

Hi Tom, seems like the goal tracker can be really unpredictable. You should see what happens with the darji2 map when the flags are picked up. Active actions end up with different goal numbers after a while and the bots stop moving. Is there any way to disable the goal tracker?

And now I recall the original maps that sometimes have problems with the bots standing there doing nothing (battery, goldrush, radar) is probably due to the goal tracker been messed up. In goldrush is easy to spot when the ally bots get the gold bars they may stop depending how the bars are picked up (order perhaps?).

CK-Chaos