Bug 666 partial fix + multi-mod compatability

Does this fix the guard behavior, kushan drones, and repair orders?

Also, do turreted weapons work as intended? Often times turrets will choose to fire at another target, most noticeably with battlcruiser ion cannon turrets.

1 Like

Currently making changes to the drone frigate so that the drones will shoot at the drone frigates current target. Also trying to get the drones to stay in formation with the drone frigate.

To be honest, I am unsure as to what the guard behaviour and repair orders issue is.

Turrets should/will target secondary enemy units if they are unable to target the primary enemy unit. This is an intended feature of the game.

As to the repair frigates, there is an issue sometimes when they are ordered to heal band-selected allies. The corvettes will just freeze.

The turret question I ask because just about every game I played, a cruiser would have one stray ion turret that decides it wants to shoot a collector or something instead of the enemy carrier or something. But yes, shooting enemies while the primary cannot be hit is intended.

1 Like

Includes changes to the kushan drone frigate.

  • Drones will try to stay in formation with the drone frigate.
  • Drones will target what unit the drone frigate is targeting.
  • If the primary target is out of range, drones will target a second unit until the primary target is in range. (Only works if the drone frigate has more the one target)

Made slight changes to the strikegroup fix as some targeting functions used in the strikegroup fix are also used with the drone frigate.

Due to both drone targeting and how the drones attempt to stay in formation, changes were made to soundscripts\speechlogic\commands.lua so the audio wouldn’t be overloaded with drone chatter.

Changed the drone weapon weapon\kus_drone\kus_drone.wepn so the drone has a better 360° attack.

scripts\attack\justshootkusdrone.lua was changes so that drones can move and shoot at the same time (Not great as the options just don’t appear available)

I’m not sure I will be able to do anything with the repair corvettes. The only function I can find the tells what unit is repairing what is one that you find what ships are repairing a certain ship. This means that I would need to loop thru most ships to create a group of ships that are repairing, seperate out the repair corvettes, then find a way to get them back to repairing if they have frozen. The later part may be easy(ish), but the first part will be a bit much.


@bitvenom: It would be amazing if you could force a hotfix to this like back then when I reported the Hyperspace salvage corvette exploit/bug. Talk to your CEO for us will you? It might even offer the possibility to implement all the stuff you added since you were relocated to another project. No matter whether is is finished or not it certainly would be a benefit to the small community. It might even attract more potential buyers if suddenly star trek shields do work as intended. (mod community = sales)

You’re the HW master… In a sense it feels as you were the main executive to this remastered project so use your influence in that regard. Considering you used to be a fan since childhood like myself make something outta it.

By the actual player community - no matter which game it accounts for towards Gearbox today: Gearbox does suffers greatly in trust and comfort. Because your CEO’s cease support for any particular game far too soon. Games which are still in need of bug-fixes, and balance adjustments This is your chance for Gearbox as a company to proof these claims to be false and wrong. And that’s not me stating these claims. You can google for this on countless forums and press review sites for numerous Gearbox projects. I still know and love Gearbox for Hl1 Opposing Force… Damn am I old nowadays. Most certainly a relic. :wink:

Ps: This post isn’t meant to discourage you or any of your fellow GBX employees - actually the opposite. I always say what’s on my mind. So take it into consideration. So far my criticism was well accepted both on countless freebie mods as well as even a few commercial products. Consider me as the meal taster in the restaurant. I write what’s on my mind whether people like or dislike it.


@JoeKGBX @pdeupree @thisquietreverie FYI


I’m pretty sure you mean: “cease support far too soon”…


Aw yeah, thanks for updating!

Now all we need is a community patch for multiplayer, and a ‘classic’ patch for Hw1 to restore ships to their original Homeworld stats with armor, weapons, speed, etc for the Hw1 campaign multiplayer.

@shadowwinterknig this is amazing! I’ve added this to STC on @Cloaked’s tipoff with credits to you in our ReadMe :wink:

1 Like

question… because i am semi new to this… @Cloaked and @shadowwinterknig

If I wanted to use the 666 fix and the patch 2.3 with my mod what is the best approach? The fix seems like something I could just incorporate into my mod so as not to have to run multi mods… but the path 2.3 might have more updates by its authors and there for I would want to benefit from that but running it in conjunction… does that sounds correct?


To bring it into STC I copied and pasted the SCaR folder from v2.1.4 into my scripts folder and updated */targetfix/default.lua with my own ships (smaller than 100m, arbitrarily chosen size cutoff)

I did notice however that the functions are declared more than once, so some optimisation is still in order, as you get this in the log:

 Cannot overwrite function nrandom 
 Cannot overwrite function GetSobGroupId 
 Cannot overwrite function LoadStrikeGroup 
 Cannot overwrite function addStrikeGroup 
 Cannot overwrite function GatherStrikeGroup 
 Cannot overwrite function GetTargetList 
 Cannot overwrite function GetAttackTarget 
 Cannot overwrite function SobGroup_CountBySquadrons 
 Cannot overwrite function SobGroup_Equal 
 Cannot overwrite function SobGroup_IsAlive 
 Cannot overwrite function SobGroup_GetDistanceToSobGroup 
 Cannot overwrite function SobGroup_GetDistanceToPoint 

Nothing damaging, just polish :slight_smile:

I can’t actually see where these are being declared more than once though so… I am not sure :confused:

1 Like

If you want to prevent this kind of behavior, you can do this :

if YourFunction == nil then
	function YourFunction(aaaa)
		return something

It will not “reload” the function if it has already been declared previously.


Unfortunately after much testing, the 666 Fix frequently causes “out of sync” errors in online multiplayer. :frowning:

Hopefully Trebic or someone else can make the 666 Fix safe for online multiplayer in the future. For now, I’ve modified the 666 Fix, so it is disabled when playing Online/LAN: StrikeGroup_v2.1.5. The following was modified:

  • restrict.lua - Now disables the 666 Fix when playing against another human.
  • default.lua - Cleaned up the comments as they were out of date. Fixed the Hgn_AttackBomberElite’s JoinStrikeGroupDelay, it was accidently set to 200 seconds instead of 2 seconds.
  • functions.lua - No changes.
  • targetfix.lua - No changes.

Despite testing the 666 Fix in LAN many times without any “out of sync” errors. Playing Online is another story… Some packets get dropped while transversing the internet, and each client/player typically slowly drifts apart and ends up playing 99.9% of the truth. The HWR engine is pretty flexible and can compensate for this. Until a hard conflict occurs causing players receive an “out of sync” error.

Due to the way the 666 Fix works, it is not very flexible in this regard and often throws hard conflict “out of sync” errors. Trebic said there is no good way to capture the members of a formation, so Trebic had to do a 200m proximity scan to detect formation members.

Root Cause
The “out of sync” errors are occuring when a swarm of fighters in combat get all bunched up, with multiple formations/squadrons on top of each other. I’ve recorded this first hand four times, and I’ve also got a bunch of sync logs from five different players supporting this. You can tell in the sync logs that prior to the “out of sync” error, each client/player is always running a slightly different version of the truth (thats typical for HWR online).

My theory is that when the 666 Fix does its proximity scan, each client may capture different formation members. This will then throw a “out of sync” error.

Perhaps theres an alternative to the proximity scan that hasn’t been thought of yet. Squadrons are formed when fighters are built. Formations are formed by the formation buttons. Maybe there’s something we can leverage based on that.

Additional Notes
Tweaking the ProximityToScan and the JoinStrikeGroupDelay are unlikely to solve the problem. After testing, the default of 200m and 2 seconds seems to be ideal.

Additionally, the 666 Fix currently uses the NRandom function to pick a target from a target list. I tried replacing the NRandom function with zero, so the first target would always be picked. Unfortunately the syncs were still occuring, so NRandom is not the root cause. Its possible however, that NRandom many increase the likelihood of a sync. Trebic, just guessing here but aren’t the target lists themselves somewhat random? If you just always picked the first target in a somewhat random target list, you wouldn’t need NRandom.


the problem with the formation buttons is it only works single player and it may split the selected group into more then one strikegroup.

i’ve tried a few different ways at capturing the formation of a stikegroup and felt the proxyscan is the best option so far :frowning:

the nrandom function gives a variety in the targets selected. for a while i was using 0 but it just felt to predictable in selecting targets.


Actually, it was even simpler than that @Dwarfinator :smiley:

In TargetFix.lua, I commented out dofilepath("DATA:Scripts\\SCaR\\Functions.lua")

In Restrict.lua I swapped around the two dofilepath thingies so that the functions are called after the TargetFix is


Now, it’s all only called once :slight_smile:


Spent the last week hammering on 666, and I came up with a solution!!! :smiley: Since Trebic’s script causes syncs online, I started looking for alternatives. Instead of trying to fix the targeting bug, I simply enabled ships to fire on secondary targets. So imagine the image below, but with all 5 ships firing their weapons at the secondary target in front of them. This works just as good, and is indistinguishable to the player.

Sounds easy right? Well modding is never easy… I know several people (including myself) tried to do this in the past, but kept hitting a brick wall. Turns out there’s a design limitation from 2003, that we weren’t aware of:

"Weapons with “gimble” setting will not periodically update their targeting assignment even if secondary target engagement and independent scanning is enabled. These will “stick” their target to the one designated either by the player, or the ship’s selected target… Use AnimatedTurret if you’d like to have weapons [attack secondary targets]… [For Example] Vagyr and HGN Mothership defense guns function much better as AnimatedTurret setting. Note that this does not require an actual turret model, see Vagyr Battlecruiser’s side hull lasers."
Source: http://hw2wiki.net/wiki.hw2.info/BugsReference_show_comments=1.html
FunctionStartWeaponConfig reference: http://hw2wiki.net/wiki.hw2.info/FunctionStartWeaponConfig.html
FunctionsetAngles reference: http://hw2wiki.net/wiki.hw2.info/FunctionsetAngles.html


The solution is to convert Gimble weapons to AnimatedTurret weapons, and allow them to fire on secondary targets.



sWeaponType: Gimble -> AnimatedTurret
iShootAtSecondaries: 0 -> 1
iShootAtSurroundings: 0 (best to leave this disabled)
fMaxAzimuthSpeed (Horizontal Tracking): 0 -> 500
fMaxDeclinationSpeed (Verticala Tracking): 0 -> 500
iTrackTargetsOutsideRange: 0 (best to leave this disabled)
fTriggerHappy (FiringArc): 25 -> 0
fMinAzimuth (LeftRotation): 0 -> -25
fMaxAzimuth (RightRotation): 0 -> 25
fMinDeclination (DownRotation): 0 -> -25
fMaxDeclination (UpRotation): 0 -> 25

Ships Affected in Default Game
Hiigaran: Scouts, Interceptors, Bombers
Vaygr: Scouts, Assault Craft, Bombers, Lance, Laser Corvettes
Kushan/Taiidan: Scouts, Interceptors, Bombers, Cloaked Fighters

Weapons Affected in Default Game:

Note that these weapon conversions will significantly improve their effectiveness, so a balance pass will need to be made after making these changes. Edit: This solution is now in the 2.3 Players Patch.

All credits still go to Trebic for tackling this. Without him, I’m not sure if anyone would have solved this problem anytime soon.


Hooray! So to make this work for mods, we need to make that change to each ship file?

1 Like

Yep, each weapon file used by a fighter or corvette. Just convert any Gimble weapons to AnimatedTurret weapons, and allow them to fire on secondary targets.

I’ve been testing fulcrum fighters extensively the last few months, and watching fighters joust ineffectually, especially when put into formations, was becoming torture. Then I realized this fix existed and I hadn’t implemented it yet, and the change has been massive. I think it even helps ‘open swarm’ behavior, because suddenly fighters will take pot shots at targets of opportunity in the furball rather than getting target fixation.

It’s still not perfect, and I still can’t get my defenders to stay in a formation to save my life, but it’s still a world of difference. My hat is off to @Cloaked and everyone else who contributed to sorting this out.


Is that all that is required? And do players then need to download the 2.3 Players Patch to benefit?

@Dom2 Yep, thats how to fix the 666 bug. See my post above for details, its pretty straight forward.

This was done in the 2.3 Players Patch, and is currently being done in other mods as well. Hopefully all major mods include this fix going forward.