pymclevel / mcedit continuation

[JiFish]

It looks like MCEdit (and therefore pymclevel) will continue development over at https://github.com/Khroki/MCEdit-Unified

I have already posted an issue regarding re-separating pymclevel back in to it's own project.

[JiFish]

I posted that here: Podshot/MCEdit-Unified#58

Perhaps this is less of a problem than I think, though?

[orphu]

Well, it's certainly not ideal. Sounds like they don't want to maintain it separately anymore. It probably means it will become (perhaps inadvertently) dependent on the mcedit code later, which is bad for anyone trying to use it elsewhere.

[orphu]

Their version of pymclevel appears to support TileTicks.

[JiFish]

#265 is possible without their version. But they did add a nice wrapper here: Podshot/MCEdit-Unified/issues/59

[JiFish]

The new maintainers didn't keep the separate pymclevel project up-to-date as promised. They have recent fixes on their unified repository: https://github.com/Khroki/MCEdit-Unified/commits/master/pymclevel

[orphu]

Coincidentally, @mathuin recently sent me a message asking how the heck we keep pymclevel up to date. I told him we didn't. haha.

I fear we may have to build our own module before long.

[JiFish]

I did look in to submodule sparse checkouts, but it seemed over complicated: http://stackoverflow.com/questions/6238590/set-git-submodule-to-shallow-clone-sparse-checkout

[mathuin]

If you folks do seriously consider writing your own pymclevel-like product, I wouldn't mind being involved.

Starting from scratch, focusing on a limited scope, with tests and everything, supporting Python 3 out of the gates, sounds good to me. I'm even okay with discarding backwards compatibility and creating a brand new interface. What do you think?

[JiFish]

That's a kind offer, thanks.

Practically speaking though, I don't think it's going to happen. I have less time than ever and the low-level stuff was never my area in the first place. I haven't heard from @orphu in a while and I assuming that similarly he doesn't have the free time to attempt this. Though he has talked about replacing the module in the past, so who knows? I wouldn't count it out.

If an interface-compatabile new version magically appeared, I'd definetly give my best to update the rest of MCDungeon. Failing that, my feeling is this project is effectively dead.

[mathuin]

Sad, but understandable. It's been the blocker on my project as well, and tracking the embedded changes in each Minecraft version was something I was happy to defer to someone else. Ugh. Ah well. If I get really, really bored and make something, I'll let you know. :-(

[AmbassadorPineapple]

Ah man, the project is dead? That sucks.

[Swede37]

"If an interface-compatabile new version magically appeared, I'd definetly give my best to update the rest of MCDungeon. "

Where can we find a good Magician..... ?

[AmbassadorPineapple]

I dunno.

[mathuin]

The magician's minimum required capabilities:

• Must have the ability to write, document, and maintain idiomatic code written in Python 3
• Must have the patience to tease out API details from poor documentation and decompiled code
• Must have the strength to throw out their work and start from scratch when Mojang does the same
• Must have the free time necessary to apply timely updates and work with fellow contributors on PRs
• Must have the passion required to do all this without flipping tables

Most folks with the patience and ability are employed and have little free time they can devote to the task. Those who do have enough free time often feel their strength and passion ebb over time. It's a challenge.

[sshipway]

I'm still lurking on the project, and submitted the fix for treasure hunts last June; however it's a shame that this project is dependent on pymclevel which is not available. I thought of porting some of the functionality over to Java as a spigot module (it would be awesome to be able to build a dungeon inside the game...) but it's just too much work.

[mathuin]

I have a pymclevel-like library written in Go that was working 100% the last time I checked, but I haven't kept it up to date because the parent project that drove me to create it had to be retired for other reasons (upstream data availability) so it lingers. :-(

[sshipway]

Is it not possible to (somehow...) pull a working pymclevel out of the Podshot/MCEdit-Unified repository and make it a standalone? This is likely less work than creating something from scratch.

[mathuin]

It is possible to take the code in the existing repository and use it to make a standalone version of the library, but then that code would have to be tested, documented and maintained. I'm not sure it saves much time, but you're welcome to give it a go!

[JiFish]

I'm not following too closely, but I was under the impression that MCEdit-Unified doesn't actually support 1.13 either. I think that version of pymclevel would give us the ability to use the new NBT tag types, but the world editing interface still wouldn't work with 1.13 saves.

It looks like MCEdit-Unified itself has been abandoned in favor of a brand new editor: https://github.com/Amulet-Team/Amulet-Map-Editor This one isn't based on pymclevel. (Which, to be honest, is probably exactly why they wanted to build one from scratch. To escape all that legacy code.)

At this stage, the easiest path might be to get rid of pymclevel entirely. Use the python nbt module to write a super-minimalist replacement that just does what mcdungeon needs. Rewrite some of the core of mcdungeon to use the new interface. But, unless we find a willing sacrifice, this is all pie in the sky.

The future might be Datapacks. Mojang is adding more and more power to this feature. You can already create many of MCDungeon's custom treasures this way and there is limited support for creating structures.

[orphu]

Hey folks!

Still around. Real life job has really been a huge thing last couple years, etc, etc. (I'd tell you, but then I'd have to kill you all)

I think MCEdit did update to be able to read/write 1.13 worlds, but, really that's only part of the problem. With the change to the way data value and name spaces work, reading and writing levels is really probably the easy part. The rest of the code would need to be refactored extensively as it makes a lot of assumptions to how data is structured that are now incompatible. In retrospect, and with more discipline, all of this should have been abstracted away in an API, but it wasn't (well, it started that way, but it wasn't maintained). I think MCEdit came to a similar place and is why they are rebooting the whole thing.

I'm very fond of this project and often think about getting back into tackling these problems, but this is very difficult for all of the reasons you folks list.

[JiFish]

Are you sure about that? This issue suggested to me that although they can read 1.13 nbt tags, actual world modification was never working. But I don't know how to verify it has 1.13 support. If it really is possible to pull in their version of pymclevel, that would be a start at the very least.