A taster of some changes I'm looking at for the next update.
Turret command profiles
Ability to configure the behaviours of the Smart turret commands.
Disable laser switching
A turret command profile option to disable laser switching.
- Does not modify the set of lasers the user put in the turret.
- Antimissile will make a best-effort use of whatever lasers are in the turret
- Throttling and capturing will not work optimally with laser switching disabled.
Smart: Capturing (turret command)
- For boardable ships it'd maintain the target shield below the boarding shield threshold
- For non boardable ships it'd strip the shield and chip away at the hull with lowest hull dmg laser
- This is the default auto mode: it can be specifically set to attack shield for boarding or attack hull for capping, the latter being useful for NPC bailing mods.
- Smart will track incoming damage to a ship fired by Smart turrets with Capturing mode enabled in order to coordinate.
- It cannot see and factor in damage from ship main gun fire or other turret commands/modes.
Smart: Custom (turret command)
- Giving an extra slot for customizable turret behaviour
- Operates as a no laser switching Offense mode with its default settings (which as noted are configurable)
This is all prototype stuff and no guarantee this'll make it into 4.2.
[SCR] Smart Turrets v4.7.2 (AP, 05-04-14), v2.6 (TC, 21-08-13)
Moderators: Scripting / Modding Moderators, Moderators for English X Forum
-
deca.death
- Posts: 2939
- Joined: Mon, 28. Feb 11, 19:50
Wow, almost missed this little pearl. What to say, it almost sounds too good to be truth, like things some politician would promise prior the electionsShimrod wrote:A taster of some changes I'm looking at for the next update.
All features sound very useful, and I know that removing weapon switching (or making it optional) does sound counterproductive but there are lot of situations where this behavior is undesired. Not to mention boarding assistance setting, that would be a bliss. Thumb up and I hope that as many changes as possible will end up in final release. 
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
I've got the command profiles, laser switching and menu updates done ready for testing.
Turns out that attacking shields is the most interesting part, as non trivial decision making needs added to a few places:
1. Target selection: skip target if it has sufficient damage incoming already.
2. Laser selection: this will prove interesting...
3. Firing loop: shoot an amount of gun slots to make up desired damage. Record amount of damage fired. Stop firing if target has sufficient damage incoming.
The logic for this is quite longwinded and fiddly, especially factoring in combinations where laser switching is enabled and whether it's in boarding or capping mode. Might need to add fudge factors to account for shield regeneration rates, if pecking away with an IRE on 0% shields is failing to penetrate into hull territory. Working on a capping logic library...
I expect it to take in the order of weeks to be coded and tested.
Turns out that attacking shields is the most interesting part, as non trivial decision making needs added to a few places:
1. Target selection: skip target if it has sufficient damage incoming already.
2. Laser selection: this will prove interesting...
3. Firing loop: shoot an amount of gun slots to make up desired damage. Record amount of damage fired. Stop firing if target has sufficient damage incoming.
The logic for this is quite longwinded and fiddly, especially factoring in combinations where laser switching is enabled and whether it's in boarding or capping mode. Might need to add fudge factors to account for shield regeneration rates, if pecking away with an IRE on 0% shields is failing to penetrate into hull territory. Working on a capping logic library...
I expect it to take in the order of weeks to be coded and tested.
-
deca.death
- Posts: 2939
- Joined: Mon, 28. Feb 11, 19:50
This sound actually like worse part, doesn't it? :)Shimrod wrote: 1. Target selection: skip target if it has sufficient damage incoming already.
Of course, there are two ways of doing this, you way (which I was uncomfortable even to mention, because I know it's pretty screwed up to achieve :) or simple way; in shield control setting NO weapon switching. Disregard "damage in air" - players will use only fast bullet/beam weapons (It's how it works in vanilla isn't it? with "attack shield" command). Leave 1-2% shield safe margin. That would be much quicker to program I'm telling you :)
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
The vanilla attack shields ship command will stop firing if the level hits boarding threshold / 2. It doesn't take into account multiple ships attacking or damage en route, so works best for fast lasers on fighters.
For turrets shooting a heavily shielded target, they want to start off with PPC volleys to strip the shield and gradually reduce down to shooting weaker lasers when approaching the boarding threshold.
I implemented an early prototype where a turret calculates how much damage it will end up sending to the target before the first bullet strikes when firing a given laser, so it throttles amount of lasers being fired downwards even before the target takes the damage, avoiding PPC overkill.
It works reasonably well if one turret is shooting, but falls over for multiple turrets and ships. No way around it except to coordinate by tracking the amount of damage shot at the target.
I've implemented the damage tracking as arrays of shield, hull and timeout stored in a local on the target. Whenever the value is queried, if playing time has incremented from previous check, entries are iterated, timed out damage expired, and totals recalculated. Lifetime is calculated from distance between ships and speed of bullet.
The approach has inherent inaccuracy:
- Distance between objects and hence bullet lifetime is not precise, in terms of size of target hulls and location relative to origin from which bullets spawn. Ships are both moving.
- We only have a timer resolution in seconds rather than milliseconds, and 'playing time' could return anything from 1 to 999 ms. More bullet lifetime inaccuracy.
- It does not see bullets shot from other scripts and from ship mainguns. I'm also limiting the tracking to bullets fired from capping mode turrets for general performance.
Whether this is a real issue in practice, whether variance is acceptable remains to be seen.
Disabling laser switching compromises in a few areas, such as missing out on Smart's throttling which reduces number of lasers being fired based on laser energy. It'll not be optimal for capping mode either but I want to see how it performs in testing before refining the handling of it.
For turrets shooting a heavily shielded target, they want to start off with PPC volleys to strip the shield and gradually reduce down to shooting weaker lasers when approaching the boarding threshold.
I implemented an early prototype where a turret calculates how much damage it will end up sending to the target before the first bullet strikes when firing a given laser, so it throttles amount of lasers being fired downwards even before the target takes the damage, avoiding PPC overkill.
It works reasonably well if one turret is shooting, but falls over for multiple turrets and ships. No way around it except to coordinate by tracking the amount of damage shot at the target.
I've implemented the damage tracking as arrays of shield, hull and timeout stored in a local on the target. Whenever the value is queried, if playing time has incremented from previous check, entries are iterated, timed out damage expired, and totals recalculated. Lifetime is calculated from distance between ships and speed of bullet.
The approach has inherent inaccuracy:
- Distance between objects and hence bullet lifetime is not precise, in terms of size of target hulls and location relative to origin from which bullets spawn. Ships are both moving.
- We only have a timer resolution in seconds rather than milliseconds, and 'playing time' could return anything from 1 to 999 ms. More bullet lifetime inaccuracy.
- It does not see bullets shot from other scripts and from ship mainguns. I'm also limiting the tracking to bullets fired from capping mode turrets for general performance.
Whether this is a real issue in practice, whether variance is acceptable remains to be seen.
Disabling laser switching compromises in a few areas, such as missing out on Smart's throttling which reduces number of lasers being fired based on laser energy. It'll not be optimal for capping mode either but I want to see how it performs in testing before refining the handling of it.
-
deca.death
- Posts: 2939
- Joined: Mon, 28. Feb 11, 19:50
Aren't you forgetting something important here? There is no way of knowing or ensuring that all or any of bullets currently "in air" will actually hit the target or not. That in certain scenarios could be serious problem.Shimrod wrote: The approach has inherent inaccuracy:
- Distance between objects and hence bullet lifetime is not precise
- We only have a timer resolution in seconds rather than milliseconds,
- It does not see bullets shot from other scripts and from ship mainguns.
Whether this is a real issue in practice, whether variance is acceptable remains to be seen.
You assume that we'll want relying in everything on turret logic. Striping the shields is never a problem for player, but keeping them low when you have you hands full often is. I we get "one turret only" shield suppress ability, that would actually be often enough but it would seem incomplete, I agree. In either case, it would be great assistance.Disabling laser switching compromises in a few areas, such as missing out on Smart's throttling which reduces number of lasers being fired based on laser energy. It'll not be optimal for capping mode either but I want to see how it performs in testing before refining the handling of it.
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
It bears testing. I'm mainly worried about the opposite: bullet damage timing out prior to bullets impacting. This could result in more damage than desired.
Early tests and a Xenon boreas in the middle of 10 player brigantines, took 2% hull damage in about 5 minutes, while being kept below something like 5% shield.
Shooting a tiger at 6km range which was moving about after a fighter resulted in plenty misses, and pauses till the missed damage timed out. Better safe than sorry though.
Haven't implemented laser selection yet though, its using best dps heaviest lasers in those tests.
Early tests and a Xenon boreas in the middle of 10 player brigantines, took 2% hull damage in about 5 minutes, while being kept below something like 5% shield.
Shooting a tiger at 6km range which was moving about after a fighter resulted in plenty misses, and pauses till the missed damage timed out. Better safe than sorry though.
Haven't implemented laser selection yet though, its using best dps heaviest lasers in those tests.
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
The bailing mode is looking promising in testing.
In testing having a shrike chip away slowly at a swarm of M4 hulls, I did not observe any ships bailing above 86% hull. This ties in with a magic number 87% bailing threshold I've seen posted on the forums.
I've used 2 configuration elements:
- Bailing threshold: default 86%
- Bailing tickle threshold: default 3%
Turrets will apply damage to the target sufficient to strip the shield and reduce hull to the bailing threshold percentage.
Once the bailing threshold has been reached, the turret will aim to apply no more than the tickle threshold percent of hull damage, as an ongoing way to encourage bailing. This damage will vary depending on available lasers. Multiple weak laser shots may contribute, or one big laser, as long as the combined damage is within the tickle percent.
If no laser has small enough hull damage to fit the quota, the shields would be allowed to regenerate sufficiently that when the bullet is shot, the shield to hull crossover effect will absorb enough bullet damage that it will not exceed the tickle threshold.
The damaging tracking is working just fine in practice. Wish I had data on capping mechanics, such as if fight rank makes a difference, whether chance to bail hits 0 after some conditions etc.
Observations.
In testing having a shrike chip away slowly at a swarm of M4 hulls, I did not observe any ships bailing above 86% hull. This ties in with a magic number 87% bailing threshold I've seen posted on the forums.
I've used 2 configuration elements:
- Bailing threshold: default 86%
- Bailing tickle threshold: default 3%
Turrets will apply damage to the target sufficient to strip the shield and reduce hull to the bailing threshold percentage.
Once the bailing threshold has been reached, the turret will aim to apply no more than the tickle threshold percent of hull damage, as an ongoing way to encourage bailing. This damage will vary depending on available lasers. Multiple weak laser shots may contribute, or one big laser, as long as the combined damage is within the tickle percent.
If no laser has small enough hull damage to fit the quota, the shields would be allowed to regenerate sufficiently that when the bullet is shot, the shield to hull crossover effect will absorb enough bullet damage that it will not exceed the tickle threshold.
The damaging tracking is working just fine in practice. Wish I had data on capping mechanics, such as if fight rank makes a difference, whether chance to bail hits 0 after some conditions etc.
Observations.
Code: Select all
Shrike vs 10 Yaki pirate falcons, rookie combat rank
- 5 Bails @ hull (86, 85, 82, 61, 35) - last one took a few minutes
- 5 fought to the death over 20 minutes
Shrike vs 7 spawned Xenon Barracuda, rookie combat rank
- 1 bailed pretty quickly at 84% hull
- 1 had collision related accident
- Remaining 5 were tickled to death slowly over half an hour without bailing
Shrike vs 8 spawned Xenon M, rookie combat rank
- 2 had collision issues
- 6 tickled to death over 20 minutes
-
deca.death
- Posts: 2939
- Joined: Mon, 28. Feb 11, 19:50
This might help:Shimrod wrote: The damaging tracking is working just fine in practice. Wish I had data on capping mechanics, such as if fight rank makes a difference, whether chance to bail hits 0 after some conditions etc.
Bailing info
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
I've implemented a state machine based around my interpretation of the capping algorithm:
The key points it tracks to are:
- As the bail check apparently triggers at a random 8th of the hull, we need to test each 8th in turn.
- 3 seconds pause when reaching an 8th to allow bail speech without overkill
- After testing each 8th it takes hull below 2.5% which yields optimum capping bonus of +10
- Thereafter it will simply strip shield to 0% / <1000 hitpoints to trigger a bail check at intervals.
- As an unknown amount of time occurred since the first bail check and the point where we're pinging the ship at 2.5% hull, we cannot reliably predict the time modifier of the next bail check, so strip the shield at 30 second intervals following reaching the final 8th to ensure the bail check is triggered promptly whenever its due to occur.
Observations:
- There's an uptick in speed at which ships bail over simply pecking away at hull, which I attribute to reaching the random 1/8th hull trigger threshold quicker.
- Ships occasionally bail from prolonged pinging at the 2.5% threshold but it's not exactly a mass exodus
- I've observed ships that have low morale (5) which never bailed even after shooting for long enough that the time modifier penalty should have reset, which should have resulted in a good bail check probability with the +10% hull bonus.
- I wonder if therefore some ships randomly spawn with a 'not capturable' flag. Unfortunately I can't find a way to test for this flag via script.
- Xenon always spawn with high morale (25) whereas yaki have a more random distribution
- Best observation late last evening was 5 out of 10 bails of a group of yaki pirate novas.
- I spawned 50 yaki pirate falcons around a shrike with a shield healing script running, while I went off for dinner. 20 were capped, 3 wandered away, 3 were still fighting, 24 had died for whatever reason while I was afk.
- Forcing target morale to 1 before shooting, 8 out of 10 xenon L were capped. The remaining 2 Ls would not bail for 20 minutes before they finally died.
- I attribute the eventual deaths to bullet damage variance occasionally penetrating the shield, gradually reducing hull from 2.5% to the kill threshold of 1%.
Code: Select all
Init
- Transition to takedown mode with a 7/8 of max hull threshold
Takedown
- { Loop until below 1/8 max hull
- Take hull below current 1/8 threshold with 1/50 max hull allowed overkill
- Don't proceed to next threshold until 3 seconds elapses
- Move to next lower threshold
- }
- Transition to Wait&Tickle mode with (Now+30) second trigger time
Wait&Tickle
- { For ever
- Take hull to 2.5%. Overkill threshold 1/200 max hull.
- Don't shoot until trigger time elapsed
- Strip shield to <1000 & 0%
- Reset 30s trigger time
- }
At any point if hull drops <= 1/100 max hull the ship is flagged for death.
- As the bail check apparently triggers at a random 8th of the hull, we need to test each 8th in turn.
- 3 seconds pause when reaching an 8th to allow bail speech without overkill
- After testing each 8th it takes hull below 2.5% which yields optimum capping bonus of +10
- Thereafter it will simply strip shield to 0% / <1000 hitpoints to trigger a bail check at intervals.
- As an unknown amount of time occurred since the first bail check and the point where we're pinging the ship at 2.5% hull, we cannot reliably predict the time modifier of the next bail check, so strip the shield at 30 second intervals following reaching the final 8th to ensure the bail check is triggered promptly whenever its due to occur.
Observations:
- There's an uptick in speed at which ships bail over simply pecking away at hull, which I attribute to reaching the random 1/8th hull trigger threshold quicker.
- Ships occasionally bail from prolonged pinging at the 2.5% threshold but it's not exactly a mass exodus
- I've observed ships that have low morale (5) which never bailed even after shooting for long enough that the time modifier penalty should have reset, which should have resulted in a good bail check probability with the +10% hull bonus.
- I wonder if therefore some ships randomly spawn with a 'not capturable' flag. Unfortunately I can't find a way to test for this flag via script.
- Xenon always spawn with high morale (25) whereas yaki have a more random distribution
- Best observation late last evening was 5 out of 10 bails of a group of yaki pirate novas.
- I spawned 50 yaki pirate falcons around a shrike with a shield healing script running, while I went off for dinner. 20 were capped, 3 wandered away, 3 were still fighting, 24 had died for whatever reason while I was afk.
- Forcing target morale to 1 before shooting, 8 out of 10 xenon L were capped. The remaining 2 Ls would not bail for 20 minutes before they finally died.
- I attribute the eventual deaths to bullet damage variance occasionally penetrating the shield, gradually reducing hull from 2.5% to the kill threshold of 1%.
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
4.2 is coming together nicely. The boarding and bailing turret modes work both with laser switching enabled and disabled, and I've regression tested a bunch of existing functionality.
I'm planning on supporting 3 bailing modes, which I hope will be flexible enough to cover everyone's preferences.
1. Strip hull to below 87.5%, then continually strip shields (to <1000 & 0%) every 15 seconds.
- Caters for people who want bails with maximum possible hull.
- This is less likely to have ships bail that have high morale as there is no benefit from a low hull bonus.
2. Strip hull to below 85%, wait 5 seconds then reduce hull by 1% at a time waiting for 3 seconds between percentage points. Hold at 2.5% hull and strip shields at 15 second intervals.
- This is aimed at people who use NPC bailing with unpredictable hull trigger levels.
3. Strip hull below 85%, wait 5 seconds then reduce hull by 25% blocks waiting 5 seconds between. Finally reduce to 2.5% hull and strip shields at 15 second intervals.
- This is aimed at having the hull <2.5% ideally before the second bailing check occurs, affording the +10% bail chance to improve chance of high morale bails.
I use an initial <85% hull level as my interpretation of the reverse engineered builtin bailing algorithm is that a bailing check will occur if hull is below a random 8th of hull per bullet hit. Thus by stripping hull below 85% initially rather than 87.5% more bullets are likely to be employed and thus the likelyhood of a bail check at the highest threshold is increased, promoting more high hull initial bail checks.
I'm planning to make the 3rd option default.
If anyone has suggestions I welcome input - at least before it's fully implemented, tested with my finger poised on the upload button
I'm planning on supporting 3 bailing modes, which I hope will be flexible enough to cover everyone's preferences.
1. Strip hull to below 87.5%, then continually strip shields (to <1000 & 0%) every 15 seconds.
- Caters for people who want bails with maximum possible hull.
- This is less likely to have ships bail that have high morale as there is no benefit from a low hull bonus.
2. Strip hull to below 85%, wait 5 seconds then reduce hull by 1% at a time waiting for 3 seconds between percentage points. Hold at 2.5% hull and strip shields at 15 second intervals.
- This is aimed at people who use NPC bailing with unpredictable hull trigger levels.
3. Strip hull below 85%, wait 5 seconds then reduce hull by 25% blocks waiting 5 seconds between. Finally reduce to 2.5% hull and strip shields at 15 second intervals.
- This is aimed at having the hull <2.5% ideally before the second bailing check occurs, affording the +10% bail chance to improve chance of high morale bails.
I use an initial <85% hull level as my interpretation of the reverse engineered builtin bailing algorithm is that a bailing check will occur if hull is below a random 8th of hull per bullet hit. Thus by stripping hull below 85% initially rather than 87.5% more bullets are likely to be employed and thus the likelyhood of a bail check at the highest threshold is increased, promoting more high hull initial bail checks.
I'm planning to make the 3rd option default.
If anyone has suggestions I welcome input - at least before it's fully implemented, tested with my finger poised on the upload button
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
For boarding the turret aims to reduce shield to a maximum 1%, and stops shooting until it recovers to the value reported by !lib.get.shieldthreshold, which I believe is 50% of the boarding threshold limit.
Occasionally there is damage variance on bullets causing the desired amount of damage to be exceeded, and also incoming tracked damage may time out before it hits (e.g. 999ms lifetime bullet times out since 'playing time' ticks over in the next millisecond). causing more bullets to be shot than desirable. This may result in a small amount of rare overkill, and the 1% floor is designed to absorb this.
In practice I'm not seeing a problem, although the tracking related variance could be eliminated by a cautious approach of adding 1 second to tracked bullet lifetime damage. The variance issue could potentially be mitigated by assuming bullets do 5-10% more damage than claimed for tracking purposes.
No need for a new hotkey. Cycle the turrets via existing hotkey to smart capturing mode. By default capturing mode will suppress shields on boardable targets, and try to make non boardable targets bail. It prefers the player target so you can have turrets focus on a primary target.
The damage tracking is not an exact science but it works well in practice. You'll be able to judge for yourself when its released
Edit: In fact I think I'll make the 'maximize hull' mode default. I've spawned 10 yaki pirate falcons in testing, and after 5 minutes 5 of them have bailed at 87% hull, rest are still going. This kind of thing would probably please people more than having most of them bail with 2% hull, even if they had a slightly better chance to bail. Reserve the 'maximize chance' option for those perseus with the extra shield type capping moments
Occasionally there is damage variance on bullets causing the desired amount of damage to be exceeded, and also incoming tracked damage may time out before it hits (e.g. 999ms lifetime bullet times out since 'playing time' ticks over in the next millisecond). causing more bullets to be shot than desirable. This may result in a small amount of rare overkill, and the 1% floor is designed to absorb this.
In practice I'm not seeing a problem, although the tracking related variance could be eliminated by a cautious approach of adding 1 second to tracked bullet lifetime damage. The variance issue could potentially be mitigated by assuming bullets do 5-10% more damage than claimed for tracking purposes.
No need for a new hotkey. Cycle the turrets via existing hotkey to smart capturing mode. By default capturing mode will suppress shields on boardable targets, and try to make non boardable targets bail. It prefers the player target so you can have turrets focus on a primary target.
The damage tracking is not an exact science but it works well in practice. You'll be able to judge for yourself when its released
Edit: In fact I think I'll make the 'maximize hull' mode default. I've spawned 10 yaki pirate falcons in testing, and after 5 minutes 5 of them have bailed at 87% hull, rest are still going. This kind of thing would probably please people more than having most of them bail with 2% hull, even if they had a slightly better chance to bail. Reserve the 'maximize chance' option for those perseus with the extra shield type capping moments
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
4.2 uploaded: support for disabled laser switching, shield suppression and bailing automation.
Code: Select all
- Added configurable turret command profiles to allow turret command behaviours to be reconfigured
- Added an option to disable laser switching in the turret command profiles
- Added a custom turret command which acts by default as offense mode with laser switching disabled.
- Added a capturing turret command which by default will suppress shield on boardable ships, while attempting to make non boardable ships bail. Can be set to only promote bailing, to support use with NPC bailing mods.
- Included 3 bailing algorithms. The default algorithm attempts to make ships bail with maximum (87%) hull.
- Included a !init file so games are automatically *modified*, without having to enable the script editor to make Smart available.
- Increase laser speed requirement in the anti-fighter and M6 laser selection algorithm.-
nap_rz
- Posts: 1383
- Joined: Sun, 25. Dec 05, 10:42
-
Shimrod
- Posts: 907
- Joined: Tue, 18. Feb 03, 01:43
Smart will happily coexist with MARS, there are no file or resource conflicts.
MARS and Smart show up as new turret commands in the ship's turret command list. Just select one or the other to switch between them.
Smart just needs the regular fight cmd software mk2.
Note that both Smart and MARS support enabling their turret commands for enemy ships to make life more challenging. This feature is off by default in both cases. I wouldn't advise enabling both Smart and MARS on enemies at the same time, or they'll chop and change between turret scripts as each others AL plugin takes control.
The neat part about that feature is you can setup battles between Smart and MARS ships and see how they perform against each other
MARS and Smart show up as new turret commands in the ship's turret command list. Just select one or the other to switch between them.
Smart just needs the regular fight cmd software mk2.
Note that both Smart and MARS support enabling their turret commands for enemy ships to make life more challenging. This feature is off by default in both cases. I wouldn't advise enabling both Smart and MARS on enemies at the same time, or they'll chop and change between turret scripts as each others AL plugin takes control.
The neat part about that feature is you can setup battles between Smart and MARS ships and see how they perform against each other
-
nap_rz
- Posts: 1383
- Joined: Sun, 25. Dec 05, 10:42
ah thanks for the explanation, about that enabling mars and smart for NPC ships, for the case of both of them, do I need to save the game and reload it whenever I enable/disable smart/mars for the NPC ships?Shimrod wrote:Smart will happily coexist with MARS, there are no file or resource conflicts.
MARS and Smart show up as new turret commands in the ship's turret command list. Just select one or the other to switch between them.
Smart just needs the regular fight cmd software mk2.
Note that both Smart and MARS support enabling their turret commands for enemy ships to make life more challenging. This feature is off by default in both cases. I wouldn't advise enabling both Smart and MARS on enemies at the same time, or they'll chop and change between turret scripts as each others AL plugin takes control.
The neat part about that feature is you can setup battles between Smart and MARS ships and see how they perform against each other