Skip to content
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

Closed
wants to merge 270 commits into from
Closed

Merge upstream #135

wants to merge 270 commits into from

Conversation

SquidDev
Copy link
Member

@SquidDev SquidDev commented Dec 11, 2022

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.

SquidDev and others added 30 commits June 16, 2022 07:56
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`
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.
SquidDev and others added 20 commits December 29, 2022 21:48
Closes #1279. The perils of ignoring the transfer API :(.
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
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.
@SquidDev
Copy link
Member Author

SquidDev commented Jan 14, 2023

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:

  • For Minecraft versions, we can either change this for 1.19.3 (breaking existing peripheral mods, though I don't think there's too many) or wait until 1.20.
  • For CC:T vs CC:R, I think we either merge this PR (and then keep the two mods in sync) or just kill off CC:R. Optionally unpublishing the current 1.19.3 CC:R version if we decided to do this now.

@Merith-TK
Copy link
Collaborator

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)

@Patbox
Copy link
Member

Patbox commented Jan 15, 2023

Yeah, deprecating CC:R makes sense. Through without unpublishing of current ver and only with a "redirect"

@Patbox
Copy link
Member

Patbox commented Jan 15, 2023

Alternatively we can wait for 1.19.4, but who knows when it releases

@SquidDev
Copy link
Member Author

SquidDev commented Jan 16, 2023

Alternatively we can wait for 1.19.4, but who knows when it releases

Yep, happy to go that route!

@SquidDev
Copy link
Member Author

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.

@SquidDev SquidDev closed this Mar 15, 2023
@Merith-TK
Copy link
Collaborator

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

@SquidDev
Copy link
Member Author

assuming CC:T's official fabric work wont get backported

Yeah, correct. The multi-loader work was a massive piece of work, I have no wish to do it again :).

@Merith-TK
Copy link
Collaborator

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet