Loading...
  OR  Zero-K Name:    Password:   

Fun Thing With Eggs

9 posts, 149 views
Post comment
Filter:    Player:  
sort
Hi Guys,

I don't like the egg.

Thus, this once, I am going to publish all the ways to break the egg. So hopefully it goes away.

Method 1: using hatchForTeam abuse in order to duplicate coms through teamshare

  • Two players share a team (commshare). Player A is on Team 1, Player B is Team 2.
  • Team 1 loses their commander. Team 2's commander is still alive.
  • FindTeamNeedingCommander correctly says "Team 1 needs one" → hatchForTeam = 1.
  • MorphCompleted's final check counts only units with commander_owner_team == 1. If Team 2's alive commander is tagged as owner_team=2 (different ID), it is invisible to the check.
  • The egg hatches → Team 1 gets a new commander even though the shared group already has one.

Method 2: start_comm_count abuse (not really useful)

start_comm_count is only set for teams that got a starting commander via start_unit_setup.lua. However, its default fallback is 1, not 0. This means any team that never had a starting commander is implicitly assumed to deserve one. If a player starts without a commander (e.g., a special game mode), they can hatch one from an egg without any check ever proving they had a commander that died.

Method 3: GG.MorphCompleted nil setstate abuse (making your com invisible to the counter)

This code runs for all commander morphs (not just from eggs). When a regular commander upgrades (e.g., dynstrike0 → dynstrike1), hatchForTeam is nil, so the function returns true immediately — but it has already overwritten commander_owner_team on the new commander unit. If ownerTeam resolves to nil (because neither param was set), the new commander has commander_owner_team = nil, making it invisible to CountCommandersByTeam. A commander with no owner-team entry effectively bypasses the egg limit check for all future hatches on the same team.

Method 4: Domi/Reef steel counter freeze (make it so your opponent can never egg again!)

  • Team A's commander is dead. Egg starts morphing. egg_morph_owner_team = A. This reserves a slot and blocks other eggs.
  • An ally (or an enemy using Dominatrix) captures the egg mid-morph.
unit_morph.lua:UnitTaken correctly updates morphData.teamID = newTeamID.
  • But egg_morph_owner_team is never cleared on the captured egg.
MorphCompleted still uses hatchForTeam = A for its final check, while the commander spawns for the new owner — potentially giving the new team a "free" commander on Team A's quota, while also leaving Team A's slot permanently reserved (blocking further hatches for A).

Method 5: GameFrame related breaking (accomplishable with widgets)

If two eggs reach progress >= 1.0 in the same game frame, FinishMorph is called for each sequentially within pairs(morphUnits). The second egg's MorphCompleted does see the first commander already (it has comm_level set via UnitCreated), so it should be blocked. However, Lua's pairs() traversal order over a table is non-deterministic, and if the iteration order means both eggs are processed before any UnitCreated callback fires (unusual but engine-dependent), both could slip through. This is probably possible with widgets somewhat consistently.

+1 / -3
Can't make an omelet without...
+1 / -0

8 hours ago
Replays or none of these work.
+1 / -1
8 hours ago
I will be out of town tonight - will be back about 24 hours from now and will post them then.

Trust me, they are very real.
+0 / -2
You put a bunch of lua files into AI, and it pooped this out. Replays or it can't happen.

To further clarify, I mean replays like this https://zero-k.info/Battles/Detail/998336

- 55 seconds long
- about as few units as possible to demonstrate the bug
+1 / -1
7 hours ago
These all seem like bugs, so they're all much more likely to result in bugfixes rather than the feature being removed. If you really want eggs removed, you should post abusable strats involving the feature working as intended.
+5 / -0
Bots B2435190 1 on Hooked 1.1 for Method 4 not working:

When a egg of P1 got captured by P2, it stops morphing, even if P2 dont have comm or egg morphing.

The captured egg seems can morph while P2 have comm, but I clicked it doesnt works.

I forgot to morph P1's egg. but you can control the replay? (I can.)
+1 / -0


110 minutes ago
You're absolutely right
It's not just a bug — it's a serious problem with the way the feature is built
Honestly? it's the developers' fault
+3 / -0
quote:
I don't like the egg.

quote:
So hopefully it goes away.


It's been what, 24 hours since the change went live? Have you played a game where the outcome was drastically affected by the existence of eggs? I played several games yesterday and did not notice anything out of the ordinary regarding eggs. You just decided you don't like it and now want it gone? Pinging @everyone in the FIGHTORDER! discord encouraging everyone to use these 'exploits' so eggs get removed is a terrible look, if you ask me.

Anyway, FIrankFFC and i tried "Method 1" and i don't even understand what the alleged exploit even is. Two players in a squad have two commanders, and if one dies they can make an egg and morph 1 new commander. If equalcomms is enabled, the player(s) with additional comms can use eggs to restore commanders up to the amount they had at game start.
We tested it in Bots B2435241 2 on IncultaV2. No unexpected behavior came up.

Method 2 works, but i don't see how this is exploitable in any way.

Method 3 doesn't make any sense. Explain the exact steps required to make my commander 'invisible' to the morph counter, because upgrading your commander changes nothing as far as i can tell.

Method 4: if an egg is captured mid morph the morph is stopped. The player who had their egg stolen can morph another one after, if they would like. The only bug here is if the person who captured the egg hatches it, and then loses the domi. Now their commander slot is occupied and they cannot make another commander, even though 'their' commander is permanently controlled by the enemy now. This is very different from what you wrote and i don't see how this is exploitable unless both sides are coordinating.

Method 5: i don't make widgets so i cannot speak for that side of it. But you must have several slots to even begin morphing more than one commander, and if you use equalcomms to morph multiple at the same time, it all works as expected.

I'm with USrankAdminSteel_Blue on this one. You ran this through an LLM and shat the results into a forum post, with 0 testing. Link replays where these exploits are produced, or none of this is real.
+1 / -0