HW3 Mod teams wishlists

G’day everyone!

As a central point to refer the BBI dev wizards to I propose we have this thread with each mod team’s consolidated wish lists of features.

Here is the compiled summary from the posts below (as of 14/09/2019)!
There are some excellent observations in amongst the posts, please review them all carefully if you’re the lucky guy from BBI checking this out :wink:

Request Category Count
Scenario editor Scripting 7
Visible construction progress outside a ship FX 5
Fuel and Ammunition consumption, regeneration and limits. Ability to genericise for other uses Gameplay 5
Model mesh sizes again limited by hardware, not software, and use of LODs to compensate FX 4
Real shields with options for adaption to bubble or hull hugging shield types Gameplay 3
“Linked” ships Gameplay 3
Persistant veterancy Gameplay 3
Mimic type ability FX 3
Randomised unit naming from list UI 3
Native random map generation Gameplay 3
LUA 5 Scripting 3
Texture memory limited by hardware, not software, and use of LODs to compensate FX 3
Documentation for the scripting functions, shader functions, anything and everything Scripting 3
Remote capture mechanics Gameplay 2
Greater control over push/pull/hold/drag weapons (newtonian) Gameplay 2
Advanced point defence options Gameplay 2
Improved AI that can perform well with and without mod races Scripting 2
Avoid hard coding Scripting 2
Map generator Scripting 2
Ability to carry externally docked ships through hyperspace Gameplay 2
Make HODs modder friendly again or use something that is Ship Rigging 2
Background objects casting shadows Shaders 2
Joints need to respect the animations of the joint they are mounted under (i.e. weapon points) Ship Rigging 2
Damage impacts ship performance Gameplay 1
Light emitters for bullets and missiles FX 1
“Wave” type weapons Weapons 1
Construction of installations (not within a ship or hyperspaced in) FX 1
Passing randomised unit name or name ID to shader for use in shader Shaders 1
Multiplayer safe random seed Scripting 1
“Glass” Shader Shaders 1
Visual Studio Code “Homeworld 3” extension with all the functions Scripting 1
Custom per-dockpath animations Ship Rigging 1
Allow AI to use hyperspace for more than just a few hardcoded default units Scripting 1
Geometry mounted on joints and subsystems need animations to apply to them properly Ship Rigging 1
Ability to query the weapon firing process via script, particularly missiles Weapons 1
Ability to modify the sensor detection range from the target and detecting unit Scripting 1
Repair functionality can also assist with construction Gameplay 1
Destructible sections of ships Shaders 1
Armour and penetration values, not just multipliers Scripting 1
Armor “profiles” with internal collision meshes that can be hit, damaged and repaired. Think tank simulation games. Ship Rigging 1
Different ammunition types for single weapons Weapons 1
Weapon skeleton slaving for stacking turrets upon turrets or making coaxial weapons. Ship Rigging 1
Shotgun-type weapons or least cone-type AoE Weapons 1
Damage Over Time effect for weapons Weapons 1
Shader accessibility maintained or improved from HWRM Shaders 1
Improved functionality for passing information to shaders Shaders 1
Ability to query build queues for what’s being built and progression Scripting 1
Parallell research Scripting 1
HOD patching system (override geometry, textures, shaders, etc) Ship Rigging 1
Resource processing by the miner directly, not just retrieval to refinery Gameplay 1
Ability to chain or queue orders to units Gameplay 1
More varied attack styles and ability to select in-game Gameplay 1
Modern localisation support, especially around unicode character sets UI 1
Build different language packs into a single mod so no need to upload for each language UI 1
Ability to interact with map objects by scripting Scripting 1
Improved collision avoidance and pathfinding around other ships and space “terrain” Gameplay 1
Long term support plan, i.e. 1 patch per year until the community stops finding bugs Gameplay 1
Ability to balance test ship v ship combat to help mod balancing Gameplay 1
Ability to animate (rotate) dock paths Ship Rigging 1
Ability to animate collision geometry Ship Rigging 1
First party tools and plugins that are maintained Scripting 1
Avoid encryption of assets Scripting 1
Multiple types of resources and ways to get those resources Gameplay 1
No “roll the dice” damage system Gameplay 1
Post release downloadable content Gameplay 1
Official port project dlc - post release: Implementation of HW1 RM - HW2 RM and Cataclysm/Emergence assets + campaigns into the official HW3 game branch. Gameplay 1
64 bit exclusive, no more RAM limitations Gameplay 1
Dynamic singleplayer and multiplayer “comp stop” feature Gameplay 1
Allowance for spectator slots in games to help with Esports adoption Gameplay 1
Music player for skirmish and multiplayer Gameplay 1
Ability for the AI to learn by saving previous game stats Gameplay 1
Improved subsystem targetting system Gameplay 1
Improved support frigate usability without the need to micromanage Gameplay 1

Ballistics for bullets are on the official feature list!


MOD TEAM: Star Trek Continuum
LINK: Steam Workshop


  • Shields that can be used in a “Star Trek” fashion
  • Remote capture mechanics (no latch required, think transported marines, Borg assimilation)
  • “Linked” ships (Prometheus MVAM, Galaxy saucer separation)
  • Veterancy, persistant in single player
  • Damage impacts performance (weapon potency, engine speed, turn rate, etc)
  • Light emitters for energy weapons (bullets, beams, missiles)
  • “Wave” type weapons which affect multiple ships if they are hit (think Klingon superweapon)
  • Greater control over push/pull/hold/drag “weapons” (think tractor beams)
  • Visible construction (Like Star Trek Armada had, only “current gen”)
  • Construction of installations (i.e. not launched from a ship or hyperspaced in)
  • Mimic type ability (In the Trek mod context, think holographic camo)
  • 2nd teir targetting priorities for point defence so if a ship is capable of point defence torpedoes aren’t ignored in favour of other ships as targets
  • Randomised unit naming from a list
  • Ability to pass unit names or unit name ID to a shader so this can be used to apply registrations to ship hulls
  • Native random map generation
  • Multiplayer safe “random” number generator
  • “Glass” shader
  • An AI that can more easily accept new races and ships
  • LUA 5 would be nice
  • “Homewolrd 3” extension for Visual Studio Code with all the functions and stuff
  • Custom per-dockpath animations, not just the hard coded list that is in HWRM
  • Allow AI to use hyperspace for more than just a few hardcoded default units
  • No limit on Texture Memory (limited only by your hardware).
  • Poly limits per unit 100,000 or higher (again should only be limited by your hardware).
  • Subsystem mounted meshes shouldn’t be left behind when the the joint heirachy is moved (warp fx)

MOD TEAM: Flag Commander
LINK: Steam Workshop


  • Commands over weapon firing process, particularly missiles (i.e. being able to check when a missile/gun has been fired, possibility to control the way it chooses new targets in-flight, or trigger specific weapon fire with code);
  • Sensor detection range modified by the target as well as the detecting unit (allow for example the design of frigates that could remain unseen longer than others);
  • Veterancy, persistant in single player;
  • Mimic type ability;
  • Unit naming (possibility to have name lists for ship classes);
  • Dedicated point defence weapon mechanics;
  • Map Editor//Random Map generation;
  • Scenario Editor;
  • If possible at all, some access to the function documentation.

EDIT, to add valid points suggested in other posts below, listed here to avoid making too many different posts for my wishlist:

  • No limit on Texture Memory (limited only by your hardware).
  • Poly limits per unit 100,000 or higher (again should only be limited by your hardware).
  • Fuel and ammo consumption, regen and limit.

MOD TEAM: Freelance Modeler/Texture Artist

  1. Visible construction from framework to completed hull (think Cataclysm)
  2. Repair bots that also help with construction (again think Cataclysm)
  3. ALL Cap ships have some kind of researchable, or add on module for point defense against Missiles, and Strike Craft.
  4. Destructible sections of ships. (If engine subsystems are destroyed they show a burning wreck in that area).
  5. No limit on Texture Memory (limited only by your hardware).
  6. Poly limits per unit 100,000 or higher (again should only be limited by your hardware).

For # 5, and 6 i understand that the dev’s have to make the game playable on a wide range of systems. This request is for removing these limits for modding.


MOD TEAM: many of them

  • Armor and penetration values, not just multipliers.
  • Actual armor profiles, set in collision mesh; and internal components (like power core, crew area, instant death) being collision objects that can be hit, damaged and repaired. Think those tank simulation games.
  • Different ammunition types for single weapons.
  • Weapon skeleton slaving for stacking turrets upon turrets or making coaxial weapons.
  • Shotgun-type weapons or least cone-type AoE.
  • Damage over time type weapons.
  • Carrying extrenally docked ships through hyperspace
  • Please keep shaders accessible
  • Also allows shaders to know more data about ships.
  • LUA 5.
  • Fuel and ammo consumption, limits and regen.
  • Order queues
  • Parallel researches
  • Hod patching system, allowing to override and update geometry, shaders, textures, whatever.
  • Or just abandon .hod and replace it with something more mod-friedly.
  • Documentation on lua, shader code and other hooks, also on engine functions.

Cataclysm Remastered Starter Pack:
(I mean, people will be trying to make it anyway!)

  • Visible external construction
  • Ship linking
  • Mimics
  • Remote capture mechanics
  • Sentinels and their polygonal shields.
  • Harvesting the debris (mostly energy crystals) by resource controllers (Processors) directly
  • Capture by workers/resource collectors


I think you can already do some of that stuff:

For lights coming from beams check the fx file ‘ion_beam_simple.lua’ : properties 04 and 13 control the light that can emanate from the beam. ( I just switched all of the beams to green or purple for the Taiidan and had to change the light they cast.)

For point defense weapons, set the accuracy to 0 for everything except for ‘munition’ in the weapon file and it should only be able to shoot at missiles.

I haven’t really looked at how it works, but the main cannon for the Dreadnaught can shoot more than one ship at once if they’re lined up.


MOD TEAM: Resurgence
LINK: Steam

BBI is probably going to use unity game engine as they used it in DOK too.

*Map Editor(something like command and conquer generals/tiberium wars have) Maybe we could use unity somehow to make these maps?


*Ammo maybe.

*More attack styles and possibility to switch attack styles in-game.


I’ve got a big long list of things I wanted HWR to do that is still applicable, and I’ll dig it up for updating reposting later, but really my biggest concern right now is infrastructure issues of modding rather than what shape the engine can be bent into. The barrier for entry and the friction on iteration and distribution must be as low as possible for a modding scene to survive the inevitable playerbase tailoff of a modern RTS release.

The single most important thing in my eyes is a robust map and mission editor. When I tried my hand at Freespace 2 modding I was shocked by how quick and easy it is to get a mission into the game and start iterating on the logic. You can start building fun though simple missions there immediately with no programming knowledge at all, and it’s more enjoyable to do so off the bat than I’ve been able to get HW2/R mission making to be after years of trying.

I think that goes a long way to explaining the longevity of Freespace Open, which has kept alive a game that launched the same year as Homeworld 1, with a trickle of new fully featured missions and campaigns coming out to this day.(the open source engine project helped immensely too, but an updated engine with nothing new to play on it has limited appeal) If we had that, I’d even stomach some steps back from the modability of HWR, though obviously I’d prefer to have both.


TEAM: 9CCN Chinese localization team
LINK: https://steamcommunity.com/sharedfiles/filedetails/?id=413642194

  • Better localization mod support, include better Unicode support and allowing us to use any .ttf or .otf fonts we want.
    Current HWRM engine treat .dat file (which uses ANSI) as a higher-priority than .ucs (which uses utf-16), making it a huge headache for players who want to play the game in Chinese if their Windows default codepage is not set to Chinese. And HWRM engine only supports fonts in uncompressed bitmap format, which is a nightmare when we try to get a font that contains tens of thousands of Chinese characters.

  • Allow us to build different language packs into a single mod, even if those languages are not in the Officially support language list, so that we do not need to upload the same mod with different languages as different steam workshop items.

  • It would be nice to be able to interact with map objects by scripting - trying to find the position of an asteroid or salvage container is pretty difficult in HWRM, let alone manipulating it…

  • Background objects casting shadows on each other would be cool.


Mod Teams: 2.3 Players Patch, Battlestar Galactica: Fleet Commander


  • Better collision avoidance for megaliths, and large/small objects in maps. ‘Space terrain’ could be soo frak’en cool if done correctly. Deserts of Kharak’s use of terrain is bliss.
  • A plan for long term patch support. Allocate some resources so we can get a patch a year for 5 years after the initial release. The community has fixed tons of bugs / exploits / large issues in HWR, and it would be fantastic if they could be released in an official patch. More information is here.
  • A robust balance tester for ship vs ship combat, such as whats available for Starcraft 2. I’m thankful I’m one of the few that has access to Gearbox’s internal balance testing window for HWR, but it needs improvement and it should be available to everyone.
  • Map maker/editor
  • Ship shields
  • Modern scripting, dealing with LUA 4.0 and limited function scope is rough.
  • Modder friendly ship models / .HOD files.

Mod Teams: BrickSpace, B5: WWE, BSG: FC


  • Rotating dock paths
  • Rotating collision geometry
  • Rotating weapons hardpoints
  • More control over simultaneous dockpath usage
  • Generic consumables system (ammo, boarding parties, fuel)
  • Externally dock ships and carry through hyperspace
  • Generic unit naming system
  • Ship linking
  • Visible ship construction
  • Veterancy
  • Improved VBO size (higher poly objects)



  • First party tools and plugins that are maintained
  • Scenario editor
  • Ability to balance test ship v ship combat to help mod balancing
  • Greater control over push/pull/hold/drag weapons (newtonian)
  • Avoid encryption of assets
  • Avoid hard coding

Mod team : Player base ^^

Requests - lesser modding specific instead contains more wishes for various game related features:

  • Open modding policy & Scenario/Mission Editor.
    Gearbox seems to be stuck in the past in that aspect, don’t enforce that upon BBI. Get a modding friendly game and receive profits for several years in return. (Think Operation Flashpoint, Arma series, Half-lIfe series, Quake series, Battlezone 2 Combat Commander “It even sparked a recent remaster due to still having an active community even 20 years later”, Star Wars Empire at War, Sins of a Solar Empire, Freespace series. All these titles combined a single thing. They were modding friendly, allowed asset creation and beyond that the possibility for fans to create their own unique set story lines expanding upon the various game universes. Most the named titles had said Editor and it reflected in the longevity of said products.

  • Return of various resource forms. Rocks, Asteroids, nebula Clouds, dust clouds, crystals, possibly even mining asteroids that can get repaired and captured by specific salvage vessels and afterwards destroyed or recaptured by an opposing force.

  • No more ‘roll the dice’ damage system. No more Supreme Commander in Space.

  • optional visible ship construction support for the engine.

  • Return of fuel on & off for mp game game setting - but enforced in any and all SP campaigns.

  • Post release dlc’s: New story campaigns and the introduction of new races both for SP and mp. Continued game support for years to come.
    Please not just merely reskinned factions like it was mostly executed in DOK.

  • Official port project dlc - post release: Implementation of HW1 RM - HW2 RM and Cataclysm/Emergence assets + campaigns into the official HW3 game branch.

  • 64bit exclusive product. No more RAM limitations.

  • An improved AI for Skirmish matches. Hw1 Classic did really good back then. AI used fleet formations, kept speed with the slowest ship, hyperspace flanked you etc.

  • Dynamic Mp map creator for select player sizes

  • Dynamic SP and MP comp stomp feature. I could imagine basic mission scenarios where you must cap, destroy, or hold something for a certain amount of time till you get your hyperspace button and get your next mission. For mp it would be the same just with 2p or 3p coop. These mission objectives should lay in an open accessible file to expand up upon with new level files and objectives to come. Ai spawning should also happen dynamically and on random positions plus normally placed assets if so desired in the mission file.

  • perhaps allowance for 6v6 matches and add by default additional spectator slots unrelated to player slots. A vital feature for these ‘electronic sports’ jockeys also another important step in keeping this game alive post release.

  • Music player for skirmish and mp. Allowing us to select specific and desired official OST tracks + repeat and skip button etc. Ability to implement own mp3 music if so desired in a shared designated music folder.

  • Ability for the AI to learn by saving game stats of previous matches (hw1 did that) ai adjusts to favorite player strategies. For the player detailed battle stats when he built what and lost what and so on. (COH2)

  • Possibly a better system for Subsystem targeting. I found em to be very intrusive and distracting in HW2.

  • Big return of properly working support frigates with style. They were a true asset back in HW1 vanilla and often meant the difference between defeat and victory.


Mod Teams: Kiith Paktu, Bulletmod


  • An alternate scripting implementation utilizing C# or an updated one utilizing Lua 5.3.
  • A cohesive callback system allowing us to attach handlers for various game and ship events that works in all scripting contexts.
  • A generic damage-pool system instead of hard-coded health and shield (EMP) pools that allows us to designate and label multiple pools, set bit-flags that define certain behaviors or effects, specify chain rules for incoming damage and how or when it gets applied to each pool, specify the default pool for incoming damage and repairs, and attach a callback function that gets called on status changes.
  • Allow weapons to directly specify what damage-pool they apply damage to; If a specified damage-pool does not exist on the attack target then the damage should be applied to the designated default pool. Additionally weapons should have some kind of mechanism to breakdown how much of their total damage gets applied to each specified pool.
  • Allow weapons to deal negative damage that heals or repairs the designated target.
  • An overhauled attack script system that allows control over everything from designated target to current flight maneuvers and more.
  • The ability to load scripts for multiplayer maps to allow for scripted events like campaign maps.
  • Scripting support for compute shaders.
  • Scripting support for high-resolution timers and clocks.
  • Scripting support and functions for manipulating all entities in addition to ships.
  • Scripting support for retrieving any and all tunables set or specified in an entity definition; Current system only works for specific numeric tunables and has no facility for string tunables.
  • Scripting support to force-activate abilities on entities regardless of battle or other status.
  • Scripting support for force-firing a weapon either at a target or a point of space regardless of battle status or active abilities.
  • Scripting support to get, set and unset a ship’s deployed status.
  • Scripting support to determine an entity’s cause of death and the entity that caused that death.
  • Scripting support for get/set access to a ship’s internal physics transform; Currently there is no easy access to things such as “facing direction.”
  • Scripting support for defining dock paths, joints, engine burns and other nodes outside of the HOD file.
  • Scripting support to break, override usage costs, and get the paired gate in hyperspace gate links.
  • Scripting support for accessing the UCS files and performing locale translations.
  • A mechanism for determining if the scripting context is about to be destroyed or shutdown.
  • A unified scripting context between the game mode and custom code scripts or a cohesive mechanism for moving data between the two scripting contexts.
  • An improved physics engine that allows for more in-depth definition of flight behaviors; Current system is limited to specifying Maximum velocity, Time required to accelerate or decelerate from full stop to maximum velocity or vice versa, the maximum angular velocity, and an enigmatic “thruster-usage” percentage.
  • An improved audio engine that allows for surround sound, doppler, occlusion and various other effects.
  • An increased game tickrate higher than 20 ticks per second.

I do a lot of C++ development for work but the little bit I have ben able to use C#, i find it syntactically much cleaner than C++ or Java. I also like the fact that with .Net core it is all available for Windows, Linux and Mac.

More than graphics, I want to see a sophisticated Ai : one that uses Nebulas to hide in and ambush enemies or finds effective paths to come at the opponent from different directions .

I like what HWR v2 patch did for adding file configurable hardpoints to a HOD.

I also want to see captureable technologies: If I capture a ship from a different player I have to spend RUs proportionate to 10% of the cost of the captured unit (if it is a different race) to start the reverse engineering process
which grants me ACCESS to the tech tree necessary to build that ship. i then have to research the each of those items myself to get them.

This means if I am Hiigaran I start the game with hgn_tech, but if I capture a Taiidan Carrier I could unlock tai_tech and would be able to research all the things the carrier can build. I don’t have the option to get any Taiidan technology other than what is represented by the captured unit when it was captured so if the it did not yet have the tech to build Frigates, I can’t ever get to them through this technique unless I capture a unit later in the game that represents additional tech.

I would like to see more differentiation between races (I know everyone has their own ideas about what a race should be, but this is presented just for the sake of discussion)

Kushan : the reference point we compare the other races to.

Somtaaw: efficient resourcing. Heavy armor, slow. Good at close combat.

Taiidan: amazing manufacturing efficiency.

Vaygr: super specialized units. Missile based. recklessly fast (fighters flying through an obstacle course in pursuit of an enemy will often crash). but nobody can out run them.

Kadesh: Sensor systems/electronic warfare, better targeting. Long range sniper attacks.

Keeper: ultra high tech but a 2x advantage in performance is offset by a 3x cost.

Raiders: ultra cheap. Mobile. As scavengers they have to make do with what they can find. They don’t much of a tech tree of their own but have to get it through what they can capture from other players. A player capturing another raider players ships get acces to all of that players tech as if it were native. For example, if the captured raider’s tech included research from each of the other races, the capturing player would not have to separately unlock hgn_tech, vgr_tech, som_tech, tai_tech, kad_tech, kpr_tech, etc.

Hiigaran: modular systems. not necessarily the best at any one thing but generally more versatile.

I would like to see hierarchical formations with auto build/replacement of lost units : fighters could be in formation with a corvette which is in formation around a frigate which is guarding a carrier. ships that are destroyed automatically start getting built by the nearest buildcapable ship and, depending on preferences, either travel out to the formation as soon as they are built or the player is notified that they are ready and can decide what to do with them from there.

Please support effectively infinite’s game space by having game maps linked together.

I think this can be done in HWRM… What exactly do you want to do?

Currently you can deploy a ship through SobGroup_SetAsDeployed, but there is no equivalent functionality to undeploy a ship or get its current deploy status. While a fully-scripted workaround is plausible it would be nice to be able to utilize existing facilities.

Likewise there is SobGroup_IsGateDeployed and SobGroup_FormHyperspaceGate which can get and set the status, but does not allow for closing the gate. Unfortunately I do not know of any workarounds for this other than completely re-implementing gates through scripting.

1 Like