Update for 1.14

[Draco18s]

Ah christ, I'm going to need to do it again myself aren't I.

[lawremi]

Happy to help.

[Draco18s]

Haven't gotten to it yet, still working on some other stuff (I've got to update tons and tons of things myself), but I'll need COG before I can release. Was just one of those "oh god, I didn't even think about that" moments.

The real problem will be that metadata is 100% gone and COG can't cheat any more using getStateFromMeta, which is going to be an utter nightmare to deal with.

[Draco18s]

List of things I cannot do:

• Cannot update the CogOreGenEvent because oregen no longer has an event at all of any kind
• Cannot update WorldHeightScale because the methods it relied on (isSkyColored and getAverageGroundLevel) have moved to I-don't-know-where
• Block.getIdFromBlock used in all _fastMatch ing: IDs no longer exist
• Ditto biomes
• All biome statistics (getTemp requires a BlockPos all the time, height variation is now depth and scale, but I don't know how they translate, no idea where num trees per chunk went)
• isModInstalled no longer maps to a single function call. Loader.isModLoaded => ModList.get().isLoaded() so I don't know how to fix the Config Parser.
• glVertexPointer now takes a new parameter
• Loader.instance().getConfigDir()
• All the packet stuff. I know how to do packets, but so much has changed that I don't want to mess with it
• FMLCommonHandler.instance().getMinecraftServerInstance()
• world.provider.getSaveFolder();

I created a branch with what I could do.
https://github.com/Draco18s/CustomOreGen/tree/1.14

[lawremi]

Cool. Do you think you can submit a PR? Looks like the NBT matching stuff that was added for Gregtech paid off.

[Draco18s]

Just a ping reminder. Haven't seen any commits related to 1.14 yet.
:)

[lawremi]

I gave it a go for the afternoon. Wow, so much has changed; it's overwhelming. This is going to take an indefinite amount of time.

[Draco18s]

Yeah, I hear ya there. It's why I looked at seeing what I could do, but there are large systems I just don't want to mess with,even though I could. And other things that I just don't know anything about.

[lawremi]

I've been working on the trivial stuff. The networking turned out to be easier than expected, largely because there are no longer packet size limits. The GUI and world gen refactoring is going to take a while. The "great flattening" of blocks might also simplify things, as the block state (or meta) is no longer so relevant to ore generation.

[Draco18s]

Great about the networking. Guis haven't been too bad in my experience so far. More along the lines of having to register new bits of it (TEs are registered, but now its based on a TE Type object, and if you want a gui, that means registering a ContainerType). But then again I haven't poked around with main menu stuff, so I could see how that could get hairy.

And yeah, the flattening will simplify generation, there was just so much involved there that I didn't want to make the attempt. I wasn't familiar with large portions of the system and I could have easily broken something and not known it (and then there's the 27000 config files that have to get updated).

[Draco18s]

How're things coming? Haven't seen a push since August.

[lawremi]

It hasn't progressed any, now that the easy stuff is done. I've been busy with other things, but I will try to get back to it. The motivation is a bit lacking, as this is not my mod/code originally. I only took it over because it was a dependency of my now dormant PFAA mod.

[Draco18s]

I hear ya, the whole "maintaining due to dependency of own mods" is why I've done what I can. I'm happy to help, but there's good chunks of underlying systems that I just don't understand. I'm pretty sure that the distribution math (the stuff that can be drawn as a wireframe or be used to query against blocks, whatever that underlying data structure is) is already being handled in a way that is going to be safe to query from threads with minimal alterations. But I'll admit limited multithreading experience.

I also managed to hook into replacing an ore generator last night (I managed to extract enough info from what was public to remove the iron ore generator and then replace it with altered data (that data being parity with what was extracted, didn't get a chance to write new values; proof of concept)). So I've got a little bit more understanding of what vanilla is doing. See this method:
https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L193

What's needed from that baseline is creating a Feature that queries COG's underlying data structure with world and position data (see net.minecraft.world.gen.feature.OreFeature) and dealing with gui screens. Wireframe visualization is nice but not critical for me.

[Draco18s]

Got a couple hours to dig into this again.

Found a whole bunch more low hanging fruit that I've been able to knock out ("oh Biome#baseHeight is now Biome#depth, cool"). But found just as many "TODO" items where I've commented out a large swath of code that just has oodles of errors that are either all related, or point to things that don't exist any more (looking at you, ConsoleCommands). Gui stuff is looking a lot more almost-ready, just a few things that I don't know how to deal with yet. As well as some blind jabs ("getNearestStructure is probably now findNearest...code isn't throwing errors at least").

Will make a commit tonight or later this weekend.

[Draco18s]

Digging into this some more. Have so far resolved a few errors, but there's a major hurdle that the distribution wants to determine its expected size using an XML property that wants World and blockpos (od.frequency.getMax(this.world...) because of things like WorldHeightScale). Unfortunately as StructureStart's constructor is invoked by Minecraft code via getStartFactory() World is not available and only chunk coordinates are.

The only option I can think of here is to change the distribution's frequency's type to not depend on the World in any way.

There's a similar issue with wireframes being turned on or off per world (ServerState.getWorldConfig(world)) but I don't think there's any solution there at all. That is, it would become a global setting.

And with getNearestStructure(). getNearestStructure itself is fine, as long as long as it has a non-null world, I was able to fix the missing Long-to-structure map (Minecraft moved it). But there's no way for StructureStart to pass a non-null world as far as I can tell, yet.

[Draco18s]

Circled back around to this once again (finally). Want to get it working before I do anything up migrating to a new MC version (ha).

I think I found the core issue with distributions not showing up with default settings. I had to strip things down to a really really bare bones config file state to find it.

<OptionChoice name='COGActive'
                  default=':= dimension="overworld"'
                  displayGroup='groupInternal'>

This results in COG being inactive all the time. Forcing it to be true, on the other hand, locks the game up during worldgen (keeping in mind that this is still a stripped down config set, only vanilla.xml and only with vanilla-like distribution options). :\

Last entry in the log:

[Cu.CustomOreGenBase/]: Loading config data for dimension '.\saves\New World\DIM0' ...

And because the project I have doesn't let me debug things (I get errors like "can't find system mod 'minecraft'" or "[mjava.lang.NoSuchFieldException: ucp") it further restricts my ability to go in and watch execution.

[lawremi]

Thanks for looking into this again. Nice find about COGActive being FALSE. A relevant line is

CustomOreGen/src/main/java/CustomOreGen/Server/WorldConfig.java

Line 348 in db93943

properties.put("dimension", world == null ? "" : world.getDimension().getType().getRegistryName());

.

It's possible that the name of the dimension has changed, or the world is null when that code is executed now.

[Draco18s]

Entirely probable. Might stringify to "minecraft:overworld"
I can check it for 1.14 easily enough.

The numerical ID is super-gone by 1.19 though, the only thing left is legacy migration code, but it's not usable meaningfully.

[Draco18s]

...and of course the next day, my working dev environment no longer works.
Great.