FritzBuglist ET

From Bots-United Wiki

Jump to: navigation, search

Contents

[hide]

FRITZBOT ET BUG LIST

Here is a place where we can compile all the known bugs, and track their status. Please leave as much detailed info as possible as to what the bug is, where it occurred, and the best way to replicate it (if possible).


KNOWN BUGS:

10. Hobbit's ET Waypointing Tool's aiscript default savename is set by the name of the aiscript that was loaded but NOT by the name used last in saving. Consequently I have destroyed the last changes in an aiscript multiple times when switching projects. Example starting a new aiscript, NEW, edit, SAVE (and set filename)<enter>, more edits, SAVE <enter> replaces the old project not the new project aiscript! The default filename should be set by that last saved OR loaded. And the editor should do the normal (1) rename old aiscript to bak (replacing old one), (2) save new aiscript.

11. Hobbit's ET Waypointing Tool's aiscript verification reports an error in activateAction_Group if the group number is larger than the last Action ID in the nav file. This suggests that it is checking the parameter against the action ID numbers rather than the group numbers defined in the nav. Likely got copied from verification of the activateAction command.

12. Deliver bug. I have often noticed a bot stopped at the node immediately preceding the closenode of the deliver action. It might be related to an event occurring in the game between the point that the object was stolen and the point that the bot got to that second-to-last node. This occurs even when the re-enable steal objectives commands are included in the aiscript. WORKAROUND: Fortunately this problem does seem to put the bot at that specific node and not zombie them just anywhere. So the simple solution is to put the last and second-to-last node inside the area of the map where the delivery takes place. Then place the deliver action there and ensure the deliver's action_closenode value points to the last node. JIC Additional workaround: roam an opposing bot into the deliver point to kill any stuck bots.

13. Defuse bug. Rarely a engineer will defuse a dynamite plant but then remain convinced that some dynamite is still planted. The effect is only possible if the defuse occurs very late like the last second or two. This might be related to a oft noted bug in ET where some voice announcements don't happen. Possibly because it is rare, it seems to just affect dynamite plants at constructions. The problem is reset if the construction gets destroyed, but with the bots on both sides convinced that dynamite is about to go off that may not happen. Thanks to enigma1 for flagging this problem, affects both 0.70b? and 0.70c and possibly other versions. PARTIAL WORKAROUND: Using a normal dynamite plant action(4) activated/deactivated by the aiscript will keep the attacking engineer bots coming to plant dynos, and if those plants are near to defuses of the construct-plant actions then they may get defused as well. This workaround can work well where the game is focused on one engineer objective (example; tank barriers in Goldrush) but not so well where more than one engineer objective is critical at the same time (example 2 barriers to a steal objective).

FIXED BUGS:

1. Bots aren't recognizing / using sliding doors. Maybe this is a feature request. A couple maps that are being waypointed have examples. I'll send navs if you need to take a look.

2. Medics still freeze up sometimes.

3. Engs sometimes go to plant, drop dyno, then forget they dropped it and camp waiting to recharge.

4. Bots sometimes lock up or freeze around landmines. EDIT: This affects all bots in the game (not just near the mines).

5. Sometimes bots freeze up while trying to get items. EDIT: Example of this is if docs are dropped, sometimes they can't calculate a path to them. Seems to be related to distance (Rocket and Rommel are good maps to test).

6. Mobile MG42 soldiers that prone when in a firefight (before getting to a specific mobilemg42 camp) seem to be staying in place even after the firefight is over.

7. I have observed in campaign testing medics with max light weapons pointing their akimbo pistols at a nearly dead comrade bot and then doing nothing. The 2 bots can stand around for a long time if the enemy never comes their way. (TomTom 11/24/2006 FritzBot ET 0.70b multiple maps) (This was also previously noted in 0.70 see forum.)

8. The use of fake construct entities to create a workaround to the lack of button/lever/..and other script to aiscript triggering, has the bug that it can eat dynamite. This is due to code in ET used to clear dynamite from the vicinity when a construction is rebuilt. Affects both 0.70b? and 0.70c and likely all other versions. THE FIX IS: to origin the fake func_construct far-far away from anyplace that dynamite might be used. In practice the distance needed varies greatly so an origin 10's of thousands away off map (but with-in the limits of the max mapping coordinate values) may be needed. Only way to be sure is to test.

9. A rarely seen aiscript problem occurs if a test is performed on some action types with action_goal -1. The test may give the wrong answer if the action was not activated. Seems to affect dynamite actions and possibly some constructions?... THE FIX IS; to use action_goal 999 instead of -1 if you are going to depend on testing that action before it is activated. Another fix is to use the func_explode instead in the aiscript by adding an action_explode with action_goal 0 with its entity set to monitor the associated func_explode of the dynamite objective. This latter alternate way does not work if the mapper used a func_construct instead (which are special waypointing cases anyway).

REQUESTED: KNOWN ET BUGS THAT SHOULD BE FIXED IN FRITZBOT ET

1. Too many entities crash ET. Fix prevents new entities being spawned (e.g. airstrikes) if MAX entities would be exceeded.

2. Script file globalaccums 8 and 9 exceed array index and corrupt other memory.

3. Script file commands cvar set, bitset and bitreset do nothing. Command cvar inc (increment) ignores parameter so no decrement possible.

REQUESTED: NEW FUNCTIONALITY

1. Finish vehicle support. Bots should not attack invulnerable vehicles like the truck in supplydepot and the train in railgun.

2. Finish vehicle support. Enemy bots should be able to man the mounted mg (like they do in Bobots)

3. Finish vehicle support. Bots from both teams should be able to use the same vehicle (e.g train in railgun).

4. Extend vehicle support. Bots should be able to use non-objective vehicles (script movers) like trams, subways, gliders etc. Currently problems arise when pathing these since the bots have to be trapped inside for the duration of travel. Consequently the bots may time out, try to exit, kill themselves, get crushed or expose themselves to enemy fire.

5. Health and Ammo roams. There should be a way to flag a roam so that a bot out of ammo or below 10-30% health would treat the roam at health and ammo cabinets as equal in importance as the top priority actions. Could be done as a new or existing action roam type, say use the ent number for the action as flags (1 health, 2 ammo, 3 both). The distance to the roam could also be used as part of the bot's decision making.

6. Convert AI selection of objectives from a flat to a cellular model. Currently a bot trapped inside an enemy position will not pursue inside objectives since these have to be disabled so that teams bots on the outside don't chose these objectives then zombie because of an path obstruction(s) (e.g. constructed barrier, destroyed ramp...). However if the bot selection of next objective determined navigation based on a cellular model, then a trapped bot would pursue the inside objective since he was in the same or a connected cell, while a team bot on the outside would filter out that objective because his cell was not connected at the time. This would require a cell manager with a data structure that would track on a team basis what other cells a given cell is connected to;

//example of data structure as Array of arrays
enum eCellteam = {none=-1, both, axis, allies); 
eCellteam sCell_connect[8];
sCell_connect cell_nets[8];

It would also require a new aiscript command cell_connect <cell1> <cell2> <2way> <team> that would be used along side associated node_connects in action tests and the default script block. The effect of the command would be to invoke the cell manager maintenance function to update the cell-nets. There would also have to be a second cell-manager function that would take the list of active actions and create a filtered list for the bot requesting its next objective. Since bots chose objectives not more often than once a few seconds this extra computing should be easily hidden from affecting gameplay. To speed up processing...

There would have to be two new console commands namely node_cell <ID> <cell_num> so waypointers could set the cell number for a node and node_defaultcell <cell_num> to make adding nodes easier. The node hud and node_info commands would need to be updated to show the cell number. For compatibility the nav file need not be changed as the 2-3 bits needed to define the cell_number could be considered as just the uppermost bits of the node group number. The node group number then would have those bits masked off accordingly. Older flat maps would still work since all their nodes and consequently their actions would be in cell zero (the world cell). For simplicity Actions would inherit the cell of their close node. In usage when a cell loses focus you would still disable the low priority objectives (camps and roams) since bots that that cannot advance the game objective state should return to the area of fighting. But CVops and engrs on the other hand could remain inside to pursue available dynamite/satchel objectives (and along with other bots steal and spawnflag objectives).

Permanent link to this page

Retrieved from "FritzBuglist_ET"