#Leaf (forked from FabricMC/fabric)
1 messages ยท Page 1 of 1 (latest)
Pinned messages from #1352893749973483531 below
Getting Started
Follow the README in the example template and change the template to whatever you desire. https://github.com/aoqia194/leaf-example-mod
Along with this, I will leave a list of repos I created/forked for knowledge if it is needed in the future idk
https://github.com/aoqia194/leaf/ - Created this to store manifests for Zomboid. Stores file hashes, launch options, game version release time, other metadata for every version. Requires some small maintenance when a version is released, which is more tedious for unstable releases than main releases. Most of the work is done by editing game_versions.json and the rest is auto generated. Used by every other leaf tool.
https://github.com/aoqia194/leaf-loom - Forked this from fabric, it does basically the same purpose as fabric's one except modified for zomboid. Used in development only.
https://github.com/aoqia194/leaf-yarn - Forked/Created this from fabric, serves similar purpose to fabric's yarn with the exception that it is not used for deobfuscation of classes, fields, and functions because Zomboid is not obfuscated. Used in development only.
https://github.com/aoqia194/leaf-filament - Small utility used by Yarn, branched to a different repository for more easy maintenance
https://github.com/aoqia194/leaf-loader - Forked from fabric, serves similar purpose to fabric's loader being that it loads mods, transforms mixin, basically does everything needed for the mods to be in the actual game. Used in production.
https://github.com/aoqia194/leaf-installer - Forked from fabric, serves similar purpose to fabric's installer, it installs the loader and dependencies into the game's install folder. Used in production only.
https://github.com/aoqia194/leaf-api - A small API for leaf to improve the ease of modding for the game. Takes away some of the pain and all that.
oh and something everyone should install when working with mixins is the "Minecraft Development" intellij plugin, which allows breakpoints in mixins and autocompletion for mixins instead of having to type the bytecode representation eg Lzombie/iso/IsoPuddles;getInstance()Lzombie/iso/IsoPuddles; for example
even though it says minecraft development and was originally made for fabric, it works flawlessly with leaf too
pzwiki page: https://pzwiki.net/wiki/Leaf
Pinned messages END
loom 0.4.0 published, should be replicated in 10 mins or so
I manually merged some upstream features from fabric-loom/1.10
Vineflower 1.11.1 is now in use, which should fix a decent amount of bugs in the decompiler output!
@valid nova Is there a reason why I don't have pin permissions in my own thread? In any case, could you please pin the 3 messages at the top of the thread?
Bcs they don't give pin permissions I guess
@rugged fog is that something that could be added ?
I don't think discord differentiates between the author and not.
So anyone could ping anyone's message in the mod-projects channel. ๐
Tho individual permissions for users can be given in specific channels I think ?
Not sure if that can be done automatically using atlas
I figured out a way so that I can run nearly all my projects' actions through github runners instead of my local server that I dont want to run bc electricity bill already like 2k
upside: I can run builds and stuff without my local runner powered on!
downside: I can't run tests for projects requiring game files!
Are tests require to run the game? Maybe there is some 'headless' option to run the game JAR or something. I think there might be a way to get game files from the terminal using some sort of Steam API?
Tests are not required to run the game. Most tests for loom and loader are just simple unit tests to ensure that the project works as intended
There is no possible way to run the tests in any GitHub runners as the runners require an installation of the game. In theory, you could make the runner download the game from Steam, but the cache gets deleted after 30 days iirc or very frequently, so build times would be unnecessarily high.
I could use local runners which is what I've been using for a while now, but me running a second computer a lot is quite annoying, and this means I have to manually build / dry release, which is tedious.
I've had to disable the tests for loom and loader completely anyway since there are lots of them and I never got time to rewrite them all (some 400 tests combined), so this was the best decision I think.
Out of curiosity, what kinds of tests?
For example, loader has tests for things like did it load a mod correctly. Making sure that loading a mod not built with leaf will fail, testing entrypoint bytecode patches, etc
Ok it seems that there no longer exists the metric boatload of tests that I previously had to nuke, I can't find them ๐
Ah, I thought you were testing strictly mods
Oh and the loader also has an automatic client test that makes sure the game boots and stuff but this still requires game files and all that
But I didn't realize I was in this post ๐
lol
I did want to write a tests library for lua mods, but I figured maybe theres no point because its super easy to do testing in lua
like even just an assert(x) works for a test
Yeah, testing if the Lua is valid isn't helpful and you can't really run aspects of the game I imagine.
Although the game does have some tests for actions and such
Just an FYI for anyone curious, my leaf GitHub repositories (except leaf itself that hosts the manifests) will be 'down'/not usable as expected as I am unforking the repositories, this involves me having to create new repositories temporarily.
The reasons why I am required to do this are mostly due to the way GitHub itself implements forks, as they are not fully the same as normal repositories.
Repositories should expect to return to normal within an hour.
Ok apparently it went like 500000% smoother than I thought it would, everything's normal and back up again.
github has a few related to forks, like not being able to track certain project metrics because it's a fork
github considers a fork to be a repository that's (in their eyes) sole purpose is to contribute upstream (to the parent repository that was forked), but in my case I am not contributing to fabric as fabric is for minecraft and leaf is completely separate.
Changes that come from upstream like feature upgrades they do for loom I still need to merge myself, but I've always needed to manually fix merge conflicts and all that myself, so this changes nothing for me.
That sounds stupid
Bcs imo forks are usually for your own stuff lol
not sure why they do it, but it's a business at the end of the day
well most times you fork something to improve it and then the hope is that you contribute your fixes and improvements back to the original upstream repository
example: any pull request
PSA @verbal panther if you know anyone who is versed well with git please let me know i need to talk to someone about my particularly shit relationship with git
One of the main reasons why it takes so so so so fucking long for me to merge loom upstream changes (ones that fabric does, they like to change loom every week it seems) is that I have to do it completely manual LINE BY LINE (it sucks so fucking bad).
EDIT: just found out that git has rename detection by default, and for some reason mine didnt work or my history is just garbage, yippee
Is it possible to make mods with this right now in terms of testing
Just to see what the solution looks like rn
Basically yes. For the loader, you do have to use 0.0.3 which is a fairly older version purely because the newest version had a bug or three I think.
Though the new version is literally pushed to main, for some reason gradle is giving me a hard time releasing it. I am getting "Username must not be null" for gradle's http client that I don't even touch and never have so I don't know why it's preventing me from releasing.
I've honestly put it off for a while just because of that really vague error.
I also mean to update the example mod template too
See:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
> Could not resolve org.jetbrains:annotations:23.0.0.
Required by:
root project :
> Could not resolve org.jetbrains:annotations:23.0.0.
> Could not get resource 'https://maven.fabricmc.net/org/jetbrains/annotations/23.0.0/annotations-23.0.0.pom'.
> Username must not be null!
> Could not resolve org.jetbrains:annotations:23.0.0.
> Could not get resource 'https://repo.maven.apache.org/maven2/org/jetbrains/annotations/23.0.0/annotations-23.0.0.pom'.
> Username must not be null!
> Could not resolve com.google.guava:guava:21.0.
Required by:
root project : > net.fabricmc:sponge-mixin:0.15.5+mixin.0.8.7
> Could not resolve com.google.guava:guava:21.0.
> Could not get resource 'https://maven.fabricmc.net/com/google/guava/guava/21.0/guava-21.0.pom'.
> Username must not be null!
> Could not resolve com.google.guava:guava:21.0.
> Could not get resource 'https://repo.maven.apache.org/maven2/com/google/guava/guava/21.0/guava-21.0.pom'.
> Username must not be null!
> Could not resolve com.google.code.gson:gson:2.2.4.
Required by:
root project : > net.fabricmc:sponge-mixin:0.15.5+mixin.0.8.7
> Could not resolve com.google.code.gson:gson:2.2.4.
> Could not get resource 'https://maven.fabricmc.net/com/google/code/gson/gson/2.2.4/gson-2.2.4.pom'.
> Username must not be null!
> Could not resolve com.google.code.gson:gson:2.2.4.
> Could not get resource 'https://repo.maven.apache.org/maven2/com/google/code/gson/gson/2.2.4/gson-2.2.4.pom'.
> Username must not be null!
What was the significance of DLeaf to PLeaf?
Looks to me you changed stuff and, as shown, username and password are saved as project-side secrets
this is why Gradle is stinky poo poo lol
"let's use grade!"
*still has to use Maven Repos / Logic that can break at the drop of a hat
What a second @floral sluice you used to build these locally didn't you?
Maven username and password is only used for releasing. Gradle is failing with the "Username must not be null!" when resolving artifacts from external public maven repositories like apache's official one.
Second to last commit before build errors
-P means gradle property, -D means jvm property
I used the wrong one, and as such, the build did not work. That is the reason for the switch
My point is I think you still need the properties, and when you used to build local, it would of took em from your intelij version of Maven.
If it's now on some Ubuntu container or something, it don't have access to your properties no?
when I was releasing it on my local runner machine, it acts the same way as a github hosted runner
But with access to your local info... like your username and password...
username and password for maven is not relevant here
it is gradle trying to resolve artifacts for download because they are dependencies
both maven repositories listed in the project are public and you can even download artifacts yourself just fine including all the hashes too
I did find a user who posted an issue for Gradle about this, but I don't know if it's the same. https://github.com/gradle/gradle/issues/6369
Expected Behavior Gradle notifies the developer that Maven credentials are wrong, e.g. "Wrong Maven credentials (null value provided). Current Behavior Gradle returns a very confusing error me...
Yes... but you have specified those properties in your build tool.
It is cancelling because it is resolving all your properties before grabbing the dependencies?
What's weird is that I didn't change anything about how my maven stuff works
It doesn't need the username... its you've defined it and it can't find it
all the credentials are is github repository secrets and has stayed the same since I created the repositories. I don't know why it would suddenly not work
What you did was move it to its own Ubuntu container.
When ran locally it is using your in-built maven , along with its properties
also I get this error locally when just building (not even publishing or anything maven related)
When it was on my local runner, it was fresh runner and worked fine
I dont get what you're saying
I wasn't using my dev pc with my .m2 and gradle caches to build and release, it was a whole separate computer
which essentially was just a github runner anyway
Tell you what, I'll try building it local when I'm home
also we can exclude any runner-related things as this error can occur doing a local build
It's possible that there's a bug in a task I dependsOn for build and processResources, so I will check that
that's the only thing I extensively changed, so I dont know what else it could be
I know you showed a snippet, but where is the full logs for the failed action?
it should be in this workflow job https://github.com/aoqia194/leaf-loader/actions/runs/15610822931/job/43971138626
though I dont know if it will let you access the logs if you are not a repository owner
if that is the case, I can share them manually here
Didn't get around to looking at this yet but it's on my radar for the morning.
If I do nothing else to help this project, I'll be damn sure to help you fix dumb ass build issues haha
yeah the biggest thing that annoys me is loom doesn't support gradle build cache
I'm pretty sure its a limitation around how loom is built, but if it isn't then maybe one day I'll fix it
Since gradle is being such a bitch and IDEA sucks with support for groovy script (its inconsistent as all hell) I will slowly migrate all .gradle files to .gradle.kts to use the kotlin DSL instead
Might take some time, but will hopefully help other things (including the current issue im having too)
Noooooooo
Use our lord and saviour maven. You know in your heart it is the one true solution xD
@floral sluice humour me (like legit just humour it) and put your username and password into the maven repositiories section of build.gradle at line 407
I.e.
repositories {
maven {
url = layout.buildDirectory.dir('staging-deploy')
credentials {
username = System.getenv("MAVEN_USERNAME")
password = System.getenv("MAVEN_PASSWORD")
}
}
}
Like even if every bone in your body is telling you it wont work
Omg @floral sluice I think that is actually it mate.
I went back through the commit history and checke the git blame. you replaced the original maven code with your own url, but accidentally deleted the credentials in the process. it was your commit on 3/15/2025
I think gradles strict for some wonky ass reason
ooo yes I did do that
The credentials being deleted wasnt an accident though, that is a local maven repository, so it shouldnt need any credentials
you see how the url isnt on the web, it's a folder in the build/
also if you look at the mavenCentral block is where the actual credentials go
but I will test it anyway like you said
Yeah, when in doubt
just in the middle of converting it to kotlin dsl, it will take a bit
My advice? shelve it in another branch and change this one tiny thing in master first
and tbh... if you are doing a full dsl rewrite, that should 100% go in a new branch just incase this fucks it up royally
I would normally do that, but I really want to just get it out the door already, im kinda cutting corners in that way
ill just revert it if it fucks up, but once its released it's released. in that case I just release a new version with whatever reverted
Right can I be your sanity check mate...
This is sodding build pipeline. If there was ever a place to NOT cut corners, its here mate
This sets a bad prescedent for the project if you stay the course.
Bare in mind this is merely advice, not judgement nor a demand.
I know i know, but if you look at the state of the original fabric stuff, it's a fucking mess of every kind
true, though I wanted to just get it working and out the door
improvements can come later, like intermediary mapping
So did the fabric devs.
Slow down and make it solid.
Remember a modding api project doesnt live or die on when its released. it lives or dies on whether its nice to contribute to
Iv'e already spent nearly a year on it and 3 or so rewrites, and i've still got stuff to do (including POCs and replacing the game's lua as a mod for leaf)
I can tell you right now that it is not very nice to contribute to, I never expected anyone to contribute anything to this
That is unfortunate
most of the contributions for loom will come from upstream
and since they are working on it constantly, I dont have a problem with no other people working on loom apart from myself
loader may need occaisonal changes (for example b43 and stuff) but for the most part, the loader rarely gets updated anymore. The code is already majorly "complete"
mappings is probably the only thing I will really need help from contributors (and its super easy to add mappings thankfully), but these arent required to run the game
a lot of the maintenance is just merging upstream for loom which I have held off and only merged necessary stuff for now, because otherwise it would make things way more complex to manage
after loom is working without issue and people test it just fine, then I will consider upgrading loom internally to 1.10+ (right now it's on 1.9 with some 1.10 commits)
After looking into it, i've decided "fuck it, I'm making it from scratch"
Project ByteMark is a-go haha
moment I realised how easy the loader is (I got it posting to the logs within 10 minutes haha) and with Mixin being a unievrsal tool, I am gonna literally scratch the entirety of fabric off and start from scratch xD
Not publicly ofc, but as a personal project fueled by spite at TIS xD
I'd suggest making a #1125644084757938196 thread then
Bcs it won't be adapted here
Im gonna keep it private and, if I make any headway to the point of needing contributors, i'd wack it up as a mod project haha
You do yours
All I will say is good luck
one of the biggest reasons why I didn't write one myself was 1 because it would take much longer and 2 i would essentially be writing the same systems as fabric anyway (since I wanted all of the epic mapping stuff too and things like intermediary, TR, loom)
you should probably think how you want to go about it, like do you want do just do what fabric does, or do you want do go more like what Forge does for MC which is recompiling the class files using patches
Also also, you may want to check out Jab's python mod loader if its worth anything, though I don't have the direct link, only the link to his github: https://github.com/asledgehammer
and there's also PZ storm you could also take inspiration from, though its old and basically was an attempt at semi cloning fabric but also reimplemented half of it which I don't understand why
Aye I wish you luck getting Leaf finished too ๐
And honestly? I wanna do it from scratch as i find this fun haha
E.g: Moment i got my code executing before the PZ code was really cool.
I know it sounds silly for such a small thing. But the buzz of "Oh shit yeah! I did a thing!" haha
Nah that's fair
Also wanna see if i can make a launcher for it aswell in JavaFX
@floral sluice when I get to that bit, i'd be honored to have your help
I will be focused on maintaining leaf for the foreseeable future until I quit everything zomboid related or when I move onto other projects
Ah fair enough mate
@floral sluice I looked at your yarn mapping for zombie inventory.
Is PZ not obsfucated, the mapping , unless I'm blind, doesn't have obafucated names
Like say the fabric yarn mapping does
PZ is in fact not obfuscated, that's why the mappings aren't needed
in leaf, they are purely for renaming of decompiled code
and also constants are inlined by the java compiler, so it can also uninline them
Brilliant
I didn't quite understand what you mean in this case
names of function parameters are not kept when java compiles the code
nor are variable names etc
Though there is no support for renaming local variables for yarn, I wanted to see about adding that eventually
So what does this mean in terms of using mixin?
Nothing. mixin works on jvm bytecode, not decompiled Java code
So the mappings are there for what step of the process specifically?
I.e. why does the code need renaming at all?
Sorry if I'm being dense here haha
.
only for visual purposes in leaf
if the game was obfuscated like minecraft, we would need them, but its not needed in pz
I don't get what you mean by decompiling code? ๐
Unless I've missed a step, I have access to every single raw java class in the zombie folder ๐ ๐ญ
I think what she means is the renaming of variables ?
But to what end?
I feel like I've skipped a few pages of the book here haha
For readability ?
Readability where is what im asking?
I ask as, full context here, I have a folder with all the classes, no obsfucation, clear names and variables. Out of the box ๐
Show me an example of a small function with atleast one function parameter
Also mappings were originally intended for obfuscated code only, so that classes a, aa, aaa, ab, abc etc turn into proper names for developers to understand.
I already stated there is no obfuscation in the game. Java compiler will automatically remove all variable names from the code. These get replaced by the decompiler with dummies like var0, var1 (or if you have the named variables, they will turn into string1 integer1 etc)
I highly doubt your variable names are as clean as what we get with the decompiler Albion's set up for PZ decompile
โ โ โ โ Main article: Decompiling game code
Zomboid Decompiler is a tool specifically designed to decompile Project Zomboid's code. It can be used to decompile both Build 41 and Build 42 game code. It is currently the best available option as it will take into account the JavaDocs of the game and will format the code in a way that is easier to read.
You will need:
โข Java 17 or above.
โข The latest release of the tool.
To decompile the game code, extra the zip, navigate to the bin folder. To launch the decompiler, run ZomboidDecompiler.bat on Windows or ZomboidDecompiler on non-Windows OS. It will automatically find your game files and have the game installed on Steam and creโฆ
albions zomboid decompiler tool uses the javadocs from previous game versions when they used to have param names and merges them into 42 so that some param names exist
so yeah, by default there should literally be nothing
I'll show you when I'm home mate.
This might be a Linux thing tbh.
As they use a custom script to even make zomboid run properly on linux
If it is? This could actually be brill news
Wdym they use a custom script to make PZ run on Linux ?
They actually have a bash script to set everything up instead of a bog standard exe
Uh
They are talking about the .sh scripts (also have them .bat for windows) which are not special and just launch the java exe itself
I run PZ without any of that on Linux
Ah sweet
yes the bootstrapper works on Linux just fine, they have win and linux versions
So for record, what does say one of the clases in your zombie directory look like raw?
package zombie.audio;
import fmod.fmod.FMODFootstep;
import fmod.fmod.FMODVoice;
public abstract class BaseSoundBank {
public static BaseSoundBank instance;
public abstract void addVoice(String var1, String var2, float var3);
public abstract void addFootstep(String var1, String var2, String var3, String var4, String var5);
public abstract FMODVoice getVoice(String var1);
public abstract FMODFootstep getFootstep(String var1);
}
It's just variable names that change
Probably not a good example of the script adding names to variables haha
I said it doesn't do that yet, I was planning on adding that after the loader update I am working on
It only lets people rename classes, functions and function parameters (at least these are the only ones I've taken note of). The first two are meant mainly for obfuscated code where the names are obfuscated as well
for context, there is literally 0 way to get parameter and variable names back from compiled java code unless the developer passes javac flags (that even then im not sure to what extent it keeps the names). At the end of the day, like ASM instructions, java bytecode itself has no way for storing variable names
I meant regarding Albion's decompiler
they asked for raw classes
I probably should've showed the bytecode or something instead, but the decompiled output gets the point across hopefully easier
and also, albion's tool doesn't change variable names either
The decompiled output...
Just as a pure sanity check, you all have a directory called "zombie" that contains all the .class files right?
Yea
It does tho
It renames like input variables
I might of been blind when I last looked but I swore the variable names were preserved in those .class es.
Will check when I'm home haha
those are function parameters, no decompiler does variable renaming from javadocs (in fact, javadocs dont even store variable names)
function test(param1, param2, param3)
local variable1, variable2, variable3
end
``` That is the difference in lua terms
Yea well that's what I meant
Function parameters
Ah turns out I was blind, I understand now.
Now time to try and get my sodding mixins to hook haha
Managed to get a custom launcher that has the agent run before the game, but it doesn't seem to be grabbing the config properly.
Lot of fun though ^_^
@floral sluice how do you set the client game file location, atm loom is having a bitch fit because I am on linux haha
or rather i am on linux and project zomboid lives in a different source folder
to what it expects
I found it in your code.
dev.aoqia.leaf.loom.util.Constants
public static Path getSteamInstallPath() {
if (OperatingSystem.current() == OperatingSystem.MAC_OS) {
return Path.of(System.getProperty("user.home"), "Library/Application Support/Steam");
} else if (OperatingSystem.current() == OperatingSystem.LINUX) {
return Path.of(System.getProperty("user.home"), ".local/share/Steam");
}
return Path.of("C:\\Program Files (x86)\\Steam");
}
This, imho, is nowhere near as flexible as it needs to be as, to be blunt, linux directories are cray cray banaynays
BHAHAHAHAHA
IT WORKS!
IT WORKS!
Yeah sod bytemark, Im gonna brave gradle and help you with this.
/*
* Copyright 2025 aoqia, FabricMC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package dev.aoqia.leaf.zomboid.test.mixin;
import com.llamalad7.mixinextras.injector.ModifyExpressionValue;
import org.spongepowered.asm.mixin.Mixin;
import org.spongepowered.asm.mixin.injection.At;
import org.spongepowered.asm.mixin.injection.Inject;
import org.spongepowered.asm.mixin.injection.callback.CallbackInfo;
import org.spongepowered.asm.mixin.injection.callback.CallbackInfoReturnable;
import zombie.GameWindow;
import zombie.characters.IsoGameCharacter;
import zombie.characters.IsoZombie;
import zombie.core.Core;
import zombie.inventory.InventoryItem;
import zombie.inventory.types.HandWeapon;
import zombie.iso.IsoPuddles;
import static dev.aoqia.leaf.zomboid.test.TestEntrypoint.LOGGER;
@Mixin(IsoZombie.class)
public class CoreMixin {
@Inject(method = "Hit", at = @At("HEAD"))
private void onHitHead(HandWeapon handWeapon, IsoGameCharacter isoGameCharacter, float f, boolean bl, float g, boolean bl2, CallbackInfoReturnable<Float> cir) {
handWeapon.setMinDamage(1000);
}
}
The fact this took 5 minutes.
My god โค๏ธ
What's that
That is a working mod.
That is a mod that, on hitting a zombie, it sets the weapon's min damange to 1000
and it worked
like
just worked xD
What is the class for context menu java side if you know
I must testt something at once xD
To one shot zombies ?
It was just a very cheap and cheerful test
To see if it worked
Context menu java side ?
That's not a thing
What class handles context menus
Context menu is Lua side
ISContextMenu is a subclass of ISPanel used to instanciate a context menu UI allowing players to chose available options for one or more objects, usually used when right clicking in the game. This article will detail how to use this object in the Lua (API) to add your own options to existing context menu objects, modify and customize them and more.
Usually, you can easily assume every UI is Lua sided
Why no ?
The entire point of me wanting to do this was to get the hell away from lua
in its entirety
They are extremely flexible that way and anyone can modify any UI elements
Fucking thank god UI elements are Lua sided
You are trying to run away from the Lua but it's not because it's not great that you don't have major things handled Lua side
Every timed actions are Lua sided (there's some java bits of course)
Every UI (almost) are Lua sided
What is modal dialog?
No idea what's that
Yeah I'm not too sure how to solve this
I only did the most common dir I know of, though I probability need some wizard to tell me all the dirs it can be
in any case, you can set it manually if required
Where and how? It requires hard changing the loader code. maybe a config option thats optionka.
optional?
yeah this is why we said it's kinda iffy to do
you basically have to write the systems yourself in Java which I really don't think is as good as just using some lua
Oh, I must've only added that for the game path
since I made the steam path final, I will change this
So they legit used lua to make some weird frankensteins monster ui elements?
I just... WHY
xD
/*
* Copyright 2025 aoqia, FabricMC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package dev.aoqia.leaf.zomboid.test.mixin;
import com.llamalad7.mixinextras.injector.ModifyExpressionValue;
import org.spongepowered.asm.mixin.Mixin;
import org.spongepowered.asm.mixin.injection.At;
import org.spongepowered.asm.mixin.injection.Inject;
import org.spongepowered.asm.mixin.injection.callback.CallbackInfo;
import org.spongepowered.asm.mixin.injection.callback.CallbackInfoReturnable;
import zombie.GameWindow;
import zombie.characters.IsoGameCharacter;
import zombie.characters.IsoZombie;
import zombie.core.Core;
import zombie.inventory.InventoryItem;
import zombie.inventory.types.HandWeapon;
import zombie.iso.IsoPuddles;
import zombie.ui.ModalDialog;
import zombie.ui.RadarPanel;
import zombie.ui.RadialMenu;
import static dev.aoqia.leaf.zomboid.test.TestEntrypoint.LOGGER;
@Mixin(RadialMenu.class)
public class CoreMixin {
@Inject(method = "render", at = @At("HEAD"))
private void onRender(CallbackInfo info) {
RadialMenu radialMenu = (RadialMenu) (Object) this;
radialMenu.addSlice("Testing",null);
radialMenu.addSlice("Testing",null);
radialMenu.addSlice("Testing",null);
radialMenu.addSlice("Testing",null);
}
}
I made... mistakes
*mfw when midnight jordan forgot the rendermethod is called once per frame
actually you know what, if you want something super easy to PR, you can add it if you want!
The Steam install path is used in Constants.java like you saw, but you can get the user-specified property in MirrorUtil.java (look at how I did it for the zomboid game paths)
Ive already come around to helping, dont make me touch gradle already, please, i beg xD
dw I am on the gradle stuff alr
xD
I've been trying to upgrade it to kotlin dsl and the latest gradle, it's very annoying to resolve deprecation things but thats my job rn
Ill have a look on friday (going to bed soon the moment if figure out how to make this LuaEventManager BEND TO MY WILL LIKE THE MERE MORTAL IT IS
Holy shit we can do profiling because of this using intelij
and memory dumps
This is so cool!
๐
yeah this was one feature I super liked
bc profiling is important in my eyes, I WANT ITTTTTTT
but keep in mind that you can remotely attach visualvm or intellij profiler to a game that is running normally, its just that you dont see certain statistics I think
Either way
MY GAWD
Aight so leaf needs:
- Better setup tools for stuff like file path
- An actual executable launcher, where you setup the paths in a settings menu within the launcher
- A big kiss on the forehead for making modding project zomboid not a massive pain in the butt
file path stuff and paths in settings menu is not needed
this is only for loom, the development environment
But the loader itself?
Though I wanted to figure out a way to set the paths without saving it, because that means when people load your gradle.properties, they also get your set game path
although they shouldn't commit it to git anyway
You need to know where the game lives to launch it surely?
are you talking about dev or prod?
Prod
prod being your everyday user
ok so when the installer does its magic, it installs to the game path
all you need to do is add the required launch parameter and you can boot it from steam into leaf
no launch parameter means leaf is disabled too
Yeah fair. Issue si unless im blind there is no real clear way to get the loader working as a user in the docs.
i.e. how do I , dummy mc dumb face, get the leaf loader and have it work out of the box rn?
what is not working about it?
I def need to write some documentation for it, but you dont make mods in the loader anyway
you make mods using the example mod
yes that is for the users to run and install leaf
sweet mother of god we need to make you a javafx launcher stat.
The native file selection is super booger aids
im pretty sure its using uhh AWT or swing
I dont know what they decided to use, I think its swing
nah I think it works fine, the more stuff I decide to nuke is more stuff I cant merge from upstream which means I have to maintain it as much if not more than the fabricmc devs which they have a literal team for
We develop a team ๐
But yeah I get you. Either way, my sweet lord baby jesus im about to start making so many god damn mods
I've already changed a metric fuckton in the loom and loader combined, and I fear if I change any more it might not be worth it
THATS WHAT IM SAYING
as soon as I get this stable im upgrading loom and thenm making moddd
The only thing stopping me now is the GOD DAMN SODDING CONTEXT MENUS
Whether you like it or not, if you want to avoid pain you probably will have to end up using lua
but you probably wont have to use as much as without java
the whole reason why I recommended java mods to be major modifications and not just adding an item or a piece of clothing is because it's so complicated to do so in Java vs the native systems that dont even need the mod loader which you can do in lua and xml
^ which means everyone can use your mod, regardless of if they install leaf or not
Also oh my god I know the first mod I am going to do. SOmething ive wanted to check for ages but done rn
The Client Chunk Requests have so many easy Ws
This could unironically be used to fix the car networking issue
you could fix that yeees
THAT is the type of mods I wanted to see for leaf, because it expands the boundary of the game's current modding
Oh my god I just figured it out
The client sends chunk requests...but if they do not recieve the chunk there doesnt seem to be a system in place to time out requests and REREQUEST... this is why the chunk loading lag is so "bad". The chunks that didnt load never got a second request sent off
Oh wait there is actually ... hmm
Okay I know exactly what I want to make first as a diagnostic tool.
A visual indicator for chunk loading progress of some sort.
Something you can graph or play in a video or something.
Just to figure out what's exactly going on
isnt there a debug tool for that? to see chunk loading
One thing I really want to do is also replace the trash logging with slf4j because jeebus its bad
I THINK i've finally figured out the cross-project dependency issues I was having when migrating to kotlin dsl since kotlin dsl doesn't do dynamic wacky bad-practice stuff and let you get away with it
Maybe? But I was thinking more it tells you the state of each chunk in terms of the code itself.
Because I am convicned that something somewhere is going wrong for people with worse of internet.
Not just "Its bad internet" but physically wrong, like requests being dropped but not resent, the amount of requests causing a clog or something
ohh I see
well it makes sense if requests not being resent bc it's all UDP, but there should probably be some reloading mechanism if there isnt already
The thing I notice the most commonly is the "The chunk doesnt fully load" problem
That is NOT bad internet in the slightest., if a chunk doesnt load for over 5 minutes, thats a request that has been dropped by accident
I've seen people with 40ms to the server get this issue
Exactly my point
Also it does get worse with more latency though
I don't know if this is related, but people with bad ping to servers sometimes cause every chunk they load to blackbox/stall seemingly forever, though it still happens to people with less ping
That is very much the issue im trying to solve
I have a friend who the game is near unplayable for
He has poor ping sometimes, like 200ms , but even so, 200ms should not permanently prevent chunk loading
realistically, 200ms should delay the chunk loading by at least 400ms, but not THAT much like you say
Exactly
Cars are the worst for it and it convinces me that this is some sort of "permanent time out" problem of some sort, as the veichle requests are in the same update loop as world streamer requests
It could be one type of request is hogging all the bandwidth or somtehing equally ddaft
Ideally the server should have it's own thread for the world streamer, which I swear it already does
What I am implying is, it isn't the intended design thats the problem.
Its a bug
From the looks of how its set up, its very all over the place, and I can easily see thre being some sort of unintended behaviour being in the WorldStreamer
I mean jesus they have a concurrent linked queue and array lists called chunkRequests and chunkRequests0.
That in itself rings alarm bells of "Yeah someone can easily of written the wrong thing down at some point"
I am in the process of asking some players what conditions it happens in, as I rarely actually play PZ anymore. I'll let you know if I get anything
I think its gonna be one of these mate where we need to make a visual tool for it
Like you would be shocked just how useful a visual aid of the major code processes can be with networking issues
Once saw a JavaFX app that actually visuallises the Garbage Collector, was wild and so cool
You can add an event that details when a chunk is about to be loaded and whatnot, something like that
Like WorldStreamerChunkRequest WorldStreamerChunkLoaded something idk
I have 0 idea of what the world streamer code does, so I'm blind for now atleast
Was thinking even deeper than that. And tracking which collections each chunk is currently in aswell :
private final ConcurrentLinkedQueue<IsoChunk> jobQueue = new ConcurrentLinkedQueue();
private final ConcurrentLinkedQueue<IsoChunk> chunkRequests0 = new ConcurrentLinkedQueue();
private final ArrayList<IsoChunk> chunkRequests1 = new ArrayList();
private final ArrayList<ChunkRequest> pendingRequests = new ArrayList();
private final ArrayList<ChunkRequest> pendingRequests1 = new ArrayList();
private final ConcurrentLinkedQueue<ChunkRequest> sentRequests = new ConcurrentLinkedQueue();
private final ArrayList<ChunkRequest> tempRequests = new ArrayList();
private final ConcurrentLinkedQueue<ChunkRequest> waitingToSendQ = new ConcurrentLinkedQueue();
private final ConcurrentLinkedQueue<ChunkRequest> waitingToCancelQ = new ConcurrentLinkedQueue();
This right here, are just SOME of the fields in the WorldStreamer.
If a student tried to do this as part of their networking logic on an assignment, i'd give em a C- at best xD
๐
the pz code is really something special
I gurantee something to do with the logic of these collections is causing the bug
Their underlying network stuff is also a little flawed imo, it's very wacky
like maybe it's stuck in pending requests and doesnt get moved to sentRequests or something?
hmm yes a UI for this would be nice
a grid map and it lights up which chunks are in which state by colour
Ive learned to stop guessing when ti comes to stuff like this and just literally do it aye.
A UI to visualise it would squash this bug in like an hour flat
I hope someone also completes the server gui flag, in b41 it was broken (dont know about now still) but that would be a cool server panel gui to have
this.loadReceivedChunks();
this.cancelOutOfBoundsRequests();
this.resendTimedOutRequests();
}
for(IsoChunk var3 = (IsoChunk)this.jobQueue.poll(); var3 != null; var3 = (IsoChunk)this.jobQueue.poll()) {
if (this.jobList.contains(var3)) {
DebugLog.log("Ignoring duplicate chunk added to WorldStreamer.jobList");
} else {
this.jobList.add(var3);
}
}
Stab in the dark here, but i'd bet my bottom dollar its something to do with this bit. A bit of code that will get the game to ignore duplicate chunks added to the job list... hmmmmmm
is that using vineflower? jesus that looks ugly
No? I just decompiled from source using intelij xD
I opened the raw .class with intelij xD
oh, intellij uses fernflower which is what vineflower is based on
I hope vineflower decompiles that better, but it's probably more likely that how it's written is how TIS wrote it
Project Zomboid has customizable startup parameters that are to override the default options used by the launcher, JVM, and game. JVM arguments must be provided first and end with -- even if there are no game arguments. Game arguments can be passed to the launcher because they are forwarded to the game itself.
Create Steam shortcut
โข Navigate to the game folder via right-clicking Project Zomboid in the Steam Library โ Manage โ Browse local files.
โข Create a shortcut of the game launcher ProjectZomboid<32/64>.exe.
โข Add the JVM arguments to the Target field.
Example: "C:\ProjectZomboid64.exe" -Xmx1024m -Xms1024m -- -nosteam
Steam application
โข Right-click the game in the Steam Library, a menu will pop up.
โข Click Properties. A new modal window will appear.
โข By default the 'general' tab in the modal window should be opened, but if not, click it.
โข Look under Launch Options โ *Selectโฆ
I documented all of them here for b41. I don't think any more got added with b42, though I will check anyway just to be sure
for production or for testing?
prod
for prod, the installer tells you the launch parameter you need to put in steam (or wherever else you launch the game from)
If you want to test your mod, I'd do it in the IDE
big cry
Steam
that is true. Maybe I will have it automatically copy to clipboard (or a button with "Copy")
wait why?
It doesnt launch it via steam from the ide
oh yes that is by default, you can change the args of the application run config in the idea
See the highlighted text here, change that arg to 1
Where the living shit is the zomboid client ?!?
Execution failed for task ':zomboid:zomboid-test:net.fabricmc.devlaunchinjector.Main.main()'.
A problem occurred starting process 'command '/home/jordan/.jdks/corretto-17.0.14/bin/java''
its not a gradle task (although runClient gradle task acts similar)
Found it but MOTHER FU...
it's an IDEA run config
@novel crow The people I were talking to about blackboxing have their own server with 600+ mods. Apparently they got rid of the blackboxing, but it still occurs sometimes with really high-ping players. Sounds definitely like a bug, but even more than that, probably can be optimised a bunch too
Help me get my damn config working first xD
.
at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
... 7 more
Caused by: java.io.IOException: error=2, No such file or directory
... 8 more
Mother fu
whaaat? I've never seen this issue ever
what even is net.rubygrapefruit
OHH my god
it's a bug in IDEA that I dont think I can solve, you need to remove the stupid path that gets prefixed in the working dir of the run config
What it should look like:
But it will have the absolute project path prepended to the start of the working directory.
this is also why I dont recommend modding using the loader's test environment and using the normal modding environment ๐
So yours would want to be set to /home/jordan/.gradle/caches/leaf-loom/41.78.16/extracted
So yeah, now to start thinking about how exactly to make this debug mod.
Saving the data captured in a format that can be turned into a grid later?
Seems like a lot of rubber band and string work to get the grid working in game
Also I'm really thinking we make a custom launcher for it.
The steam params are confusing at best for a user.
If you want wider adoption you really need a clean way for users to install and run it that doesn't require command lines.
If you make the UI in lua (I KNOW I KNOW but hear me out)
I will end you
and then use events to change the UI like yourUI.chunkUpdated(x, y, ChunkState.INVALID) or something
There is about to be unhealthy levels of violence
it makes your life 10x easier than writing the UI in java, means you can access the ui in game and stuff
I'm not learning Lua I swear to God almighty himself
It's not hard to paste an option into steam
99.9% of players are using steam, and this is the best option I've found so far. Trust me, I've tried looking
Context is key.
How hard is it to install a normal project zomboid mod? I know we both know the answer, but humour me
there were other projects like pz storm that made a launcher, it was too tedious to use
normal as in lua? wdym
Yes
uhh you subscribe to the workshop
Exactly
to the mod on the workshop
That's the level of simplicity we have to at the least match
Yes it does, but running the game via a steam launch param, I dubno how to describe it.
I call it the "consumer effect".
UX should be measured by the UX of the normal solution.
Hell I'm a NERD and I put off getting leaf setup due to installer issues and still haven't got the steam command working
I swear, it's the simplest way I've found that users said they wouldnt mind doing
I understand that.
Might be worth MVPing a tiny, 1 click and done launcher maybe?
Just to see if it has any potential gains
Nothing fancy, just bare basics
Click, game loads
yes but this means having a whole manual uninstall process
literally everyone I asked preferred having just a launch option control leaf ON/OFF vs manual uninstallation or having separate batch files just to play the game for every version
True i agree.
Issue with the installer is, even if the command is copy pasted, what if the user wiped their clipboard
As of right this second there is 0 way to get that command again after installation is done
now I will get around to adding that copy button to the message that shows up, just so people dont have to type it manually
My above issue still stands haha
true, maybe I can detect if it is already installed
I do already show a message saying its already installed. I could include extra context
Or save the command to a file the user can access
that's even more tedious for people
Or, hear me out, we are duct tape and stringing a problem that boils down to the fact the steam launch param ain't ideal
they dont like inconvenience very much I tell you ๐ญ
it is ideal, wdym
it's THE best way
using the official game launcher
We have just spent 5 minutes scratching our heads on how to get the user the param again
? If you needed it personally, I can just type it out for you
I'm thinking for the sake of the user
I already said I would add those feedback into the installer so you can copy it again if needed
I appreciate that but what if the usee was dumb and didn't read the popup message? Is there any feedback to tell em the launch param is the issue?
Ofc not
Also I did update the readme even just a little to have just in case
that is on the user, I can only do so much
I am not about to go and drive to the user's house just to click on the button again to show a message, this is stupid
also just noticed I forgot the ".json" in the readme ๐
I appreciate that
That's okay ill do it if you pay 50% of the fuel
Btw i think you asked before where to put mods and I forgot to answer
you make a mod following the standard workshop structure and you put your jar under .leaf/mods
so the .leaf folder would be alongside the media folder
So how does the workshop work?
Also wouldn't leaf be hidden for end users?
Lol I did . / and it hid it... because it's . /
Or am I being really dense about hidden directories
You named it .leaf ?
Might want to remove the dot to not hide the folder by default no ?
Or is it different for the users ?
It shouldn't be hidden, though I can't be sure for every OS they use. I put a dot at the start mainly because it makes it appear at the very top of the folder structure
If the folder remains there, it doesn't do anything on its own anyway, but I will still consider that
you publish mod to workshop, someone subscribes, boom
The only issue I see there is that you might get in trouble with steam potentially as technically your workshop mods won't work out of the box
I can see that being a sure fire way to piss off TIS
I doubt that will be an issue
There are mods on the workshop that literally do nothing. Some hard crash your game instantly. Some are well coded. Steam does not care what you put in your mod so long as it conforms to their guidelines of no copyright infringement and stuff like that
And of course only certain file formats are banned, but JAR isn't. iirc its like bat, exe, some other ones
Sweet.
Now time to go bed and prepare for a weekend of Java modding babbyyy
I've nearly got the full loader stuff converted to kotlin dsl. I'm just finishing up on a few checks to make sure things actually work as intended like checking the jars for the correct files etc
so far it builds and publishes, and the contents of each jar look fine
.folder hides the folder in Linux, at least every Linux distro I've used for now
hmm that's not too bad then. I think I will keep it as-is for now, and if more people complain in the future then I will change it to like an underscore or something. I will add a note to the installer readme about where the installer installs files to
Why do you need it at the top tho ?
I wanted it to appear separate from all other game files
so people know that it isn't related to zomboid's code
I think following the classical PZ naming for mod folders sounds better overall for entry, .folders are really just folders that are supposed to be hidden to most, or ignored by most
Like the .vscode folder .idea
etc
and since no zomboid folders have a dot at the start, I was hoping it would stand out
Why not put it alongside media ?
but it really doesn't matter if people dont delete the .leaf folder, even if it exists it doesn't mean your game will load leaf
the only thing that determines loading leaf is the json file, so if you have that launch parameter basically
myMod/
โโโ media/
โ โโโ ...
โโโ leaf/
โโโ ...
Oh then that's really not necessary to make it standout imo
it should be myMod/.leaf/mods/YourModHere.jar
but that one probably shouldn't be .leaf. I think I made it change on the fly so you can use leaf or .leaf
In fact, it's more likely some might interprete the folder as something like .vscode .idea or .git meaning mistakes done by the mod maker that made these files uploaded in the mod
What's the subfolder mods for ?
for the java mod
anything you wnat. I created that parent leaf folder to contain anything leaf related that modders want to store. for example, configs
That should be good enough
Although actually now that I think about it, configs should be stored in the cache dir
Yea true
ok I DONT KNOW WHY there is a separate mods folder bc I cant remember why, im sure it will be of some use later down the line
probably for storing the remapped mods if I ever re-enable intermediary
I think it's good to have a subfolder
In case other folders on the side need to be added to be allocated to specific stuff
You think this is good enough to explain to people?
Wait did I confuse myself ?
So you got a .leaf folder alongside the game file media, zpmbie etx, and also a .leaf folder individually in mods right ?
the leaf/.leaf (can be either) in a mod is where you put mods in the mods folder
the .leaf folder (specifically) in the game folder is just for libs like the loader itself
I see
.leaf might be adapted for the game files
Tho the issue of hidding the folder on linux
I would prefer people use leaf instead for mods just because it is visible by default
Yea
For the game files tho, windows user will see it, probably
And it makes sense to have it stand out
Just use an _ like a normal human being ๐ญ
But yeah well done for swapping it to kotlin.
Quite the achievement to move it all.
Also fuck you for moving it all to Kotlin! My nemesis! ๐๐คฃ
sacrifices for the greater good!
That's only the loader though. Thankfully all the other projects should be a breeze as the loader is the only one that is insane

But yeah I just can't get the steam command to work..i feel I'm being stupid
I think I have now but, imho? as a qol thing you should add something to the main menu version info to say leaf is running
here
@floral sluice does leaf have a logo?
not yet
that is all done in lua so I can't without doing some crazy lua shenanigans from java
I do change the window name, so you can look at that
It should be Project Zomboid (leaf) if leaf is loaded correctly
There is a cheat we can do actually as i just discovered
we can change the sections of the background in the main menu
So we can edit one of the sections to have a nice leaf logo in it
And then inject and change the call to our logo
To show you what i mean btw
I swapped it out for the lightning version of the background piece
- pzexeconfig leaf-1.0.0-41.78.16.json
Well this then didnt work
no space
inbetween the -
it should be in this format: ```
-pzexeconfig leaf-{loaderVersion}-{gameVersion}.json
although the json might be named leaf now, let me check that too just in case
it is leaf, editing the readme now
Either way, any idea how the game loads the texture images etc??
Maybe check out zombie/core/Texture.java
specifically the reloadFromFile function which takes in a relative string path to the texture like media/textures/../texture.png
some other classes may be like zombie/core/textures/SmartTexture.java (see getTextureWithFlags)
idk it seems a bit everywhere
hey, leaf-loom seems to have an oversight, it assumes the game files are in C:\Program Files (x86)\Steam\steamapps\common\ProjectZomboid, which isn't always the case, for example i have them at D:\SteamLibrary\steamapps\common\ProjectZomboid, is there a way to configure this or do i just have to move the game over to the C drive ?
I'd suggest an environment variable, maybe something like LEAF_STEAM_LIBRARY_ROOT and you'd check for it here: https://github.com/aoqia194/leaf-loom/blob/main/src/main/java/dev/aoqia/leaf/loom/util/Constants.java#L45-L53
if it is set it would take precedent over the defaults, in my case i'd have to set this variable to D:\SteamLibrary
@floral sluice second person to have this issue ๐
huh, nice ๐
i did search for messages before writing mine, couldn't find anyone
so...
you can set the path manually in the build.gradle file by doing
loom {
// Inside the already existing loom block at the top (!)
loom_client_install_path = 'D:\\SteamLibrary\\steamapps\\common\\ProjectZomboid'
}
I slept much longer than expected so im sorry for the late reply
These are just default constants, which I should probably change the name of those functions to like getDefaultSteamClientInstallPath or something
You really want to check here: https://github.com/aoqia194/leaf-loom/blob/main/src/main/java/dev/aoqia/leaf/loom/util/MirrorUtil.java#L39
either this, or it might need to be declared in the loom {} block in the build.gradle, I forget which one all the time 
it is there, original message updated
I should really put this in the docs, but im not sure where
maybe both in loom AND the example mod?
I was planning on doing documentation at the very last step since I wasn't expecting people to actually use this until I properly announced it for testing ;-;
Skill issue 
being a ful time student does that to you
Perhaps a start in some documentation for stuff that won't change too much since the project is picking up some attention ?
it's already on the example mod readme! I added it right after
the reason why I hate writing docs is mainly because im biased because I created the thing, so I just assume a lot and it's hard to think of all the cases, whereas someone who does not know will go through and ask about all the cases (just like sparta did with the install thing)
I also found and fixed the loom issue for the zomboid-test loader project where the working dir is prefixed incorrectly, unironically its not a bug but a feature, but since the working dir is no longer set to the project but the game's path, have to disable it!
also i should probably convert all the ext props like loom_client_install_path to camel case because it looks nicer imo
@valid nova when you get the time, please unpin the pin you made before, because stuff like that can always change and I dont want people relying on it in this channel
I think the respective repository READMEs and the pzwiki will be the place for this info, which these are already in the pinned messages.
That's completely fair
I get the same with the wiki tbf
Some stuff sound obvious to us now, but it's not for them
Done
Usually I'd rather push documentation in an appropriated wiki on the repo bcs you're limited to a single page on the official wiki
Perhaps later IF the project grows into something bigger it'd be possible to consider more individual pages to Leaf and a whole section to it
But in its current shape, it's better to have its own documentation
this is exactly what im doing dw

There is another factor with documentation too.
The curse of knowledge problem.
If you leave docs till the very end, you underestimate what is "common sense" or not, as you've spent the whole project just "knowing it", making the writing of actually comprehensive docs harder, as you are almost always guaranteed to assume the end user knows something that, in reality, isn't as intuitive as you assume.
Source?: 12 years of programming experience haha
Good use for LLM tbh. Tell it to come into the process not knowing anything, and identify clarification issues.
Which kind of works in its favor, as "not knowing stuff" is a massive issue for LLMs. ๐
thats why I kind of like the document-as-you-go thing im doing currently
does leaf support b42 ? it seems the yarn mappings are for b41
bc chances are, if someone is asking me how to do something, it should probably be in the docs
yes it does, yarn mappings are placeholder right now and using 41.78.16+build.1 right now will not affect anything
They do work, just not had the time to do proper mappings yet
and with unstable, doing mappings for every unstable version would be extra work that I don't need ๐
yeah, understandable ๐คฃ
I'm still not entirely comfterble with the cheating problem this brings in as of the current moment.
Might be worth us having a basic anticheat baked in or as an example mod.
But tbh it's more a base zomboid problem as their logic being client side is wild
definitely not a leaf problem
who cheats in this game ? most servers are usually just a small group of friends anyways ๐
there's no way on this planet im baking in an anticheat to leaf. it is going to be a separate mod if someone decides to create a java-sided anticheat
some people cheat in mp, but most people play singleplayer or small friend group like you say
a large handful of cheaters can be caught anyway with manual moderation
It is true.
Was just wild how 0 skill a damage cheat was to make for example
sorry to keep bothering you with this but it seems it's still failing with that property
Could not set unknown property 'loom_client_install_path' for extension 'loom' of type dev.aoqia.leaf.loom.extension.LoomGradleExtensionImpl.
hmm, maybe it does need to go in the gradle.properties file...
try putting that line in the gradle.properties and try again
im gonna push a loom update soon that makes it an environment variable so not to worry ๐
well it worked on gradle.properties, now it's complaining about not finding zomboid 42.9.0 ๐
if you are going to make changes on loom make the variable be separated with dots, just like the dontRemap one, for consistency sake
well it seems this is the gift that keeps on giving, now it's complaining about an Illegal char
it will be an system environment variable so that people can set their install paths on a per-system basis
LOOM_CLIENT_INSTALL_PATH and LOOM_SERVER_INSTALL_PATH
though server in leaf is unused at the moment as it's unnecessary.
can you send the full line that gradle is complaining about?
yes, you have to escape backslashes in strings, and it doesn't need to be enclosed in quotes either since it's in a .properties file
loom_client_install_path = D:\\Some\\Path
example
ah i see
is there a way to skip the hash checks ? it's currently failing to copy the game files over to .gradle cache, because the sha1 hash doesn't match the one it expects due to the game version not being 41.78.16 but 42.9.0
You can change the properties to put the version you need I'm pretty sure?
i did try that first, but then it says it can't find 42.9.0, so i'm assuming i have to leave zomboid_version=41.78.16
see, this is what happens if i set it to 42.9.0
and if i leave it alone it progresses but fails in copying the files over to gradle cache because of hash checks
unstable also needs the revision number in this format:
{version}-{branch}.{revision}
like 42.9.0-unstable.29660
this is needed because the version number itself is inconsistent as they have posted updates with the same version number before
ok, i think this time it'll finally work ๐ we'll see if i hit another wall
i will sleep soon i promise
https://tenor.com/view/melting-melt-spongebob-meme-spongebob-meme-gif-19186896
just one more update
ok I completely converted loom also to kotlin dsl, PITA but it wasnt as bad as the loader was, ill upload it when I wake up later bc im tired as all hell
also in that update:
upgrade to gradle 8.14.2
environment vars for game paths
changed extension properties:
- loom_client_install_path to clientGamePath (and some others but they arent used by 99.999% of ppl)
i figured I better do at least a little changelog stuff so people know at least a little of what is changing just in case ๐คท
getting the following errors when i try to run the zomboid client with the example mod, SDK is set to java 17, one of the errors seems to indicate mixinextras is built with java 21, any ideas ?
i should maybe add that i can't even launch zomboid with leafs config, i get the following error, probably related
loader 1.0.0 did have this issue, I believe I fixed it in 1.1.0
the first error issue was because 1. I compiled mixinextras with java 21 on accident, and 2. Zomboid changed their logging system for seemingly no reason at all, so I had to create a separate patch for b42 logging in 1.1.0
the second error was caused by the above
ok so loom 0.5.0 is published, remove the game path from the gradle.properties and set the environment variable LOOM_CLIENT_GAME_PATH to the absolute path to the ProjectZomboid game folder
I am using 1.1.0 if I'm not mistaken
huh you are but it's showing up as 1.0.0 in that log file
actually no, that console.txt looks like you are trying to use leaf through the installer, which you probably installed 1.0.0 or something
pretty sure I used the latest but I'll check in a sec
i will do some testing of my own right now, as of current I can boot up the loader with mixinextras working perfectly fine
so, i used installer 1.0.1, as for the loader version you're right it's 1.0.0, because the installer doesn't list 1.1.0
so 1.0.0 was the latest i could have installed
oh it probably didn't update the manifests for that since when I published it my github token expired
ok so I think you should stick to loader 0.0.3 until I release 1.2.0 which should be very soon
this is because all the other versions above 0.0.3 have mixinextras, but I needed to do some tweaking to it so that it works properly
that's fine i'll wait for the new version, not in a hurry ๐
this is all a mess until I release 1.2.0 basically lol
which all im doing now is triple checking that it releases proeprly due to the switch to kotlin dsl
and that change in the installer will also be here soon
ok just noticed the installer was now listing loader 1.1.0, so i reinstalled using it, still crashes zomboid with the second error from before i believe
hmm maybe the logger for 42 was in the update I've yet to publish
either that or they changed it again but it was working for me
just dw about it until 1.2.0 is released which I will probably tmr
just put a new installer version out to fix some bugs and add that copy to clipboard option so if you speedrun the message it will be copied to your clipboard, and there is a button to do so on the main panel
loader update will need to be pushed to tmr again because I've got to fix a couple bugs with ZomboidAssetConverter as well
i ended up compiling the current main branch of leaf-loader myself, and it fixes the problem, you have 32 unreleased commits, one of them is a separate log handler for b42, so you were right all you have to do is publish a new release, unless something else is broken i haven't encountered and you know about
yes
I was having publishing issues since the switch to kotlin-dsl which I fixed and there was one more thing I wanted to add to the loader before I release 1.2.0 but if it becomes too much of a task i'll just publish it anyway
no problem, speaking of publishing issues, loom 0.5.0 published release seems to be borked too, take a look
it even passed the dry run for release
this is a problem for tomorrow me and im gonna make an issue on github so my tiny brain can remember
and since maven replicates and then its read only, so I cant change it ๐
thankfully ill just blame it on the 0. prefix and say "its in early access" or something
Fixed the publishing issue in loom 0.5.0 due to a mistake when I pulled the all nighter ๐ญ
released 0.5.1 in place of 0.5.0 so that it actually resolves lol
I couldn't sleep and so I decided to fix it, it's now 03:08 and i want sleep so that is where I go
Did you figure out what was causing errors in the build in the end?
Need Leaf in my life ASAP.
Inject it straight into my veins ๐คฃ๐คฃ๐คฃ๐ญ
Need to be able to mod zomboid using a real man's language ๐ช๐คฃ
for which project?
Whatever one had the gradle issues
I don't think I have any more gradle issues after sparta reported the loom one, since loom and loader are now both kotlin dsl
i've yet to do the installer/example-mod though
I thought we started our convos with each other with some huge road block?
Like our first convo was you putting off some gradle or build error
let me go see
edit: cant find much
if I remember correctly, it was the in the loader with the "Username must not be null!" trash that gradle was giving me. Upon rewriting the buildscripts using kotlin dsl for gradle, it worked as normal
Oh sweet easy haha
@floral sluice has the example mod event registration ever worked ? because leaf's mod loader seems to be calling onInitialize() before LuaManager.init() is called (before GameWindow.init() is called too) which means LuaManager.env is null, and we get the following error
Yes I believe this was fixed, if you're testing the workshop mod I haven't updated it in a while due to having to do it manually every time
my mistake was that I did it in onInitialize instead of init (or wherever the events function is, I forgot) like you mentioned
not testing the workshop mod, i built the current loader main branch and the example mod with a few modifications to make it work for 42.9.0
hmm let me check
perhaps the fix is in the loader's dev branch, you do have a few commits there that arent on main
it is to do with the example mod
because I register the event when the mod is initialised, but mods get initialised before the game does
I forgot why I changed it, I could've sworn I had this same issue and changed it
you can probably just edit the exampel mod yourself for now, mixin the function whjere all the events get added (its in LuaEventManager, probably registerEvents() or something like that which registers them) and register it there
or actually just remove the event completely, if you are only using it to test then you can remove the custom event and just keep the version mixin
im slowly catching up on issues as you mention them, because I was stupid in the past not to use issues or even a todo list, so I ended up forgetting a lot of these things
think i just found yet another issue 
for wtv reason, i can't start the game with leaf and debug mode at the same time, like it starts but debug mode isn't enabled
maybe -pzexeconfig overrides the other launch parameters and i have to enable it within the config ?
it shouldn't and has been working fine for me
keep in mind that jvm args need to be before -- if you use them. for example:
no jvm args: -debug -cachedir=C:\Zomboid -pzexeconfig leaf-1.1.0-41.78.16.json
jvm args: -Xmx8192m -- -debug -pzexeconfig leaf-1.1.0-41.78.16.json
though I doubt this is the issue actually
can you send the params you are using actually
also where you are putting the args too
not using any jvm args
initially i had them like this -debug -pzexeconfig leaf-1.2.0-42.9.0-unstable.29660.json
then i swapped -debug to the end, didn't work either
and yeah, if i remove -pzexeconfig leaf-1.2.0-42.9.0-unstable.29660.json and leave -debug it does start the game with debug mode enabled
hmm
I suspect debug isnt being passed from knot (the loader for the loader) to the actual game main class
for whatever reason even though it should
whats the first few lines in the console.txt
with debug and leaf at the same time ?
yes
it should show in the top (first hundred lines or so) of the console.txt if debug is being passed or not
and if there are any broken args
it will say like "unexpected argument" or something
there's a unknown option "--debug"
seems like it's adding another - to the parameter
i thought i fixed this in 0.0.3 ๐

luckily I have the loader project open right now doing unrelated thing so ill check
yeah for some reason I didnt account for this earlier, it will be in 1.2.0 as well
to get around this temporarily just set the jvm arg instead, so remove -debug and add this to the start of the args: -Ddebug --
you probably have more regressions then if you had fixed this in 0.0.3, probably a merge conflict that wasn't resolved correctly ?
no, turns out I never fixed it in 0.0.3
I thought I did, it was an edge case that I didnt think about
wait no that was the bootstrapper args
but I looked at your console and it seems that the bootstrapper consumes them anyway
found it!
im stupid and put the solo args (like debug) with a prefix ๐ญ
when I was writing thism I assumed that I removed the -, but I never did
another way to get around it rn is to just not add the prefix to the launch options ๐
so just debug
given some launch options can have a + prefix instead of a -, i think you shouldn't remove it and assume it's a -, so just leave it
Looked into it and realized I never updated from example mod repo. @floral sluice, should I pull it and merge it into my mod repo?
yes I am keeping the original format
you dont have to, pretty much its the same except for the build.gradle and gradle.properties, those are the only two files that will change that you need to keep up to date
and not specifically example-mod's ones, but because of things like the loom version, it will be updated every so often
and gradle/wrapper/gradle-wrapper.properties too
that is in the example mod?
yeah
oh yes, that will update, but you can update it yourself, its not specific to the example mod either
it's actually better if he updates it himself before updating anything else, the latest loom requires the latest gradle, but you can't update it after changing the loom version because the project won't sync, to update it run .\gradlew.bat wrapper --gradle-version 8.14.2
I see. Thank you.
Have one more question.
Is it possible to create a Gradle task to update Loader and Loom to the latest supported game version I've specified, or is it better to manage this manually?
hmm, you could probably make one but im not going to do it at the moment
turns out I do append the extra - for a reason, I store args without the - like I thought I didnt
this is getting too annoying ๐
hmmm, but then if you do append and need to append, it would result in having a single - instead of 2
the only issue was that I forgot to call substring when storing args that dont need values
so it was storing "-debug" instead of "debug" but only specifically for args without values
actually fixed this time thank god
also do people actually use + args? I thought they were only used for specific things like for steam using +connect, but I dont know of a single person who actually uses that
they exist, they are useful if you want to direct connect to a server
eh I only documented 2 as of 41.78.16
ill still add support for parsing them just because
@floral sluice whenever you can take a look at this, it ain't much but it's honest work: https://github.com/aoqia194/leaf-example-mod/pull/1
looks good to me, see a small requested change but that's all!
oops, just realised I left comments for a potential leaf-api version on gradle.properties, and another on build.gradle that tells people to go to gradle.properties to change versions ๐ maybe that should be changed / removed to avoid confusion
hmm I didnt see that in the commit
but yeah leaf api probably wont exist
or will only exist if I find enough things to compile into an api
I finally figured out one issue that was plaging me with installing in prod environment, I forgot to write a bytecode patch to check the internal version of the game, so in dev it works because the version is manually specified by loom, but in prod the version isn't always specified (I think I did in newer versions of installer to sort of skirt around the issue)
which I will get around to writing soon now that I've fixed some other non-relevant issues on github
@floral sluice 42.10.0-unstable.30053 released
thanks for the heads up
Manifests are published ๐
yippee, all from static bytecode analysis
now lets just pray that they dont change the version functions over and over again like they have in the past
Nice!
How do you plan to use this value?
the loader needs to know the game version for some things, like using the right logger patch among other probably more important things
I see. Supporting two game versions probably won't be an easy task ๐
I just spent about a ..week? exploring how Zomboid tile rendering works.
I wanted to implement tile rendering as 3D objects, but I didn't know it was almost done by the TIS devs
Yea that's kind of already a thing
There's literally zero information about it. It's only used in one .txt file that I had never checked before.
I wish I had at least a little bit of documentation on it ๐ฅฒ
Documentation is a lot to ask for haha
The devs will do zero documentation
And the only time I heard about it was a discussions with Ash where he mentioned the game already had such a system
Used for the washing machine I believe
And that it's been present since B41
But no one ever noticed it, or at the very least ever did anything with it
Then Ash being Ash he started mumbling random stuff that was kind of impossible to determine what he was even talking about ๐
So yea documentation is a lot to ask for ๐
Exactly. I noticed that a while ago but didn't take it into account.
But I found a toggle in imgui called FBORenderChunk.HighResChunkTextures that enables it to work constantly.
Such a cool feature and it's almost never used
There's probably a reason to it not being used often
Not for me ๐
I mean, feel free to use it lol
I really want the devs to convert most things to 3d, because it expands the abilities of everything
think, like a microwave that spins the food, something like this
well now that I did the version class detection thing, it was the last thing I wanted to add before 1.2.0 release, thats why it was taking so long ๐ so hopefully I can release it
idk if ill be able to get the loader update done today bc I've got an earwax buildup so far deep that ear drops dont do anything, so I cant hear out my left ear and it is really the only thing I can focus on right now (its annoying as hell)
im on a roll today even though I cant hear properly ๐
one of the biggest things stopping me from releasing 1.2.0 also was I couldn't figure out why kotlin dsl couldnt grab properties from gradle.properties file... I had it ignored in gitignore this whole time ...
so embarrased LOL
Yeah, it's actually planned to work like that - like doors that have an "open" animation
ok loader 1.2.0 should be replicated to maven very very soon
it is published
I added the localization wanted and testers wanted tags. I think it's time for some more testers to hopefully speed up the whole bug report and fix cycle that has been going relatively slowly.
Also some people with different translation abilities would be nice to help with loader translations along with the installer's translations too.
upgraded filament and leaf-example-mod to kotlin dsl as well
if you have already created a mod using the example mod, I'd suggest taking your java files + your leaf.mod.json and storing it, then re-cloning the example mod and apply your changes back on top of the latest example mod
It's not much, but I'm ready to help with Ukrainian translation and testing as well.
Keep in mind that I'm focused on B42 and using Linux, so my reports might be considered as low priority, since it's not a widely used configuration for the average player.
I would also appreciate a brief description of the testing process. I mean, what exactly should I do?
I do take reports using b42 lightly because stuff will probably change quickly with unstable, but Linux is still a target platform along with mac
the only thing I am not and will not support is x86 because that's really old nowadays
and I'm not quite sure on ARM either (I don't know Bout that yet)
The testing process is just using leaf how it sh old be used, like making mods with mixin and just making sure that it works correctly without issue
Though I'm my case testing really focuses on just using it how its intended to be used. Maybe I should expose the project to more people to hopefully get more people using it (therefore more testers)?
I'm using loader version 0.0.3 (since I believe it's the only one that works with 42.10.0) and I'm already using it for mixins - just to slightly modify the rendering process for now. I haven't explored all the possibilities yet; so far, I've tried basic injection, method overwriting, and access wideners. Despite the graphical artifacts I'm experiencing, everything related to Leaf seems to be working fine.
Oh, I suppose using an old loader version isn't really something worth testing.
can you try 1.2.0 that I released recently? It should work with latest version now
i too will be testing it rn
@floral sluice whenever you can check this one out too: https://github.com/aoqia194/leaf-example-mod/pull/2
your SwapLua repo has the same problem btw
yeah when I was testing i fixed it locally, though I thought I already pushed the changes
fixed, thx
I am having an issue not being able to view and evaluate local variables while debugging. Lmk if anyone else has this same issue, and I'll try and look into it. Though currently I have absolutely no idea why it won't work.
Actually, me too. As far as I remember, it has always worked like that.
Debugging in my mod classes works just fine. If I overwrite vanilla methods with my own, I can see the local variables.
and I'm sorry for not responding regarding 1.2.0 - I still haven't had the opportunity to properly check it
don't worry, you're not obligated to test every little thing 
but yes, for some reason, debugging specifically the games Java code with a matching decompile doesn't like locals
Now I asked some people over at Fabric, didn't get a full answer because they are mostly just community and not everyone actually worked on fabric, but the only thing I got told was that it was weird and that stuff in the same scope as a lambda isn't captured
i need to go get some more testers from the official PZ discord ๐
i doubt anyone even knows this exist outside of a few people
tbf I don't really like to "advertise" because it feels scummy, but how else do you get people to know
Agreed
I think making some example mods that users actually try out might be a good idea
thats what im in the process of doing, everything just takes a while ๐ฐ
Sooo, I probably did something terrible and broke my project ๐
I opened an issue in the leaf-loom repo
uh oh lol
EDIT for anyone wondering: I don't think this is an issue with loom as I fixed an issue with this stuff before
It's time to start a troubleshooting page ๐
True that, it's probably for the best
@novel crow If you ever wanted something to do, maybe you can add something small like this? Though I won't delegate it to anyone but myself if you don't want to.
I was debating whether to have the wiki under example mod or under the installer. I decided to put it under the example mod.
I will probably add to it later
Probably best to put it under the main leaf repo
With the installer
So modder that tested leaf mod intuintively look for the wiki there first
Also bcs the wiki might be used for leaf users too
For guides to installing
I thought about it more, people who are using the installer don't need to worry about these specific issues that only happen when you are developing leaf mods
so I think example-mod is the best place for it, it's where people go to use the template to make a mod
installer wiki would be the place to put stuff like issues and troubleshooting with the installer. To my knowledge, there isn't any troubleshooting needed for the installer
But instead of making 2 wiki for users and modders, why not bring bother together ?
Limits the repetition of informations around 2 wikis whenever there's common informations for users and modders
Also gives an open door to users to get into leaf modding
I think that's something for the pzwiki page
I want each repository's wiki to contain info about that stuff
for example, the installer wiki should only have info related to using the installer as a normal user, not say loom issues for developers
I feel like including developer info with normal user info is not a good idea all things considered
then you get people confused and trying to install intellij IDEA and loom just to add leaf to their game
The official wiki might not have enough space for that
Currently you're allowed a single page for the project unless it grows to a point where everyone basically uses it
I'm not saying you should mix them
But make a clear sectionning between both
Make a clear redirect to the user wiki with a massive button
HOW TO USE LEAF
And for modders the wiki for them is not far
It's always a question of properly writting and presenting the things you knowo
I think the official wiki page should have some explanation, I think that's a good way to "lie" to the users that this is a trustworthy and serious project (not that it isn't but that's not really a confirmation of it to have a modding project page)
a single page is all thats needed personally
if I need more I can always link to github wiki
theres not much to explain though, the usage guides are in README and most part clearly visible
troubleshooting could probably be in the readme under a section, theres probably not even a wiki needed
Small like what?
just like a little troubleshooting section in the readme of leaf-example-mod
probably add to it as issues arise, currently the only glaring issue is what gigawatte created an issue for, which is getting a failed file copy when file hashes dont match (see the log and more context in the closed issue here https://github.com/aoqia194/leaf-loom/issues/4)
@floral sluice
You recently mentioned the leaf-api and the functionality that could be added to it. How about a wrapper for LuaManager? Just something to expose java mod classes and certain methods.
I think it could be useful for all modders
hmm I don't personally think that's enough to add an api for, it's pretty straightforward to do
though I like the idea of a main leaf api, i think I will need some more functionality to justify it myself ๐
What would even go into the leaf api.
presumably the api would have some classes for interacting with the game easier
though I can't think of much that would be worth putting in there right now
the one benefit that an api does have is that it can reduce mixin conflicts, because only one mod needs to mixin those functions instead of literally every mod, but if you use mixin correctly, there's little worry for conflicts.
Hii @floral sluice
Here's another thing to think about (B42, of course):
ComponentType.java is likely used to enumerate all available components in the game, and all of them are hardcoded with IDs.
From what I can tell, the game relies on these IDs quite heavily. This could lead to a real mess when modders overwrite vanilla components IDs - or when mods components conflict with each other.
So maybe we need a way to dynamically generate these IDs, possibly based on mod_id hash or something similar
hmm
@full mountain would you happen to know more about this by chance?
Also, if the ids being referred to are the first param in the enum value (the short) like 9 for script and 2 for fluid container, shouldn't these not be changed unless a modder is really knowing what they're doing?
The only time there would be conflicts is if (like you said) someone overwrites vanilla component ids. Why would anyone ever do that though? You can add your own ids, but if you're replacing vanilla ids then I feel like you get what you pay for ๐
Though I could definitely be misunderstanding this system, as I'm not personally aware of anything related to ComponentType and the ids
A modder might add a component with a hardcoded ID = 20, and later the devs could introduce a vanilla component using that same ID. But that's the lesser issue. The bigger problem arises when every second mod starts conflicting with others, all fighting over the same IDs.
If a modder wants to add their own id, you could create an id based on the last enum value + 1 to make sure it's always non-conflicting
that's what I would do anyway, not sure if there's a better solution
That's in the case that everyone does that tho
Just take a very big number no ?
you could, but thats probably not the best idea
I appreciate the concern though btw, if there is actually something worth putting in an API then I'll probably do it, but I'd want it to be a complicated system for me to put it in an official leaf api mod
Although it's probably better to have it in one mod, and then let people add mixins to it as required, how does that sound
I'm also just trying to limit how much separate repositories I have to make, because maintaining each one sucks ๐ญ
Agreed, a sort of library mod ?
Yea it sounds awful to handle
yea, to temporarily get around TIS spaghetti
but also, I don't want to make an API for unstable either, there's too many frequent code changes for it to be worth it imo
Though I could publish a separate unstable artifact, I feel like it's an uphill battle
Yea makes sense
this will not work, component ids are used for serialisation and need to always correspond to the same component
oh like if the id of the component changes, stuff breaks?
this approach will break as soon as:
a) a new component mod is added
b) a mod or vanilla adds a component
c) the load order changes for whatever reason
also, does this mean it can't change ever? if there are conditions for it, i'd like to know
I don't even know what the component is or what its used for
oh... its just ECS stuff
TIS's is not a 100% adherent implementation, systems are collapsed into components, and most legacy logic is not using components at all so most behaviour is still hardcoded to entity classes
but it's the way things are being designed going forward, and definitely how mods should want to
however in the current design component IDs changing will nearly always break something
but what im curious about is if the id when changed, breaks stuff. like does it breaks maps, saves, mod data, etc?
it breaks saves
if it were designed for mods it probably would have used string identifiers instead to avoid this
hmm I don't suppose there's any way around this from an API perspective
string ids would be ideal, but even changing that would also break saves too
you could have a library that persistently maps IDs to a string identifier or something, and allocates from the end to avoid running into vanilla's namespace, but you do risk running out of IDs that way
so basically I think it would be good to have in a separate api, if it's going to break a large amount of people's saves
and it would still cause issues when components are removed
i suppose you could have something like ModComponentContainerComponent that delegates all of its methods to a list of mod components, and saves them with a string identifier
as long as all mod components add themselves through that instead of through the vanilla system you can fix a lot of those issues without having to mess with vanilla code
and it would give you the ability to expand the component api if needed
so that would be compatible with vanilla?
or are you talking about just an api for the component stuff even if it breaks
basically just```java
class ModComponentContainerComponent : Component {
ArrayList<ModComponent> components;
public void anyMethod() {
for (ModComponent component: this.components) {
component.anyMethod();
}
}
}
ohh wait I see
you would add this as a single component to an entity, and then mod components would add themselves to this component instead of directly to the entity
and thats technically only 1 component
that way you can handle deletions without messing with vanilla code
since the IDs and handling of them are up to you
Also, the concept of components in TIS game, the names give me no impression of what it actually is
Like what would a LuaComponent even do in the concept of an ECS?
it does literally nothing, they dummied out the code
but it would delegate its calls to lua functions
(i suspect it's dummied out and not truly unimplemented because there's an enum for lua calls which makes no sense if they never implemented it at all)
ok I should ask, if you know, since I'm still confused.
like whats the goal for a component in TIS codebase currently (or even in the future)
hmm I dont think im asking the right question lol, or phrasing it correctly
to add behaviour to objects in a way that is generic and reusable
ok, so it's just half-baked is the reason why im so confused, because it seems they've implemented it 1/4 and not fully
yes it's half-baked, it would be an immense amount of work to port all legacy functionality to use it, and i don't think they even want to do that
but new functionality generally uses components, and reworks of old functionality too
oh so they're probably doing a "add more components as you go" kind of thing
yeah
fluidcontainers are definitely the best example of its use
of the components that do exist a lot of them are completely unused/unimplemented or barely do anything at all
some of them relate to features that haven't been added yet and some of them would imply way bigger reworks required
existing features i would expect to use components in the future would be things like item containers and radios
hmm I agree this is going to be relatively difficult for them to migrate to their component system quickly, it will probably only be half done by the time b42 comes out
i don't think they'll go out of their way to migrate things to components as much as they'll use it for things that it's convenient for, the examples i gave are things that already use composition anyway so it's not much of a change
i don't think we'll ever see the end of IsoPlayer or anything, even though with traditional ECS design you would not have entity subclasses at all
that would be my ideal future as well, i'm quite a big fan of ECS design, but i'm aware that it's an immense amount of work that probably isn't ultimately worth it
As much as the inheritance tree sounds good for a game, imo ECS system is far better for longevity
also keeps the subclass crisisโข away
then you get classes with basically no implementation only for the purpose of inheritence and nothing else
inheritance is rarely a good paradigm, and i think TIS has probably noticed this by now, but it'd be an incredible amount of work to extract everything out into components
inheritance is generally only useful when you have a very shallow inheritance tree, it's not the best to design something this large around
sometimes I wish they would just say, "hey we are working on a Project Zomboid sequel, and redoing the engine in full 3d, but some devs will still work on content updates for the live branch"
having the game in full 3d would basically allow for a live in-game map editor
you could get away with a somewhat-live in-game map editor currently, but I wouldn't trust it's stability ;-;
Iโve just started getting into all this ECS stuff. If I understand the concept correctly, adding new mechanics and systems to the game should be relatively simple and fast.
I believe ECS systems are actually present in the code, named EngineSystem
I'm already working on a couple of component-based mods - I'll see in practice what kinds of mod conflicts might arise
oh interesting, i hadn't actually seen this
it's still a divergence in the way that components aren't supposed to have any code at all, they're meant to be POD only and all functionality is provided by systems
but i didn't know they had any implementation of systems at all
Using your previous example about FluidContainer - there's a system called FluidContainerUpdateSystem. It calculates how much water should be added to FluidContainers during rain and is also responsible for petrol evaporation.
Maybe that is new? I thought the rain in fluid containers was a relatively new update
yeah, it was added not too long ago - around 42.5 or so, I think
it's actually 42.3.0 I believe:
Add FluidContainer meta-entity system, and push fluidContainer components to meta, so rain collectors will be filled with water when player is away.
unironically you just reminded me of an issue/missing features from loom ๐
What's everyone's opinion on also including a bat/sh script like the game does but for leaf? Would anyone even use this?
Of course for the client, it's intended for 95% of users to use the bootstrapper like everyone else, because it's far more modular solution than having to write and edit scripts for batch/bash. But since servers don't have this luxury, it's already on my mind.
After I get leaf settled, I am going to do a fair bit of related stuff with pz (but not Java modding yet, I think its been enough Java for me considering I've been basically only using Java for the past year just to work on leaf)...
launch option is good enough, only thing that would make it better is if you manage to add a "Launch with Leaf" option to the menu steam opens when you try to launch the game
there's a program that let's you edit those can't remember the name though
Yes, but assuming they are added in the appinfo.vdf where htey are stored, Steam will replace this..
So it's not very viable for an actual feature
Honestly, using an alternate launcher like Playnite allows for adding custom launch configs too, it's a nice software, but I understand most peple dont use it
Spent the whole day trying to add my custom component to theComponentType enum.
Not as easy as I expected ๐
yes it's certainly tricky since enums are I believe mostly constant
you either have to do some wacky interface stuff or bytecode patching iirc
actually you could hack the helll out of reflection to do it
Using this example, I almost got it to work. I just need to figure out how to access the new component from Lua.
https://github.com/SpongePowered/Mixin/issues/387#issuecomment-888408556
thats a nice solution, I completely forgot you can use (who would have guessed) mixin/mixinextras annotations to do it ๐
Ok adding new components will probably have to go in a leaf-api sort of thing if this is what is going to be done, because stuff like this exceptionally easy at breaking
infact, I think @Shadow completely nukes mixin compat with other mods trying to mixin the same thing
I tried to access the new component via FromId method but Java expects short type and fails coz Lua uses Double I believe
lua does use double/long yea
The problem is, even if we added a method to convert lua number to java Short/Integer via some java function, lua would =iirc just turn that number back into a double lol
it's a bug in kahlua
it's meant to convert number types automatically, but for some reason it doesn't convert *to* short correctly
it does convert from short, and between other number types fine
of course it is ๐ญ
why do you need to use FromId though?
kahlua exposes enums as tables, just use ComponentType.MyComponentType
Also I was wrong before, that mixin for the enum should be pretty compatible with other ones
Still, it would probably be nice to avoid the boilerplate inplace of one function calla
I tried this approach at first, but it returns nil. Java debugger also displays null for that field. It's not initialized, and I don't know why
i'm not entirely sure how leaf works, are you making your modifications after lua init? that seems unlikely but i don't see why else it wouldn't be there
the mods get initialised way before the actual game is, so yes if you are doing anything that requires lua to be loaded you need to mixin the init for lua
think about mixin like your code was already there before you booted up the game, thats how it is
so in theory, the enum in lua should be fine, because it exists before lua inited
kahlua uses some pretty outdated reflection API, is it possible that mixins just don't cover it?
or at least in Java it shouldnt be null
wdym?
mixin works like placing your code in the class like it was already there, so if you're adding a field to a class, the game (and java) can't really tell that you've added it, it looks like it was already there. think if the developer also added that custom enum member, it would be the same
i don't really know how mixins are actually implemented is the problem
the only point of error is the actual mixin code itself, which it looked ok to me
it has the massive(est) wiki ever on the github
ok yeah i briefly read their description and it doesn't sound like it should be a problem
but basically, all leaf stuff including mod init and mixin class transformations happen way way before game is started, the game's entrypoint is ran super far after down the line
i have to guess that you're not correctly modifying the enum at all then
