search

lawremi / CustomOreGen

Custom Ore Generation mod for Minecraft, originally by JRoush
Artistic License 2.0
40 stars 25 forks source link

Update for 1.14 #227

Open Draco18s opened 4 years ago

Draco18s commented 4 years ago

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

lawremi commented 4 years ago

Happy to help.

Draco18s commented 4 years ago

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 commented 4 years ago

List of things I cannot do:

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

lawremi commented 4 years ago

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

Draco18s commented 4 years ago

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

lawremi commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

lawremi commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 1 year ago

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 commented 1 year ago

Thanks for looking into this again. Nice find about COGActive being FALSE. A relevant line is https://github.com/lawremi/CustomOreGen/blob/db939431ccab85707754c69c6d54858d1fcdf9ff/src/main/java/CustomOreGen/Server/WorldConfig.java#L348.

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

Draco18s commented 1 year ago

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 commented 1 year ago

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