search

schrum2 / MM-NEAT

Modular Multiobjective (Hyper) Neuro-Evolution of Augmenting Topologies + MAP-Elites: Java code for evolving intelligent agents in Ms. Pac-Man, Tetris, and more, as well as code for Procedural Content Generation in Mario, Zelda, Minecraft, and more!
http://people.southwestern.edu/~schrum2/re/mm-neat.php
Other
50 stars 20 forks source link

Erroneous shape creation at initial shape when evolving #867

Closed JoannaBlatt closed 1 year ago

JoannaBlatt commented 1 year ago

When evolving a second shape appears above the first shape created. This shape is greater y coordinate than the initial shape should be. It lasts for the whole time the shape is supposed to last. The proper placed shape appears briefly before both shapes are cleared. The shapes appear different. Spawns above all shapes set at y coordinate 5.

Maybe change the number of threads to check if it's duplicating one of the other thread shapes? Visually does not appear the same as the second shape. Maybe a way to output all the blocks in both areas to compare? Maybe try to isolate both shapes to compare blocks and compare with the archive?

Moves with initial shape when initial starting shape position is changed. Y is set to 30. Otherwise coordinates are the same as initial corner. Currently corner is set to -403, 30, -203.

schrum2 commented 1 year ago

See if the extra problem shape appears for different numbers of threads. There is a parameter called "threads". Try setting it to 1 and testing, then increment until the problem occurs again.

JoannaBlatt commented 1 year ago

The starting Y position was too low so the shape would appear and then be wiped and respawned at a higher y coordinate. The minimum to keep this from having is startY: 25, but for buffer room the startY parameter in parameters.java was set to 30.

schrum2 commented 1 year ago

Verified that the old batch files in Experiments-2023-GECCO-MinecraftFlyingMachines run fine with this change

schrum2 commented 1 year ago

Although making the startY higher fixes this, I may have found the root of the problem. I'm about to do a commit that tags the possibly offending code. First, we need to verify whether or not this code is actually causing the problem. Make the startY small enough to cause this error to happen again, and then see if commenting out this offending code makes the error go away (though it might cause some other problem).

In general, it would be nice if the code automatically looked at various parameters at the start of the simulation, and determined then how to adjust startY on behalf of the user, rather than requiring the user to get it right. If the startY value is adjusted, we can print out a message indicating that it was changed and why.

schrum2 commented 1 year ago

The place to look to fix this now is the fitnessScore method of TimedEvaluationMinecraftFitnessFunction

schrum2 commented 1 year ago

Fixed by last commit