Removing build queue shuffling abuse and exploits

Many experienced players are aware of this exploit/loophole/appropriate-noun, but it does not yet have the attention it deserves. @scole if I could annoy you one last time regarding an issue of balancing/bug-fixing importance, it would be this.

Build queue shuffling lets players stagger the construction of different ships (need 2 at least to avoid merging queues for same ships) to accumulate significant construction progress and allow several ships to complete and launch within seconds of each other.

Why is this an issue? Because players can effectively use this mechanic to turn carriers/shipyards into “clown-cars” full of frigates/capital ships and jump them on top of an enemy. You can essentially queue an infinite amount of ships with 99% construction progress for incredible force projection from carriers/shipyards and avoid the hyperspacing cost associated with jumping each individual ship - you are still limited by unit cap however.

Another potential use of this tactic is to almost artificially inflate the unit cap of very limited ships by keeping several replacements ready e.g. having 3 of 3 BCs out in a default-cap game and another 3 queued at 95% construction ready to replace them upon their destruction (yes I realise these are extreme examples however they are not improbable in team games).

The only balancing “upside” to build queue shuffling for infinite construction progress is that it can be done with every race but this is not sufficient justification to keep it in the game. While it is cool from a metagaming perspective, it bypasses intended balancing mechanics and doesn’t give players time to react when they are on the receiving end. If a player wants to amass a flanking strikeforce of frigates, it should be done the hard way - hyperspace behind their lines, out of sensor sight and begin amassing the fleet one ship at a time.

Showing the steps to reproduce it with HW1 carriers:

Showing the final effect with a HW1 carrier:

3 gravity wells hypespacing in simultaneously while 8-10 frigates pop out one by one.

Using it in conjunction with another bug to create carrier “piñatas”:

I finish the production of 6 heavy missile frigates and 6 infiltrator frigates from a Vaygr carrier within seconds and then I save time by scuttling said carrier and letting them eject all at once.


The video above also highlights another bug (which I will refer to as the ejection bug). Ships that are caught in the ethereal state between, “launched” and actually spawning in the game world from its respective production ship, are not affected by the ship’s destruction. They are instantly ejected with full HP.

Only ships that can permanently dock, and appear as such in the Launch manager (which include strikecraft and certain utility ships), will be destroyed upon destruction of its parent ship. However if a player tells 10 squadrons of fighters to launch just seconds before the destruction of the parent ship, they will all be ejected and survive regardless if only one actually physically flew out before the moment of destruction. This is a cheap way to avoid the loss of stored assets. Frigates and capital ships cannot dock so as soon as they are built, they are also caught in this “ethereal state” where they are neither launched nor docked and will survive without consequence.


Solutions:

First of all, the ejection bug needs to be fixed. Ships that are docked or are in the ethereal state between docked and physically launched need to be destroyed no matter what upon destruction of the launcher.

As for the build queue shuffle mechanic, there are a couple of potential solutions to minimise its abuse without impinging on its original intended purpose of allowing players to put something on hold and build something else that the situation calls for:

  • (a): Implement a cap on the total number of ships in the build queue that can simultaneously have any level of construction progress accumulated.
  • (b): Implement a cap on total construction progress accumulated (using % as the metric because it scales equally with every ship).

Example for option (a):

Let’s say the cap is 3 ships so only 3 ships at any given time from the same carrier/MS/shipyard can have any construction progress greater than 0%.
I have a carrier and I decide to build queue shuffle 4 ships. I get 3 of those ships to +95% construction each like so:

Upon beginning construction of the 4th ship (the torpedo frigate), the construction progress of the ship at the very end of the build queue (flak frigate) is instantly reset to 0% and the RUs for whatever progress I had on it is refunded:

HW1 race might need +1 extra ship to this cap.

Example for option (b):

Let’s say the cap is 250% so I can only have 250% of total construction progress accumulated from the same carrier/MS/shipyard across various ships in the build queue.
I have a shipyard and I decide to build queue shuffle 5 ships. I get all 5 of those ships to 50% construction each (totaling 250%):

Upon reaching the cap, every extra % on the ship currently being built is subtracted from the accumulated progress that the ship at the very end of the build queue has. So as the current ship approaches 100% construction (the defense field frigate), the ship at the end of the queue (flak frigate) approaches 0% construction (RUs are refunded accordingly):


Note that with both of these suggestions, you can still queue as many ships as you want, you just can’t accumulate as much construction progress simultaneously across many ships to use for frigate swarms, carrier piñatas etc.

EDIT: Fixed videos, working properly now.

7 Likes

As an FYI regarding the ejection thing, there is code that explicitly handles that so Relic either thought that was working as intended or it is a fix for a crash.

3 Likes

I forgot to mention the special case when a carrier/shipyard/MS is captured, all ships in the ethereal state will still continue to launch from its parent even if it has changed sides. I hope the code can handle these exceptions too - either the ships should be destroyed or they also change allegiances along with its parent.

1 Like

Actually, this could be an easy fix. Just set the maximum amount of individual production queues(paused or not) to a certain number (5-6 sounds reasonable). This wouldn’t solve the issue in it’s entirety, but it could limit the clown car effect.

Why not just limit it to production of one ship of each type? (And 2 of each type for HW1) It’d be so much simpler and easier to understand.

If you are building a Torp, then move Ion to the top, it won’t build the Ion until after the Torp finishes or you hit cancel by the Torp. (Or the torp resets to 0%)
If you move corv production up to the top, the Torp would pause instead and continue after the corv(s) finish.

While these examples might work from say, a balance point of view, they’re super complicated to explain how the mechanics work to a new player. They’re hard to document. They aren’t very intuitive.

But option a makes the most sense of those.

That seems intended to me. It’s already been launched moments before being captured.
If anything there is just a bit of a problem where things tend to appear quite a delay after they’ve finished in the production queue.

1 Like

BTW, did you know the AI, at least in classic, does this stacking. I remember many times chasing a carrier and it suddenly spits out a bunch of frigates one right after another. It was either cheating and making them out of nothing or stacking and waiting to pop them out like puppies.

1 Like

I’d rather not have to go back to the build menu every time a scout finishes.

This happened because the carrier is faster than the frigates so as they finish they are cradled inside the carrier until it stops, thus spitting out several ships at once. Some people used that as a tactic in HW1 on large maps.

1 Like

The CC Trojan horse. :smile:

How theoretical… This is an issue only when you are doing a LEGO game with something like rush protection. Any skilled game will definitely require you to actually use the ships, especially BC not to get your team totally owned while you keep everything safe and hidden…

The most I would stack could be 2 to 3 frigates on MS/CC as a hyper cap, but since tech sharing is no longer possible and MS isn’t capable of being captured this is now a much less likely option.
The only stacking currently I do is building a few DD stacked if I ever want to jump. This has a downside as if you get your capital facility killed, all of them are gone back to RU, so it has its own risk as well.

I have not heard a single complaint that this is an issue and will only remove yet another strategy for no good reason.

Also, I’m not sure how having docked fighters/corvettes being released at once on blown up cap ship can be a real problem. You are basically already losing.

1 Like

I don’t see why you’d have to… One scout ends, the next one starts.

@scole Please do NOT remove this advanced mechanic from the game. Players playing this game theoretically on the forums have no idea how useless the “unlimited” queue concept is in the actual game. Queue stacking is limited to very few risky strategies.

First of all, defender can build the same amount of ships and defend against a hyper jump with no issues. Second, the attacker has to use additional RU for jump and refineries at home. This leaves his RU ops wide open to attack, kill those refineries and he’s out of RU for a long time. Hyper-cap is a risky strat and has been countered many times.

Third, stacking BCs sounds good, but it also can be a good way to lose a game if you get caught out of position with already built BCs. And finally, there’s absolutely NOTHING wrong with using build micro to advance your own game play. I understand that some rookie players see it as “unfair” because it takes a little bit of skill to use, but let’s not dumb down the game, please?

1 Like

How are you supposed to react to what the other player is doing if scouting doesn’t do anything?

2 Likes

This is a little confusing but it seems like it would work fine to me, there is some potential for lost RU here because the RU is a whole number (afaik, engine wise it may not be), however minute that might be.

Here’s one idea for build queue shuffling, it’s done by introducing a minimum undock timer for each ship class.
Every time you build a frigate, other frigates cannot undock until at least half it’s build time has expired.
This means you don’t lose any flexibility with the build systems, but are unable to overwhelm opponents after using said strategy. Without further amendments to the idea however, you’d still be able to produce say a Destroyer + Frigate + Fighter combination.

Dealing with the hyperspace exploit is more complicated (if the former is not dealt with) and probably would come down to charging the player for 75% complete vessels onboard. I’m not entirely sure it merits it however, so long as production vessels are unable to simply churn out units they clearly don’t have space for.

Scuttling a vessel in order to deploy units, although non-sensible, requires a fairly large cost investment. If the developer wants to touch on it, I would recommend damaging the vessels to 50%-75% if they pop out in this fashion. It’s as simple as checking if their parent is living when initially undocking. Having all the units explode 100% I feel is bit of a cruel solution, even if it is the correct one, as the player losing their production vessel is USUALLY the one losing.

Are you seriously concerned about that?

  • Do you have problem checking modules?
  • Are you screwed with 1 sensor distortion probe?
  • Is HW1 without any modules a cheat to you?

There are so many counter arguments without valid reasoning, people need to know HW2 before trying to nerf the game as a whole.

If you actually play, stacking unneccesary amount will screw you if you get suddenly attacked and takes away too much of your focus on queue management.

LOL, how do you play HW1 when you can’t see what the other player is building/researching?

But hey, at least HW2 gives you a hint: if you see frig mods and he’s not building collectors - he’s stacking. If you see early refineries and ms/cc are together - jump incoming. Once you have faced this strat - you’ll be able to spot it no problems. And it can be countered with… level 0 tech (bombers).

Well, that’s where I think HW2 did things better except for this issue.

If someone has a frigate module AND corvette module on a Hiig carrier, it can be producing docked Corvettes.

This same things extends to HW1. You could see their frigates except for this queue canceling.
IIRC, in HW1 you could only pause production of one unit of each type. IE, like “option a”. You could not create and extra queue for another ship of the same type.
So if I’m not mistaken, you could could many different ships to all come out at once, but not 2 HCs both out simultaneously.

Then go dual frig facilities and pwn both moves at once.

So unless you can see 100% what they’re up to, your game is screwed? This is just hilarious.
I bet you can easily be tricked into fake hyper torp as soon as you see early frig mod, when in fact I’m not even building one but going bigger.
Play, learn and then analyze if that’s even remotely a problem in the game.

There are many ways to anticipate what other team is up to, besides like I said stacking too many only causes you trouble than worth it.

Once again, I’m not sure how much experience you have on HW2 but if this is about “HW2 doesn’t work the way I like from HW1 (and don’t care how HW2 works)” then there is something wrong in the principle of your argument.

You’re making a huge jump from near 0% to 100%.

You’re saying that near 0% information is okay because you shouldn’t be able to see 100%. Who said anything about 100%?