search

mannyzhou5 / evolutionchamber

Automatically exported from code.google.com/p/evolutionchamber
0 stars 0 forks source link

Larva Production #147

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Flipping through the code I noticed two things about larva:
1. An additional base will not spawn larva
2. If +4 larva are generated the event of the current natural larva still 
completes and spawns an additional larva beyond the four.

The attached patch attempts to correct these issues. It assumes, 
optimistically, that you always remove a larva from the hatchery with the full 
capacity for regrowth, but also that the larva generated from the Queen is 
spread amongst all hatcheries. (The later might be a little pessimistic.)

(As a side the patch also removes a few redundant checks and adds checks to 
ensure pushing / pulling three workers or taking a worker off minerals to make 
a building don't put you in the negative for 'workers on mineral' counts.)

Original issue reported on code.google.com by nafets...@gmail.com on 12 Nov 2010 at 6:17

Attachments:

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
"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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
"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

GoogleCodeExporter commented 9 years ago 
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