#sculptor
1 messages · Page 1 of 1 (latest)
Currently when rebuilding patches against client sources, the PNG files cause issues. Todo: looking at an ignore method.
Potentially have to fully exclude assets/textures, as well as icon png (as no suffix match is currently possible)
Currently the run server task is disabled, intending for me to figure out what arg the client needs to start, at a base level and to add a run client (again optionally showing).
However, since client includes the server sources, I could leave run server there even when doing a client, even if it might be more confusing.
Thoughts?
3e42f25 Improve UpdateVersion task - Machine-Maker
[PaperMC/sculptor] New branch created: feat/better-update
Adds 3 CLI arguments, --latest, --ci and --type to better control how you want to update.
[PaperMC/sculptor] New branch created: update-gradle
3e1ae42 chore: update gradle and silence warning about ... - Machine-Maker
Made a PR since it includes an additional change to silence warnings about mismatched kotlin-dsl versions. https://github.com/gradle/gradle/issues/17016
e9b793a revert back to using original directory names - Machine-Maker
[PaperMC/sculptor] New branch created: old-directories
[PaperMC/sculptor] branch deleted: feat/better-update
79e13a2 chore: update gradle and silence warning about ... - Machine-Maker
[PaperMC/sculptor] branch deleted: update-gradle
7ded89e revert back to using original directory names - Machine-Maker
[PaperMC/sculptor] branch deleted: old-directories
[PaperMC/sculptor] New tag created: v1.0.3
// $VF: Couldn't be decompiled
remove this, doubt anyone cares
this is always true, the mache extension isn't evaluated at this point in time yet, needs to be done in target.afterEvaluate further down in order to take effect
reposting from discord:
client always includes server, right? thoughts on, instead of that enum, using an "includeClient" boolean instead, which will then do the stuff, but still allow server to work? is that possible?
like, having one project where both runServer and runClient can work
I don't think the client includes everything the server does. I think there are dedicated server stuff that is excluded.
The runClient seems to be missing all the resources from the resource pack, like textures and sounds. Also, it should be more explicit about what a user has to manually change in order to log in to the client correctly.
Also, this is just the server jar too right?
Technically, this still only applies to the server jar, since its doing the whole unpacking the bundler. I think its fine to leave the names as server here because of that
This doesn't seem to be used anywhere?
Should we not check if the args contain the flag rather than if it's empty? Or is it intentional so if you override it you can still get the gui?
I think all the getOrElse in this PR should be replace with defaults on the mache extension (so that the defaults are all in one place)
maybe before downloading, we should check if the user has minecraft installed and use that asset directly (still downloading if the particular index doesnt exist).
vanillagradle check these folders: https://github.com/SpongePowered/VanillaGradle/blob/430fbaaaf64b346ad1fb3773f94b996fd60361f9/subprojects/gradle-plugin/src/main/java/org/spongepowered/gradle/vanilla/internal/Constants.java#L60C40-L60C63
I had issues with getOrElse never returning the "or else" I think, which is why I went for checking if the return is empty
Also I wanted to put the defaults in the mache extension, but I ran into the issue where I couldn't get access to the project directory for the default values
I've now realised that I could use string replacement and placeholders, like the decompiler args, but I've got to look how it's done already
d285349 Add workflow for auto-updating mache - Machine-Maker
Replaces https://github.com/PaperMC/mache/pull/15 by moving the logic over to sculptor
f47efb8 re-enable cron schedule - Machine-Maker
[PaperMC/sculptor] New branch created: update-workflow
e8b0fda Add workflow for auto-updating mache (#9) - Machine-Maker
[PaperMC/sculptor] branch deleted: update-workflow
[PaperMC/sculptor] New tag created: v1.0.4
3ca9ed4 use gh app for tokens in workflow - Machine-Maker
2eb809f use mache-sculptor email for update commits - Machine-Maker
ad6e35a fix duplicate resource files in src/main/java - Machine-Maker
[PaperMC/sculptor] New tag created: v1.0.5
This looks good to me as an initial implementation of client support.
In the future, we might want to look into having client classes in a separate source set, with a separate patches directory. But again this is good enough as a starting point for client support.
Correctly call #get on the extraArgs ListProperty to resolve its content instead of calling Provider#map on it, which simply creates a transforming provider based on extraArgs without actually evaluating the transformation logic until queried.
The problem lies in the JGit library not supporting ssh as a valid option for gpg.format. The only format they support is openpgp, but that's beside the point. Since [they don't have SSH registered as a valid config value](https://github.com/eclipse-jgit/jgit/blob/2f1873be7a2a7387482ac...
I've gone ahead and "PR'd" a fix to the JGit library that should mitigate this.
dont we disable gpg signing? or does it fail just with the config set already?
It fails on initialization of the Git repository. The call() method in InitCommand uses RepositoryBuilder to construct a Repository with default values if none are set in the local repo. Because I have gpg.format set as ssh globally, it tries to use it but fails since it's not registered as a value that can be set.

Forgot to mention: It seems to compile with no errors, and ./gradlew setup executes successfully when Sculptor is published locally for use in Mache.
JGit 7.0.0 officially released a month ago on maven central. I've removed the reference to the eclipse repository.
This approach changes the names of the versions/$ver directory to have a -server and -client directory respectively.
Then it modifies the migrate task to migrate both server and client directories to the new version.
It might make sense to use the server patches to patch the client and only have client specific patches in the client module but right now it's just a concept and this can be worked on if decided to go with this approach.
I updated the open task to reflect the new build script.
It still won't work for all versions because it fails to parse the MacheMeta file because older versions have missing fields. But it should work for recent versions post #4. I don't know what the best way would be to fix that problem, so I didn't touch it for now.
I tested it with 1.21.3 and it works perfectly.
A small change but this moves the runClientSetupAssets.json file into the .gradle/mache directory instead of the root .gradle directory.
This looks like you are actually moving it from build to build/mache? Is there a reason this is necessary?
I just figured moving mache stuff into the mache directory makes sense.
Right now it would also not be deleted by the clearMacheCache task because it's not in the mache directory.
Ok I think I know what you mean. It initially was in the build directory thats why I kept it there. Are you suggesting to move it to the mache directory instead of the build/mache one?
Ok what i wrote there did not make any sense. Sorry for that I don't know what happened there lol.
What exactly are you implying with your message? Are you saying this is unnecessary and if so, why? Are you suggesting moving it into the ./gradle/mache directory?
My initial point still stands with "Im doing it for consistency and that all mache generated files are in mache directories".
f772026 Publish minecraft dependencies as variants - jpenilla
[PaperMC/sculptor] New branch created: minecraft-deps-variant
10042e6 Publish Minecraft dependencies as variants (#16) - jpenilla
[PaperMC/sculptor] branch deleted: minecraft-deps-variant
[PaperMC/sculptor] New tag created: v1.0.9
a8cb8a9 Fix javax annotations missing from compile clas... - jpenilla
[PaperMC/sculptor] New tag created: v1.0.10
[PaperMC/sculptor] New branch created: feature/configurable-max-heap-for-external-jvms
e0f48ad Allow property based configuration of jvm heap - lynxplay
Sculptor spawns two child jvms during its workflow, specifically
remapping and decompilation. Both of these have been limited to a
hardcoded maximum heap which might be too low in some cases.
The commit allows users to configure their own value for these heap
limitations via gradle properties.
7acc4bf Bump to 4G for decompilation - lynxplay
c691944 Allow property based configuration of jvm heap - lynxplay
[PaperMC/sculptor] branch deleted: feature/configurable-max-heap-for-external-jvms
[PaperMC/sculptor] New tag created: v1.0.12
5170501 Add some debug logging for publishing repo selecti... - jpenilla
[PaperMC/sculptor] New tag created: v1.0.13
[PaperMC/sculptor] New branch created: feature/update-setup-gradle
1613537 Update the gradle setup action to v4 - lynxplay
6022a33 Don't log download messages when quiet is on - jpenilla
[PaperMC/sculptor] New tag created: v1.0.15
[PaperMC/sculptor] New branch created: dev/v2
Updates for Codebook v2 (removed remapping)