#Leaf (forked from FabricMC/fabric)
1 messages ยท Page 5 of 1
Nice.
that doesn't look so bad
(though maybe the resulting constant names could be a pinch shorter, lol)
though I guess thats accurate to where they are in the codebase... shudders
turns out mixinextras was not working in dev this whole time, but it works in the loader's test project, so thats why I missed it lol
How come in works in dev but not in the test env?
It's the opposite. The reason why it works in the test environment is because it's bundled with the loader in the parent project, and then used in the test project. The reason why it doesn't work in the dev environment is because loom isn't adding it to the classpaths when it un-bundles it for use. I think this will also affect the loader though im not sure
@floral sluice btw at some point puzzle got some base Project Zomboid support, and I joined with the intent to continue it, but I don't really want to compete with another loading causing a minecraft situation
I was wondering if you would like to join puzzle and create a unified loader for project zomboid
if you can come up with a better solution, by all means go for it
I don't plan on dropping this though unless something better does get created
As I'm fixing up the gradle for puzzle-loader-zomboid(https://github.com/PuzzlesHQ/puzzle-loader-zomboid), im thinking we could merge some stuff & put combined effots towards making a unified loader, sorta merging some of leaf's things
One of the main reasons why I am not going to switch as of right now is mainly because I spent around 3-4 months specifically for learning fabric's codebase, so if I have to switch to an entire new one and redo everything I've spent my time on previously it's just not worth it for me right now, especially when i've still got stuff to add
i knew fabric's codebase was a mess, but holy crap i didn't think it would take 3-4 months to learn
I honestly think fabric is quite bloated for what it is
I agree to an extent, it's fairly convoluted but most of the things it does make sense within reason
I take it you started puzzle loader after looking at fabric?
Also, when I call the project "leaf" it's mainly just to gain a destinction between fabric and leaf, but leaf is pretty much to a T exactly like fabric if you exclude some things i've added and the zomboid game specific stuff, but I will never call it "my" loader or claim that I did all of it, just to clarify why its a different name
i mostly started it out of wanting to finally having my own loader & yeah that I thought fabric was a bit over complicated internally
Orignally I started making it for a game called CosmicReach thats in its alpha stages
I did base somethings off of fabric design to add some familiarity in the mod.json
also, what did you have to change?
like.. what specifially?
I dont really know honestly
I never really keep track of what I do exactly on a timeline just to remember it, I do something and if I fix it or it solves an issue then it basically becomes purged from my memory as I move to the next issue/feature/etc
something like that, I just have shit recall ability
but if I had to guess, it was probably mostly editing loom/loader to be zomboid specific (not obfuscated, so no need for remapping, and game handles some things differently in the IDE like workingdir needs to be set to where the game libs are)
ah, btw most of the stuff like loom or manifest stuf wont really need to change, except for getting some deps for the puzzle loader
i'm just not joining a separate project rn, I have a fair few reasons some of which I don't know how I can express them, but somethings not in order:
- i dont see the point in creating the whole stuff essentially based on fabric if its going to be rewritten/separate anyway, i'm like more either create it from scratch and fully own it or fork someone else's project and acknowledge it like that
- I get free upstream commits from the maintainers of fabric easily, which is lots more than zomboid (and in my case it's extremely helpful since im solo right now), so having a fabric-derived project but where you can't directly add upstream commits is not what i wanted for it
- if I had 10$ for every time someone came to me and said they had a mod loader project and or wanted to merge/abandon leaf for it i'd have around 30-40$, so I meet it with skepticism every time, they didnt go far with it and if I did delete my project for it, then my work is for nothing because they ended up saying no anyway
- this is my free time project, so if I did delete it for another projects like puzzle, I would actually need a want to do it properly. I don't see much of a want here for me personally, especially when most of the stuff I've done over the past year is already done, doing it twice will probably just drop me out of zomboid modding completely, and I dont think I would come back to it
- this is a more personal reason, but I tend to only contribute/work on things I know the people well enough for, some people who will be nice to you and once you have committed 10,000 lines under AGPL/MIT/etc then they don't know you anymore, it's surprisingly common
basically the tl;dr is that I will see where it goes, but im not going to instantly move on to something else just like that
response to Bullet Point 3: People normally don't go far with mod-loader from scratch projects because they are too ambitious about their goals or aren't fully interested in it or it was a small thing until they reached a wall they felt too lazy to get around or just get burnt out too fast, mine is persistent and won't fall off at https://github.com/PuzzlesHQ, its been going on for quite a while now and I don't plan on abandoning it discontinuing/deprecating it. The only reason I would take a break from it would be because I'm doing school, not home, gaming, or don't know what the next step in development would be since it is virtually finished.
response to Bullet Point 4: Much wouldn't really be deleted except for the `leaf-loader` repo + I have a project base already ready & updated to the latest core puzzle there is, and I could help out in the development in the project zomboid loader/mod. Also migrating code could either be done by you or me as I don't think much would need to change too entirely much. Also something like this has happened before but they screwed you over? (not sure how to respond to that)
response to Bullet Point 5: I'm sorry that its that common for people to just abandon or steal your code after writing that much. The project may be LGPL but I will make sure you own your code as over at puzzle you own what you write. I know you don't know me well, and I may not know you but I will make sure you are not removed or anything from your projects you have worked on.
I just don't want to cause any sort of loader wars or anything, and I want you to be able to know that this will always be and option to join puzzle at any time and be added to the puzzle-loader-zomboid segment. Puzzle isn't some low effort project put together by someone who doesn't care, it was put together me and some people on my time to make this usable and have general purpose core for extension to any game.
-# This is the biggest message I made ever
holy heck i wrote alot
I couldn't include it in the msg, but I respect that you don't want to join at this time & that its gonna be an offer that will be there for you to accept & you wont be solo if you join, as I and a couple others could help if needed.
what does puzzle do differently that we should consider this anyway? all you've really said is that it's similar to leaf ๐
What's going on here ?
its a general purpose mod loader with easy expandability to other games, it has a way to configure how certain things work via CLI arguments(https://github.com/PuzzlesHQ/puzzle-loader-core/wiki/CLI-Arguments) + you can add what you need or want to the core when you want. I modeled a bit after fabric like the existance of game providers & the mod.json, but it has built-in mixin capabilites, fabric-like programming-language-providers, a simple GameLoader that is optional & helpful when gauging progress on mods and loading things, easy class transformations using IClassTransformer + it has full support for java 24+.
also access-transformation supporting forge-accesstransformers, fabric-accesswideners & a custom format
and an easy way to add a custom mod manifest(puzzle.mod.json) format
zomboid uses java 17 btw
ik, just mentionin what it can go to (max)
the min is 17 due to neoforged bus (which i need to move to cosmic & zomboid separately)
Github Organization: https://github.com/orgs/PuzzlesHQ
Access Transformation (changing public/protected/private/final): https://github.com/PuzzlesHQ/access-writer
Mod Manifest Format parsing/transformation: https://github.com/PuzzlesHQ/mod-format-framework
The Core Mod-Loader: https://github.com/PuzzlesHQ/puzzle-loader-core
The Cosmic Reach side of Puzzle: https://github.com/PuzzlesHQ/puzzle-loader-cosmic
This Project Zomboid side of Puzzle (working): https://github.com/PuzzlesHQ/puzzle-loader-zomboid
TLDR what is Puzzle about and for ?
it does have a decent amount of difference
puzzle loader is a general purpose mod loader with easy expandability to other games
its for making modding easier than general patching & somewhat familiar if you have modded before
puzzle-core is the base modloader and puzzle-zomboid is a mod that gives you very basic api (eg. mod Initialises) but you can add more apis to it or make a separate mod like cosmic-api (https://github.com/PuzzlesHQ/cosmic-api)
-# sorry if we are bombarding you with messages
not to offend, but this to me seriously sounds like fabric with some internal refactoring, I don't see much benefit that a user would get outside of using forge transformers which most people wont do
You have to remember that PZ is extremely new to integrating java modding into the public, most people probably don't even know what a java mod is, and an even larger portion of people will refuse to install java mods, it's not some holy grail like Minecraft where the community though multiple years (thanks @verbal panther for the Notch minecraft lore :D) has already accepted Java modding to be the standard
in the case of Minecraft it's not like they could do with something else I guess
I think there were attempts to add Lua modding to Minecraft (or other lang) but obviously didn't get enough adoption because the standard of using Java mods was already set
I've basically had leaf exist here since a month after it's initial creation, and only very recently (I'd say past two months) has anyone even looked this way (barring GigaWatte and some people who saw this early on)
If you want to tell people about the puzzle loader, you can create a separate mod project channels and talking about it in the official PZ discord, but I (with due respect) don't want this channel which I mainly use for inquiry about leaf and rarely issue/feature reports to become an advertising campaign for puzzle
Also to clarify, I don't consider puzzle a loader war, I really don't care about a loader war.
In reality, if puzzle became the preferred java mod loader, I would stop working on leaf in favour of other projects like some games
@maiden sundial I'm curious but where did you get a hold of Leaf that made you come here ?
oh, i joined here to get a scope of the current modding enviornment & discovered the existance of leaf
and invited him
^
Never had an issue sharing the room with others.
The room was just me for like 10 years.
turns out I already had windows server support in the installer, idk why I don't remember writing any of this...
at this point im having to ask everyone else if I added a certain feature ๐ญ
Documentation is king!
(and the hardest task)
im honestly relying heavily on github issues, because I can see what I've marked as done (and thus what needs to be done)
but I believe that I wrote all that before I added the issue for it
weird.
If someone on linux and has the dedicated server installed, please send me start-server.sh
my internet is not good enough for me to install it myself right now
or do people use ./ProjectZomboid64 to start the server? I don't know how it is done on linux..
It's weird how Linux has a server bootstrapper but windows doesn't
lol I did it so long ago it's crazy
So I've currently only got an init extension in the api for when lua initialises, is there any other stages someone would recommend (that would be easier to have a function over an event listener)?
Lua init is the only stage I can specifically think of, as once lua is loaded most mods are sending it
@full mountain if you know where I can get b42 javadocs that have param names and the like pls let me knowwww
even if some of them are old names and whatever, as I can import them to yarn
Uhhh. Before world dictionary is compiled so you can procedurally add items to the game? (Dunno if event listener would work fine for that?)
Random other feature thought: Delete/Disable recipe.
Since thats impossible to do in LUA as of B42.
(id wager enough modders wanna do that, that you shouldn't have them try and do it themselves in weird and/or conflicting ways)
(Rebalancing a recipe is so much easier when you can just delete the existing recipe and add a new one)
hmm I thought you could at least to some extent
letting people add items/recipes/etc from Lua would be cool
B41 supported it, B42 only supports you stealing one recipes input/output list and applying it to another.
And maybe changing the quantity of an ingredient? Or was it the basename? (It was one or the other but not both lol)
I spent like an entire day poking at it and I only found 201 ways to crash the crafting UI
Theres plenty of variables in there.. you'd think might disable a recipe.. but no, they just disable the crafting UI
You definitely can't just freeform add/remove ingredients.
Yea, exposing an API to lua would be really nice
it might be half way there with the existing load functions, just.. yea, No idea where to go after loading it ๐
Doubt LUA currently has the access to do it without java help
Can you do it with DoParam?
I don't think that exists for recipes
pretty sure its Item only
btw, PZ merges recipes
ie, if you have two recipes that say, take a hammer with the same name, and one outputs sheet metal, and the other outputs a handle
you now have a recipe that takes two hammers and outputs sheet metal AND a handle.
Because that is 100% everyones intended behavior when redeclaring a recipe! totalllyy!
Oh and a few vanilla recipes suffer from this because the recipe is duplicated in vanilla PZ
Or just replace
IMO replace is the most useful method maybe with a console.txt note that your replacing a recipe that someone is totally gonna notice in the 1meg log file.
But no, for beefcake to replace one vanilla recipe it has to do a full file replacement override mod.
And no way to turn that on/off via LUA either.
(ie sandbox options)
So atm there is no good way to make sandbox configurable recipes -_-
im done with zomboid modding for the forseeable future. if you want something like leaf, wait for puzzle to maybe have some stuff like it. i will still be updating game manifests if you ping me or you can create them and PR yourself
i will still be active in zomboid chats occasionally.
@floral sluice just wanted to say thank you for your time and effort working on the leaf project.
I will continue trying to finish my mod, as Iโve had some success with its hardest part. The only things left are properly injecting all the logic into the game engine and debugging the remaining bugs
@floral sluice Thank you for your work on Project zomboid. I'm sorry I never got leaf working. I don't see puzzle as being any better, easier or more complete btw, I just need 'Java For dummies' level guides to use anything as complicated as either.
@fresh nexus Haha, it would be awesome if it existed. It's pretty hard for me as well to code the things I need using Java and mixins for PZ because of the lack of examples ๐
Spent what felt like an eternity getting custom entity components and systems to work
Yea I have literally no idea what a mixin is, its syntax format or anything and im far too afraid to ask the 1000 questions needed to figure it out.
I will make a wiki page for that then
Anyway @floral sluice , I thank you very much for all the modding help you have provided me and will miss you in the community.
Mixins themselves are pretty well explained on the GitHub repo. But when it comes to using them with PZ, I end up with completely different errors that I can't understand - mainly because of how PZ is written
I am sad to see you go as it was fun and interesting to see how you did things :)

mixins will be for the most part transferable to puzzle, as they also use the same systems (mixin, access widener for example)
also, I wish you would've said something more, I am open to helping if you need help with mixin issues (loader agnostic). I wish I didn't break mixinextras though, because you probably would've had even a little easier time with some things
The main reason I'm not asking is because I'm not sure whether these issues come from my Java-mixin-programming skills or from the Project Zomboid architecture. Currently, I think I've resolved all of them and working on the lua part (At least the game starts, the map loads, and the new systems are working). As I mentioned before, there are practically no examples of how to do the things I need in PZ, and inspecting minecraft mods source code written with mixins hasn't been very helpful. Also I'm also not sure where I can apply MixinExtras, because once again, there's a lack of proper examples - so I'm just learning through trial and errors using the mixins only
MixinExtras should've been automatically included from the loader, it was my mistake that it wasn't being included which I only found out recently
also asking is how you find out, even if you dont know if its an issue with your code or mixin, it's probably best to know what the issue is anyway
Sure, but at some point constantly asking feels just like your annoying the people who are trying to help because you don't even know the basics. Its like asking Einstein how to add 1+1, you feel really embarrassed that your several magnitudes below them in skill in the subject and are going to have to ask a hundred questions just to fill in the basic gaps before you can ask anything interesting to them. Many people who are socially awkward have no clue of the balance between the two (self learning and asking) either. <like self>
I don't think it's reasonable to expect everyone to be an experienced senior programmer - especially in the field of the game modding, where I believe most modders are enthusiasts with ideas they just want to bring to life in any way they can
So, it's mostly a personal choice not to ask. I usually only ask when I'm completely stuck
Sorry for the off-topic, by the way
I agree. but when you said there's a lack of examples, did you look at the fabric mixins wiki page? it should've explained most of the generally used mixin types
I did mention you need only a basic level of Java for that reason. you can literally learn a crash course of Java in like an hour if you wanted to
I'm sorry but I and most other people probably aren't going to teach you how to use Java, there's just too much to cover and it becomes redundant to constantly tell people the exact same things. I guess it's fine for a few things, but if you're asking like in that example "Einstein how to do 1+1" of course is going to be awkward when Einstein told you previously that you need a basic level of skill in math to partake in his classes. it's why basically all other Java mod loader has a requirement for basic Java knowledge
and I'm going to guess that puzzle won't be including a wiki just for Java too, because of that being so pointless. they might want to include their own mixin examples, and I guess I could've added more examples to the example mod, but you can't start saying there was a lack of examples when no one asked me to add a bunch of mixin examples, and I also linked to a few pages that explain it all and have examples.
though not to get the impression that im defending what I did, because imo I didn't do nearly as much as I wanted to. I haven't archived the project or anythng because of the slight chance I pick it back up in the future, but right now (at least until 2026) I can't put much time into it, and the game is just tiring for me personally to work on
If I may ask, was it something specifically about PZ that drove this decision or was it outside factors (lack of time, cost-benefit, drive, etc.)?
lack of time was the biggest reason, second to me realising that I wasn't doing it for myself
dont get me wrong i do really love seeing other people enjoy things (especially stuff I can potentially create) but zomboid is just a game i can't see myself personally enjoying from a player perspective, but also developer perspective since i know pretty well that i wont get a dev position
They were hiring
I mean, IDK how viable that is, but I figure it might be possible if one were so inclined and had whatever they were looking for
not arguing the motivation, more like mentioning since I read about it awhile back
I think I understand. When I stopped playing PZ for a few days, I kinda lost most interest in it, I haven't gotten back into it
and I kinda lost interest in modding it when I saw how complicated it was on the backend of things
and how it's in the middle of changing so anything that's done will likely break over and over
they're hiring people with years of industry experience, not really the average modder
when they do hire modders from what i understand it's more on a 'suprise! want a job?' basis
it's not something you can apply for or would be reasonable to expect/aim for
Sounds about right
i figured it would be more beneficial if i worked on my own game that i actually would enjoy playing
I figured grokking what's already there to a decent degree is probably complex and hard enough that I'd be better off putting that time into developing a game of my own
at least if I fail there, I fail making a thing for myself
not to mention if i did get a job at TIS, i wouldnt be working on a game i enjoy, so probably wouldnt be the best fit for it anyway even if i can handle the workload
Oh, haha same train of thought
Well I appreciate and thank you for the effort you put into leaf regardless, I did learn some stuff in the process of getting it set up
most of the stuff like java, mixins and access wideners/ducking will be appliable to puzzle if you do decide to continue
so dont feel like it was all for nothing situation
im assuming here that puzzle will develop correctly here, obviously if it doesnt continue or changes everything including mixin/wideners it wont be
I don't know of any other way to mod a java program without access to sourcecode that doesn't rely on mixins
hell the first time I heard about mixins wasn't in Minecraft
it was a college professor talking to us about how these sorts of modifications were done to a corba system
i really wouldn't go into modding expecting to get a job out of it
you'll gain experience that will help you get a job but the likelihood of directly getting a job from it is pretty close to zero, the success stories are rare outliers
it's happened more often with PZ specifically for sure but it's not something to bet on (and honestly i wonder if TIS even needs more modders at this point ๐ )
Yeah part of me wants to be irritated because asking for industry experience feels like kicking down the ladder. But OTOH I've seen the codebase, I don't think introducing more absolutely green people here would be good
@floral sluice if I may, do you have any plans to make a game then? Or is it something to do in the indeterminate future?
yea i definitely wasn't expecting it, i started modding because i wanted to use the mod i was making
only started thinking about TIS when i got into the java, because i realised that we're basically doing TIS job
definitely in the future not an exactly sure when i will, but it probably wouldn't be a game idea that you would like (if i remember you talked about something before)
Modding is the Jack that built Bethesda's house
finding other devs who want to make a game similar to yours is just as important imo
what for?
I plan to go it solo, because I have no clue on the time resources, I'm not making a living off it, I'm just learning the engine and I have no hurry.
But it's good to be in community with people who have similar pasions so that you can exchange creative energy, resources, advice, etc.
I don't think that requires similar game ideas. It just requires doing the thing because you like doing the thing, vs say, because you think you'll make the next Fortnite or some other get rich quick scheme
same
but the reason why i say similar game ideas, is personally for me i dont want to work on a game that i dont like the idea of
it would be a repeat of zomboid for me
Completely fair
Thanks for your work
@floral sluice is migrating from Bukkit-like modding to Fabric a big step?
I may look in the MC marketplace again so thought I'd ask someone who knows the current ecosystem.
If by bukkit-like modding you mean for the end user to use, I guess you could just make a similar API/abstraction that is bukkit like for others to use
It would have to involve mixin and whatnot but you could theoretically design it the same way and it would functionally work the same (imo better actually)
probably one of the only major benefits to creating a bukkit-style api for fabric would probably be so that people don't have to use mixins as much, but they will have to use them at least once if their mod is complex enough, so I don't see the appeal
i am not that into mc modding recently, so take it with a grain of salt. when i was looking at fabric codebase it was mainly the code part, and lesser about minecraft, though i happen to know how the minecraft-specific stuff works purely because i played minecraft with fabric in the past occasionally
I'm going to try and squeeze myself back in here for a little, turns out I still have some drive left in me to get this to a proper working state, I hate leaving shit half broken. might take a week for me to pick it back up, bc I'm currently working on emmylua
most priority for me out of all the bug is mixinextras stopped working, shouldn't be a crazy fix i just forgot to add it to cp, the slf4j conflicts with the game i figured out how to fix that like 10 minutes ago as i woke up for some reason, after those important things are done ill work on adding some mixin documentation after asking people here what they need documented and if its necessary
I'm going to be holding off merging upstream changes especially until I can fix the important stuff aswell
to avoid burnout from PZ im going to be avoiding completely the trashpile that is PZ codebase, so I'm not going to make any pz mods, only going to work on the leaf toolchain, while also working on emmylua
and I also think that taking it too seriously like i was getting paid was bad too, so that's gong to stop as well. anyone can commit and idgaf how bad your code is, ill review it and tell you what to change if needed and possibly a better way, but I'm still not expecting anyone to commit anything, just telling me about the bugs or making an issue report is more than enough.
To make it clear, I won't be starting work on leaf right today because I really want to finish the current thing im working on with emmylua, but once that's done then I will work on leaf more
I might add some breaking changes to the leaf manifests, since I'm already rewriting the generator for it
The "breaking" changes are mainly just converting certain types from string to integer, for example the attribute bytesDisk representing the size of whatever on disk in bytes, is currently a number-string aka "123456" instead of just 123456. I did this initially because it has parity with minecraft's manifests, but it seems kind of dumb now and is slower (even if just a little) as well
though I doubt anyone but me is using the manifests anyway lol
manifest generator rewrite nearly done despite me saying it would be done like 2 days ago lol
I should stop giving time estimates, I do it because i feel bad
well its still rough and I can probably improve the generator even more in the future, but I think it was worth it, got it down to around 20 seconds on my cpu
keep in mind that is for every manifest creating from scratch, the old version takes 30 seconds just to add one version ๐
Nice improvement!
if anyone needs to know (unlikely), the new manifest generator introduces a breaking change with the size numbers relating to files and such, these are now unsigned 64-bit numbers instead of strings
which also means loom won't be able to parse them as of yet
i believe the original use of strings was to not have to worry about overflow, but considering how a u64 can represent 18446744 terabytes, I don't think PZ will hit that mark anytime soon
But I was this close to making a mod where you can watch the entirety of youtube on your PZ TV.
ill fix it very quickly since it isnt a big change, but I might as well fix some other bugs too if im gonna release
like the mixinextras one
I reverted the main breaking change which was a simple json attribute name, because it was stupid anyway, so loom should be working normally again
(not really important msg) im doing internal changes that wont affect loom much, like formatting the entire toolchain to get consistent formatting because christ on a bike it could do with some love
just a non-important update, but yes this project is still being worked on, albeit extremely slowly as of current. to keep a long story short, irl/health/money issues and the whole circus related to that has delayed me on doing a lot of work that I want to do. I can't say however that it was impossible for me to do any work, because technically yes I could've, but it's not very fun to work on something when you feel awful in every sense of the word.
not trying to farm sympathy points, its just a project update because im kind of embarrased at how little work i've been doing, partly mostly due to uni, so my github commit history is as clean as a medical practice
tl;dr not abandonded yet, just getting my things together irl
Take care of yourself first ! ๐
B42 MP unstable has just been released, and in light of that I've kind of got some more motivation to prioritise leaf over christmas, since this has dropped pretty recently as of this message im gonna focus on migrating some things slowly since somethings have changed
Two of these that i've noticed in my short time is:
- The game now uses a
projectzomboid.jarto bundle class files instead of them being scattered over the game directory. Vineflower fails to decompile some important class files now such asCore.class
The first means that I will have to change some of my previous code that I wrote to support both legacy class structure and also the newer jar files (which is the standard, and what fabric/minecraft uses anyway), so that will be a little annoying but shouldn't cause too much chaos.
The second means im gonna have to fix some of these issues in vineflower, which I will be prioritising over leaf short-term because thats kind of more important than leaf
The versioning system I made for the game to keep it standardised following semver was MAJOR.MINOR.PATCH-BRANCH.REVISION but now this is going to need to change as the game no longer uses SVN revision numbers and it seems they have moved to git instead, favouring the sha commit hash, so I will keep the old format still as legacy but the new format will be MAJOR.MINOR.PATCH-BRANCH+BUILD where build is the short version of the commit hash for that game build (seen in the text in the bottom right) and revision will still exist as an optional but very rare case where they decide to bring it back for whatever reason purely because I know its something they would do lol
I am certain other peopel will discover much more about this when they come to, but i will sleep now so if anyone has any relevant information that i might need to know for leaf please let me know here!
decompiles fine for me, issue may be he on your end
no file in zombie fails to decompile for me
hmm what i did was download the latest zomboid decompiler release and run it against the extracted jar file
its possible this isn't an issue with the latest vineflower, or maybe its an issue with decompiling everything not just the zombie folder
the last release is a vineflower version behind what i was using yeah
i'm just writing up the patch notes now
by the way @floral sluice , LocalVariableTable is included in the new class files so mappings are not really necessary at all anymore
vineflower won't use these by default but it's very easy to get it to, i can point you to where it happens in zomboid decompiler if you need
hey @full mountain, so i was unable to decompile the newest version vith ZomboidDecopiler. I got this:
projectzomboid.jar not found, aborting```
am i missing something?
are you on linux?
nah, windows
oh, yeah of course not, that's not a linux filepath ๐
have mac and noticed there is no zombie dir but thats another issue
is that where your game is installed? and projectzomboid.jar is there?
that is where the game is but the file is not there
is there a projectzomboid.jar somewhere in there? all the game code should've been moved into that jar in 42.13
if you still have a ProjectZomboid/zombie folder your game might not be updated?
(possibly it's the wrong installation and you have b42 somewhere else?)
just making sure, b42.13 shuld be in the beta branch right?
yeah, should be on unstable
oh, im still on b42.12.3 somehow
ah yeah, unfortunately new version of zomboid decompiler aren't compatible with earlier versions of the game at all due to the magnitude of the changes, i'll look into giving a better error message for that
yes got it, i now have to figure out why i dont see the update option
oh now i understand why on mac it didnt work, i was using the old version of decompiler
and here the situation is opposite
anyway thanks for help
glad to help!
for future reference, worked on mac, but had to point decompiler to the path: ./ZomboidDecompiler ~/Library/Application\ Support/Steam/steamapps/common/ProjectZomboid/Project\ Zomboid.app/Contents/Java
yeah i don't think it has autodetection for mac paths, i didn't know where it would install them to
do you know if all (or most) macs would have it installed to that path?
yes I am almost certain of that
ooooo
I think minecraft might also include these since they went away from obfuscation too, so maybe that's why they're also doing it
very helpful
are constants still inlined as well if you know?
i didn't check, i'd be shocked if not
Imagine if they just s/final//
mod ALL THE CONSTANTS!
i know for certain that the loom wont work without changes, but its possible the loader still works after this update lol
shouldn't stop it from bootstrapping etc
its kinda ironic
long time no see! i've come back to this chat because of ZombieBuddy coming to life so quickly. I didn't expect it to develop that fast!
anyhow, im here to have a serious discussion about if leaf is worth actually pursuing in parallel of zombiebuddy. I don't want to feel like a "competitor", and would like to not contribute to the standards problem (see https://imgs.xkcd.com/comics/standards.png).
I have had this discussion in my mind many times over, so im looking for external input here. I figure that there's only a point in continuing to work on leaf if it offers something worthwhile over zombiebuddy. I'll list some that I can think of/remember, but im asking if anyone has something to add. any discussion is good, even if critical of leaf; for example, it's completely fair to judge how long it's taken me to work on leaf, many such things have been blockers for that (annoyingly so).
some things I can think of: (separate message below due to character restrictions)
upstream parity with fabric
POSITIVES
- most likely, improvements and maintenance changes that are compatible can easily be brought to leaf without much hassle once this is set up
- developers from fabric/minecraft can basically have a 1:1 developer experience
- documentation from Fabric (excluding Minecraft specific codebase documentation) can be reused
CONCERNS - fabric has been around for a long long time, and there's a lot of not-really-legacy-but-old code. this doesn't affect performance but is still something to note
no auto updater (disregarding the installer)
POSITIVES
- user is in full control of versioning, can roll back if a version is buggy/malicious/etc
CONCERNS - users may want a seamless experience(?) but the installer is simple (select version, "install", add launch option), so im very conflicted on this
install method
in this case, I really mean the way leaf installs itself and manages dependencies and such. the current method is by using game launcher/boostrapper configs (the configs read by ProjectZomboid64.exe and the like)
POSITIVES
- full control over loaded JREs, JVM options, class path, and everything else before the JVM is even created. doing this without cluttering launch options
CONCERNS - requires adding/changing a launch option in Steam/game shortcut/etc also specifying the game version of the loader but this is automatically copied to the clipboard using the installer, and also could be changed(?). example
blah-41.78.16-1.2.3.json
patching style
POSITIVES
- I don't think zombiebuddy has as much control for patching as mixins allow (though I will accept being wrong as I need to look into it more)
- patching is done as early as possible, whereas zombiebuddy/similar usually tend to patch later. this has it's own benefits/concerns attached. (I believe zombiebuddy is adding a method to have early patches as well if im not mistaken)
CONCERNS - it has a slightly higher learning curve for creating class/method/field patches
toolchain size
POSITIVES
- different QOL tools such as the loom development environment for super easy java mod developing, and filament+yarn for remapping if needed in the future (very powerful code remapping essentially)
CONCERNS - it takes more to maintain (but considering upstream, not as much. the way I've modified yarn though means manual cherry picking/patch merging. thankfully filament+yarn doesn't change that much and is for the most part stationary)
and of course probably by far the biggest two issues with leaf are literally my fault, those being development time and the fact that there are currently no proof of concept mods published to the workshop (because leaf isn't production ready yet which I care VERY MUCH about๐ญ). though im planning something probably considered insane for the first official leaf mod (excluding the API) if or when I do finally publish a prod-ready leaf
for context and a TL;DR instead of reading all the above:
im inviting literally anyone with any critiques about leaf to let me know. you hate me (I hope not! :c) and or leaf, tell me about it (seriously)
the reason I've wrote all of that is because I am already working on some POC for a large-ish java project for PZ, and im really having a mental battle for lack of better words for choosing which platform to use. I'm kind of scared of abandoning leaf because I can always trust myself to maintain something, but I can never know for sure if something else is going to be maintained (if you know what im trying to say!)
upstream parity with fabric
I wouldn't say it's 1:1. Sure the way the system works it's 1:1, but really the API is absolutely not the same at the end of the day. Also from my understanding what Zombie Buddy provides is similar ? Like it allows you to hook to methods and shit, which from what I remember of Leaf is basically the same ?
no auto updater (disregarding the installer)
Ok but an auto updater doesn't stop you from using old versions. It should be a button that says a new version is available and that's about it, the user clicks it or not who cares and they can still chose what version they want to use (no point having a forced update for such an app like Steam has for example)
install method
Don't see much difference with Zombie Buddy. At the end of the day, an installer will do some things weird and other things right, so idk, tho I'm convinced it's definitely possible to just have a one click installer
toolchain size
I have expressed in the patch that all of this is just confusing. You throw words of tools here and there but this has never been clear and by having a million things like that you dilute the important information between a million other random advanced information. Modding is easy in PZ, it's not hard to get a hold of and Java modding shouldn't be that much harder
Like I get this is a project you care about, tbh I like the project too, but the development has been too random around it to be an actual proper tool for modders. Continue working on it if you enjoy it, but to me you should let go of it, or bring your knowledge to Zombie Buddy which has proven itself now
its definitely not 1:1, I didnt mean it to come off that way exactly. but it is (for the developer anyway) pretty much 1:1 from setup to mixins/access wideners (patching). I say 'excluding PZ-specific things' because obviously you aren't going to use minecraft classes in PZ. in this regard, downloading and setting up the example mod is pretty much exactly 1:1 with fabric's example mod. writing patches using mixins and access wideners is also 1:1. I made sure not to change any of those for parity. I'm also going back on some (rather ambitious) changes I made early on because they broke some backwards compatibility.
true. I guess if you had a way to select 'no', and then manually install the other versions too, it would work the same.
yes an installer is just an installer in that way. since zombiebuddy uses a dll it probably can change the jvm arguments too. though thats a very niche feature.
im gonna assume "patch" is a typo here. I've mentioned this it feels like a thousand times before already but i'll say it here again, as a regular user, you're not supposed to know what filament/yarn/etc actually is. this is just internal portions of the toolchain. as a developer, you only need to know what loom is really (which is the development 'environment' for making mods), and that only requires a brief entry-level position of knowledge.
also I've done a little more reading about zombiebuddy, and it doesn't even support extensive patches akin to Mixin or other. from what I've read on it's docs (which is still not as much as I'd like), it allows for method patching (including parameters and return values) at the start and end of methods only.
for context, mixin allows you to patch to an insane level, such as replacing only a specific argument in a specific function call inside of a class method. or wrapping an existing function call in a class method with your own function
this is what's confusing to me. you can't say it's the be-all-end-all if it lacks things something else doesn't (in this case, thats the reason why im still working on leaf/fabric, because it can give people things that everything so far doesn't have)
Ok sorry this is going to sound rough and kind of like a bomb but, sure Zombie Buddy doesn't have all these nice things, but it understood one thing that I have told you many times about Leaf: the way you manage mods should be unchanged, which you can't say that about Leaf since, unless that was changed and I'm mistaken, will load mods from every installed workshop items
The Steam Workshop should not be a mod manager
The in-game mod manager should activate each individual Java mods
also btw if it looks like im taking a defensive position here, it's because I kind of am. this discussion is meant to be serious and a push-and-pull of sorts to bring up certain points etc
that is true, and it's possible to do, but I think it would require a game restart to do. does zombiebuddy require restarting the game after enabling java mods in the in-game mod loader?
ok if thats the only major concern then thats not much of a concern for me personally
As long as you don't surprise close the game and make it clear to users
There's many reasons why Leaf was never used, and that's definitely one
You consider it to not be important, but if your Java mod loader is not easy to use for users, then they won't use it
^ I meant not much of a concern to implement ,as in an issue
not that I wouldnt add it ๐
Ah
I agree surprise loading java mods is an absolute disaster waiting to happen
Zombie Buddy also has a whole system to sign previously loaded files
So it asks the user to confirm loading specific mod files, and it'll sign those files as already being loaded in the past so they don't need to be accepted again, unless those files got changed in a mod update
yeah that is very good for zb
having a whitelist approach is definitely a good idea (but not so exclusive like that one other project a few years ago that required a digital certificate for a java mod)
Loading a java plugin will always carry this sort of threat with it. As long as the code is protected that initiates the loading and it only fires when it should then asking or requesting loading or mapping permitted API to plugins as they're called should work fine.
A plugin shouldn't load another.
Reflection is also an issue.
You won't have a 100% guarenteed sandbox in this sort of approach so being honest and forcing some conformity or standard on telling the user exactly what the plugin accesses is really the only things you can do.
yeah that's an annoying part- you can load mods inside of mods
I could always disable that feature though, or just have it notify the user for the inner mods as well. im not sure when you would use such a feature, even in minecraft
but you bring a good point which im probably going to look into. that being: can a mod use reflection to go up the tree and load other stuff. but I mean what does it matter when once a Java mod is loaded, they can literally execute anything they want?
I just thought, if I do ever add source code mods like Albion suggested (which is a cool idea), I wouldn't be able to do jar signing like I imagined I could do
I actually solved that inner plugin problem by creating modules inside of Jar plugins where you could house multiple plugins essentially under one jar.
I worked for Minecraft servers. The amount of work done to make sure that all plugins in a group of stuff were the right ones was nuts.
Also config management.
So having one jar that housed all sub-plugins as modules in its own folder all provided in one bundle really fixed a lot of that problem.
Another weird thing I did with my server framework was make the core functionality its own plugin bundle. It loaded itself as a plugin.
For organizing that core plugin, this made it a lot easier to manage.
I'd get past that security issue by telling the users up-front that what they're doing isn't safety-proof.
You will turn Leaf into an orphan project if you decide to go down that road. PZ is already security-prone so stacking an extra dimension of security to manage something as risky as 3rd party java code is.. well yeah not useful time spent.
Apart from Fabric's mixin culture, I have a living example of my system for loading and managing plugins, events and commands on my repository from like 10 years ago.
this is true, I dont intend on making it so "safe" that only certificates signed by myself are valid lol but it still needs to have some sort of precautions
I don't think the signing thing matters as a feature though because a malicious person could just put it in their bio and continue as normal, users most likely would run it anyawy
so the only thing i can see actually having benefit is just the warnings of "hey xyz mod is being loaded for the first time"
and then its a whole separate thing of well how do I let the user clear that loading history, like where to put it
Basically don't sell or oversell protection from malicious plugins.
The community will organically fight for authentic and non-malicious projects.
yeah thats a thing im also worried about
because i feel like if i add all these things and it gives a false sense of security, then people will blame me for the malware
I am kind of preferring for quality over quantity for leaf mods though (not that i get to pick what gets made, but i can sort of pick what gets verified/used by the community)
You'd know that quality can only be controlled to a certain amount when handling plugins.
:)
true, I generally mean like from an API standpoint
I spent 3 years and around 90K lines of code and ended up being the only person to write plugins for my framework.
for example, i can advocate for putting an NPC mod into the API and then people can just create and manage NPCs using that verified API, over having 5 different NPC mods from other people
i think this way moreso because its easier for me personally to verify the code in the API ( through myself and pull requests) over 5 mods from independent people
yeah i dont expect people to adopt leaf initially too. im just gonna make mods and if people want to use them they can type situation
cant get your hopes up too much
also this isn't leaf specific but im going away from the branch structure ive used for years because it gives the wrong idea and not much benefit. i've used the develop on dev and merge PRs into it, and then when a version is ready push to main. i think this is no longer a good idea for me because 1. im just merging into main every time and nothing else, making a separate branch redundant, and also bc 2. people probably think the projects are dead/unmaintained because main hasnt had a commit in a while, even though I could for example work on dev every day
so now im going to just be doing develop on main, use tags (which are essentially just branches anyway) for per-version releases like normal, and obviously still have feature and fix branches where necessary
anyway, thanks for coming to my ted talk

You can use Jira lol
I Jira'd Sickle to retain my sanity.
a random note to put here but im not copying game files over to a cache folder anymore (speed up loom for people with old hard drive! you know who you are!) because I realised that the idea of being able to work on java mods with multiple game versions at once (in the IDE) is silly and theres just no need for it
to be honest, idk what I was thinking when i decided that was the right decision. these are the perks of trying to do something multiple times. you learn each time lol
TIL that for PZ, they have a launcher (wrapper executable to create a JVM using the config ProjectZomboidXX.json) for literally every platform except macos ๐ฅฒ. well the macos one exists, but it doesn't seem to have a ProjectZomboid64.json to accompany it by default. im so lost
that ^ is going to essentially make macos unusable until I can figure out a better way to load it or something. turns out they just hardcode the main class and classpath ๐