130 files in a folder saves\map\region\ when creating new map
https://raw.githubusercontent.com/SvEgiiVEteR/ModPackSV/master/fml-client.log
Map created not for very long.
But if I set mods mages, industry. the difference in speed between the
RTG-1.7.10-0.5.0.jar and RTG-1.7.10-0.4.0.jar very noticeable
a problem with lots of files *.mca, seems out of the Biomes O'Plenty

with Biome Tweaker-1.7.10-2.0.180.jar only 6 files
CC problem or RTG?
but with BT can not find biomes BOP

me was told that a lot of files * .mca is not good.
and Slows down the generation of the presence of other mods if they are many.
and if I use BT can not find the biomes BOP(using generation of RTG and no one biome not found ..), but the files * .mca only 6
if I use the CC, it creates a lot of files *.mca and biomes BOP found

the problem itself that if I set a different mods, magic, Industrialna and more, creation of maps slow and even slower to gregtech.
with version 04 it was not so

sorry for bad english))

What exactly is the problem?

Your configs matter too. Did you change the CC ocean parameters configs?

not for the test I always remove all configs and RTG and CC
BT will not be used since there is need to register ID biomes. they changed me + many mods biomes.

but I tried to BT + BOP + RTG with your config. only 4 file.
I inst CC. and 30 files are created. if I put more mods, the Number files increases to 130+

I noticed that the new RTG + CC create a lot of files. after I decided to try 05 rc2 version on their full assembly with mods. and a new map created for a long time.
with a minimum amount of mods it is easy to overlook.

I only get about 8 files with that seed. Unless you're getting a start many thousands of blocks from 0,0 it's not CC creating those files, it's some other mod.

I installed the current mods
BiomesOPlenty-1.7.10-2.1.0.1394-universal.jar
ClimateControl-0.4.beta39.jar
RTG-1.7.10-0.5.0.jar
SmartMoving-1.7.10-15.6.jar
SmartRender-1.7.10-2.1.jar
InGameInfoXML-1.7.10-2.8.1.82-universal.jar
LIB_LunatriusCore-1.7.10-1.1.2.21-universal.jar
EnderCore-1.7.10-0.2.0.31_beta.jar
Waila-1.5.10_1.7.10.jar
NEIIntegration-MC1.7.10-1.1.1.jar
NotEnoughItems-1.7.10-1.0.5.120-universal.jar
PlayerAPI-1.7.10-1.4.jar
RenderPlayerAPI-1.7.10-1.4.jar
RenderPlayerAPIEnhancer-1.7.10-1.4.jar
38 files

or 3 mods
BiomesOPlenty-1.7.10-2.1.0.1394-universal.jar
ClimateControl-0.4.beta39.jar
RTG-1.7.10-0.5.0.jar

log
http://paste.ubuntu.com/14698999/
seed -1160707664362226860
37 files

and test seed -8399536139921155204
9 files

CC will create a lot of .mca files looking for a start location if it has a hard time finding a place to start. That happens if the land incidences are low and if the available lands are bigger. I have a report in that GregTech is messing up the CC generation and increasing the water % but I haven't looked at that yet.

thanks for the explanation.
I always have a lot of files created
seed: -1160707664362226860
the more mods - the more files

Initial Test setup:

BiomesOPlenty-1.7.10-2.1.0.1394-universal.jar
ClimateControl-0.4.beta39.jar
RTG-1.7.10-0.5.0.jar
configs: new, default
seed: -1160707664362226860

Result: about 40 region files are created before spawning in the world.

[18:17:13] [Server thread/INFO]: srs_bsns[local:E:e79da9ea] logged in with entity id 112 at (-5131.5, 66.0, 4883.5)

This is quite a distance away from x:0, z:0, and it seemed strange that no land would be found closer to the center of the world which is where spawn is generally created. To better see it I added JourneyMap to map the chunks that are generated, because region files are only created if there are chunks generated.

This is the initial map (reduced to 1000x1000 from 10752x10752):

The jumble of pixels near the center is in the region near x:0, y:0. The diagonal line of chunks stretches from about x:5000, z:-5000 (top right) to about x:-5000, y:5000 (bottom left, where I spawned), hence all of the region files.

and here is an area generated near the center (/pregenradius 0 0 0 64, note: the small area inbetween was just me /tp'ing to x:-2500, y:2500):

Clearly there is available land near the center for spawn, and some of the initial chunks generated near the center actually contain land.

To rule out there being an issue with this old version of BoP, I tried with the lasted build, 1640, but had the same results.

Next, knowing that BoP, in this case, is mostly just adding biomes with RTG and CC handling world gen, I removed BoP (leaving only RTG + CC) expecting the land structure to be very similar, and it was.
Spawn was also created where it would be expected to:

[19:39:59] [Server thread/INFO]: srs_bsns[local:E:2c6e2510] logged in with entity id 57 at (-158.5, 62.0, -270.5)

The initial world generation didn't contain any of that long diagonal set of chunks, it was simple as it should be, and only 4 region files created:

What is most troubling, however, is that upon /pregen'ing this area the diagonal errata returned, including a spawn-like area located in the x:-5000, y:5000 region (actual spawn marked by red circle):

Something in either RTG or CC is causing this generation errata (I assume RTG?), but it's not a case where CC can be removed to rule it out.

This should be investigated further.

Were you using pregen in the first case where you get the diagonal errata?

The splat of chunks near start might be the vanilla start chunks. None of this looks like the CC search, which should look kind of random and kind of spiralish. It does often miss smaller landmasses.

No, in the first case pregen was not used and the errata was generated upon initial world creation.

How does your function select a zero-point before beginning the search? Because, as you said, in the initial test it doesn't look like any search was done at all, and spawn, although a great distance from the region of x:0,z:0, was on land, so it's hard to say if any recovery was even attempted. If a recovery was attempted near the center I probably would have seen a spawn like I did when I removed BoP. (near x:-158.5,y:-270.5)

Does your function check chunks that have already been generated before searching in chunks that haven't been? Because that could explain the spawn with the initial test. With BoP loaded the diagonal chunk errata was already generated at world creation, whereas with BoP removed the errata didn't occur until I pregen'd.

Whatever is creating those diagonal chunks and square area, though, is happening during the creation of chunks near the center. I'm sure if I fly around and create chunks manually I'll be able to center in on the area it starts in. I might test for this in a bit.

BoP might be doing something - it might have a spawn search. Probably has to actually, since there's a "spawn on beach" option.

The CC function is intended to run before anything has been generated apart from the spawn chunks. It pays no attention at all to what chunks exist. It starts at the vanilla spawn location and runs a strict square spiral outwards, hitting the 50th chunk, the 100th after that, the 150th after that, and so on, forever, until it hits land. If it never finds anything it at least used to hang about when it got 25,000 - 30,000 blocks from spawn. It was running out of some resource but I could never figure out what (it calls unload chunks).

I could send you a version with my debugging logs on which will leave a record of the search in a file in the minecraft directory (along with a lot of other stuff).

The chunks right near the center are probably the spawn chunks, which are created when the world object is created, which is before CC ever sees it. Are there about 20 or so? For something to run THAT early it would probably have to subclass the WorldServer object.

No, I don't need a debug version of CC, but thanks for offering. I don't think there's any issue with the spawn recovery function or that it is even involved in this issue, I was just curious how it worked.

After doing some more testing I found a way to replicate this issue every time using just:

RTG-1.7.10-0.5.0.jar
ClimateControl-0.4.beta39.jar
configs: default
Seed: -1160707664362226860

1. Create a world. You will spawn @ x:-158,y:-270. and only surrounding chunks will have generated in regions [0,0], [0,-1], [-1,0], [-1,-1], therefore you should only have 4 region files.
2. Without even moving, quit to the main menu.
3. Reload the world and watch as 32 new region files are created.

Furthermore, the server log is showing that it's 'Preparing start region for level 0' a second time when reloading the world:
https://gist.github.com/srs-bsns/570db8a586715435737d (It should be obvious, but I added a line when I quit to the menu)

This generation of a second spawn area (the one near x:-5131,y:4883 from my previous posts) after the world has already been created and the weird diagonal of chunks being created along with it is very odd. Does minecraft itself have some kind of diagonal linear search for land to create a spawn point?

I'm not sure why this operation doesn't run until reloading the world. With BoP also loaded it happens at world creation and the spawn location is @ x:-5131,y:4883.

It shouldn't be hard to override this behavior once the source of it is discovered.

I get the spawn, but not the extra files.

Could this be another Windows vs Mac issue? I just reproduced this as per @srs-bsns's instructions and it only created 4 region files on first load, but then when I quit Minecraft and loaded up the world again, it created the 32 new region files.

This appears to have been fixed with RTG 0.6 and CC 0.5.beta45... just tried a few test worlds (including the seed that @srs-bsns listed above), and no excessive region files were created upon creating world, quitting, logging back in, and then flying around for a bit.

@whichonespink44, due to the changes made in RTG 0.6.0 and the changes @Zeno410 has made recently in CC, it's impossible to get the same world to generate, even using the same seed and adjusting CC's new defaults to the old values. Because of that there's no way to reproduce the environment in which this was occuring. However, this was likely a very rare type of occurrence to begin with, so I don't think it needs to be a big concern.

I'm no so sure I'd want to go as far as to say it's fixed, but I don't see a reason to keep this issue opened.

I'll keep watching for this in the future, but of the many hundreds of test worlds i've created with these mod versions and beyond, this is the ONLY occurrence of this that I've seen.

Cool, yeah we can always re-open if it pops up again.