Limitation of actions in the aiscript file

[enigma1]

Hello,

I was doing some waypointing for the mlb_temple in ET. After completing nodes, actions etc, I edited the aiscript and after several crashes of the ET I figured that there is a limitation of actions in the aiscript.

Seems like the number of action definitions is limited to 16. Is there a way around it and if so how can it be done?

Seems that the problem comes from the fritzbot DLLs. Is the source available by Mal in someplace, I checked the wiki but I do not see any references.

Thanks
CK-Chaos

[TomTom]

Welcome enigma1 to the FritzBot Forums (! like your name ).

Yes the previous waypointers for various temple type maps also hit these limits. But despair not, CrapShoot convinced Mal to make a 32 action-test-block version last January. Download it here, then extract the DLL and replace the older version in your \fritzbot sub-directory.

As to your second question, no FritzBot is NOT an open-source mod. Fritzbot Source Code is not available nor are compiled AI libraries. But we waypointers have found many work-arounds that are largely documented in some of the 31 current articles in the Fritzbot ET wiki. So if you hit another limitation, post the details here and we can likely provide some good ideas to fix it.

[enigma1]

Hi Tom,

Great thanks, I just tried it and works fine. So hopefully I should be able to finish this.

I encountered few other issues still haven't investigated in depth.

The first one on the mlb_temple is with the main bridge where the tank passes. With the regular (mlb_temple not mlb_temple_final) there are 2 constructions, one on each side of the bridge. So if I define the first one (on the allies side) to be a major construction, I can see the engineer going there builiding it allright and then starts spinning around.

To get around it I made the first one a minor construction and then within the aiscript I activate conditionally the next action for the bridge construction on the axis side (which is a major one). This way it seems to work, as long as there is no heavy fighting the allies engies will build the first structure and then proceed to the next one.

Another issue I noticed is that durung fighting at the beginning where the canyon is, both axis and allies insist to move forward to meet each other and they end up in the water of course. Then the only way out of it, is through the well. Well there is some notes in the wiki about it, haven't got a chance to deploy the fakebrushes yet. But my question is, is there some switch for the bots (at least the engies) so they won't have to jump forward during fighting? Haven't seen anything in the docs.

Another issue I'm having is that I cannot conditionally connect nodes for non-constructibles. Like where dynamites are placed inside the temple I will have to simply connect nodes. The problem comes if the axis engies defuse the dynamites, the nodes will end up connected as each of these action to connect nodes will trigger unconditionally. I am going to try 2 different actions for each wall but I may end up exceeding the 32 actions limit.

I am deploying a bunch of actions in the aiscript to connect nodes when the dynamites explode within the temple, the reason I run out of actions earlier on.

Thanks again, nice work with the transmitter btw.

Regards
CK-Chaos

[TomTom]

There are generally 2 ways to do aiscript blocks normally for non-constructible dynamite objectives. (1) add the dynamite action with the ent num of the TOI and then test if complete in the action test for that action. However (2) there is normally a func_explosive targeted by the TOI in the map and you can add an action (type 34 action_event_explode) that targets that ent num. Then in the aiscript just add a test block for the action_event_explode action ID. This latter action block will be called only once when the dynamite succeeds. I like this method a lot since it saves a little in terms of keywords required and if an one-time objective can be satcheled it is the only way since satchel actions do not trigger action tests. Now it can be tricky to find the entity number of the targeted func_explosive but it can be found generally by flying around repeatedly hitting your /viewent bound key or failing that by using Hobbit's waypointing tool's bsp reader and following the target-targetnames. (my just posted WIP for v1rocket_b2 uses this method at the gate. See Action ID #6 at the top of the gateway above the dynamite action. Notice that they use different but similar ent numbers)

Now in the highly unlikely chance that you need to follow the death of something that is not targeting a func_explosive nor a func_constructible you can communicate the information from the script file to the aiscript file through some advanced waypointing script file changes (e.g. similar to the helper ents in FritzBot_Buttons_And_Levers ). But that should only be used when absolutely needed.

Can't take much credit on transmitter. That is really the effort of Craig and the bindlestiff, all I did was help with corrections and suggestions.

[enigma1]

Hi Tom,
Yes I read the suggestions from the forum and wiki. The documentation is very good indeed.
I will try few things including treating the walls as major costruction plants instead of dynamites to see if this works. I am trying to avoid adding entries/entities through the main .script file as I read that I should limit the fake entities to 5 otherwise there might me memory leaks. There are already 6 faketois I had to create for the tank splines to detect the barriers and other events till the tank reaches the temple. So I am not sure if what I read was an old post and with the later DLLs it's no longer a problem. If I have to add another fake entity.... oh well I need to rework all the actions and re-check the entities again (as they surely will change). I was hoping to avoid that.
I have tried different maps and with the major cosntruction objectives pumping up the goal numbers, I had to rethink my approach enabling solely groups instead of relying on the goal ID.
I am using hobbit's tool since I started with fritzbot, although I'm messing around for a over a year now I didn't post anything earlier on.
Thanks for the links I will check them too. I will post again once I test the map with the moded actions.
Regards
CK-Chaos
PS: When I checked Michelangelo's nav file (for the mlb_temple) had a similar approach to for the bridge construction. I saw exactly the same problem I was having with the ally eng spinning around the first bridge toi (when its a major construction).

[TomTom]

Again if you look at a few more recently waypointed maps (e.g v1rocket_b2, saberpeak...) you can avoid the memory leak problem by using just one TOI for a group of splines. The trick is to link the TOI to a func_constructible and add a minor construct to the waypoints that is never enabled. The action test for that fake construct will be triggered anytime the line "construct <targetname>" appears in the script (use the targetname of that particular func_constructible). So instead of 5 TOIs and 5 func_explosives you can use 1 TOI, 1 func_constructible and 5 func_explosive. Then you need to do a lot of tests for the associated action_event_explode in the constructs action test. (See action 23 to action 27 checks inside of action 29's test block in most recent v1rocket_b2 post). This also saves on the need for more action tests at the expense of more keywords inside a single action test (limit is 64 keywords per test and 256 total).
I think there are examples in the wiki somewhere or in the forums. (Note; the alertentity for the func_explosive must be before the constuct command)

Update: downloaded the mlb_temple to look at the dynamites in the temple. All the associated func_explosives I found were equal to their TOI ent number Plus one;
temple corridoor wall crack (t649)
original trigger_objective_info 134
original func_explosive 135

temple caves access breach (wall2)
original trigger_objective_info 475
original func_explosive 476

floor breach to the escape caves (dalle)
original trigger_objective_info 477
original func_explosive 478

so you can do the second method just add the action_event_explode actions with an action_ent one greater than the one you are using for the dynamite (verify with viewent to be sure)..

[420Blunt]

Originally Posted by enigma1

The first one on the mlb_temple is with the main bridge where the tank passes. With the regular (mlb_temple not mlb_temple_final) there are 2 constructions, one on each side of the bridge. So if I define the first one (on the allies side) to be a major construction, I can see the engineer going there builiding it allright and then starts spinning around.

I was playing around with the bridge for this map a few months ago and I was able to set it up so the allies could build the bridge from their side of the river and didn't have to travel across to the otherside. This also fixes them from spinning around.

If you want feel free to use it.

[enigma1]

Hi again,
Ok I got the moded script from 420Blunt and used it for the map. Things were easier. I also checked the script Tom suggested for the dynamite explosive events. So I used those instead and ended up with just 2 faketois in the map.
Still working testing things with the objectives and waypoints there are several things I need to correct, but here is what I have done so far. (I added the scripts and nav files in a zip archive).
www.asymmetrics.com/tmp/fb_mlb_1.zip
Again thanks for the help.
Regards
CK-Chaos

[TomTom]

For a first WIP very good.
I'll just give some general advise and preferences here. Specific observations I'll leave for a PM later.

Aim actions:
There are 2 general styles IMO. I prefer to use an action_add 3 3 70 1023 1 0 0 style. That is an aim-only action that is enabled at game start and remains active forever. An alternate style is to place the aim actions in with the camp actions e.g. action_add 0 3 40 1023 1 X -1. The problem with the latter and with other aim actions that are not active throughout the game is that it adds another thing that you need to keep track off to prevent error messages (and bots turned in a random direction). Likewise if you make your aim actions team specific (action_add 3 -1...) you will probably have to either add more actions (and there is a limit) or find and re-edit your existing aim actions. Conceivably the only reason you would ever want to disable an aim action would be if you had one camp linked to multiple aims and I don't recommend that. Also the aim direction need not be exact, bots scan within their FOV better than most human players and are expert at discerning the direction you are firing from.

Roams and Alt roams:
Bots do not need to touch/enter the action radius of a roam to satisfy it. They only need to touch the roam's closenode. So a good practice is to place the action on top of the node that you want them to navigate to. This is very important if you are trying get the bot to touch something (like a heath and ammo cabinet...). And like all actions double checking the closenode attribute can be very important when looking to do a quality release.

Route nodes:
the bindlestiff is the expert on these, but I will put in my 2 cents. Routes at spawns if they are to cover all the spawn pads (visible for your team with command: mal_showspawns 1) ,then the radius can get rather large. And when the spawns are scattered you may make even larger. But the one thing you do not want is the route's radius to touch any of the alt-roams that are used by this roam. Now the editor menu goes upto 1024 for the draw distance so routes that are smaller than that you should be able to see the spokes when viewing with draw radiuses on. Therefore it is a good idea to keep route radii under 1024. Now if spawn pads are badly scattered (>1024) you can always use multiple identical routes and cover the spawns that way.

Camps except mg42 and panzer:
Bots are quite happy to waste ammo into the wall in front of them, so set the action radius and stand-up flag (action_ent of 1) as needed.

Zombies:
If you see bots standing still spamming simple messages (I'm attacking etc.) for more than 5 seconds then they are likely zombied because an action they have selected to pursue they can not find a path to that action's closenode. This typically happens through a game state that has enabled the action but disconnected the path (through the aiscript or a conflict between the aiscript and the goal tracker). To diagnose this problem you need to compare the g_action_info goal with the current goal_num to see if the action is currently equal (active). Then check that the closenode can be navigated to by that bot. Checking the closenode is very important. I can't tell you how much time I lost on dm_hillb2 and NOTW because the closenode of just one action in the whole waypoiints were wrong. When you review the ability of the bot to navigate to the closenode you need also be aware that the node flag for dangerous leap and team-specific nodes may prevent the bot navigating. There is one exception to the 5 sec. rule. Engineers that select a dynamite objective that already has dynamite planted, only seconds away from blowing up will till the dynamite to blows or is defused before moving.

Active forever:
When using aiscript activation/deactivation, all actions should be set as active forever (action_active x 1). Forgetting this step can complicate debugging because those actions that stop working were likely stopped by the goal tracker. IMO only ports of maps from RTCW are candidates for using the goal tracker (but do use goal 0 for actions that must be active from the start of the game).

I'll keep these tips in mind should we redo Denny's RTCW tutorial.

[enigma1]

Hi Tom,

Yes these are very good tips. Especially the closenode one I totally forgot for the final steal objective on the mlb map. I fixed it as well as I fix several other things and added few more waypoints and actions.

The link I posted earlier now contains the update files.

I still have 3 main issues with this map.

1. Seems to be another limit of statememnts inside the aiscript file. If I add like another 5-10 lines of actions (doesn't matter what) ET crashes after the allies complete the first major objective (you can see lines commented out for this reason in the aiscript).

2. I tried adding the fakebrushes from the wiki example but I got a crash outright. I am not sure if there is this limit (from 1) or the positioning yet. Even if I add the brushes properly though I notice the bots stuck at the bottom of the well sometimes. (The whole issue here is if the bots jump inside the water they cannot get out)

3. Inside the temple after the allies engineers place the dynamites (AND axis builds the wooden barrier) and these actions are complete, allies (LTs, Medics, Soldiers) stop. There are actions assigned however and I checked the closenodes they're good. Now If I blow up once the wooden barrier they wake up and from there on, they do as I expected (at least for as much as I tested the map).

I also noticed the goal number increments every time a major action is complete (as documented) but it does not decrement if a major dynamite plant goes through. I suppose this doesnt matter as the groups and aiscript control the key actions.

Another question I have is about the trap-buttons inside the temple. I assigned 1 action to activate each of the buttons for the axis. I do not see anything happening though. The button actions are assigned the func_door entities that's what I understood looking the rtcw tutorial. (I should not use the invisible user entity right?)

Thanks again for the tips.

Regards
CK-Chaos