Closed GoogleCodeExporter closed 8 years ago
"If +4 larva are generated the event of the current natural larva still
completes and spawns an additional larva beyond the four."
Isn't this normal behavior? Can't there be up to 7 larva per Hatchery (3 from
Hatchery + 4 from Queen)?
There are some other questions about the patch. I don't know a whole lot about
EC, just throwing some questions out there :-). Thanks for the patch.
EcActionBuildBroodLord.java:
In isInvalid(), it looks like you removed the requirements that you need to
build Corruptors, since Brood Lords morph from Corruptors (as opposed to Brood
Lords being built at a Hatchery)?
EcActionBuildBuilding.java:
Why did you make this change? You need one Drone to build a building. It
doesn't matter whether or not the Drone is mining minerals.
EcActionBuildDrone.java:
Why did you remove the isInvalid() method? How is EC supposed to know how many
minerals a Drone costs to build?
General:
* Looks like you removed the supply and mineral requirements from certain
isInvalid() methods. Are these requirements checked somewhere else?
* You removed calls to super.isInvalid() in a lot of the overridden isInvalid()
methods. Any reason for this?
Thanks again for the patch.
Original comment by mike.angstadt
on 16 Nov 2010 at 9:44
I believe 19 larva is the maximum amount a hatchery may accumulate (3 from the
hatch and 16 from 4 larva spawns). The hatch itself stops generating larva
after reaching the 3 larva limit.
Original comment by netpr...@gmail.com
on 16 Nov 2010 at 9:50
In regards to the first point I was referring to when you have 2 larva, then
the +4 spawn, totaling 6, stopping the next one from auto-spawning.
EcActionBuildBroodLord.java:
I don't see where I removed the requirement for the Corrupters, they're still
there in the isPossible function.
I removed the supply cost (because it's dealt with by the parent class) and the
requirement for the hive or evolving hive since it's required to make the
greater spire to begin with.
EcActionBuildBuilding.java:
While it doesn't matter if the drone is mining minerals, the program currently
only removes a drone from minerals. So if you had all drones on gas you'd end
up with -1 drones on minerals.
General (and EcActionBuildDrone.java):
* The cost of a unit is checked in the isPossible function, and thus was a
redundant check.
* Less than half the existing functions called super.isInvalid() in the
overridden isInvalid() methods. super.isInvalid() always returns false. Either
way would be fine I just picked the smallest change for consistency.
Original comment by nafets...@gmail.com
on 16 Nov 2010 at 10:06
"The cost of a unit is checked in the isPossible function, and thus was a
redundant check."
Oh, I see that now. Plus, all of the other EcActionBuildUnit classes either
don't check the mineral/supply cost in the isInvalid() method or don't have an
isInvalid() method at all.
"EcActionBuildBuilding.java:
While it doesn't matter if the drone is mining minerals, the program currently
only removes a drone from minerals. So if you had all drones on gas you'd end
up with -1 drones on minerals."
But it should also be able to remove a Drone from gas, right? Sounds like a
new bug...
Original comment by mike.angstadt
on 16 Nov 2010 at 10:58
It would be a pretty simple swap to change it to take one from either, it just
wasn't doing so currently, so I just fixed the check.
If you wanted it to take a drone from other scenarios there are 5 to consider:
1. Drones Mining Minerals
2. Drones Mining Gas
3. Drones Going on Minerals
4. Drones Going on Gas
5. Drone Scouting (which you probably don't want to use)
The first two are simple to code and check, the 3rd and the 4th are a little
more involved requiring an additional check on each transfer.
Original comment by nafets...@gmail.com
on 16 Nov 2010 at 11:50
Yeah, I think that Drones from 1-4 should be available for making a building.
I don't know how it should make that decision...maybe just always take a
mineral-mining Drone unless there aren't any. I think you're right, scouting
Drones should be left alone.
Original comment by mike.angstadt
on 17 Nov 2010 at 12:08
After looking at the code I realized that to complete 3 and 4 would require a
lot more checks to be added to the program (for the push / pull 3 setting, to
cancel the future drone arrivals at the gas if removed during transfer,
multiple buildings using transferring drones etc.) when, in the end, the build
would get optimized away anyways for either excessive drone transfer or lack of
drones. Thus adding the support would likely slowing things down more and
accomplish little.
Thoughts?
Original comment by nafets...@gmail.com
on 17 Nov 2010 at 1:15
Well, a real player playing a real game could do any of the 1-5, so I guess it
boils down to how close we can simulate a real game.
Original comment by mike.angstadt
on 17 Nov 2010 at 2:06
I'd also argue that option 3 and 4 would probably be optimized away since
taking a drone while transferring results in a second or two that it wasn't
mining which is pointless from the optimization standpoint.
The option of taking a drone off the extractor should only be used if you don't
have 'push/pull three only' or 'don't pull workers from gas' selected since
otherwise the program will have no way of returning the extractor to full
capacity.
Anything I'm missing?
Original comment by nafets...@gmail.com
on 19 Nov 2010 at 9:52
"The option of taking a drone off the extractor should only be used if you
don't have 'push/pull three only' or 'don't pull workers from gas' selected
since otherwise the program will have no way of returning the extractor to full
capacity."
That sounds reasonable.
I say go ahead and commit the patch. Email Lomilar for commit privileges:
fritley@gmail.com
Original comment by mike.angstadt
on 3 Dec 2010 at 10:55
Fritley fixed the larva in r167
The other changes have been made during the refactor.
Original comment by nafets...@gmail.com
on 5 Dec 2010 at 5:08
Original issue reported on code.google.com by
nafets...@gmail.com
on 12 Nov 2010 at 6:17Attachments: