Actually it was pretty easy to make a TC compatible version. Updated the above post's link with a dual-game spk; make sure to select the right game upon installation.
EDIT: 3.01 - Fixes a trivial issue where the Argon Drone Interceptor from DCS2 was not included in the blacklist
[SCRIPT] Military Base Response revamp v2.16 [2011-10-27]
Moderators: Moderators for English X Forum, Scripting / Modding Moderators
Version 3.02:
* Fixes a critical error with the scout self-restarting logic
TO NOT BREAK SCOUTS, you must go into the "Military base revamp" config in the community configuration menu and press "Install/update". IF YOU DO NOT, SCOUTS WILL STOP DEAD AND DO NOTHING.
I made a critical error when I implemented the scout self-restarting logic. I tried to start a new task in a script running in that same task, without realizing that doing this deadlocks that task...
This has been fixed and a safe way to self-restart scripts has been implemented.
MilitaryBaseResponseRevamp-V3.02-07.05.2017.spk:
https://drive.google.com/open?id=0B80_E ... WJiSEREekU
I have removed the links to the broken versions.
* Fixes a critical error with the scout self-restarting logic
TO NOT BREAK SCOUTS, you must go into the "Military base revamp" config in the community configuration menu and press "Install/update". IF YOU DO NOT, SCOUTS WILL STOP DEAD AND DO NOTHING.
I made a critical error when I implemented the scout self-restarting logic. I tried to start a new task in a script running in that same task, without realizing that doing this deadlocks that task...
This has been fixed and a safe way to self-restart scripts has been implemented.
MilitaryBaseResponseRevamp-V3.02-07.05.2017.spk:
https://drive.google.com/open?id=0B80_E ... WJiSEREekU
I have removed the links to the broken versions.
Version 3.03:
* Xenon bases that change ownership to another race now terminate their Military base response scripts
* Xenon Relay scouts now have race logic disabled, so they no longer have their scouting logic disabled (as well as keep them from despawning). You will need to turn off and turn back on the Xenon military base option in the Artificial Life settings for this fix to take effect.
Version 3.03b:
* Xenon Relay scouts now have a random wait period before respawning, so now killing them now means something.
* Xenon Relay scouts now start will full engine tuning and half full rudder optimizations (to match Jobs spawned recon ships get)
MilitaryBaseResponseRevamp-V3.03-18.05.2017.spk:
https://drive.google.com/open?id=0B80_E ... zVsYlEwWlk
(Mods, please let me know if quadruple posting like this is a problem)
* Xenon bases that change ownership to another race now terminate their Military base response scripts
Spoiler
Show
Relevant to the Hub plot
Version 3.03b:
* Xenon Relay scouts now have a random wait period before respawning, so now killing them now means something.
* Xenon Relay scouts now start will full engine tuning and half full rudder optimizations (to match Jobs spawned recon ships get)
MilitaryBaseResponseRevamp-V3.03-18.05.2017.spk:
https://drive.google.com/open?id=0B80_E ... zVsYlEwWlk
(Mods, please let me know if quadruple posting like this is a problem)
I'm impressed you are continuing to update this for so long, it is really fantastic. This is one of my favorite AL scripts that adds so much flavor and a motivation for me. (Say the Xenon have taken Black Hole Sun, I actually feel obligated to go take it back for the Argon!)
I have 3 questions. You mentioned you fixed the logic for a ship trying to jump somewhere it couldn't (like trying to jump to a ToA). This problem also appears in Litcube's PhanonCorp (not the LU version), where the Phanon traders will try to jump to a ToA and do nothing. So, the questions:
1) If I replace ToAs with Jumpgates, will MBRR-spawned ships jump to them?
2) If I /don't/, and another mod, like Improved Kha'ak, spawns a Kha'ak horde in, say, Saturn 3, will the Terrans slowly meander over there using the ToAs to respond, and/or will they jump to the nearest jump beacon to reduce travel time?
3) Would it probably be simple to take a peek at your logic and edit Litcube's stuff to do the same thing?
I have 3 questions. You mentioned you fixed the logic for a ship trying to jump somewhere it couldn't (like trying to jump to a ToA). This problem also appears in Litcube's PhanonCorp (not the LU version), where the Phanon traders will try to jump to a ToA and do nothing. So, the questions:
1) If I replace ToAs with Jumpgates, will MBRR-spawned ships jump to them?
2) If I /don't/, and another mod, like Improved Kha'ak, spawns a Kha'ak horde in, say, Saturn 3, will the Terrans slowly meander over there using the ToAs to respond, and/or will they jump to the nearest jump beacon to reduce travel time?
3) Would it probably be simple to take a peek at your logic and edit Litcube's stuff to do the same thing?
Version 3.04:
New features:
* Military Base Revamp spawned ships will now spawn with upgrades (Engine tuning, Rudder optimization, Cargo Bay Extension)
> Regular ships will spawn with a bit of randomness, leaders/generals will always have maxxed out stats
* Military Base Revamp spawned ships will now spawn with increased aggression, morale, and flight skill
> Regular ships will spawn with a bit of randomness, leaders/generals will always have maxxed out stats
* Military base patrol ships will now set their homebase to the military base they are currently "working for".
> This lets you see, at a glance, which military base is coordinating which ships by checking the "owned ships" option of military bases.
Balance tweaks:
* Last version "unbroke" Xenon relay scouts, but this had the unfortunate side effect of making Xenon incursions into commonwealth space FAR more frequent, excessively so. So now Xenon relay scouts only have a chance of calling for an incursion
> Huge ships and stations will still always cause them to call for incursion, but smaller stuff won't always cause it to happen
> Careful about attacking them, attacking them will also cause them to always call for an incursion
>> Keep in mind, just because a scout calls for an incursion, doesn't always mean the receiving military base is obligated to always send in forces
> This may still be too excessive, in which case I may dial down chances even further (in particular, maybe make the chance to call for help when an enemy station if found to below 100%)
Bug fixes:
* Missile boats (ships with missile turrets, e.g. M7Ms) will now "throttle" how often they kite (move to stay at the edge of their range)
> Always kiting was leading to those ships sometimes not attacking, and instead always running away
* Xenon relay scout SIGNAL_KILLED handler now delegates the delayed respawning to a new global task, to get a random wait out of the SIGNAL_KILLED handling task
> Having a wait on the SIGNAL_KILLED handler may have been causing some Xenon relays to be unkillable.
>> If you have such an unkillable Xenon relay wandering around (stuck at 0 HP but refusing to die even if you attack it), you can use a "jump out of existence" script command on it to get rid of it. (No GUI for that, sorry, you will need to use the script editor yourself)
> Please let me know if this change didn't fix it and you do see new unkillable Xenon relays continuing to wander around causing trouble
MilitaryBaseResponseRevamp-V3.04-24.06.2017.spk:
https://drive.google.com/open?id=0B80_E ... nhnc2M4ZU0
New features:
* Military Base Revamp spawned ships will now spawn with upgrades (Engine tuning, Rudder optimization, Cargo Bay Extension)
> Regular ships will spawn with a bit of randomness, leaders/generals will always have maxxed out stats
* Military Base Revamp spawned ships will now spawn with increased aggression, morale, and flight skill
> Regular ships will spawn with a bit of randomness, leaders/generals will always have maxxed out stats
* Military base patrol ships will now set their homebase to the military base they are currently "working for".
> This lets you see, at a glance, which military base is coordinating which ships by checking the "owned ships" option of military bases.
Balance tweaks:
* Last version "unbroke" Xenon relay scouts, but this had the unfortunate side effect of making Xenon incursions into commonwealth space FAR more frequent, excessively so. So now Xenon relay scouts only have a chance of calling for an incursion
> Huge ships and stations will still always cause them to call for incursion, but smaller stuff won't always cause it to happen
> Careful about attacking them, attacking them will also cause them to always call for an incursion
>> Keep in mind, just because a scout calls for an incursion, doesn't always mean the receiving military base is obligated to always send in forces
> This may still be too excessive, in which case I may dial down chances even further (in particular, maybe make the chance to call for help when an enemy station if found to below 100%)
Bug fixes:
* Missile boats (ships with missile turrets, e.g. M7Ms) will now "throttle" how often they kite (move to stay at the edge of their range)
> Always kiting was leading to those ships sometimes not attacking, and instead always running away
* Xenon relay scout SIGNAL_KILLED handler now delegates the delayed respawning to a new global task, to get a random wait out of the SIGNAL_KILLED handling task
> Having a wait on the SIGNAL_KILLED handler may have been causing some Xenon relays to be unkillable.
>> If you have such an unkillable Xenon relay wandering around (stuck at 0 HP but refusing to die even if you attack it), you can use a "jump out of existence" script command on it to get rid of it. (No GUI for that, sorry, you will need to use the script editor yourself)
> Please let me know if this change didn't fix it and you do see new unkillable Xenon relays continuing to wander around causing trouble
MilitaryBaseResponseRevamp-V3.04-24.06.2017.spk:
https://drive.google.com/open?id=0B80_E ... nhnc2M4ZU0
Last edited by TechSY730 on Sun, 25. Jun 17, 05:32, edited 6 times in total.
@EveRohann
No, I don't think XRM should pose any issues. In fact, any new ships types added will automatically be picked up and spawned by the script alongside vanilla ones. The only thing is that if XRM added any ships that NPCs should not have, you will need to update the ship blacklist to exclude them (plugin.mbase.cfg.invalids.xml).
To get the changes to apply, you will need to click the "Install/Update" options in the configuration menu.
@Soulmata
1. Yes; the script checks for warp gates dynamically; if you add more warp gates, the script will pick them up.
2. Yes to both. If there are no warp gates, it will try using the built-in jump logic instead of its randomized warp gate choice, which will mean it will use jump beacons. (Note that this means they will never use jump beacons if there are warp gates available; this is a bug I hope to address at some point). If there are no warp gates or jump beacons, then the script (as of my updates) will just have the ships move to the sector "the slow way"; better late then never after all
3. No idea about Litcube's Universe. The script does a lot of its own stuff instead of relying much on built-in scripts, but I wouldn't count on that being enough to ensure compatibility. In particular, this script replaces one or two of the built-in scripts for integration purposes, which would highly likely clash with Litcube's changes. Also, while this script doesn't modify Rapid Response fleets, it does integrate with them, which may cause issues if Litcube edited them.
Plus there is the same caveat I gave to EveRohann, you may need to edit the blacklist (plugin.mbase.cfg.invalids.xml) if there are ships the NPCs should not have. To get the changes to apply, you will need to click the "Install/Update" options in the configuration menu.
On the bright side, any new ships types added will automatically be picked up and spawned by the script alongside vanilla ones (hence the potential need to update the blacklist).
No, I don't think XRM should pose any issues. In fact, any new ships types added will automatically be picked up and spawned by the script alongside vanilla ones. The only thing is that if XRM added any ships that NPCs should not have, you will need to update the ship blacklist to exclude them (plugin.mbase.cfg.invalids.xml).
To get the changes to apply, you will need to click the "Install/Update" options in the configuration menu.
@Soulmata
1. Yes; the script checks for warp gates dynamically; if you add more warp gates, the script will pick them up.
2. Yes to both. If there are no warp gates, it will try using the built-in jump logic instead of its randomized warp gate choice, which will mean it will use jump beacons. (Note that this means they will never use jump beacons if there are warp gates available; this is a bug I hope to address at some point). If there are no warp gates or jump beacons, then the script (as of my updates) will just have the ships move to the sector "the slow way"; better late then never after all
3. No idea about Litcube's Universe. The script does a lot of its own stuff instead of relying much on built-in scripts, but I wouldn't count on that being enough to ensure compatibility. In particular, this script replaces one or two of the built-in scripts for integration purposes, which would highly likely clash with Litcube's changes. Also, while this script doesn't modify Rapid Response fleets, it does integrate with them, which may cause issues if Litcube edited them.
Plus there is the same caveat I gave to EveRohann, you may need to edit the blacklist (plugin.mbase.cfg.invalids.xml) if there are ships the NPCs should not have. To get the changes to apply, you will need to click the "Install/Update" options in the configuration menu.
On the bright side, any new ships types added will automatically be picked up and spawned by the script alongside vanilla ones (hence the potential need to update the blacklist).
-
CloneSargaent
- Posts: 68
- Joined: Wed, 16. Jul 14, 19:27
Thanks for continuing development on this TechSY730 liking the fixes you've done 
. But I'm having bug on my XRM setup where the Paranid M1s, M2s, M7s, and m6s spawned by MBRR are equiped with only HEPTs while the other races ships are being equiped some what properly.
For example:
-Terran M1/M2s have PSPs and SSCs but no FBCs or FPD.
-Split M1/M2s only had PGPs and ISRs
-Argon and Boron only had PPCs and CFAs
- Teladi Gauss and FBLs
But the Paranid are the only ones spawning without PSG
This bug makes paranid nearly incapable killing 7 Xenon destroyers without there being 38 M1/M2s and thats OOS. IS all those ships get steam rolled by those destroyers.
. But I'm having bug on my XRM setup where the Paranid M1s, M2s, M7s, and m6s spawned by MBRR are equiped with only HEPTs while the other races ships are being equiped some what properly. For example:
-Terran M1/M2s have PSPs and SSCs but no FBCs or FPD.
-Split M1/M2s only had PGPs and ISRs
-Argon and Boron only had PPCs and CFAs
- Teladi Gauss and FBLs
But the Paranid are the only ones spawning without PSG
This bug makes paranid nearly incapable killing 7 Xenon destroyers without there being 38 M1/M2s and thats OOS. IS all those ships get steam rolled by those destroyers.
Not sure what is going on; MBRR uses the standard "add default items to ship" command, which, AFIAK, should be equipping ships with their most powerful weapons. Maybe this is an XRM specific thing? I'll test it with some Paranid M2s on my "psuedo-vanilla" setup.
In any case, as a fall back, I can try augmenting the ship spawning logic to check if the ship has at least some of the most powerful (non-ammo) weapon they can equip, and add some if the standard "default items" logic doesn't.
In any case, as a fall back, I can try augmenting the ship spawning logic to check if the ship has at least some of the most powerful (non-ammo) weapon they can equip, and add some if the standard "default items" logic doesn't.
-
Mythrantar
- Posts: 173
- Joined: Fri, 17. Jun 05, 06:35
No, I haven't been able to reproduce it. It may be something that only triggers in XRMs loadouts.
But the script uses the built-in command "add default items to ship" to load up ships, so if he is seeing it for MBRR Paranid ships, I would expect that naturally spawning ships would be hitting similar issues.
I think I can add a workaround to check to see if the ship had at least some of the most powerful laser it can mount, and if not, give it a few of them.
But I just haven't had time until recently to be able to devote to this.
But the script uses the built-in command "add default items to ship" to load up ships, so if he is seeing it for MBRR Paranid ships, I would expect that naturally spawning ships would be hitting similar issues.
I think I can add a workaround to check to see if the ship had at least some of the most powerful laser it can mount, and if not, give it a few of them.
But I just haven't had time until recently to be able to devote to this.
-
CloneSargaent
- Posts: 68
- Joined: Wed, 16. Jul 14, 19:27
Thanks for looking into my issue TechSY, but i might have figured it. There is a post on this thread on page 66 by risbosix, he attempted to put MBRR into XTC which already has integrated rrf and that caused ALL the MBRR ships to mount m3 class weapons. Unfortunately I didn't see this statement about MBRR on the main page XRM about XRM-AP(my setup that I'm having the problem with) before downloading MBRR:
TechSY, but i might have figured it. There is a post on this thread on page 66 by risbosix, he attempted to put MBRR into XTC which already has integrated rrf and that caused ALL the MBRR ships to mount m3 class weapons. Unfortunately I didn't see this statement about MBRR on the main page XRM about XRM-AP(my setup that I'm having the problem with) before downloading MBRR:It never occurred to me that XRM-AP's rrf may be in conflict with MBRR so this may not be solvable problem.MBRR is not necessary for XRM in Albion Prelude. AP includes its own race response system which XRM fully utilises
Last edited by CloneSargaent on Thu, 17. Aug 17, 00:27, edited 1 time in total.
I am curious about what change in XRM causes loadouts from MBRR spawned ships to be so suboptimal. MBRR's ship spawning and loadout logic is completely standalone; I can't see how it would conflict.
Sadly, I don't play XRM, nor do I have any interest in installing it just to test this. But if anyone knows what is going on, I may be able to implement a workaround.
But as mentioned, on the main page, MBRR is sort of redundant with any mods that expand upon RRFs, so maybe this is no big loss. If you want the sector takeover functionality, there should be other mods that let you do that.
Sadly, I don't play XRM, nor do I have any interest in installing it just to test this. But if anyone knows what is going on, I may be able to implement a workaround.
But as mentioned, on the main page, MBRR is sort of redundant with any mods that expand upon RRFs, so maybe this is no big loss. If you want the sector takeover functionality, there should be other mods that let you do that.
I also have CloneSargaent's issue and also have XRM (AP) installed. The problem seems to really only hit the Paranids. Exactly like Clone said, their M2s are popping into the sector with measly HEPTs. Every other MBRR faction's troops so far have equipped decent to pretty mediocre weapons for their fleets.
I have only a couple of scripts/mods with this installation, but I don't see how they could interfere too much: MARS, Yaki/Pirate Guild, XRM Phanon, a couple of minor scripts and TechSY's MBRR, and IR 2.0 (I heard I.R conflicts with MBRR because they do pretty much the same thing, but I wanted to see for myself, so I made a separate folder to test them. Apart from just making everything more chaotic I don't see any noticeable issues, yet.)
The reason I even considered merging those two, was because MBRR has a much more interesting and customizable invasion system compared to IR. I like everything else about IR, but IR's assault fleets only bother Xenon and Pirate sectors and often take them over and it's very annoying. Apart from the lame loadouts, though, MBRR's spawn fleets are causing mayhem here and there. It's cool to see the Boron invade a Split Sector and mess everything up for once. I'm not sure I'm going to keep this installed, though.
Does anyone have any recommendations on a better mod that has factions invade each other? Or at least where I could begin to modify the loadouts of MBRR's spawned ships, or keep IR's assault fleets but stop them from complete overrunning Xenon and Pirate sectors. One of the things I like about MBRR is that it allows you to disable factions from overrunning pirates. Really, that's a pretty understated feature.
I have only a couple of scripts/mods with this installation, but I don't see how they could interfere too much: MARS, Yaki/Pirate Guild, XRM Phanon, a couple of minor scripts and TechSY's MBRR, and IR 2.0 (I heard I.R conflicts with MBRR because they do pretty much the same thing, but I wanted to see for myself, so I made a separate folder to test them. Apart from just making everything more chaotic I don't see any noticeable issues, yet.)
The reason I even considered merging those two, was because MBRR has a much more interesting and customizable invasion system compared to IR. I like everything else about IR, but IR's assault fleets only bother Xenon and Pirate sectors and often take them over and it's very annoying. Apart from the lame loadouts, though, MBRR's spawn fleets are causing mayhem here and there. It's cool to see the Boron invade a Split Sector and mess everything up for once. I'm not sure I'm going to keep this installed, though.
Does anyone have any recommendations on a better mod that has factions invade each other? Or at least where I could begin to modify the loadouts of MBRR's spawned ships, or keep IR's assault fleets but stop them from complete overrunning Xenon and Pirate sectors. One of the things I like about MBRR is that it allows you to disable factions from overrunning pirates. Really, that's a pretty understated feature.
-
CloneSargaent
- Posts: 68
- Joined: Wed, 16. Jul 14, 19:27
I haven't tested MBRR with XRMTC to see if happens with TC yet. But Rhine its most likely because it is in conflict with AP's built in RRF scripts. Which has killed any use RRF type scripts with AP without lag or major bug (which sucks imo). IR/IR2.0 and LV's RRF (for TC) are only other plugins I can think of, but they not as optimized as MBRR and XTC's RRF. Outside those 4, I have not seen a plugin that had invasions and/or an RRF that worked as intended.
Actually I think I fixed the issue. I don't know single lick of this code stuff so I had to "reverse engineer" (lol) a solution.
I was messing around with the script editor in game and decided to spawn myself a Paranid destroyer while using the "add default items to ship" command to outfit it. Lo and behold, the ship spawned with HEPTs.
I looked for an mbase script that created ships (mbase.spawn.create.ship.rand or something), and there was the same command outfitting ships. I had another mod using its own self contained script that decked out its ships with the most expensive weapons available to them so I added it in right before the "add default items..." command. Now, the new ships that spawn are using the best weapons XRM has to offer. The old ones with the crappy HEPTs are still around, but I believe that's because MBRR ships don't just vanish, they go back to their base.
I don't know anything else about this scripting business, though. I could easily be wrong. Also, I'm expecting my game to blow up soon since I combined MBRR with IR and XRM. It's a pretty hilarious combo, however. IR's response fleets are absurd. Sometimes, they try to deal with MBRR's invasions by spawning in even more dudes to lagtastic levels. So it's like World War II in space in a few sectors right now.... I don't recommend it, just because it is so damn laggy. I haven't noticed any bugs other than the former yet, but there's prob a lot of stuff going wrong underneath the hood that I haven't realized yet. Honestly, I just want to see what happens
I was messing around with the script editor in game and decided to spawn myself a Paranid destroyer while using the "add default items to ship" command to outfit it. Lo and behold, the ship spawned with HEPTs.
I looked for an mbase script that created ships (mbase.spawn.create.ship.rand or something), and there was the same command outfitting ships. I had another mod using its own self contained script that decked out its ships with the most expensive weapons available to them so I added it in right before the "add default items..." command. Now, the new ships that spawn are using the best weapons XRM has to offer. The old ones with the crappy HEPTs are still around, but I believe that's because MBRR ships don't just vanish, they go back to their base.
I don't know anything else about this scripting business, though. I could easily be wrong. Also, I'm expecting my game to blow up soon since I combined MBRR with IR and XRM. It's a pretty hilarious combo, however. IR's response fleets are absurd. Sometimes, they try to deal with MBRR's invasions by spawning in even more dudes to lagtastic levels. So it's like World War II in space in a few sectors right now.... I don't recommend it, just because it is so damn laggy. I haven't noticed any bugs other than the former yet, but there's prob a lot of stuff going wrong underneath the hood that I haven't realized yet. Honestly, I just want to see what happens
Code: Select all
$turret.cnt = $ship-> get number of turrets
while $turret.cnt
dec $turret.cnt
$weapon.type = 6
= $ship-> call script 'anarkis.lib.armturret' : turret.nb=$turret.cnt weapon.select=$weapon.type disable.ion=[FALSE] disable.ammo=[FALSE]
endIt calls the Anarkis's Pirate Guild script that arms their men, so it needs anarkis.lib.armturret. I'm not sure if that script itself is dependent on anything else. It seems like its standalone, but idk. Putting the weapon type at 6 tells the script to give everyone the most expensive stuff. It has more options but I haven't tried them yet.
@rhine770
Thanks for that, but I went ahead and wrote my own code to loop through and find the "best" lasers, and give some of those.
It isn't as sophisticated as anarkis' script, but at least I don't have to add a dependency onto another library this way.
Version 3.05:
Bug fixes:
* Introduced logic to ensure that ships generated for MBRR have at least some of the "best" weapons they can mount in their various turrets.
> This is a workaround for mods that "break" the "add default items to ship" command and cause it to generate sub-optimal layouts (XRM is a notable example of this for Paranid ships)
> Currently, "best" means find the weapon with the best shield damage, best hull damage, and best laser speed (that isn't impulse ray emitter, unless that is the only thing the turret can mount), and gives some of each of those.
> This will not fix ships already spawned, but they should naturally cycle over time as conflicts ensue
Known issues:
* The way the laser augmenting script currently works means that extra weapons may be added, potentially so many that the normal cargo capacity of the ship is exceeded, or they get more weapons then they have mounts to put them in
* Finding the "best" weapon uses very simple logic
> When finding the "fastest" laser, it will choose the fastest even if there is another one that is only slightly slower but much more powerful
> When determining the best weapon for hull and shield damage, it only looks at damage of the projectile, and does not consider rate of fire. A more accurate measure would be DPS. However, so far I have not found a way to get the fire rate of a weapon through scripting. This is somewhat mitigated by weighting OOS damage heavier than IS damage (which is my understanding the OOS damage doesn't care about fire rate; let me know if I am wrong).
* The logic for "best" weapon probably won't work for missile turrets, but MBRR already has logic in place for stocking ships with missile turrets
MilitaryBaseResponseRevamp-V3.05-20.08.2017.spk:
https://drive.google.com/open?id=0B80_E ... Gc2QTYyRms
Thanks for that, but I went ahead and wrote my own code to loop through and find the "best" lasers, and give some of those.
It isn't as sophisticated as anarkis' script, but at least I don't have to add a dependency onto another library this way.
Version 3.05:
Bug fixes:
* Introduced logic to ensure that ships generated for MBRR have at least some of the "best" weapons they can mount in their various turrets.
> This is a workaround for mods that "break" the "add default items to ship" command and cause it to generate sub-optimal layouts (XRM is a notable example of this for Paranid ships)
> Currently, "best" means find the weapon with the best shield damage, best hull damage, and best laser speed (that isn't impulse ray emitter, unless that is the only thing the turret can mount), and gives some of each of those.
> This will not fix ships already spawned, but they should naturally cycle over time as conflicts ensue
Known issues:
* The way the laser augmenting script currently works means that extra weapons may be added, potentially so many that the normal cargo capacity of the ship is exceeded, or they get more weapons then they have mounts to put them in
* Finding the "best" weapon uses very simple logic
> When finding the "fastest" laser, it will choose the fastest even if there is another one that is only slightly slower but much more powerful
> When determining the best weapon for hull and shield damage, it only looks at damage of the projectile, and does not consider rate of fire. A more accurate measure would be DPS. However, so far I have not found a way to get the fire rate of a weapon through scripting. This is somewhat mitigated by weighting OOS damage heavier than IS damage (which is my understanding the OOS damage doesn't care about fire rate; let me know if I am wrong).
* The logic for "best" weapon probably won't work for missile turrets, but MBRR already has logic in place for stocking ships with missile turrets
MilitaryBaseResponseRevamp-V3.05-20.08.2017.spk:
https://drive.google.com/open?id=0B80_E ... Gc2QTYyRms
