Litematica work items / learning a new language
JSpencer000 opened this issue ยท 3 comments
Hi,
Sorry if this is the wrong forum to communicate this, not sure what the correct forum is.
I'm software engineer with 30+ years experience with C, C++, C#. But I'm new to Java, and Git. I recently started using Litematic and want to see if I'd enjoy helping work on it. So far I've forked it and got the litematica-fabric_1.16_snapshots_temp branch building and running. Originally, I planned to see if I could add undo/redo to it. Since I often accidentally messed things up when using Litematic. But that's a pretty major change, and probably isn't the best place to start. So... I was wondering if there are a list of to be completed tasks available. I'd like to find something to work on that I think would be fun to work on but relatively small. I'm not really interested in taking on a after-work job where I just do tasks others choose. If I'm doing that, I'd rather be paid. Instead I'm hoping to find stuff I enjoy that aren't as addictive as playing Minecraft itself.
I thought about trying to add more documentation, in game help, or in game prompts. Since I found learning Litematic a bit challenging. For instance, if you had "additional help mode" on. When you were in move mode displaying something on the HUD that explained what things you might want to do next for instance (Select area to be moved, press to move). I'd want more detail than that, but that's what comes to mind at the moment.
Github just added the Discussions feature, so that would also work now. And Discord is another option, but I don't think it's really linked that visibly here in the repo.
I have a massive todo list, but the live version isn't visible anywhere. And in general I tend to have the mind set that I want to design and implement any new major features myself. I like to know exactly how everything works and is connected in the mod, plus I like to know that I made everything in the mod myself. Granted this isn't the best thing for the mod itself or the users, as then all progress is dependent on my time and motivation to work on things... But I also fear that if the mod would start to become "less all mine", then I would start to quicker lose interest in working on it at all.
So in that sense you don't have to worry about me tasking you with implementing everything on my massive TODO list, it's far more realistic that I won't "allow" you to work on anything ๐ Well I mean obviously you can work on anything you want at least for your own use, but I might just not accept any bigger PRs.
That being said, good ideas are always welcome. For example I'm well aware that the mod is currently difficult to learn for new users, and there is some kind of documentation/tips & tricks system on the TODO list. The current idea for that would be that it would contain a number of basic topics that would describe how some of the basic systems work and how you do things, and then also smaller tips and shortcuts to various things, basically how to do things fast. It would most likely be searchable by keywords. If you for example have other ideas for how that system should work usability-wise, I'm all ears.
And then also development-wise the main development version is still the 1.12.2 LiteLoader version, so all new features and changes should go to that version first, and they will then be merged forward from there. However that unfortunately also means that the latest MC version is going to be further and further away from where the new features are first added... All the 1.13.2+ versions are already far behind, the last merge from 1.12.2 happened in early June 2019. That's also why some of my client mods now have those annoying "temp features" branches, which contain some cherry-picked features from 1.12.2 that were often requested, or in some cases some small new features are implemented first in those temp branches, and will then later be "properly" implemented to the main development branch, and then merged forward via the "main" branches on each MC version. So the temp features branches are supposed to be thrown away once the next proper merge from 1.12.2 to 1.13.2 -> 1.14.4 -> 1.15.2 -> 1.16.4 etc. happens.
And even further, this past summer I started working on a massive refactor of malilib. Litematica is currently the only mod that hasn't yet been fully ported to all those changes, so the current liteloader_1.12.2
branches of all the other mods are in sync, but Litematica's is not. I still need to update all the GUI code to the new way stuff works in malilib. And due to how big the refactor is at least in malilib itself, I may need to do the next merge in an awkward manner, basically starting the merge, and then deleting all the java code and copying the 1.12.2 LiteLoader version over, and then trying to apply all the relevant changes and MCP -> Yarn renames again by looking at the old diff between the branches. Because due to the MCP <-> Yarn name differences and other vanilla code changes between the versions, just trying to resolve the merge conflicts like you would do normally in Git is most likely going to turn into such a total chaos shitshow that it's just not doable...
The main reason that main development still happens in 1.12.2 is that the "main target audience" which is the technical minecraft community, is/was still playing in 1.12.2. And even more importantly, I often implement things that I want or need myself, which is a great motivation booster for getting stuff done. And I still play in 1.12.2 myself for an unknown amount of time to come. So although it would probably be best for the majority of the user base that main development would happen at the latest release version of MC, it would mean that I would then get all the new stuff last myself... But I think it's still possible that I may move the main development to the latest release version at some point, but not before I clear most of my current TODO list... which will not happen very soon :p
However I don't intend to keep supporting all the major MC versions indefinitely, I'm most likely only going to do the next bigger update from 1.12.2 via all the major MC versions. And after that I will probably drop support for anything after 1.13.2, before the current release version. In other words I would keep supporting 1.12.2, 1.13.2 and currently 1.16.4. This is also why I would like to cram as much as possible to that next update before starting the merge.
The reason for 1.13.2 is that I would like to update my server to 1.13.2 at some point, but I'm still not sure if I ever want to update that server to 1.14+ due to a bunch of the vanilla changes (both in-game and code) in that version and later. But I'm still not even sure if I'll actually ever update that server even to 1.13.2, as that also has a bunch of issues, the main problem being that the Data Fixer Upper and the world format conversion is buggy and broken to this day, when updating old 1.12.2 worlds to 1.13+. I would need to make a custom mod that tries to un-fuck that update process and make sure that it doesn't nuke any chunks, like it seems to do currently to a small number of chunks.
As to getting rid of the separate branches, I don't see how that could happen. I would then need to use some kind of C-style #ifdef
/ #ifndef
type system to enable or disable code blocks within the same code base. And that would just make everything a totally unreadable mess. There are both vanilla code changes that affect code between versions, such as method signatures changing, or some functionality moving to different classes entirely or being completely refactored. On top of that the 1.12.x and 1.13.2 versions use the MCP names, whereas the Fabric versions use the Yarn names, which means that a lot of the class and method names differ between those versions. And I do want to make Forge versions as well for 1.16+ again, so I will also need two adjacent code bases for the same MC version as well but with the different naming scheme when that happens. One thing that would help with that is if I could somehow get a Forge dev environment set up that works properly with the Yarn names. But MCP does not use intermediary class names, so the class names would still differ even if the method names were using Yarn.
And finally here is the current TODO list: https://masa.dy.fi/tmp/minecraft/client_mods_todo_2020-12-10.txt
Thanks for the detailed response and an explanation of the branches. Litematica is a really nice mod, which clearly a lot of effort has gone in to.
You may want to consider moving the main development branch forward from 1.12.2 in the future. Or finding a way to break the requirement of having a separate branch per Minecraft major release.
It's sounding like you're not really wanting additional contributors to the project, which is fine. It's your project. If that's not the case then I need something specific you'd be happy with someone else working on. Ideally in my case, a list of items to pick from.