-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge upstream #135
Merge upstream #135
Conversation
This causes an NPE when serialising or opening printers and disk drives. Fixes #1109
No bearing on MC, but allows us to drop the depenedency in other projects (CCEmuX, eval.tweaked.cc, etc...) I'd quite like to spin the core into a separate project which doesn't depend on MC at all, but not worth doing right now.
Fixes #1116
- Switch to plugins { ... } imports for Forge (FG finally supports it!) - Use FG's new fg.component to clean up our Maven metadata instead. We also mark JEI as optional (using Gradle's registerFeature), which means we've no stray deps inside our POM any more.
This reverts commit b7f698d. Apparently slf4j is on the classpath in dev but not in live. Will apply this on 1.18 and later instead.
Just saves us from having to worry about conflicts with other mods which bundle Cobalt. This might make the transition to Jar-in-Jar easier too - not sure yet! Also produce an API jar - fixes #1060.
Forge checks for early access now which is sensible, but given we sidestep Forge's ConfigValue system anyway, not very useful for us :D:. Fixes #1117
Notionally speeds up the build a little, though not really noticable in practice.
No bearing on MC, but allows us to drop the depenedency in other projects (CCEmuX, eval.tweaked.cc, etc...) I'd quite like to spin the core into a separate project which doesn't depend on MC at all, but not worth doing right now.
We removed the config which ran all JavaExec tasks with the given launcher, so need to override this again. A little abusrd that this isn't done by Gradle, but there we go.
* `throug` -> `through`
Spelling error Turtle API
i.e. 1.100.8 rather than 1.19-1.100.8.
Makes it run about twice as fast. Still irritatingly slow, though really want to avoid making it incremental or anything.
- Changed page background to render as one quad, instead of two halves. - Set page background to a z-offset that is between zeroth (potentially bold border) and subsequent background pages. Bold borders were at the same z-offset before.
No longer warns about empty comments. Closes #1107.
Hahah. Serves me right for trying to optimise too much. Fixes #1123.
Was deprecated pre-1.19, just forgot to remove it as part of the update.
Merge gone wrong I suspect. I should probably add a check for this. Fixes #1130. Slightly embarassing that this has been around for 7 months.
Should prevent #1130 occurring again. Possibly worth submitting a PR to Forge for this too.
Been meaning to do this for years, woops.
Rather than blanket disabling http with http.enabled. I think it's still useful to keep the option around, but hopefully make it clearer what the ramifications are.
Closes #1279. The perils of ignoring the transfer API :(.
Closes #1278.
Looks like this was removed in b048b66.
I was having issues where dropped items would clip into blocks when dropped, and then phase upwards through the turtle instead. This makes things a little more consistent with dispenser behaviour.
- Publish Forge and Fabric - Include version hash in the download
See #1278
Co-authored-by: Trenord <luca.ilari@gmail.com>
I originally put cc.import in a separate directory from the main modules. This means that programs must extend the package path in order to import these modules. However, this ends up being a mixed blessing: while it makes it much harder for users to accidentally require user code, it also means we can't expose a public interface which wraps a private module. Instead, cc.import now lives on the main package path, but lives under the cc.internal namespace and is not documented anywhere. Hopefully this should be enough of a clue that one shouldn't use it :p.
I feel like we should have been doing this from the beginning. Love to uncompliant for 11 years :/.
I'm really not sure why the modem one fails. I can't reproduce outside of CI, so quite hard to debug :/.
This gives us slightly better guarantees that the config has actually been loaded. This, along with a FCAP bump, fixes this config option not doing anything on Fabric.
There's still some remaining bugs (#1282), but I think worth getting the fixes for the worst issues out first.
While slightly irritating (requires Cobalt magic), it's much, much faster.
I think this PR is stalled but, as people are using CC:T for Fabric more than I'd like, would quite like to get some resolution here. The main problem as it currently stands is that CC:T for Fabric and CC:R's APIs are incompatible, due to drift over the last year. While worlds are compatible between the two - peripheral mods which target one will crash on the other. I think there's a matrix of options here:
|
Personally since CC:T is officially going multiloader fabric. I am for depreciation of CC:R in favor of CC:T, especially with the API Drift due to the main goal of CC:R being 1:1 parity with CC:T, (Outside of textures and the aforementioned Netherite Tool turtles. Of which I'm still trying to figure out when the fuck those got added) |
Yeah, deprecating CC:R makes sense. Through without unpublishing of current ver and only with a "redirect" |
Alternatively we can wait for 1.19.4, but who knows when it releases |
Yep, happy to go that route! |
As agreed above, CC:T for 1.19.4 publishes Fabric jars as well as Forge ones (see cc-tweaked/CC-Tweaked@2661829), so closing this. |
honestly having one final release for CC:R (an 1.18.2 and 1.19.2/3 release) of the latest update wouldn't be a bad idea in my opinion, would allow resolving a few final bugs. assuming CC:T's official fabric work wont get backported that is. if it does get backported that would also be great |
Yeah, correct. The multi-loader work was a massive piece of work, I have no wish to do it again :). |
I mean in theory it should be as simple as backporting the code a bit, same way you would get normal code to back port but, I can see why one would say no on that front :) |
Yeah, I don't really know how to write a description for this. This pulls in the work on making CC:T multi-loader compatible, which should make it easier to keep CC:R in sync with CC:T in the future.
Fixes #121, Fixes #122, Closes #133. Should also resolve some of the other issues (#130), but I'm less confident there.