search

mannyzhou5 / evolutionchamber

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

yabot functions #110

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It would be better to implement the Yabot family functions in the sub-classes.  
This would allow for more flexibility.

Original issue reported on code.google.com by Bob0the0...@gmail.com on 3 Nov 2010 at 2:16

GoogleCodeExporter commented 9 years ago 
Here's an example of a fix.
### Eclipse Workspace Patch 1.0
#P EvolutionChamber
Index: src/java/com/fray/evo/action/build/EcActionBuildSpawningPool.java
===================================================================
--- src/java/com/fray/evo/action/build/EcActionBuildSpawningPool.java   (revision 
85)
+++ src/java/com/fray/evo/action/build/EcActionBuildSpawningPool.java   (working 
copy)
@@ -33,6 +33,21 @@
        });
    }

+   public String yabotGetTag() 
+   {
+       return " ";
+   }
+   
+   public String yabotGetType()
+   {
+       return "0";
+   }
+   
+   public String yabotGetItem()
+   {
+       return "41";
+   }
+   
    @Override
    public boolean isInvalid(EcBuildOrder s)
    {
Index: src/java/com/fray/evo/action/EcAction.java
===================================================================
--- src/java/com/fray/evo/action/EcAction.java  (revision 85)
+++ src/java/com/fray/evo/action/EcAction.java  (working copy)
@@ -60,7 +52,6 @@
        .replace("InfestationPit", " ")
        .replace("NydusNetwork", " ")
        .replace("RoachWarren", " ")
-       .replace("SpawningPool", " ")
        .replace("SpineCrawler", " ")
        .replace("Spire", " ")
        .replace("SporeCrawler", " ")
@@ -134,7 +125,6 @@
        .replace("InfestationPit", "0")
        .replace("NydusNetwork", "0")
        .replace("RoachWarren", "0")
-       .replace("SpawningPool", "0")
        .replace("SpineCrawler", "0")
        .replace("Spire", "0")
        .replace("SporeCrawler", "0")
@@ -208,7 +198,6 @@
        .replace("InfestationPit", "38")
        .replace("NydusNetwork", "39")
        .replace("RoachWarren", "40")
-       .replace("SpawningPool", "41")
        .replace("SpineCrawler", "42")
        .replace("Spire", "43")
        .replace("SporeCrawler", "44")

Original comment by Bob0the0...@gmail.com on 3 Nov 2010 at 3:47

GoogleCodeExporter commented 9 years ago 
It was done in the more monolithic way because the YABOT author is making 
changes to the map to allow for some problems EC output causes. Once that is 
ready then I was planning on remapping the string generation similar to you've 
described.

It's also been discussed to write a new data structure that would make this 
suggestion obsolete, but I don't know how close that is to completion.

Original comment by AudioL...@gmail.com on 5 Nov 2010 at 12:35

GoogleCodeExporter commented 9 years ago

Original comment by Frit...@gmail.com on 6 Nov 2010 at 1:41

GoogleCodeExporter commented 9 years ago 
Was this patch committed?  Can we close it?

Original comment by mike.angstadt on 10 Nov 2010 at 6:07

GoogleCodeExporter commented 9 years ago 
I don't see the changes in the source code. So no, they are not committed.

Original comment by netpr...@gmail.com on 16 Nov 2010 at 7:00

GoogleCodeExporter commented 9 years ago 
The reason I asked was because when I applied the patch, it looked like no 
changes were made, but I actually applied the patch incorrectly.

Original comment by mike.angstadt on 16 Nov 2010 at 8:38

GoogleCodeExporter commented 9 years ago 
I think that what Bob0the0mighty is suggesting is that each EcActionBuild 
sub-class should contain methods which are used to generate the appropriate 
YABOT data for that action, instead of being centralized in the 
EcAction.yabotGetTag(), EcAction.yabotGetType(), and EcAction.yabotGetItem() 
methods.  I think this makes sense.  Especially because it doesn't rely on 
using the actual names of the Java classes to determine the appropriate YABOT 
codes.

So, there could be three abstract methods(yabotGetTag(), yabotGetType(), and 
yabotGetItem()) in EcActionBuild, which require all the sub-classes to provide 
the appropriate YABOT data.  The three methods in EcAction could be removed.

Original comment by mike.angstadt on 16 Nov 2010 at 10:01

GoogleCodeExporter commented 9 years ago 
Fixed in r130.  Improved the YABOT encoder so the type and item numbers of each 
unit/building/upgrade are contained within the encoder class, instead of within 
the EcAction class.

Original comment by mike.angstadt on 22 Nov 2010 at 11:06