intel_center waypoints
 

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

Re: intel_center waypoints
 

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.

Re: intel_center waypoints
 

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

Re: intel_center waypoints
 

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.

Re: intel_center waypoints
 

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?

Re: intel_center waypoints
 

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

Re: intel_center waypoints
 

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.

Re: intel_center waypoints
 

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

Re: intel_center waypoints
 

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).

Re: intel_center waypoints
 

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

Re: intel_center waypoints
 

Enigma: perhaps my solution to similar goal tracker problems will help. See my posting at http://forums.bots-united.com/showthread.php?t=6617

Re: intel_center waypoints
 

Hi bindlestiff, I tried it with action groups before the roams and did not work. I could not try it with single actions as there are many combinations among the 14 flags. With groups did not work, fritzbot did not like the fact that I was assigning all the flags of each team to the same group. darji2 has the conditional in comments in the .aiscript. I changed things since then but it lists groups 20,30 as the ones I was playing with.

Thanks
CK-Chaos

Re: intel_center waypoints
 

2- Not certain, if it is the steal goal tracker bug then it may be more likely that something like a barrier was constructed/destructed at that point in time. If it happens again pause the bots, extend the timelimit and query the g_action_info of the steal vs the goal_num when the gold is in the bank. Does the steal really get permanently turned off by accident? is something else out of sorts? I am sure CrapShoot would appreciate any bugtracking.

(this is in answer to the bottom of page 1 if you have not guessed)

Re: intel_center waypoints
 

the double connections is a known bug. in some cases action tests are being called twice with dynamite / explosive actions. Maleficus and I discussed it a while back and unfortunately he never found the time to fix it. I suspected it had to do with unreliable results being returned with an engine function (trap_EntitiesInBox). Although I have never seen a case where explosives never triggered a correctly set up action test, it certainly wouldn't surprise me.

Re: intel_center waypoints
 

It may be specific to the intel_center map, not sure. It could be the .script file or the bsp not being working properly? I remember using the same approach for the mlb_temple map and the nodes would connect correctly every time. I prefer to use the existing entities where possible instead of adding new func_explosive entities.

Re: intel_center waypoints
 

You can also just do the workaround of node_disconnect before node_connect. For example action 50 in my v1rocket_b2 handling the fueldoor.

Re: intel_center waypoints
 

Hi Tom. yes I thought about it and tried it earlier on it would work against the double connection, but there were instances the nodes won't connect at all, basically looked like the original event was never triggered at all in some cases (although the wall did blow up)

Re: intel_center waypoints
 

quick question... are we talking about Intelligence Center (beta 2) ??
http://returntocastlewolfenstein.fil...e_Center;39675

if not, which version and please provide a link to the map :)

Re: intel_center waypoints
 

Yes that should be the map. You can always check the wiki article nova2001 started for map status for some map download links. I am maintaining the article for those waypointers that don't do so yet.

I would also point out that I have already referred enigma1 to the prefered readme format which has space for map download links
.

Re: intel_center waypoints
 

Yes the b2 is the ext for the pk3. Internally the scripts are named just as intel_center. That is the latest I had; got it from the Bunker Gaming, where I use to play from time to time.
http://bunker.aaxxss.com/forums/index.php

Re: intel_center waypoints
 

how do i get access to that link?

Re: intel_center waypoints
 

The access User name and password are specified in the popup dialog box and in this thread and talked about here. I'll send Ned a pm too.

Re: intel_center waypoints
 

Reviewed and tested Enigma1's waypoints for the coming waypoint pak. Balance good, and mainly just needed some cleanup. I have shifted the nodes closer to the tank for more casual escorting of the tank by passing Allies. Trimmed down the botsight from 5000 to 4000 (still high but the streets are roughly 4000-5000 long end to end). Corrected route 2 so bots will use the backway more often from their initial spawn. If you find the tank damaged in a position that the allied bots do not repair RSVP (I have not done a step and repeat tank repair test for lack of time).

Get the modified waypoints here (calling the rev 0.10.1). Link expires next month.

Re: intel_center waypoints
 

I just had a couple of games on this map. I wasn't testing anything specific, just playing. It went well with no obvious issues but I did notice the tank was left idle at times longer than it should. It was never a LONG time but longer than one would expect.