Some blocks don't clear

[schrum2]

Occasionally some blocks will persist around a flying machine that are leftover from a previous flying machine. This seems to be most common with Observers, but definitely happens with other blocks as well. This happens even though the Java code clears the area before putting a new machine in it, and also checks to see that the area is clear before placing a new machine.

I ran an experiment and waited for these blocks to appear, specifically an observer block, and I verified that EvoCraft was incapable of:

• Replacing the Observer with AIR (type 5). Trying to replace with AIR did nothing.
• Reading the presence of the Observer. When the EvoCraft readCube function is applied, it thinks that the block contains AIR.

Although the API is incapable of sensing the object, it does act at a physical obstacle to other shapes in the game, which is a problem. However, the EvoCraft API was able to replace the Observer with a different non-AIR block type, and then that block was quickly cleared out by the evolution code that routinely clears the space before each new shape is evaluated.

So, a possible fix is the following: Whenever we want to clear a space (which really means filling it with AIR), we instead fill it with something like Wood first, before then issuing a second command to fill it with AIR.

First, track down every call to either of the two fillCube methods in the MinecraftClient that fill the space with AIR. Replace those calls with calls to a new method instead called clearCube in the client. Then define this clearCube method to work by calling fillCube twice: once with some type of wood (or almost any block really), and then again with AIR.

[schrum2]

While doing this, you can also feel free to move any public static methods associated with clearing space from other classes (like ChangeCenterOfMassFitness) into this class (don't make a separate class for clearing yet, but it might be good to cluster all the clearing methods in the same part of the MinecraftClient). Just make sure to update all references to those methods ... Eclipse should point out all the syntax errors created by attempting to move the methods, so fix all those references, and make sure the whole project successfully Maven installs afterwards.

[JoannaBlatt]

minecraftLonerShapeTask contains a clearBlocksForShape method -clearAndSpawnShape -minecraftLonerShapeTask-new Thread-run -minecraftLonerShapeTask-oneEval -minecraftShapeTask-evaluateOneShape

changeCenterOfMass has clearAreaAroundCorner method -clearAreaAroundSpecialCorner -getCenterOfMassBeforeAndAfter

-TimedEvaluationMinecraftFitnessFunction-fitnessScore

-minecraftBlockEvaluateExperiment-run -minecraftBlockRenderExperiment -run -shiftBlocks

[schrum2]

Creating wood before air seems to overwhelm the system so that the server dies. It is not clear if the problem is specifically the use of the LOG block, or if there is simply a problem with issuing two big fillCube commands back to back. For now, the LOG commands are commented out, but I think we could add a pause using Thread.sleep(2) (also needs a try/catch ... see how this is done in ChangeCenterOfMassFitness)

[JoannaBlatt]

changed to glass and seems to have stopped crashing the server. Still puts a stain on it seems like.

[JoannaBlatt]

Maven install works, but seems to take twice the time. Created a clear with glass boolean parameter to test with.

[schrum2]

Clearing with Glass seems to work, but results in massive slowdown. This is annoying since we probably don't need to clear everything with Glass all of the time. We need to investigate a way to limit how often the Glass is used instead of just using AIR, but this is a problem for later. There are more pressing issues for the moment.

[JoannaBlatt]

created minecraftClearWithGlass parameter and set default to false. Glass clear doubles the time of maven install.

[JoannaBlatt]

on a small scale did not have a significant impact on time. Run 1 without glass was done in 3.5182 minutes. Run 2 with glass stalled when starting at evaluate in parallel. Try number 2 of run 2 worked and was done in 3.8718999999999997 minutes. Run 3 without glass was done in 3.50765 minutes. Run 4 with glass was done in 3.8577833333333333 minutes.

noticed that in either case the shape would appear briefly, disappear, and then reappear.

started to test with the big flying machine bat file

created a main in minecraftClient to test clear with glass against clear without glass.

[schrum2]

I'm currently re-running one of the GECCO batch files for ME.PO using the new glass clearing setting. If this finishes satisfactorily, then we can close this issue. However, we may still turn this setting off sometimes since the extra work seems to impose a non-trivial slowdown.

[schrum2]

The old GECCO batch file worked and produced flying machines even with the glass option on. This more or less works, so I'll close the issue.