How to fix the support frigates and repair corvettes

Just a suggestion, Instead of making them latch onto ships like the HW2 resource collectors do, just make them “attack” an allied ship but instead of reducing health, increase it instead. A similar thing could be pulled off on the resource collectors too to make them spin around the asteroids. What do you guys think?

I read a post from one of the devs (I don’t want to say who in case I misremember) that sounded like they explored a LOT of avenues to try and make the harvester beam work (and by extension the frig healing beam since it’s the same thing) because the harvesters circling the roid and of course massed healing frigs behind dessies/HCs are very much signature HW1 effect but they were unable to do it.

If you want to use a weapon to fire healing shells or beams (lets say the weapon allows the damage to go into the negative, it depends on how the variable is saved. Damage is not generally expected to into the negative so…) then you’d have to pick a weapon to modify. The closest that comes to mind in HW2 is the ion beams. Could do something nice with pulsars maybe?. From a modding perspective I am not sure how much you can mod the animation or if a new animation can be added (at that point I see no reason why Relic couldn’t have done this as it does sound rather simple so there might be a reason). You’d have to modify it’s flight pattern to circle around a target (kinda like corvettes in HW1 that is absent so there might be another issue to get that flight path in). Maybe the tools will allow that kind of editing or you’d have to script in a new ship if you can’t edit existing ships on that level.

Like I said, it sounds simple so if GBX really tried to get this in but couldn’t then it can’t be that simple, however modders are particularly creative so a solution of some kind will be found.

1 Like

Thing is , Gearbox HAS the source code , there’s not really much that prevents them from adding more code and exceptions for Hw1 ships to make them behave differently. Putting that responsibility on modders and expecting them to come up with a solution isn’t really a fair since they don’t have the same kind of access to the source code like GBX does.


Well that pretty much suggest GBX is lying if I understand you correctly.

This particularly stands out to me because of how adamant and kinda sad the dev was that they couldn’t do it. I’ll see if I can find the quote at some point.

I’m not saying they’re lying , that’s why I was starting the discussion in order to help the devs as best as I can. After all the development team needs the support of the community to make the game as best as they can. More on topic, I don’t think it’s impossible to do, it just takes more changes in different areas to pull off. For example , the flight patterns are one thing that needs the most attention IMO since they pretty much determine the effectiveness of the ships.

Uow, that is actually a really really good idea!!! They could shoot greens pulsar beams and heal, that would have the same effect of the old beam, well done sir!!!

The implication doesn’t have to be that they’re lying, it could be that the task was too great.
I would imagine with the source code that nothing from HW1 mechanics is impossible to implement in HW2 but would require substantial rewrites of the HW2 engine to make possible - time and effort which GBX probably thought wasn’t justified just to introduce a single feature.

I would like to know what the technical hurdle was that prevented them from implementing the heal beam assuming it can be conveyed in layman’s terms.

Awesome we solved the problem in 10 minutes and I have never modded a game before in my life! (I’ve done some gfx though, does that count?)

Joking aside what I’m saying is that in this particular instance from what I do know or have experienced as being possible in the HW2 engine (played PDS mod, they made some good use of flight models) the problem is most definitely not the flight pattern or even the beam itself. Now they were able to add a new animation to the harvesters and repair ships so it’s not the animation that’s the issue either.

So what is left might be the way the healing/harvesting ship ‘tethers’ itself to it’s target and then applies the effect. Come to think of it the way formations and some tactics work in HW1 also almost feels like the ships are tethered to each other. With strike groups and squadrons instead of formations in HW2 that entire tethering mechanic might just plain not be present in HW2 engine and would explain why even modders have been having issues with this. Heck this might even be tied to the fact that the HW1 engine is physics based and the HW2 one isn’t.

Maybe adding proper working support frigs/repair corvettes would defectively require an engine rewrite.

Cases like this is when modders creativity, free time and persistence comes to a) emulate the intended behavior or b) creatively re-purpose something completely unrelated to perform the same task. Modders are really good at that and have the free time, something developers never have enough of.

Anyways that’s just some wild guestulating on my part.

Continuing the discussion from How to fix the support frigates and repair corvettes:

But they could fix this shortcoming like relic did for HW1… releasing the source code to the community. Win-win for both sides: GBX has not to care anymore about complaints & bug fixes & providing support and the community could built up the perfect version together themselves.

Yupp, with source code everything is possible, must have been therefore economical considerations which prevented HW1 mechanics & a HW1 engine based remake. Which is understandble as GBX took with the license fee alone a considerable economical risk. Let’s hope that they either made enough money to invest more love (and ressources) into the HW1 remake or that they allow at least the community themself to fix it with source code access.

Continuing the discussion from How to fix the support frigates and repair corvettes:

A noble idea but I imagine its like herding cats to get the members of any community led project all pulling in the same direction. At the very least some form of official Hub/oversight would be needed just to keep things running.

Right, would be really a nice thing!

For homeworld a hub exists already: or the Tanis shiipyard over at relic-forum

And other projects proved that community driven source code projects can work out quite successfully e.g. the Gothic 3 community patch where the modders worked together for years.

Yes a unified community project would be a nice thing … :slight_smile:

A kind of hub already exists, or the tanis shipyard over at the relic forum.

And, there are examples of community driven successful source code hand-overs e.g. Gothic 3 where the community & modders fixed the game in year long work, or Jagged Alliance 2 where the community fixed & ported it or arx fatalis…

Yes indeed a combined community project would be a nice thing. :slight_smile:

Centralized hub could be the GBX forum or on of the other dedicated HW sites (homesource or relic’s tanis shipyard)

There are several examples of successfull community driven source code handovers available, Gothic 3, Jagged Alliance 2, Arx Fatalis, unreal etc

(For some reason this post disappears magically again and again… )

WEll, anyway it still is the best idea to fix those things so far.

Welp, Should they release the source then I’ll definitely be taking a crack at it- Support frigates and corvettes were some of my favourites to use in the original, It kind of bugged me in HW2 that the repair option required docking.

When you think about it, it makes more sense to dock unless you’re doing some form of repair drone, The beam itself is a bit fantastical. Even so, it was more fun.

That said, It really breaks down in to how the values are handled by the engine, In something like Unity (Which is being used for Homeworld: Shipbreakers by the way) it wouldn’t be too difficult in Javascript or C#/++, You have Point A and Point B, set up a raycast and if it’s within a specific distance then you add value to the health of the target.

I’m not as familiar with oribiting and the pathfinding mechanics though, so I presume those play a much larger factor, or the HW2 Engine has some limitations in how it handles that mechanic.

Given the chance though, I’ll likely invest a stupid number of hours in trying to get it to work provided Gearbox doesn’t do it first :wink: #gamedevlife

It does look really awesome though, The displacement on the beam geometry is awesome. Seems like two cylinders with an animated texture and vertex shader; I love the look. :smiley:

Great! You can already start by taking a look how the HW1 repair mechanic was implemented in the source code:

There are already AI behaviors in the game which more than qualify for an appropriate “tether” mechanic. Get a group of Ion Cannon frigates and target a capital ship, move that capital ship away from the frigates and some of those frigates will keep pace with the target at the same X, Y and Z offsets with lateral movement. Some of them fall behind in a chase position and some of them still retain a level of lateral movement to keep their bow pointed forward at a target even if you had them positioned perpendicular to said target.

Thanks for the link! I’ll follow it on my Github Acc. :smile:

I like this code, For the corvette they’re using some vector math so that it only repairs on the top hemisphere of the ship, which is nice. There’s some in there which does some extra calculations to ensure that it doesn’t get stuck, which is awesome.

I particularly like the distance stuff- This part seems like it could potentially conflict in the new engine if the way they handled the coordinate system changed in the new engine-

void startRepairEffect(Ship *ship,SpaceObjRotImpTarg *target,vector *trajectory,real32 distance)
    ShipStaticInfo *shipstatic = (ShipStaticInfo *)ship->staticinfo;
    RepairNozzleStatic *repnozzlestatic = shipstatic->repairNozzleStatic;
    //Use ship->rceffect, since ship isn't a resource collector,
    //the pointer isn't being used
    etglod *etgLOD = etgSpecialPurposeEffectTable[EGT_REPAIR_BEAM];

    etgeffectstatic *stat;
    sdword LOD;
    udword intLength;
    udword intWidth;
    matrix coordsys;
    real32 targetRadius = target->staticinfo->staticheader.staticCollInfo.collspheresize;
    vector repairBeamPosition;



    intLength = TreatAsUdword(distance);
    intWidth = TreatAsUdword(targetRadius);


Since it’s all class based it should be transferable, If you break it down, you’re just having a point in space move and do an action. Since it’s all relative motion however, it’s somewhat of a pain in the butt.

I’ve done similar things in Unity in C#, though not this complex that ran into similar problems- We were trying to script a fully dynamic camera that followed the player and could be adjusted on the fly in a modular way but still have trigger points and other things. It was a pain to get working, but definitely possible.

I’d presume the same is true here- At its core, it’s all just code, The biggest difference being that for me, it’s not my fulltime job and there’s no time limit. Since there’s no pay, I can spend 300+ hours researching shaders, code, texturing techniques, C++, etc to figure it out. This is why Modding comes up with some really cool stuff because it’s all passion driven.

In a studio, you’re confined by deadlines, budgets, and target goals. If you have a set release date, there are some things that you need to get working for functionality, and things that you’d like to have done. Generally those are reviewed in a post-mortem after development is done. In this case, I would say that it wasn’t a lie when they say they couldn’t get it working, it’s very possible they couldn’t due to other reasons- but the biggest factor is time. If it can’t be accomplished within a plausible timeframe then it doesn’t get done. It’s sad, but it is a business and that’s just how things work.

I’d be more than willing to dive in and try to add the functionality (I won’t say fix it, as it’s not broken, just different) - but from a plausibility standpoint it won’t be possible unless they release the source and even if they did, the game itself would need to be rebuilt (i.e. the exe) for it to work. I’m not sure how extensive the modding capability will be for HW:R yet, so time will tell. I’d chant ‘let me look!’ but legality likely prevents me from doing it for free even if I want to lol.

Here’s to hoping! :smiley:


Great! One hub for the Homeworld source code developers & modders was and is the homesource forum:

Maybe all interested hackers & modders can gather there … looking forward to the results with the assets and releases of GBX :slight_smile:

That’s pretty awesome, I’ll have to check it out. I’ve been out of the loop for years, but I’ve gained a lot of code/art knowledge lol. It’d be fun to contribute if I can. :smile:

I am kind of curious as to why noone’s tried porting it to unreal since all the source is in C and Unreal can go to C++, Since it has physics, while it’d be complicated, I don’t think it’d be impossible xD