Inactive [ADMN/MISC] WorldGenerationControl v2.6 - Generate areas of your world at will [1.0.1-R1 / 1.1Dev]

WorldGenerationControl 2.6
Formerly ForceGenChunks
Which is a confusing ass name so I changed it

WorldGenerationControl on BukkitDev

This is a very simple plugin to allow you to pre-generate a region of your world. It does not affect already generated regions. As of 2.0, it can also repair lighting of existing regions.

Features

• Generate arbitrary regions by coordinates
• Queue multiple generations
• Various speed settings to control lag vs generation time
• Works on a live server
• Doesn't lock up the server (unless you use the /allAtOnce option)
• Low ram usage, works on servers with 1gig of memory.
• Generates trees & ore, not just land
• Can generate valid lighting
• Can force regenerate lighting on existing chunks, to fix light issues.

Bugs/Quirks

• Generating land and light take lots of CPU - nothing the plugin can do to prevent that! If you don't want to lag a live server, use the /slow or /veryslow modes.
• Designed for servers with at least 1gig of memory allocated to them (-Xmx1024M). Servers with lower memory limits may encounter heap exceptions. If you have less than 1gig of memory, try using /slow or /veryslow modes.

Commands

The /genregion (or /generateregion) command can be entered by any server op, the server console, or anyone with the appropriate permission (see below).

The syntax is:

/genregion WorldName StartX StartZ EndX EndZ​

For circles (/generatecircularregion or /gencircle):

/gencircle Radius [WorldName xCenter zCenter]​

​

The world and center coordinates for the circle command are [optional] if you are a player (not the console). It will default to your current/world position.

All coordinates are in normal, in-game coordinates - but will be adjusted to the nearest chunk boundary (inclusive).

Options

All commands can have options applied to them like so:

/gencircle 1600 MyWorld 0 0 /fast /lighting​

Options are not case sensitive. The available options are:

• /allAtOnce - Don't pause between steps, generate everything requested all at once. This will make the server basically unusable until the generation completes, but get the job done fastest. Very useful in conjunction with /onlyWhenEmpty
• /veryFast, /fast, /slow, /verySlow - Adjust speed. Has no effect if /allAtOnce specified. Normally the plugin will cause mild lag while generating usually doing around 700ms of work per three seconds (depending on the server CPU). Raising the speed with fast or veryfast will cause more lag but speed up the generation, slow or veryslow will reduce lag while increasing generation times. Veryfast will cause a lot of lag. Veryslow will cause almost no lag, but will take something like 10x longer.
• /forceKeepUp - Force the server to 'keep up' with garbage collection and chunk saving. In particular, 1.9 Has a new async chunk saver, which appears to be rate limited, meaning it may not keep up with fast generations. This option forces the chunks to be saved immediately, rather than on a separate thread.
  You should use this option if you notice the plugin spending a lot of time "waiting for the server to catch up" and don't mind the minor increase in CPU usage caused by forcing it to keep up. /allAtOnce mode will always use this option.
• /lighting:none - Skip generating light data for loaded chunks. See Notes on Lighting below.
• /lighting:force - Reset and regenerate lighting for all chunks we pass over, even if they already have lighting data. Useful for fixing areas with corrupt lighting.
• /verbose - Print detailed timing info while generating. Doubles the amount of spam the plugin prints!
• /quitAfter - Shutdown the server once this (and any other pending generations) are complete. See the Using in a Script section below.
• /onlyWhenEmpty - Only do generating when the server is empty. The plugin will pause generation and wait until players leave, allowing you to generate lots of land without worrying at all about the extra CPU. You can use this in conjunction with /allAtOnce to have the server use 100% when it is empty towards generating land, without causing any lag when players are online.
• /destroyAndRegenerateArea - As the name says, this will delete and destroy all land in the area given, generating new land instead. I cannot stress enough how this will delete your world (or the specified area of it at least), so please understand what you're doing and make backups!

Permissions

Permissions are optional. Server ops and the server console can always use generation commands. However, if you have permissions installed, the following permissions are used:

• worldgenerationcontrol.generate - Allows user to queue generations. Implicitly grants worldgenerationcontrol.statusupdates.
• worldgenerationcontrol.statusupdates - Allows user to see generation progress messages. These can be quite spammy, explicitly removing this permission will cause only the server console to see these messages.

Examples

/genregion OurBeautifulWorld -50 -50 50 50​

Would generate from -50,-50 to 50,50 in game coordinates. Simple!

/genregion "Bob and Sam's \"Awesome\" World" -50 -50 50 50​

​

The same command for world: Bob and Sam's "Awesome" World. Quotes can be placed around world names with spaces, world names with actual quotes in them can be escaped with backlashes.

/gencircle 1000 /fast /verbose /lighting​

​

Would generate a 1000 block radius circle around the issuing player, using the /fast speed setting, with verbose output, with lighting!

/gencircle 1000 MyWorld 100 100 /veryslow​

​

Would generate a 1000 block radius centered in MyWorld at 100x, 100z, using the veryslow speed setting so as not to cause lag.

/gencircle 10000 MyWorld 100 100 /allAtOnce /onlyWhenEmpty​

Would generate a HEUG circle centered at MyWorld 100,100 at max possible speed, but pause the generation when players join. Useful if you want your server to use 100% on generating when it would otherwise be idle.

Notes on Lighting

By default, minecraft only generates lighting info for a chunk when it is first approached by a player. This is fine, but if you want to generate an external map with something like Minecraft Overviewer, it means the areas players haven't visited will only have 'fast' lighting, with pitch black shadows.
To fix this, by default, WorldGenerationControl forces new chunks to have lighting info, as if a player were nearby. This shouldn't cause any problems, but takes about 8% more CPU-time. You can skip this step with /lighting:none -- the chunks will still be lit when a player wanders by, so this is only an issue for external tools as mentioned above.
There is also /lighting:force, which will force-generate lighting for all chunks it passes over (even those already generated and with proper lighting), which is useful for making minecraft recalculate the lighting in areas with glitched shadows.

Using in a Script

The /quitAfter option lets this plugin be used as part of a script. For example, some users like to generate maps for a lot of random seeds to share with the community or post on /r/minecraft for delicious karma. Because bukkit/java freaks out when EOF is encountered in input, the proper way to do this would be something like:

Code:

echo "gencircle 1000 TestWorld 0 0 /allatonce /quitafter" | cat - /dev/full | java -jar craftbukkit-0.0.1-SNAPSHOT.jar --nojline

​

Download
https://github.com/downloads/Nephyrin/WorldGenerationControl/WorldGenerationControl_v2.6.jar

Source
https://github.com/Nephyrin/WorldGenerationControl

ChangeLog

• 2.6
  • Updated to work with 1.0.1 / 1.1 builds.
• 2.5
  • /forceKeepUp now keeps up on garbage collection as well
  • Renamed /forceSave to /forceKeepUp to reflect that it also keeps up on garbage collection.
  • When the server is floating at >80% memory for too long, the plugin will try invoking a GC. This fixes the issue where the default Java GC options would have it float at 80% memory forever as long as nothing forced it to catch up.
  • Cleaned up /verbose output a little.
  • Check if we have <200Megs free in addition to <20% free, prevents out of memory errors on 512Meg ram servers (which this plugin doesn't technically support)

• 2.4
  • Add /forceSave workaround for 1.9's AsyncChunkLoader silliness.
  • /allAtOnce now implies /forceSave
  • Make the memory limit a little more conservative to ensure we don't hit GC overhead errors on low memory servers
  • Once the memory limit has been hit, wait for ram to decrease below the limit by at least 10% before resuming
  • Tweak the NextTickList bug workaround - instead of flushing the list, just ensure it stays below a threshold. Should fix the minor lag spikes from the fix.
  • Minor optimizations
• 2.3 - Death to Memory Issues edition
  • Includes a fix for CraftBukkit's poor NextTickList handling, allowing high generation speeds on low memory servers
  • Invokes the GC directly when running close to memory limits to prevent GC Overhead errors
  • Takes a break if memory usage gets unacceptably high to let the server catch up
• 2.2
  • Lighting now talks directly to CraftBukkit and is now approximately 115 times faster. Yep.
  • Because lighting has gone from taking up 92% of processing time to a trivial amount, the plugin no longer splits lighting/generating/saving into separate steps.
  • Because lighting is now very fast, /lighting is now the default. It can still be disabled with /lighting:none
  • /lighting:extreme is now named /lighting:force, and only eats a little bit more CPU.
  • Added /destroyAndRegenerateArea - which regenerates all chunks in the region. Beware!
  • Removed /lightExisting, lighting is now only done as-needed either way, and /lighting:force can be used to try and fix corrupt light areas.
  • Fixed /gencircle being centered incorrectly when called by a player without coordinates
  • Improved accuracy of some fuzzy math logic to ensure only requested areas are generated
  • Added /onlyWhenEmpty - this causes the plugin to only do its work when the server is empty, pausing and resuming as needed when players join/leave.
  • Minor speed/overhead improvements

• 2.1
  • Fixed issue with /allAtOnce being too aggressive on lighting, causing memory issues on low-memory servers.
  • allAtOnce mode now returns into the server briefly between ticks, allowing other commands (such as /cancelgen) to be run.
• 2.0
  • Name changed to WorldGenerationControl from ForceGenChunks
  • Large rewrite
  • Supports Minecraft 1.8's lighting methods
  • Added options: lighting, speed, verbose, quitafter
  • Added permissions support
  • Normal speed is much, much less laggy. Speed options provide control over lag during generation.
  • No longer trusts server to cleanup chunks, manages process through lighting step and cleans up chunks directly. maxLoadedChunks removed as a result, even on high speed settings the plugin will never load more than 1024 chunks into memory.
  • Cleaned up and improved status messages.
  • Use block coordinates instead of chunk coordinates
  • Support queueing multiple generations
  • Better in-plugin API for other plugins to interact with this one.
  • Other things I likely forgot
• 1.4
  • Added progress % to generating status messages.
• 1.3
  • Added support for quotes and spaces in worldnames via quotes and escape sequences.
    • To generate for map: Bob's "Wonderful" Funland
    • /forcegen "Bob's \"Wonderful\" Funland" -10 -10 10 10
  • Fixed the "Invalid world name" error message giving the wrong world name for /forcegencircle commands.
  • Separated generation and cleanup phases - plugin now prints a message when generation is complete, and a second message later when cleanup is complete.
  • New generations can be started even if cleanup isn't done, the remaining cleanup will just be merged with the new task's cleanup.
  • Removed warnings about players being in the world, with above changes there is no harm in them being there.
  • Added some colors to plugin messages. Pretty.
  • Plugin messages now show who did what.
  • Tested with recommended builds 1000 and 1060.
• 1.2
  • Added /forcegencircle
  • Players who use the command now see the progress, not just the 'generation started' message.
  • A few minor text tweaks.
• 1.1
  • Wait for chunks to unload, instead of assuming our unload requests succeed. Fixes a 'leak' of loaded chunks in large generations, chunks that never unload until a reboot.
  • Add a optional maxLoadedChunks argument to /forcegen, setting this higher reduces the time spent waiting for old chunks to unload, but causes more chunks to reside in ram, increasing memory usage.
  • Added /cancelforcegen, to cancel generation in progress.
• 1.0
  • Release

 

How Works on a live server? i don't understand

 

Maps are infinitely large in the x and z direction. Whenever a player moves into a region that hasn't been explored by anyone yet, the map will generate new area of that section, and so on. The rendering caused from exploring like this can cause lag, especially with multiple people exploring multiple areas at the same time. With this plugin, you can render designated areas with one command, which can potentially reduce future lag, fix lighting, and create certain sections of the map without having to explore them (useful when used with border plugins to stop the map from being infinitely large and map plugins like dynmap). Hope that helps!

 

I understand Thanks a lot
when is possible will use

 

I don't know if this will be helpful for anyone else working with 1.7 worlds. I was having trouble with version 1.4 and CraftBukkit 1060 not generating land. It would go through the motions, but even after doing a dynmap fullrender the land would never show up. I even tried teleporting to what should have been a newly generated area only to find myself in the blue. I'm pretty sure I was experiencing the same problem Spruu was having.
So I downloaded the last dev build of CraftBukkit for 1.7, which is build 1092 and stepped up with each version of the plug-in. To my surprise, it loaded version 2.5. Next I was going to do some small tests unattached to existing land. Well do to a type-o on my part, I just successfully generated a swatch of land in unexplored area, across the main land and past it. It came out perfect and left the existing land unaffected. Everything matches up really nice.

The command I used was "genregion OurCraftV3 -2440 480 2800 860".

Here is the link to CraftBukkit 1092 (http://ci.bukkit.org/job/dev-CraftBukkit/1092/). I still need to do a really large area, but this is progress. Thank you Nephyrin for making this plugin, my users will be happy to get their 1.7 world back. I wish I would have know about your plugin when we made the jump to 1.8.

Update: genregion OurCraftV3 -4160 -4160 4160 4160 worked without issue.

 

Glad you're having success with 1092 and WGC 2.5. If you're not having the memory leak, that would simplify things a bit. For what it's worth, 1.4 on Bukkit 1060 works fine for me, as long as I generate it in segments. I've worked out that I can do a 250x250 chunk area (16km^2) just before it runs into problems. So I've been okay doing [-250,-250,0,0] [0,-250,250,0], etc. Then again, I do run it with 4GB allocated. I don't think it actually uses all that, but it's worth noting (I forget how high it got before crashing).

Warning, very large images:

Show Spoiler Hide Spoiler

I did a 64km^2 generation and subsequent map render of a seed in 1.7 terrain and one of the pre-release terrain gens if anyone is interested. Seed: 3.14159265
1.7
1.9.?

Show Spoiler Hide Spoiler

 

thank you, great plugin! now i just have to leave the server gening the world overnight to make a 20,000 x 20,000 block world...

 

Hi
I really apreciate your mod, and thanks a lot for that

But i have one question about performance, and my following explanation let me think it would be possible to generate faster ; let me explain :

I generate a 4000x4000 region like this :
genregion world -2000 -2000 2000 2000 /allatonce

The console says that 63001 regions (chunks) have been queued : seems correct to me, since sqrt(63001) = 251, *16 = 4016 blocks wide, which is what i asked.

But it also tells me that 196 passes must be done, each one loading 625 chunks
So 196*625=122500 chunks to load, which is almost double of what i want ..

Am i correct to say there is a lot of chunk overloading, or did i misinterpret the debug output ?

Also, when looking into the code, i see this :

Code:

if (this.speed == GenerationSpeed.VERYFAST) regionsize = 32;
else if (this.speed == GenerationSpeed.FAST) regionsize = 24;
else if (this.speed == GenerationSpeed.NORMAL) regionsize = 12;
else if (this.speed == GenerationSpeed.SLOW) regionsize = 8;
else if (this.speed == GenerationSpeed.VERYSLOW) regionsize = 6;
else regionsize = 20;

The VERYFAST algorithm seems to load larger region size (32) than the ALLATONCE (20), which is odd to me. Is it correct, or is there a tiny error in the code ?

Thanks for your attention

 

@Sushen -
The reason more chunks are loaded than requested is because of the way chunk populators and lighting works - you cannot light or populate a chunk unless all its adjacent chunks are loaded, meaning we need to load 'padding' around each region to ensure we don't miss single columns of chunks for lighting/populating. (This is controlled here)

This causes more chunks to be loaded than necessary per pass, but since these overlap-chunks were already generated on the previous pass, the overhead is simply re-loading them, not regenerating them. To solve this, the plugin would need to move along progressively, loading/unloading single columns in a snake-like pattern, which would also mean we could fine-tune chunks generated per pass more accurately. However, the total generation speed benefit probably wouldn't be very significant (but i'd certainly accept any patches)

As for the all at once thing - all at once only pauses for a few ticks to let the server process its queues and such, otherwise it never really 'stops'. Its region size should probably be the same as very fast, but since it loading them as fast as it can anyway, it shouldn't affect overall speed much at all.

 

@Nephyrin
Thank you for your quick answer
I understand the need to overlap queued regions, and at fisrt look it seems that a fair amount of modifications is needed to adapt your algorithm to keep these border chunks loaded..(overlaping chunks shouldn't be unloaded, and be memory moved to the queued regions that need'em)
As for the speed benefit, i think it should be 10% signifiant as the real speed bottleneck is the disk access (the generation itself is done very quickly compared to save or load - 10 times faster)

For the moment, i dont think i'll do a patch because i started a brand new project of generating terrain with MCP rather than bukkit (a pity those API aren't unified :\), my goal being to do a standalone jar that builds a fast biome map (i hope to gen a biome map of a 4000x4000 terrain in less than a minute, instead of 20 minutes for a full terrain gen) : i need it to choose the correct seed for a real map generation, and i'm fed up of waiting until i get a sexy terrain ^^

For the last point, you're right - the speed benefit in putting 32 sized regions with allatonce is fairly useless

Edit :

Cool, job done in 17seconds ^^

By the way, i tried it with the 1564 Bukkit build and it works fine

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Hi, Is it possible to make this only regenerate lightning only at existing chunks and not generate new ones ? There is bug in MC that is preventing chungs to make correct lighthining when they are aproached and this would help fixing it.
Th.

 

You said you got the whole generation done in 17 seconds with a 4000 x 4000 area. What type of system are you running and how did you get it to render so fast?

It has taken me 6m20s to render a 1000-radius map with lighting. The command I used was...

Code:

/gencircle 1000 world 0 0 /allAtOnce /veryFast /lighting

I don't understand why it is going so slow. The server has 2.5 GB allotted to it for memory.

 

I'm not generating the map itself in 17 seconds - that would be pretty crazy ^^
I'm just generating an image with biome colors for a given seed in 17 seconds
(this generation does not need any map, it just uses the vanilla terrain generator classes)
The result looks like this :

 

How did you do this? I am trying to come up with a good seed for my new SMP server and want to make sure tundras and at least one mushroom biome exists. Are you using a different plugin/program?

 

I did my own program, but it's not packaged, so I don't distribute it ..

 

I'm having trouble with WGC and the newest version of Bukkit, gridlines are appearing in all biome generation items... Snow, ice, trees, brush, etc:





Has Nephyrin been around?

Someone else opened a ticket on the BukkitDev page, I added my info to it.

Thanks!

 

I haven't been playing minecraft recently, but I should have some time this week to look into issues with the new build. The 'grid' problem is probably due to chunks now requiring a two-chunk radius around them for populators to run -- if anyone is feeling adventerous find the 'int overlap = 2' line and change it to 4 and recompile. This will hurt generation speed though, I'll probably need to implement a progressive generator instead of a grid based one :-/

 

I like this plugin I wonder how easy it would be to have it babysit other generators, Im not really familiar with java.

 

Thanks, I'll try making that change! I could really use this plugin again, getting ready for my server to go live and want to pre-generate my land to save processing time in production. I've been getting by with WorldBorder's generation command during testing and setup, but unfortunately it can't light its generated chunks, resulting in nasty shadows in Dynmap.

EDIT: Your fix for the NextTickList leak was added to CraftBukkit, correct? Is the workaround in the code still required?

 

@Darkhand81 - The nextticklist issue (it's not *technically* a leak, more of a catch-up problem) still exists. The pull request was never responded to by the bukkit team: https://github.com/Bukkit/CraftBukkit/pull/501/

The fix in the plugin should still work.
(Edit: Actually it'll still work once the obfuscated variable names are updated, though it may be broken as I'm sure they've changed recently)

I'll see if I can get this working with the new release build this weekend. No promises though!

 

Hmmph you're right, it's not in there. If it makes you feel better I just added the change to my local version, the fix will be running on my server as soon as it comes back up.

Thanks very much! I recompiled with overlap set to 4 and it seems to work at default speed, but strangely I tried /fast and had the same issue again.

 

Messed my server now look at this, how do I delete certain chunks? I have to delete the messed up part. http://imageshack.us/f/687/20120113200327.png/

 

Mike Primm to the rescue! Build 1735 incorporated the fix.

 

I just pushed v2.6, which fixes lighting/obfuscation issues with the newest builds

I wasn't able to reproduce any significant slowdowns on the newest generations - there seems to be some confusion from @Sushen's comment that he generated 4000x400 in 17seconds. But, to quote him:

Most of the CPU time this plugin spends is simply in minecraft's generator. It does add some overhead due to its grid-based method, but even if that was optimized it could only get *maybe* 30% faster than its current speed.

bloods-stone:
This will work with any generator you have installed, not just the default one. No other tweaks are needed. Just load up the desired generator and go.

 

Thanks so much! I'm finding this plugin to be invaluable for initial world setup. It just doesn't make sense to generate chunks in production anymore.

 

"It does not affect already generated regions." This plugin has ruined my Minecraft world built on by ~25 people. I used one of the example commands "/gencircle 1000 /verbose /lighting" near the edge of my generated world. It deleted everything that was in a 1000 block radius and replaced it with grid-like chunk errors. I'm now going to spend the next couple of hours fixing things in MCEdit. Why has the plugin done this?

 

I have mangled a significant portion of our map due to the 'int overlap = 2' issue with the more recent versions of Bukkit (I guess that is what is causing this?).

I will take a look at the code, let me know if you're already close to a fix! Thanks!

Read Nephyrin's post on Jan 11. Something happened with the way chunk boundaries is handled. Hopefully there is a fix soon!

(Normally, the only way to affect existing regions is to use the /destroyAndRegenerateArea switch, btw)

I think I see where the issue is in the src, but I cannot even compile the .java doc unedited... I am sure I am probably just doing something wrong (I'm using jdk 1.7.0_02) with javac.exe, but it comes up with 100 errors.

Anyone have any ideas?

Oh! I forgot that I am mildly retarded. Let me try this again!

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Excuse me for not reading the whole thread as I am on my iPhone and in a rush, but does it generate the world in chunks? Or by blocks. For example, if I want to generate "1000" would that be 1000 chunks or blocks?

Back at my computer and had the time to read and understand the concept, no more info needed at the time!

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

I found the entry in the code, once I can figure out how to make a separate build with eclipse I will try it out and let you guys know if it fixes the bad chunks/grid pattern issue.

 

I just tried this with

Code:

genregion TestMap -1000 -1000 1000 1000 /allatonce /lighting:force /destroyAndRegenerateArea

and it still generates those "grid errors":


And even worse, now I'm getting this error lots and lots while dynmap renders that map
(of course, I can't guarantee it's due to the overlap=4 change, but previously I never got it):

Code:

2012-02-09 10:17:28 [INFO] Attempted to place a tile entity (net.minecraft.server.TileEntityChest@1d7720a) at -532,26,-851 (WATER) where there was no entity tile!
2012-02-09 10:17:28 [INFO] Chunk coordinates: -544,-864
2012-02-09 10:17:28 [SEVERE] java.lang.Exception
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.Chunk.a(Chunk.java:607)
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.Chunk.a(Chunk.java:586)
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.ChunkLoader.a(ChunkLoader.java:234)
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.ChunkRegionLoader.a(ChunkRegionLoader.java:53)
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.ChunkProviderServer.loadChunk(ChunkProviderServer.java:135)
2012-02-09 10:17:28 [SEVERE]    at org.bukkit.craftbukkit.CraftWorld.loadChunk(CraftWorld.java:256)
2012-02-09 10:17:28 [SEVERE]    at org.dynmap.bukkit.NewMapChunkCache.loadChunks(NewMapChunkCache.java:590)
2012-02-09 10:17:28 [SEVERE]    at org.dynmap.MapManager$2.call(MapManager.java:1189)
2012-02-09 10:17:28 [SEVERE]    at org.dynmap.MapManager$2.call(MapManager.java:1184)
2012-02-09 10:17:28 [SEVERE]    at org.bukkit.craftbukkit.scheduler.CraftFuture.run(CraftFuture.java:34)
2012-02-09 10:17:28 [SEVERE]    at org.bukkit.craftbukkit.scheduler.CraftScheduler.mainThreadHeartbeat(CraftScheduler.java:137)
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.MinecraftServer.w(MinecraftServer.java:503)
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:435)
2012-02-09 10:17:28 [SEVERE]    at net.minecraft.server.ThreadServerApplication.run(SourceFile:465)

 

Were you getting the mangled chunks (the grid pattern) before you changed the code? In other words, is the error being thrown the only change?

Because my map looks exactly like the pattern in your screenshot, and I was unable to get the code to compile with the overlap set to 4 instead of 2. (first time ever messing with Eclipse/Github/etc)

Anyone know where the author went? Just busy?

EDIT by Moderator: merged posts, please use the edit button instead of double posting.