Flying Machines with TNT Block Shape

[schrum2]

Make a batch file that evolves flying machines (just copy a GECCO batch file), but uses the explosive/TNT block set. The point of this is to verify that explosives don't find ways to cheat the change in center of mass fitness function. I believe that this has been extensively tested by this point, but we want to make sure.

It would also be interesting to see if this just ignores TNT to evolve flying machines like usual, or it ends up creating missiles (though there won't be targets to test with).

Since you'll be basin this off of a GECCO batch file, the shapes will just be 3x3x3 and have real-valued genotypes, but we could also try evolving with the direct encoding.

When it comes to explosives, we probably don't need to scale up to 5x5x5 yet. Let's get success at the 3x3x3 level first.

[TjRaffert]

When it doesn't detect movement I'm guessing it ends evaluation early and the already lit TNT doesn't get cleared and blows up the next shape.

[schrum2]

We have a problem where TNT from one evaluation gets blown into the air, then lands on top of a new shape that spawns in the space, ready to be evaluated. There are two possible fixes:

1. Add a longer delay between sequential evaluations in the same spot
2. Move the evaluation corner for each new evaluation

Since these will be parameterized, we should implement both solutions and then decide later what works best.

To add a delay: In MinecraftShapeTask at the end of the method

public static <T> Score<T> evaluateOneShape(Genotype<T> genome, MinecraftCoordinates corner, ArrayList<MinecraftFitnessFunction> fitnessFunctions)

add some code that checks a new command line parameter "minecraftDelayAfterEvaluation". If the value of this parameter is greater than 0, then do Thread.sleep for that many milliseconds.

To move the corners: In MinecraftLonerShapeTask, in the oneEval method, the code takes and puts from/to coordinateQueue. We can have a new command line parameter: "minecraftXMovementBetweenEvals" that has a default value of 0. For every corner that is taken out of the cornerQueue, instead of just putting the same corner back in, add "minecraftXMovementBetweenEvals" to the x coordinate and put that result back in. We probably also need to have an upper limit "minecraftMaxXShift" that limits how far we can shift a shape over. When determining the new x coordinate, we can mod (%) by the value of "minecraftMaxXShift", so that the shapes will cycle through a limited range of values.

[TjRaffert]

[STICKY_PISTON at (293,84,-257) oriented EAST, QUARTZ_BLOCK at (293,84,-256) oriented WEST, QUARTZ_BLOCK at (293,85,-257) oriented SOUTH, QUARTZ_BLOCK at (293,85,-256) oriented UP, OBSERVER at (293,85,-255) oriented SOUTH, TNT at (293,86,-256) oriented DOWN, OBSERVER at (293,86,-255) oriented SOUTH, PISTON at (294,84,-257) oriented SOUTH, OBSERVER at (294,85,-256) oriented NORTH, TNT at (294,85,-255) oriented NORTH, STICKY_PISTON at (294,86,-256) oriented UP, REDSTONE_BLOCK at (295,84,-256) oriented DOWN, STICKY_PISTON at (295,86,-257) oriented WEST, REDSTONE_BLOCK at (295,86,-256) oriented SOUTH, PISTON at (295,86,-255) oriented UP]

This shape got put in flying machines during a batch run. In the postSpawnEvaluateChangeCenterOfMass Shape did not move far enough to count as a flying machine Shape mostly gone. Partially blown up? XX CALC FINAL SCORE RETURN result final score fitness: 0.2849829429593488 ChangeCenterOfMassFitness: 0.2849829429593488 Currently watching: ID100_.txt

[TjRaffert]

https://github.com/schrum2/MM-NEAT/assets/111467145/b70724b2-3e50-48d2-9427-5bd8f73604be

[schrum2]

Part of the problem here seems to have been that the spaceBetweenMinecraftShapes setting was set unusually low in the batch files and parameter configurations. Once set appropriately (at least 10), some of the errors went away. We're still not sure whether a shape that oscillates and then blows up would get the appropriate fitness, but are looking out for it.

[schrum2]

If currently running tests have no erroneous flying machines by tomorrow, then we can close this issue

[TjRaffert]

The two tests I ran overnight are almost complete and have a high fitness of 5. This probably isn't good.

[TjRaffert]

I am running a Third test with the same settings and a GECCO test as a sanity check.

[schrum2]

@TjRaffert I believe that your run from over the weekend confirms that this works. There were no false positives, right? If so, close the issue.

[TjRaffert]

I had it running on another machine and have several false positives.

[TjRaffert]

If the shape pushes a block away that survives the explosion, it can still get max fitness Here is the file ID58472_.txt

[schrum2]

The fitness function has been adjusted to account for this case, but the manner in which is has changed warrants re-running of all previous checks to verify that it works. So, do the following again:

• Run the original GECCO batch file for Observer Piston Orientation to make sure it can make flying machines
• Run the batch file that is the same as this GECCO batch file, but includes TNT, to verify that we get no false positives

[schrum2]

Everything seems to work now.