This object is in archive! 

Automaton BETA: AI basic (task) BUGS and Feedback on other blocks.

1llusionist shared this feedback 14 months ago
Not Enough Votes

I spotted several issues and possible improvements for the AI Basic (Task) and AI Flight (move) blocks while testing out an escape pod design, both in single player and in a game hosted by a friend, where we also tested the other blocks.


Often, when reconfiguring waypoints using a single one-way gps, the block will physically take the new coordinates and show the proper waypoint in the list, but it will start flying towards the original first ever waypoint that was put in the list.


The behavior is a little bit different in multiplayer private games, as it will exhibit this problem more often if another player than the grid owner boards the automated craft and sometimes it will resume normal operation after a few minutes and start heading to the correct gps.


The block also seems to ignore collision avoidance settings from the AI flight (move) unit, even with precision mode enabled when surrounded by blocks like in a hangar or escape pod bay.


Both the AI basic and AI recorder task units have great functionality, but have mutually exclusive features that would greatly simplify player lives if they were merged together. The ability of the basic controller to manually input a gps different from the actual position of the grid, would save hours on recording very long routes that would be impractical to fly each and every time you setup a new drone, missile or escape pod. The recorder on the other hand, allows for relative positioning from a mothership and is useful for allowing grids to leave it safely, contrary to its counterpart.


Yes, you could use both in conjunction, but smaller miniature grids like missiles or escape pods may not have enough space to spare for an extra AI block, or additionally an antenna and spare remote to record a route. You would also need to painstakingly re-attach them onto the carrier ship, possibly after traveling all the way back to recover them if you did not want to scrap the first drone used to update a blueprint for mass production.


Alternatively adding an option to initially force the grid to travel in a straight direction when it starts moving could also solve issues with exiting hangars and cramped interiors.


Another thing I have noted regarding the AI Flight (move) is that the upper limit for the minimum altitude setting of 500m is simply too low for grids that have automatic parachutes, when traveling across long distances the altitude varies rapidly a lot with the topography changes so I experienced many unexpected deployments of the parachutes that would prevent effective unatended operations and if there were no parachutes it would likely have crashed in a hill or mountain.


Having an unlimited ceiling on the controller would also help reduce fuel consumption by allowing drones to operate in lower gravity orbits before coming down with a second controller or possibly adding a bypass altitude option toggle that could be executed when reaching a tasked waypoint.


Regarding the event controller block, i see several attributes that could be useful:

-Monitoring thrust levels of single blocks or groups of thrusters could allow for scriptless gravity drive synchronization wich would greatly reduce lag on dedicated servers.


-Block count, ship mass or generic ship/subsystems integrity checks would be more intuitive and granular to use for triggering a Flee response.


The AI offensive combat also has two areas where it could use some improvement:

-Additional filters with the closest targeting option as it will often switch to unpowered debris pieces with no computer blocks that have detached from the enemy ship and will proceed to waste valuable time and ammo before it switches to another dead target.


-For the intercept attack patterns used for missiles guidance, it seems like proportional is better at keeping track for the initial approach, and fairs better with most designs regardless of how many thrust directions are covered, but misses more often during the terminal phase before impact and tends to go around orbiting. Adding a distance-based switch between guidance algorithms would allow to switch to target prediction, which fairs better for the final approach. I am suggesting this over using a sensor as the ideal switch distance we have found during testing is often outside of the vanilla detection range.


I have also experienced the bug that others have reported during the livestream, where doing ctrl-a on items highlighted from a search selects all the other blocks of the ship regardless of their show in terminal status, which is highly annoying when making groups.

Leave a Comment
 
Attach a file