Drone Carrier Software 2 (DCS2) v2.07a

[foxtrot76]

But it does not work, the script simply ignores the code and the Carrier jumps

*Chuckle*... yeah, that is why I have not posted an update yet!

You discovered some of the issues, yes. Another is that the carrier is "losing" whatever battle it is in, so it cannot afford to wait for fighters for long.

I am approximately where you are in the test process. My current thinking is that the carrier should emergency transport fighters in range, jump, *then* recall the rest. Possibly expand the radius for the emergency transport to 20 or 30km.

What if the carrier decided based on it's current status? Say carrier is
<60% health 15 secs wait then jump.
<50% health 10 secs wait then jump.
<45% health GTFO no matter what.

Would that work?

[DrBullwinkle]

The Emergency Jump script does not activate until the carrier's shields are already below the threshold set by the player. So we already know that it needs to jump, and jump "soon".

One of the problems with the vanilla Emergency Jump scripts is the ten-second jump timer. If we wait ten seconds, then the carrier may be in extreme jeopardy. This is why people often set the shield threshold very high (like 80%).

Emergency Jump is more reliable, in part because it does not wait the ten seconds required to plot a proper jump destination. The cost, of course, is that the jump destination is unpredictable. I have had emergency jumps take a carrier from Gaian Star to Jupiter, which is a very long way in the wrong direction. The reason was that I antagonized pirates, and there are pirates in many sectors, so Emergency Jump could not find a "safe" sector any closer than Jupiter.

Anyway, I do not think that the script will benefit from more tests. We already know that the carrier is losing the battle and must exit quickly. Recalling fighters is "optional".

[foxtrot76]

Funny thing about that... the US was created because of over-zealous taxation.

Hmmmm...

The only difference between death and taxes is that death doesn't get worse every time Congress meets.
Will Rogers

[DrBullwinkle]

[DrBullwinkle]

Edit: BTW I took a look at your script in XStudio to adapt the preferred weapon choices. I have to say it's quite an impressive nice piece of work! I never realized how much work there was behind this script.

Thanks. A lot of the code is there to make the script flexible. So that it can be used with various mods and other scripts such as ADS and CODEA.

1) Is there a different way to keep drones docked without having to remove homebase settings?

If there is, then I do not know how to do it. Forcing drones to re-dock if they launched without "orders" causes "dock/undock cycling" which is annoying. That is why I recently added the option to keep the homebase always On. Yes, the issue is vanilla behavior.

Is there a way to call a list of compatible weapons for the chosen drone, and having a sort of priority list (based on weapon stats?)

There is, although choosing priorities in the script would be more complex than the current system. Shimrod does that sort of thing in Smart Turrets. Do I need to repeat that weapons do not matter much to fighters? Shields are a far more important choice.

That said, I suppose that I could add a "fallback" case that auto-selects the most powerful compatible laser IF all other laser checks fail. That would solve your LX problem. At least the drones would get a gun, even if it is sub-optimal.

• LX's? Really? Aren't you supposed to be *shooting* Xenons rather than *flying* them?

[Etyneo]

2) I noticed a large portion of the variables are about choosing and checking which weapons can be mounted on what ship type. Is there a way to call a list of compatible weapons for the chosen drone, and having a sort of priority list (based on weapon stats?) or something similar to select the weapon? I ask because I noticed that the LX drone with XRM mod doesn't get any weapon assigned due to the fact that none of the weapons in your list are compatible.

I expect this is to allow the weapon selection code to work on user specified drone types, and to allow DCS2 to work with many mods that may change what weapons that ships can fit. XRM, for example, changes a ton of weapons related things, including which weapons any given ship can fit.

Edit: Derp...maybe I should read the whole paragraph before replying to it... I've not noted an issue with weaponless drones...but then again, I don't set them to be LXes...unless I'm running a Xenon Rogue start...which I'm not this time around...

In any case, perhaos DrB could get away from a static list of weapons and query the game itself to see what weapons are compatible with what ships... Yes, I do realize that this could be a lot of work, but it would have the benefit of effectively eliminating the problem of LX drones with no guns in XRM...which would also ensure that at least the weapon selection part of the code is compatible with any mod.

[DrBullwinkle]

I've read many similar discussions (smart turret thread) about weapons of choice vs fighters between PPC and beams. ... When I get home I'll think about how to setup such a test. What would you suggest 100 rounds of 10 fighters with weapon swapping vs 10 fighters without? Would 100 rounds be sufficient to produce somewhat reliable results?

The discussion of choosing a weapon to shoot *at* fighters is quite different than the discussion of choosing weapons for the fighter to shoot. Capital ship weapons vary widely in their stats (PPC vs Flak, for example). Fighter weapons do not vary so much. For a fighter, the most energy-efficient weapon is often superior to "heavier" weapons, simply because the fighter can fire more shots with the efficient weapon.

You do not need 100 rounds to test this. A single round of your favorite M3 (with any weapon you prefer) against Falcon Haulers with EBCG's is all you need to demonstrate how it works. Heavy shields wins every time. Especially so if you mount efficient weapons on the heavily-shielded fighter.

[foxtrot76]

Thanks for the reply

Do I need to repeat that weapons do not matter much to fighters? Shields are a far more important choice.

Hehe no, I wasn't thinking about weapon swapping, but rather about a situation such as a mod like XRM changing weapon compatibility for ships as well as changing weapons stats.

• LX's? Really? Aren't you supposed to be *shooting* Xenons rather than *flying* them?

After all you're giving us the tools to distribute large scale destruction, what better custom start to chose from?
"Captain we're surrounded"
"Nonsense, we're in a target-rich environment"

The discussion of choosing a weapon to shoot *at* fighters is quite different than the discussion of choosing weapons for the fighter to shoot. Capital ship weapons vary widely in their stats (PPC vs Flak, for example). Fighter weapons do not vary so much. For a fighter, the most energy-efficient weapon is often superior to "heavier" weapons, simply because the fighter can fire more shots with the efficient weapon.

Since you brought up weapon swapping I'll take the chance to clarify what I ment. I was more looking at travel speed of the weapon projectile itself, noting that the travel speed has a significant impact on the efficiency of the weapon vs fighters. This is why I brought up the example of PPC vs Beams.

I completely agree with you concerning energy efficiency being important, but when looking at fast-moving targets the actual projectile speed becomes proportionally more important the higher the speed of the target is (and subsequent transversal speed).

This all boils down to my personal observation (not backed up by testing) that it's better to land hits due to fast travel time (and lower DPS), rather than being able to shoot longer and have a theoretical higher DPS which doesn't really get applied since most shots will miss. However the opposite is true the slower (and usually larger) the target becomes but also the lower the transversal speed becomes (this can also apply to a fighter flying straight towards or away from the shooter). Energy efficiency becomes therefore more relevant as the target becomes slower transversally and sustained fire is called for. This is the foundation of my reasoning behind weapon swapping.

I'm not really asking for you to implement the option since it's not really crucial. I'm genuinely curious about the topic since I have perceived a notable improvement in effectiveness and am starting to wonder if I was fooling myself. =)

[DrBullwinkle]

I'm genuinely curious about the topic since I have perceived an improvement in drone effectiveness and am starting to wonder if I was fooling myself. =)

How do you measure "effectiveness"?

If you measure how many kills per minute (without caring about drone survival), then weapons might make a difference.

If you measure whether your fighters die or enemies die, then weapons do not matter much at all (to AI pilots). Survival is more important than firepower.

[foxtrot76]

I'm genuinely curious about the topic since I have perceived an improvement in drone effectiveness and am starting to wonder if I was fooling myself. =)

How do you measure "effectiveness"?

If you measure how many kills per minute (without caring about drone survival), then weapons might make a difference.

If you measure whether your fighters die or enemies die, then weapons do not matter much at all (to AI pilots). Survival is more important than firepower.

I personally measure effectiveness in how fast my fighters deals with it's current target and moves on to the next one. I'm starting to see now where our opinions differ. We both strive for the same result abeit using different approaches.

Edit: Survivability often depends on shields but also in how fast you get an edge in the battle when both formations collide especially if yours is outnumbered.

[DrBullwinkle]

Right. That is why you have come to the wrong conclusion.

[foxtrot76]

Right. That is why you have come to the wrong conclusion.

HA! prove me wrong! (jk you don't need to prove anything)

Still I'm glad we finally came to understand our respective approaches to the "problem". This is the beauty of sandbox games... multiple solutions and all are "right"

[DrBullwinkle]

Sure. Fine.

• (Except that your "solution" is not right in any important way. Imagine explaining to the mothers of your dead pilots why you gave them bigger guns and weaker shields. )

[foxtrot76]

Sure. Fine.

• (Except that your "solution" is not right in any important way. Imagine explaining to the mothers of your dead pilots why you gave them bigger guns and weaker shields. )

I understand, and won't insist. I'll simply test it and either there will be silence from my side or....

[Mad_CatMk2]

1) Is there a different way to keep drones docked without having to remove homebase settings?

If there is, then I do not know how to do it. Forcing drones to re-dock if they launched without "orders" causes "dock/undock cycling" which is annoying. That is why I recently added the option to keep the homebase always On. Yes, the issue is vanilla behavior.

I recall CODEA did something about unequipping weapons on landed fighters to prevent them from automatically launching? Or is it a combination of both? Or I'm wrong..

[DrBullwinkle]

Removing weapons might be less invasive than changing the homebase. Thanks, I will give it a try.

[Tiek]

But it does not work, the script simply ignores the code and the Carrier jumps

*Chuckle*... yeah, that is why I have not posted an update yet!

You discovered some of the issues, yes. Another is that the carrier is "losing" whatever battle it is in, so it cannot afford to wait for fighters for long.

I am approximately where you are in the test process. My current thinking is that the carrier should emergency transport fighters in range, jump, *then* recall the rest. Possibly expand the radius for the emergency transport to 20 or 30km.



EDIT: The problem with the carrier needing to jump quickly is the reason that I never bothered to completely fix the "problem" in the first place.

Hi Doc... Yep, I understand your point of view... to save the Carrier is more important, I know it's useless to wait for fighters if the Carrier can't survive What do you think of sending fighters to the nearest Station if they are far beyond the 20 km at the time of Homebase emergency jump (and start the journey to Carrier if the Station is not available)?
Something like this:

Code: Select all

  RecallFighters:
  $CheckFighters.flags = [Find.Multiple]
  $sector = $ship -> get sector
  $fighters = find ship: sector=$sector class or type=Caccia race=Player flags=$CheckFighters.flags refobj=$ship maxdist=99999 maxnum=99999 refpos=null
  $f = size of array $fighters
  $sector.owned.fighters = array alloc: size=0
  
  while $f
    dec $f = 
    $fighter = $fighters[$f]
    $homebase = $fighter -> get homebase
    $env = $fighter -> get environment
    
    if $env == [SECTOR] AND $homebase == $ship
      append $fighter to array $sector.owned.fighters
      $k = size of array $sector.owned.fighters
      do if $k
        write to log file #$PageID  append=1  printf: fmt='%s is recalling fighters. k=%s', $ship, $k, null, null, null
      
      $fighter.distance.to.homebase = get distance between $fighter and $ship
      $has.docking.computer = $fighter -> get amount of ware Computer d'atterraggio in cargo bay
      if $fighter.distance.to.homebase < 20000 AND $has.docking.computer
  * Fighter is close to homebase carrier, so use Docking Computer.
        $fighter ->interrupt task 0 with script !lib.interrupt and prio 1000: arg1=null arg2=null arg3=null arg4=null
        $fighter ->put into environment $ship ->
        write to log file #$PageID  append=1  printf: fmt='Fighter %s recalled and is attempting to auto-dock at %s. Shields=%s. Hull=%s', $ship, $homebase, $shield.percent, $hull.percent, null
      else
        if $fighter.distance.to.homebase >= 20000
          $CheckFighters.flags = [Find.Nearest] | [Find.DockingAllowed] | [Find.Friend] | [Find.Neutral]
          $station = find station in galaxy: startsector=$sector class or type=Stazione race=null flags=$CheckFighters.flags refobj=$fighter serial=null max.jumps=6
          if $station -> exists
            $fighter ->interrupt task 0 with script !lib.interrupt and prio 1000: arg1=null arg2=null arg3=null arg4=null
            skip if $fighter -> is script !ship.cmd.movestation.std on stack of task=0
              $fighter ->start task 0 with script !ship.cmd.movestation.std and prio 2000: arg1=$station arg2=null arg3=null arg4=null arg5=null
            write to log file #$PageID  append=1  printf: fmt='Fighter %s recalled and is attempting to return (flying) to %s. Shields=%s. Hull=%s', $ship, $station, $shield.percent, $hull.percent, null
          end
          if not $station -> exists
            $fighter ->interrupt task 0 with script !lib.interrupt and prio 1000: arg1=null arg2=null arg3=null arg4=null
            skip if $fighter -> is script !ship.cmd.returnhome.std on stack of task=0
              $fighter ->start task 0 with script !ship.cmd.returnhome.std and prio 2000: arg1=$homebase arg2=null arg3=null arg4=null arg5=null
            write to log file #$PageID  append=1  printf: fmt='Fighter %s recalled and is attempting to return (flying) to %s. Shields=%s. Hull=%s', $ship, $homebase, $shield.percent, $hull.percent, null
          end
        end
      end
    end
  end
  endsub

Based on some tests done it seems to work

[DrBullwinkle]

What do you think of sending fighters to the nearest Station ... ?

There is nothing wrong with doing that, as long as the station is friendly and the fighters can dock there.

In most cases, if the carrier is in jeopardy, then the fighters are unlikely to survive as well. In any case, it probably does not matter much what the script does with the fighters -- the player will have to intervene and guide any fighters that survive the lost battle.

• (Please do not quote entire posts. It makes the thread *harder* to read rather than easier.)

[Etyneo]

I'm noting some odd behavior with 2.07. I've modified the config t files to set peacetime bomber percent to 0 (all language variations of the file...just to be sure...). However, I'm noticing that anytime I start DCS2 on a new ship, or increase the number of slots DCS2 is allowed to use, it tends to build a bomber, regardless of my setting.

After some time, DCS2 will replace the bomber with an Interceptor. While not a huge issue (provided I get all the creds back for that bomber and equipment...) I just thought I'd point it out.

[DrBullwinkle]

OK, thank you for the report. I will take a look at that.

Yes, you get all of your credits back when a drone is recycled. That is true when you turn off DCS2, as well as when bombers are automatically recycled every ten minutes or so.

You do not need to edit all of the t files -- just the one for your language. If you play in English, that is the -L044 file.