Squashing Bug #666 (Partial Fix)

The lag is caused by the program I was using to record the video

Showing off that the hw1 interceptors are staying in formation while attacking, also they are keeping the same target.

[Edit] 2nd attempt at a video, also with a better/working bandbox attack

At about ~18 sec, the strikegroup is targeting an attackbomber which was not part of the bandbox selection, that’s why it switches targets (I think it happens at least one other time in the video).


After trying to fix this for a while, I am going to have to throw in the towel. The issue is that the target selection is done on a per ship level, meaning each ship in a squadron/strike group is creating there own targeting list. Upon creating this list, the ship then selects the best target, and if more then one, it will randomly select it’s target.

While fixing HW2 squadrons can be down with scripting, fixing strike groups can not (That is if they are forced to stay in formation while attacking). Most of my earlier results where happening as the units where creating similar targeting lists and I was just getting them to attack the first target in that list. But if there targeting lists differ, then they will attack different targets.

The code to fix squadrons is

Rule_AddInterval("RULE_FixSquadronTargeting", 0.25)

function RULE_FixSquadronTargeting()

  for player = 0, Universe_PlayerCount()- 1 do
    local int,max = 0, SobGroup_Count("Player_Ships"..player)

    while (int < max) do
      SobGroup_FillShipsByIndexRange("temp1", "Player_Ships"..player, int, 1)

      int = int + 1
      int = int +(SobGroup_Count("temp1")- 1)

      if (SobGroup_Count("temp1") > 1) then
        SobGroup_GetCommandTargets("temp1", "temp2", COMMAND_Attack)

        if (SobGroup_Count("temp2") > 0) then
          SobGroup_FillShipsByIndexRange("temp3", "temp2", 0, 1)
          SobGroup_Attack(player, "temp1", "temp3")
  • This does not work with bandbox selection (After the first target is destroyed, a new targeting list is created)

Well thank you for at least trying to fix this on your own time anyway, it is truly very much appreciated! Really shines a bad light on GBX though for leaving the game in this state after creating this issue with the 2.0 patch in the first place. This really doesn’t give me much confidence for any future game in the franchise coming from GBX, which sucks because I love Homeworld :cry:

At this point I should ask if it is possible to create a community patch mod with this and the other fixes that are possible to mod out… Unfortunately I can’t mod. However, I can, and am willing to, do repetitive jobs (provided that someone gives me the raw files and the instructions).

I helped in making a mod localizable, so if there is something similar that I can do, count me in :slight_smile:

I quite enjoy doing scripting for HW2 and would be happy to help, though I can’t be sure as to how much time I can put in as I am meant to be working on a mod for the game.

To show my lack of knowledge, what are the other issues?

If one of the issues is that defense fighter’s don’t shoot down ballistic weapons, that is due to HW2 not having that ability. Changing the ballistic weapons to missiles kinda helps, but there are issues surrounding that. One being that missiles don’t collide with asteroids. Also, while scripting can force a unit to target missiles, it can not distinguish between different types of missiles (fake ballistics, missiles, torpedoes). And if not forcing a unit that can only attack missiles (defense fighter), it will target a ship and not disengage.

If GBX does ever come back to this game, even if not to fix any bugs, I do hope they add 1 function that allows filling a sobgroup with the strikegroup of a selected unit. This is all that is needed for a basic scripting fix for bug 666. But that is just one function of a growing list of functions I wish GBX would add.


I was referring mainly to the thread “2.1 Patch Balance Issues”, but it seems it was removed (you can see a glimpse of it here: Announcement - Public Patch Preview). I don’t know if every issue that was written there is now fixed or not…

@echo7 and @shadowwinterknig, it is possible to rework some features through modding to ‘fix’ some of the primary issues with the game, but the biggest offender is the broken targeting behavior.

For the most part, each ship has to be looked at and re-balanced. Some need drastic changes, others need minute tweaks. I put up a post months ago trying to gather some people for a community fix of sorts, but was burnt out at that point and not many were on board. However, seeing as how I have a lot more free time in the coming weeks, I’d be willing to join up with some people mod away.

As far as other issues, I think multiplayer balance as a whole needs tweaking, but that’s hard to do without tackling the targeting issues (unless reworked). Some other problems involve random sound bugs and ship fire animations (gearbox didn’t do some weapon/subsystem .events files correctly), excessive changes of targeted ship based on distance, infiltrator/marine latching… and more. I still have copies of my old spreadsheets that are helpful too.

1 Like

Yeah, I was actually just looking for that thread, but I noticed it wasn’t there either. Its a bummer, as cloaked put a LOT of effort and dedication for the game and community. At least a majority of the issues were implemented in the current patch preview, but the standard game still needs those fixes.


Couldn’t help myself, I think I am getting obsessed with trying to figure out this error.

Doing things a different way. Still got a ways to go, but results are looking better.

1st target not all kushan interceptors are targeting the same unit. Once that target is destroyed at ~30sec, then they start targeting the same unit. A few times towards the end of the clip, I start quickly switching their stance between aggressive and evasive to see if there targeting the same unit.

There is also a hiigaran interceptor squad flying around that is in the same strike group as the kushan interceptors, but is able to target different targets even though their inital target was the same as the kushan interceptors. (Problem with the old way I was doing things)


The player units are 5x Kushan Interceptors in a strike group, 5x Taiidan Interceptors not in a strike group and 2x Hiigaran Interceptor squadrons in a strike group.

To explain the ATI

<ShipType> <InStrikeGroup?>
  Max Targets ? Current ?

Current is how many units the group is currently targeting, 1 is what it should be.
Max Targets is the highest Current has been. Current needs to be higher then Max Targets for ~5 seconds before Max Targets is set. If Max Targets hasn’t changed for ~20 seconds, it is reset back to Current.
This is done due to how the script captures the strikegroup. If a ship moves too far away from the rest of the strike group, it momentarily thinks its in a different strike group. Longest I’ve noticed Current to be higher the 1 is for ~10 seconds.


Made a few tweaks to the code. Also made changes to the ATI display (Removed the Max Targets reset after ~20sec and added a timer to see how long the strike group has 1 target)

Next I will need to check band box selection and also mixed ship type strike groups and different formations.

A few issues I’ve noticed with this is that the targeting line may flash before changing targets (this only occurs after the strike groups primary target is destroyed)
Due to how I gather units for a strike group, there are moments when 2 strike groups are in close proximity and one strike group destroys there target, either the entire strike will start targeting the other strike groups targets or members will think there in a different strike group ( for the second case, this is only temporary until the strike groups move apart)

Have you looked at the ‘attack behavior visualizations’ link in the initial post? It might help direct you a bit with the target flickering as to what the problem could be.

Thinking about the issue, I believe it’s with my script where it’s trying to force the strikegroup to attack a unit that’s in it’s death phase, something the game doesn’t like.

The excessive switching of targets is, to the best of my knowledge, is caused by the attack styles. ((My script doesn’t allow the attack styles to switch target))
The attack styles are basically a set of possible actions the unit can do using a weighted random system. One of these possible actions is ‘PickNewTarget’. The issue (At least what you have noticed in the vanilla game) is that the unit is selecting this action too often, either from there being too many ‘PickNewTarget’ actions in the attack style, or a ‘PickNewTarget’ has a too heavy weight.
Removing these doesn’t fix Bug #666, but is what is causing both the constant switching of targets, as well as the random (temporary) fixing of Bug #666.


This might be the best I can do on this issue. The biggest problem is trying to find units that are in the same strikegroup.

No need to read the following as I’m just rambling on about a better fix if gearbox was to add a few new functions.


If gearbox was to continue with Homeworld, and for some reason chose not to fix this bug, then (at least for me) 3 new functions and changes to 2 other functions would make this bug easily fixed with lua.

For the new functions, the most important is something to get the strikegroup of a unit.


Next, due to how strikegroups work, it would be best to know the group stance (“None”, “Batch”, “Shape” and “Subs”)


With group stancing, sub formations are determined by there attack family and combat family. Currently, there is no way I know of determining a units combat family other then loading the units ship file. As such, adding a new filter tag “combatFamily” would be of use.


While the above determines what units are in a strikegroup as well as there current stance grouping, deciding who to attack with lua will replace any back-end code that does a much better job. To correct this, first it would be best to know what unit a ship is attacking.


Lastly, there would need to be a way to set the primary target from a list of potential targets, this could be done using

SobGroup_Attack(<Player>, <SobGroup>, <SobGroup-ToAttack>, <PrimaryTargetIndex>)

If these function were added, the lua code to fix this bug would be

function FixTarget_Init()
  if (Rule_Exists("FixTarget_Rule")~= 1) then
    Rule_AddInterval("FixTarget_Rule", 0.25)

function FixTarget_Rule()
  if (attackFamily == nil) then
    attackCount = getn(attackFamily)


  for player = 0, Universe_PlayerCount()- 1 do
    SobGroup_Copy("Player_Ships", "Player_Ships"..player)

    while (SobGroup_Empty("Player_Ships")~= 1) do
      SobGroup_FillShipsByIndexRange("Squadron", "Player_Ships", 0, 1)
      SobGroup_FillSubstract("Player_Ships", "Player_Ships", "Squadron")

      if (SobGroup_InStrikeGroup("Squadron")== 1) then
        local groupStance = SobGroup_GetStanceGrouping("Squadron")

        SobGroup_FillStrikeGroup("StrikeGroup", "Squadron")
        SobGroup_FillSubstract("Player_Ships", "Player_Ships", "StrikeGroup")

        if (groupStance == "None") then
          -- fix everyone

        if (groupStance == "Shape") then
          for int = 1, attackCount do
            SobGroup_FilterInclude("StrikeFamily", "StrikeGroup", "combatFamily", attackFamily[int])
            SobGroup_FillSubstract("StrikeGroup", "StrikeGroup", "StrikeFamily")

            if (SobGroup_Count("StrikeFamily") > 0) then

          for int = 1, attackCount do
            SobGroup_FilterInclude("StrikeFamily", "StrikeGroup", "attackFamily", attackFamily[int])
            SobGroup_FillSubstract("StrikeGroup", "StrikeGroup", "StrikeFamily")

            if (SobGroup_Count("StrikeFamily") > 0) then

        if (groupStance == "Batch" or groupStance == "Subs") then
          -- only fix squadrons
          while (SobGroup_Empty("StrikeGroup")~= 1) do
            SobGroup_FillShipsByIndexRange("StrikeFamily", "StrikeGroup", 0, 1)
            SobGroup_FillSubstract("StrikeGroup", "StrikeGroup", "StrikeFamily")

            if (SobGroup_Count("StrikeFamily") > 1) then



function FixTarget_SetPrimary(player, sobGroup)
  local player,primaryIndex = SobGroup_OwnedBy(sobGroup), SobGroup_GetPrimaryTargetIndex(sobGroup)

  SobGroup_GetCommandTargets("FixTarget_SetPrimary", sobGroup, COMMAND_Attack)
  SobGroup_Attack(player, sobGroup, "FixTarget_SetPrimary", primaryIndex)

Made a slight change to my attempt at a fix so it is multiplayer safe

Also tried a slightly different way at capturing strikegroups

v2 seems to be better at capturing strikegroups, but there is the added risk on incorrectly capturing units from another strikegroup (Though only when they are too close, should fix itself when the move apart)


I don’t really understand the details of what you are doing but I’d like to say that I’m very pleased someone is making progress in this area :slight_smile:



I updated the main post quite a bit, and included your fix!


Wow, thanks a lot for your work! I have a few questions though:

  1. Is v2.1.2 MP safe too or just for SP and skirmishes?
  2. If it is not, do I have to manually remove a version before using the other? Or, how do I swap from the MP safe version to the SP one and vice versa?
  3. Where do I unzip the files? (Sorry if the answer seems obvious to you guys, but I am not a modder :confused:)
  4. Can a Steam version be made (for ease of installation) to make it visible to a larger audience?
  5. In multiplayer, do all players need to have the fix or it is sufficient that only the host has it (like it is for Cloaked’s Ace Maps from ModDB)?

Thank you again :slight_smile:

1 Like

Trebic created a new thread for the 666 fix here:

I did some testing with the latest version of the fix, and its SP and MP safe. However you can only use this in SP or LAN, until a formal Steam Workshop mod is created. For multiplayer, all players will need to have the mod.

I’m now planning to release a Patch on the Steam Workshop soon. It would include the 666 Fix, the balance fixes included in the Patch Preview, and balance fixes for the few remaining minor open issues.

Edit: Here’s some additional technical details from messages I exchanged with Trebic:

Click to view technical details