mod-dev-talk Thursday 22 July 2021
Replying tocr24it would literally have less verts than the incubator smh
Panes don't count
Replying tocr24it would literally have less verts than the incubator smh
On the topic of the incubator, what do you think of em?Replying toSolly@CDAGaming Is the one who insists I not use fapi
^^ for good reason indeedReplying toCDAGamingHell you could throw the Aether into quilt on day-one and it would work 99%
@CDAGaming
...that will happen anyways because quilt will (supposedly) be able to load fabruc nidsReplying toAzzyypaaras...that will happen anyways because quilt will (supposedly) be able to load fabruc nids
They didnt promise that it always would thoughReplying toCDAGamingIt's an eventuality that quilt will diverge enough from Fabric to be incompatible
A compatibility layer will be maintained for a while, if not by us, then by the community.- Does that mean that this should be reopened? https://github.com/devs-immortal/The-Aether/pull/405
Replying toCDAGamingAgain, take a look at 1.18, the existing biome api is 💥
And it is a thing foretold, we know it will break, we can prepare.(edited)Replying tocr24we should be using json for biome garbage for now
We already are by the most part, my very vocal displeasure makes it clear :3See that is the problem here, you are seeing it as a crutchThis is the equivalent of using java and avoiding all of its bundled classes.It is mad, and not the good kind- Who's also to say that the FAPI will even exist in say 5-10 years from now, and half the code is using said API. In the hypothetical that no such miration layer exists, all that code would need rewriting. Grated the API has it's benefits, but it's a double-edged sword especially if one day that api just doesnt exist anymore (Like what occurred with Rift and that whole nightmare)
- CDA, to think, let alone pressume that we can go an entire decade without needing to do any major factors and rewrites is not just mad, it is beyond even being pretentious and wishfulIt is just downright... downright... I can't even think of a proper word to describe itIt is silly, it is ridiculous, it is nonsensicalIt is impossible, that is the best word here, impossible, given our stance as a mod for a game as large and fluid as minecraft it is downright impossible for us to achieve anything close to thatYou need to understand that you are greatly impairing not only you, but the entire team and everyone who wants to play the mod by pursuing something so pointless.
Replying toAzzyypaarasCDA, to think, let alone pressume that we can go an entire decade without needing to do…
True, but I'm trying to eliminate a lot of the time spent on future migrations. (IE instead of looking at both the API and Mojang on what's changed, we'd only need to look at Mojang for the diffs) Maybe I am being a bit paranoid and optimistic on this, but there is some concerns if we rely too heavily on one api.Replying toCDAGamingTrue, but I'm trying to eliminate a lot of the time spent on future migrations. (IE…
A bit paranoid is a substantial understatement here.- We don't need to be the first to every new version, we can take our time, we are after all just a mod, in that same vein wanting to be swift is sensible, but the degree to which you were trying to take things was not. I kind of saw the writing on the wall here as this whole argument feels nigh-indentical to the old "no JiJ" ordeal we had.
- I should have perhaps been swifter to point out the trouble this would bring, snuff out the flames before the fire spread, I am not free of fault here so don't view this as me trying to take some kind of moral high ground.It is ultimately the case that any route we go we will need to migrate things, and trying to optimize around that is ultimately silly as, at any rate, it is a minority of dev time, it is just like the old joke about spending five days automating something that takes five minutes and you do once a month, it is entirely silly! But at the same time, it is easy to get dragged into such things. At all steps we take, the first things that should come into consideration are the time and health of the team, community opinion and enjoyment, and ease of dev in that order, not such minor things as this.And when it comes to all three, libraries, in particular the fabric api itself, are key to have, use, and abuse.Please do pardon me if I came out as too harsh in the middle of that, but I care about us as a team and our ability to create things together, and I do feel like some lines must be drawn so that we may continue development in a manner that is healthy, timely, and fulfilling.
Replying toAzzyypaarasWe don't need to be the first to every new version, we can take our time, we are after…
It isn't just that I want it to be swift, but I also want a future where players can enjoy the Aether together without boundaries. When I began modding, noone gave a damn over older versions of MC, or working with one another across modloaders. People were always at eachother's throats over which loader had the better mods, which loader was better... Sure there were efforts like multiconnect, and ViaX to bridge that gap a bit, but those only scratched the surface of what inter-compatibility should be. The future I'd prefer the Aether to have is one that can work on any loader for the MC versions we support. Atm, for example, Forge and Fabric will almost certainly never work together (And drama spikes up very frequently between both communities), but the possibility to have compatibility cross-loader was proven to be a possible success in earlier experiments (And that was without any changes). The experimentation I did, and my reasoning at heart for my passion and keeping external APIs in non-use as much as possible, is that I'd like us to be the first to prove with an absolute certainty that an experience unbounded by modloaders and different mods IS possible, not made up, and is within realistic goals. The future I'd love to see for The Aether, is where it's community doesn't care which modloader you use --- you'll get the same exact experience regardless no matter what. The Aether's always been about pushing boundaries, and I think we as a team could pull this off, if my experiments provide conclusive results. That's the secondary reason for why I'm so pushy over this, but I'm also sorry if it comes off as me being too optimistic still...(edited)- Just to throw in my 2 cents: while cool that the aether could be loaded on both loaders and cross play would be possible, I'd ask WHY it would matter, since I suspect that most people would intent to use the aether with other mods, not just as standalone with other clientsideeven if they were, clientside mods all have equivalents but even then with GG's aether a division makes more sense anywaysI don't think opting to make it work on both loaders is worth the hassle, forge and fabric will just get different aethers
I suspect that most people would intent to use the aether with other mods
The point is that this would also work, for client-side mods on both loaders. The server-side will always have it's limitations (This is especially true with Forge's having more restrictions that prevented my experiments from taking place)Replying tocr24I don't think opting to make it work on both loaders is worth the hassle, forge and…
While it would be less hassle, it would be effectively fracturing The Aether's audience in half, likely permanently- Even now, our audience still has to consider the choice: Which Aether version should I use, and which modloader (Both of which are causing fractures) If the experiments are successfull, it eliminates the modloader completly out of the equation for The Aether at least, since you'd have the same experience regardless of which one you choose.
- Such a goal is noble but it is ultimately misguided, it is like trying to solve homelessness by throwing money at it, it can fix some things but it the issue will stand as it is the result of an endless amount of variables(edited)
Replying toAzzyypaarasYou still would not, as near nobody plays modded with a single content adding mod
You wouldnt just be using The Aether, that's an extreme limitation xD The primary point of the experiment is simply just to have a modded server able to accept Fabric and Forge clients with The Aether (Clients can have any combination of mods on their end, provided they dont conflict with The Aether's code). If it's successfull, it means other mods can perhaps flesh out what was started to allow more forms of inter-compatibility.- why would another mod do thisThere are already only very few mods that are both on fabric and forge, most of them either clientside or tinyAnyone who is on forge is not going to port to fabric for this, specially not the heavy hitters like thermal that every forge modpack is obligated to have
- The 1.16 experiments proved it could connect, but gave issues bc of the significant codebase differences, and it not able to handle the non-present mixins (It gave a similar effect to if The Aether failed to load on Fabric). The 1.17 experiments however will use the exact same codebase (With the only changes needed being a build.gradle change, and any mod metadata migrations I'll need to do)
Anyone who is on forge is not going to port to fabric for this, specially not the heavy hitters like thermal that every forge modpack is obligated to have
The point is that you don't need to choose, you dont need to change your modloader for this. - Anyone who is on fabric will have an aneurysm if not only do you ask them to port to forge after 30000 other people have done it, but you also ask them to do a near complete refactor of their code, and while we are not yet to the state of forge we are certainly on our way to have must-have content mods
- Again, for the client-side, you won't need to choose. And bc of the mappings being perfectly aligned in 1.17, the codebase remains the same if you aren't using an extreme API that relies on data not applicable to the other endSo for mods following said principle, things will work to a 99% degree of success in theory (As said theory is what I need to test tomorrow)
- I am going to put this simply and clearly. • No other mod is going to do this except for those you make • AR is already associated with fabric and is going to be competing with both the original Aether and Aether 2 in forge. • A substantial majority of players, specially modded players focusing on adventure mods, play mp, something which I have noted before this would only allow with only itself installed • Cutting ourselves off of libraries gimps development time and our ability to do more complex things, particularly beyond the fabric api • Such a pursuit would completely kill any chance we could have for integrations with other mods • Even if this succeeds the Aether will remain fractured as it is doubtful that addon and content makers wouldn't pick favorites, this will cause a split. • You are harming the project by pursuing this • I will not allow this any further, if you want to continue with your wishful endeavors fine, but fork or else.(edited)
- Could someone please close https://github.com/devs-immortal/The-Aether/issues/374
- @kalucky0 Since it appears you originally wrote it, do know why this was removed? https://github.com/devs-immortal/The-Aether/issues/355#issuecomment-884665612
- I mentioned it before but gud made a library that allows you to add stuff to some hardcoded stuff via tags, forgot the name of itWe were going to add it but nobody got around to it :3We ought to use thatThjrereThese two are also real
@Jack Papel swet blocks when Replying toSollymoa_meat
Trust me, this is one of the less egregious name - id mismatchesReplying toJack Papelhttps://drive.google.com/file/d/1ToI_gfY8IVFehRN5Mqj9Qj-066C9Kjn5/view?usp=sharing
Oh boy a bug alreadyof course it would be thatThat's a cheat so it doesn't count
the black looks grody
