mod-dev-talk Tuesday 8 June 2021

94 messages9 people

Sunny15th04:01
my friend got this error I don't know what happened My friend uses the same API version as me.
message.txtText file, 1018 KB. Not stored in the archive.
cr24Team04:06
Are they using optifine?
Jack PapelTeam04:10
You should have your friend download the latest version of the mod
It appears he's on an outdated version that didn't work for servers
cr24Team04:14
they're up to date
its says on line 9810
Jack PapelTeam04:15
I see the aether 1.0.3 in the mods list(edited)
I can't give line numbers since I'm on my phone but it's here:
cr24Team04:16
its modmenu
Jack PapelTeam04:17
So they're not on 1.0.3? Apologies
cr24Team04:17
Mixin apply failed mixins.modmenu.json:MixinTitleScreen -> net.minecraft.class_442: org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException Critical injection failure: @ModifyArg annotation on adjustRealmsHeight could not find any targets matching 'Lnet/minecraft/class_442;init()V' in net.minecraft.class_442. Using refmap modmenu-refmap.json [PREINJECT Applicator Phase -> mixins.modmenu.json:MixinTitleScreen -> Prepare Injections -> -> modify$zlj000$adjustRealmsHeight(I)I -> Parse] org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException: Critical injection failure: @ModifyArg annotation on adjustRealmsHeight could not find any targets matching 'Lnet/minecraft/class_442;init()V' in net.minecraft.class_442. Using refmap modmenu-refmap.json [PREINJECT Applicator Phase -> mixins.modmenu.json:MixinTitleScreen -> Prepare Injections -> -> modify$zlj000$adjustRealmsHeight(I)I -> Parse]
modmenu 1.10.6 is installed
🙃
https://www.curseforge.com/minecraft/mc-mods/modmenu/files get a 1.16 one its not the aether crashing p sure
Sunny15th05:05
Replying tocr24Are they using optifine?
No
Crackers010612:19
Replying toBlodhgarmWait what amount of ram have you allocated?!? Or I mean how much dose your computer even…
8gb
S
SweepSwap15:19
trinkets is now officially on 1.17
- 👀1
CDAGamingTeam16:13
One step closer, though sadly as I mentioned earlier, there's several dependencies needing updates (Some due to breaking on Gradle 7) Once all the deps are updated, then the real port work can begin 😄
SweepSwap16:15
fabric is so awesome
day one people can port mods over
CDAGamingTeam16:16
Actually earlier
SweepSwap16:16
well yeah
some snapshots are compatible already
CDAGamingTeam16:16
As 1.17 is equal to the release candidates, so most mods already had ports ready to fire xD
SweepSwap16:16
like from the release candidates especially
yeah
and there are already new mods
lol
im glad that the datapack still works
CDAGamingTeam16:17
In time, sooner or later, a Forge and Fabric port will both be stable 😄 Who knows if it'll happen in 1.17s lifespan, perhaps 😛
SweepSwap16:18
Replying toCDAGamingIn time, sooner or later, a Forge and Fabric port will both be stable 😄 Who knows if…
of what
i just looked at a random mod
and that was the first comment(edited)
CDAGamingTeam16:18
I thought you were showing Aether's comments lol
my bad haha
SweepSwap16:18
its aight
why would you need to port aether reborn to forge
Jack PapelTeam16:19
I think he's talking about GildedGames' aether mod
SweepSwap16:19
oh yeah
makes sense
i bet theirs will be drastically different
CDAGamingTeam16:21
I mean tbf, they are adopting the same strategy of porting to data-driven for their biomes and dimensions, so their architecture there is similar
Honestly, there may even be a way one day to load the GildedGames version maps into the Fabric version, bc of the fact that it's data-driven and easily configurable
SweepSwap16:22
so you could literally change most of everything to be the same
CDAGamingTeam16:22
Pretty much yea
SweepSwap16:23
either way around?
CDAGamingTeam16:23
Only main difference in generation would be the block ids, which the namespace could be changed locally to allow compatibility.
IE If both the forge and fabric version adopted the same block namespace and block names, their worlds would technically be compatible with eachother
All theoretical ofc, as noones shown this off in concept, but the math checks out and realistically it should work
Jack PapelTeam16:25
Sounds similar to that bedrock<->java compatible server project that was up a few years back(edited)
SweepSwap16:25
gesyer?
and then floodgate
i used that before
CDAGamingTeam16:26
That would be a lot different sadly, as bedrock <-> java has many more system changes that complicate it
SweepSwap16:26
i managed to play on a java server i made on my ps4
and there was no servers at that point
CDAGamingTeam16:26
This is just data-driven world generation, and in this case, just renaming values xD
SweepSwap16:26
and there are still no external servers
just featured ones
human ingenuity at its finest
Jack PapelTeam16:27
Replying toCDAGamingThat would be a lot different sadly, as bedrock <-> java has many more system changes…
If someone wanted to, it'd probably be easier to make compat with forge aether <-> fabric aether than it would to do bedrock & java
of course once we get all the dungeons and whatnot created
Purely hypothetical, there'd be practically no reason to
CDAGamingTeam16:29
Data-driven stuff would be configurable, but the way we do structures will determine if they can port, but blocks and items would be convertable as long as they use the same namespace and object name
Jack PapelTeam16:30
The server could just translate whatever it needs to, and choose one version for world gen and behavior
CDAGamingTeam16:30
For example, if both ports had the_aether:cold_parachute as the exact same id, what stops mc from thinking (and in this case correctly assuming) that they are the same item xD
Jack PapelTeam16:30
That would be nice certainly
CDAGamingTeam16:31
It's definitly a theory i wouldn't mind testing once both ports are further down the line (I need them both at relatively the same position development wise to reliably test this)
Jack PapelTeam16:32
The player inventory is stored in the world file, yes? You could test it that way - though I suppose that'd just be item IDs
CDAGamingTeam16:34
That too The other thing that would be an issue, is that if the namespaces are different, to publish this change would require a refactor on one of the ports to match the other's namespace (Which would corrupt every old world not based on the new namespace, but would only need to be done once)(edited)
Jack PapelTeam16:36
I suppose it'd have to be us to make the change, since I assume GG's aether will be backwards compat with 1.12 aether(edited)
Are old 0-255 worlds compatible with 1.17? I didn't remember if they made that a thing. If not, now's a better time than any for namespace changes
Actually that's a silly question, I don't believe they'd wreck compatibility considering their use of semantic versioning(edited)
CDAGamingTeam16:47
Replying toJack PapelAre old 0-255 worlds compatible with 1.17? I didn't remember if they made that a thing…
Yes they are, but they may not in 1.18
As the build height and cave changes were postponed to Part II (1.18)
Jack PapelTeam16:47
Ah yes, I forgot
CDAGamingTeam16:48
And yea I personally am all for doing the namespace change sooner rather then later
SweepSwap16:48
Replying toCDAGamingAs the build height and cave changes were postponed to Part II (1.18)
you can check with the caves datapack
CavesAndCliffsPreview_2.zipArchive, 91 KB. Not stored in the archive.
CDAGamingTeam16:48
All the team needs to do that though is permission from GG to use that namespace with intent for compatibility, and confirmation on whether or not that namespace is expected to change or stay for the long-term.(edited)
fishy16:53
Replying toCDAGamingYes they are, but they may not in 1.18
mojang is doing their best to make sure old worlds will be compatible with 1.18, so I’d honestly be surprised if they weren’t compatible(edited)
fishy16:56
Replying toJack PapelI suppose it'd have to be us to make the change, since I assume GG's aether will be…
and no there won’t be compat with 1.12 worlds
cr24Team17:00
we also have some different blocks
what happens with wisterias?
CDAGamingTeam17:26
The different blocks would poof theres no way around that
I was talking about the similar blocks, which is 95% of our blocks and items
AzzyypaarasTeam18:56
Replying toCDAGamingI was talking about the similar blocks, which is 95% of our blocks and items
currently
As updates go on that number will go lower
cr24Team19:15
Lol
Crackers010620:21
tbh I just want a straight up port of Aether I to Fabric
that's why I've been working on my project because I couldn't find an already existing one lol
kalucky0Team20:55
That was the initial plan
But it changed a little bit along the way
CDAGamingTeam22:32
The initial plan was split into two phases: - Make a 1:1 on-par port of Aether I on 1.16 (Having the archive as part of it's foundation) - Add content to it after a stable port to modernize and bring it up to 1.16 terms Eventually (Almost right around the time the ChunkGenerator collapsed), the two phases merged together and became what it is now