The last commit was 4 months ago by Yueh.

Will this mod be updated to 1.12?
Or it just simply depends on whether someone (who has commit rights) will magically have some time to get back to it?

And what about #2306 #2399 ?

it is not dead, but i have no insight on what is mostly beein worked on by now
aemodernport is mostly independend to the basic ae2
and the other issue got closed due to no discussion progress if you scroll up to yuehs last comment on this
this mod is as stable yet as it could be imho, most issues are from external sources (AE2stuff, strange chunkloading, stacking storages with bad API behaviour) and some smaller forge problems and the global energy systems messup since 1.9

and to top up my comment as always:
do not forget to add energy cells, an AE system can only work with an power input of "me system total CAPACITY"/tick and some operations can surge this capacity instantly without energy cells, then the system reboots and act strange

I was giving it a go at updating to 1.11 when 1.12 wasn't out yet (IE, 2 weeks ago to last week), and have a bunch of stuff in a "dirty" branch that I need to clean up before committing.
But I tried to contact yueh first in an attempt to find out if there was stuff that I would need to look out for or attempt to fix / ideas / goals for that version. Since then I haven't really worked on it because I wouldn't want to do any real work if it wasn't effectively going to get merged in the long run.

I was planning on resuming work even if yueh didn't respond last weekend, but a wedding party from one of my friends kind of screwed up my planning.
Once a somewhat "stable" fork of 1.11 is done updating to 1.12 should be kind of easy I'd assume, but with the state of the codebase I wouldn't be too quick to declare that.

it isn't dead,i think just yueh busy now.

After not receiving any comment from yueh about whether or not he'd allow other people to do the update I decided to just bite the bullet and continue my work on the port.
It's somewhat completed, with a few UI's displaying a tooltip where it shouldn't and rendering issues on cables+facades on a specific side.

https://i.imgur.com/dhlb0i5.png

The issue with rendering cables & select blocks that remain : http://i.imgur.com/SU0L5vR.png
UI issue that I still have to fix : http://i.imgur.com/1tHZyza.png
Strangely enough it doesn't happen in the interface, only in the interface terminal.

But P2P's, storage, buses (in/ex/storage), QNB's, assemblers, crafting cpu's, ... work atm.

I tried to stay as close to the AE codebase as possible, in order to not increase the chances of the work that I've put in going to waste eventually.
Yes, it's 1.11.2, but seeing as there's no 1.12 version yet and the original "goal" was 1.11.2 I just decided to more or less complete it for 1.11.2 first.

Last I checked (which was only a couple days ago), the 1.12 version of Forge was still a Beta release. I'd think any attempt at moving AE2 toward 1.12 would be premature at best and a distinct waste of time as worst.

But I do like that it stores air now. (And since this is the Internet, I have to point out that was humour. Really.)

@mgdgfbhevdyeh Algo abandoned the project long time ago. At around when the channel system was implemented. Users complained way too much about how complicated it is (which is not).
(Much like Notch did with Minecraft itself. He got fed up with users complaining non-stop about everything.)

I added an issue tracker on my fork of the repo to keep track of the port.

It'll be less off topic this way.
GuntherDW#1

If you want to try out my port to find any bugs that I haven't catched yet you can do so at https://github.com/GuntherDW/Applied-Energistics-2/tree/rv5-1.11 . (No public prebuilt jars available just yet. It's a bit too early to put it into production packs.)

@mydexterid i know those.

To make it short: No, not really alive.

This is mostly due to me lacking the required time for it. Of course this could potentially change at some point, but do not count on it.

On the other hand, if I actually have a bit of time to spend on it, then I am really lacking the motivation for it. Forge tries to pretty much everything to make the development harder and harder each time.
Like I am no longer able to debug AE indev with any other mod present as normal .jar as the classloader completely screws up. Neither the normal or deobf build or whatever. Some mods seem to work, when available via a maven repo, but that is rarely given. Which is just bonkers for a mod mainly designed to link other mods together. And no, resorting to System.out.print() is certainly not an option...

A port to 1.11 is probably still possible, but there are so many things left which are based on 1.7 or 1.8 and thus are really messy. So a quick port to 1.11 will certainly make it way more messy. I quickly scanned over the current attempts and there are probably many things, which might work now. But they are guaranteed to break once Forge or Vanilla changes something. Probably in a very obscure way. Combined with the lack of time to actually review any possible PR, I cannot really accept them with good conscience.

1.12 will probably be way worse. I really expect the new recipe to majorly screw with AE2.
Not that I do not like the idea to have .json based recipes. It will actually be similar to what we already have. Just without us having to maintain the actual code.

But I expect that they will be mostly designed for vanilla recipes. Which will be fine for the basic recipes like the decorative blocks. But probably break for anything oredict related or more complex NBT stuff. Forge will probably provide a half cooked solution for it, which will allow some recipes to work, but still force us to write our own system. Stuff like the facade recipes, inscriber recipes which do not consume all items, etc. Thus we will end up with some recipes using the Mojang .json syntax, some Forge and some are either hardcoded or using something completely incompatible.

As we are not the only one affected by it, I highly expect to every other mod implementing their own system and of course a good amount will implement it in such a way that it totally breaks autocrafting.

A really major break will be that Lex in his infinite stupidity seems to have decided that every mod is no longer allowed to have blocks or items disabled via config. (As the config will not be loaded at the time you have to register your blocks/items)

Something AE2 highly depends on. On one side as a feature to allow mod pack makers to customize the pack. Which is now gone, every player can simply spawn in any blocks they miss, regardless of the authors balance idea. Or just simple things like disabling silicon or redundant dust/ore/ingot types. Also gone, let the player have fun dealing with 10 different copper ores...

The more serious part is that we need it in certain cases. Like once channels are disabled, we have to disable controllers and smart/dense cables as it will otherwise cause havoc. Which pretty much means we have to completely redesign the grid system. Or remove the channel option and have the vocal majority constantly whine about it. Having different implementations, say to fallback to a dummy implementation, which just adds a decorative block, is of course also not possible. Thanks to the config file not loaded. Or we have to write our own config system..

So for 1.12 I pretty much expect these requirements:

• Rewrite the whole recipe system to be a bit more user friendly and integrate it somewhat with the vanilla one. Should the vanilla/forge part be lacking (expected)
• Rewrite the whole grid system to allow it to handle disabled blocks/parts after they are needlessly registered to prevent it from blowing up.
• Rewrite the GUI stuff, mostly due to grid, block registration and so on.
• Rewrite the network handling, mostly to being like forge 1.7.0 alpha state and of course GUI/grid/registration stuff.
• Probably rewriting autocrafting to handle the coming custom and broken recipe implementations
• Rendering of course, it is pretty much a 1.10 wrapper around a 1.8 wrapper around a 1.7.10 render (and I would not be surprised, if some parts are copied from AE1 in 1.6.4 or even 1.5.2)

All in all pretty much touch/rewrite the most complex parts of AE2. Combined with already expecting that 1.13 will be another major break. Like there are still talks about removing metadata, which would be one option to avoid the registration part (put everything into a single itemid and just use metadata just as now. Only on a ridiculuous level).

In terms of the other port (modern one). I would not expect anything. They spent like last year to redesign the API part, which was just a fancy way to query the GameRegistry for a certain block/item/whatever and have convenient methods to create an itemstack or similar (or null when disabled).
Which of course is completely wasted time with 1.12 as it no longer allows blocks/items to be disabled.

luckily, recipes aren't that horrible in 1.12 forge.

and those jsons not being horrible can play well into autocrafting.

That rendering error is fixed, along with 2 others. Also fixed an integration issue. I don't have my repo accessible right now to bother listing them all.

Can't you guys combine forces? Right now it sounds a bit like it's a competition. ;) I know for a fact that GuntherDW has been working on his port for quite a while and that it pretty much works. It's a bit a waste of time to both work on the same thing.

Well I just found out what caused the rendering issue by diff'ing the 1.10 files with the 1.11 files. Looks like it was something that yueh comitted... I don't know why I didn't do this sooner.

I don't treat it as a competition, I started mine without knowing about Gunther's. I simply work differently and haven't pushed my commits worked on this week yet

Sure the basic recipes are pretty easy. But none of them have NBT data or more requirements.

Like the facade recipe is just any itemstack + 4 anchors. But it has to meet some requirements like

• Being a block not item
• Being a solid/opaque/full block
• No TESR or similar
• No other fancy rendering (two pass whatever)
• Some more

any is probably already outside the normal features. Maybe the factories can solve it. But then it is forge. Thus half is NYI and the other half is useless. At least for any sane solution. Like I seriously do not want to have to mock a fake world as it is no longer an ItemBlock and we actually have to "use" the item on a mock BlockPos to observe, if it could place a block. Which then blows up because they expect a real world as they need the chunk coords for tinting the block..

You can bet something is missing in forge and we have to find a workaround, probably a risky one which could cause a player to loose their inventories due to unable to detect full or empty cells or something similar or open the can of worms and have to implement a custom solution.

well, i'm sure there's people kind enough to help :)

So that basically means AE2 is dead?

A rewrite is a noble idea, of course, but if there isn't a port that works in the meantime, the mod will probably be obsolete by the time the rewrite is done. That would be a massive shame of such a fantastic mod.

In other words, wouldn't it be a better idea to provide a working 1.11.2 port, and then think about rewriting parts of the mod? It seems to me that it's a bit premature to think about all the possible ways 1.12, 1.13 or forge can break AE2 in the future. Isn't it a matter of crossing those bridges when we get to them, and work with what there is at this moment and at least make it so players can enjoy AE2 in 1.11.2 playthroughs?

i'm still waiting on full 1.10 support, even some passive remarks to current issues would be nice other then just silence. If ae2 gets dropped in the future fine ill figure something else out but in the mean time its a central feature in many packs still, at least those that don't used refined storage (which at this point is tempting even for me)

Like I am no longer able to debug AE indev with any other mod present as normal .jar as the classloader completely screws up.

@yueh Can you elaborate on that? I've had no (unsolvable) issues in dev environments with other mods & AE2

But they are guaranteed to break once Forge or Vanilla changes something.

In other news water is wet...? 1.11 should be in non-breaking changes stage, but yes it's natural if something changes in the core code things might break...

A really major break will be that Lex in his infinite stupidity seems to have decided that every mod is no longer allowed to have blocks or items disabled via config. (As the config will not be loaded at the time you have to register your blocks/items)

Just because they're registered, doesn't mean there has to be a way to craft it (i.e. don't register the recipe, have there be a condition that depends on config, etc). If someone cheats it in, well that's on them. Otherwise you're trying to 'balance' creative, which seems a fool's errand to me.

@JelmarG

So that basically means AE2 is dead?

Only in the sense that there won't be a release from the original team due to their personal time constraints. As it is open source others (myself being one of them) are working on "unofficial" ports independently which by the terms of the licence should mean that the original team can integrate that code in the future should they so desire.

As for 1.12, once forge is stable regarding recipes it will be looked into and dealt with by someone in the community, I'm sure.

@thiakil You and @GuntherDW could team up. His 1.11 port is pretty much done. I'm sure you guys can get a solid port going on.

I'm sure we will eventually. Right now my port is actually further along, just not yet public.

@thiakil could you define that "further along" a bit more? My first point was getting a base up and running, IE a version people could actually start playing on ready. Any and all "improvements" or other "fixes" would come later.

Besides the rendering thing which I'm having issues with (This is the first time I'm actually doing any sort of rendering code with forge so it's a bit "experimental" for me), what else is there still to do?
QNB's work, P2P's work.
I could re-enable or add the WAILA/IC2 interfaces, other power networks, and add the fixes that are in the 1.10 version (in fact my "dirty" repo had just that), but IMO getting a version up and running for 1.11.2 was of more importance to me in the end.
Once I've figured out what exactly was changed or is causing the issue it's done. Time to "release" and start implementing the rest of the 1.10 stuff and bugfixes/improvements/features/....

I'm sure there are enough people who would be willing to to help, even if it's a lot of work. But if there isn't a central figure within the owner group of the repo to actually lead the endeavour, there will never be enough manpower. That'll probably sink the mod before anything else.
Wow, I didn't expect yueh describe the issue so extensively, but it is very useful to know what he thinks about the project.
Although as I see he mostly wrote about problems and not solutions.

Probably applies to both.

The solutions are pretty limited. I could probably dedicate some time for AE2, but more towards project management. Say issue management, development roadmap, "mentoring" and so on. Maybe a small bugfix here and there or code review. But that is pretty useless without any real development. Bit of a chicken/egg problem. Without a lead, there won't be many changes. But without devs, there is also nothing to lead.

Also having a high dev turnover rate is also not helpful. I certainly cannot spent a month explaining the internals to some new dev, just to have them leave 1 month later because some reasons.

Very likely means that for non-deobfed mods that they aren't handling the Forge runtime deobf (for modern Forge anyway). Or, in the case of deobf builds that the mcp mappings used were a different snapshot, which the deobfCompile dependency handles and needs to manually be done for non-maven deps.

I already considered it. But neither normal jars nor deobf work. Regardless of matching mappings or not. I even build custom deobf version with matching forge versions/mappings or changed AE itself. Etc.

The moment it runs via debug. The IDE probably uses a real javaagent to inject debug/sampling/whatever and then fucks with the forge homebrew class loader. It kinda works with largly forge independent mods (JEI for example). But the moment it touches blocks and forge wants to asm patch the crap out of them it fails to actually patch them and dropping the class completely. I also talked with mezz, asie, some others and iirc cpw. But even they have no idea.

Probably started around the end of 2016 or beginning of 2017. So it not always happening. Or at least I did not run into it previously. Like maybe it would have affected it previously, but just a reduced amount of mods. Until forge decided to asm more stuff. Like similar to the fluid breaking stuff during 1.7.10, where they asm patches old mods in the hope they will then work with the new system.

This specific example sounds like a failure in the coder using the function.

And that applies to some of the forks on a quick glance. Like some comparisons against Items.AIR (isn't that null?), when it should probably be itemStack.isEmpty(). If mojang or forge has the glorious idea to make air -1 it will probably explode in some rare edge cases. And then you have to ask yourself does it crash because AIR is no longer null and you should fix it to still consider it as AIR or was the port faulty and it should actually be isEmpty().

What on Earth would be causing a crash in this instance?! If you block is registered like it is supposed to be there would be no Forge crash. Are you suggesting AE throw an exception if a block disabled in config is placed? That would be a dick move.

It kinda applies to channels/controllers. Disabling channels will also disable the controller as well as smart/dense cables. Which is required because it does not actually disable it, but remove the upper limit. With that in mind, cables could transfer thousands of channels, but the rendering etc is still expecting at max 8/32 to select the right textures. So keeping the cables is not really an option. While we could simply use Math.min(amount, 8) or so, it will still be confusing to display any value between 0-8/32 even with disabled channels.

Something similar applies to a controller, they are more like a flag to a grid and the moment they are present, it will fall into a controller based grid. Not an adhoc network with a limit of 8 channels (or infinite with disabled, but still an adhoc). So the moment a player places them it will also not longer work with disabled channels and fallback to a normal grid.

It would be an option to have like multiple tile entity classes and just replace the normal one with a decorative dummy one, which does not count as flag. But thanks to forge, we have to register the stuff before knowing channels could be disabled...

Not explicitly, no. The CC NonCommercial clause prohibits uses that are "primarily intended for or directed toward commercial advantage or monetary compensation."

The CC NC is really vague here. It really depends on who you ask or what you read and goes from "yeah, you can use as long as you don't sell it directly" to "You cannot make a single cent, even indirectly".

With Curse being actually amazon now, I have no idea how they would manage it. At some point another mod might decide to fuck with them. Which then causes amazon to simply ban everything based on CC NC as a precaution.

Is this listed somewhere? Can it please be? Sounds like useful information to me.

Pretty much the list in my first post. But to summarize it shortly

• Everything inventory related (A horrible mess of IItemHandler as well as I(Sided)Inventory
• Everything network related (AE2 was one of the first mods developed for 1.7.0 and forge missed much of the current stuff like the SimpleNetworkWrapper or however it was called. Not that the implementation still sucks...
• GUI/Container/Slots also a custom implementation, while Forge iirc now provides default ones for most cases (like the fake slots for the bus config)
• Always rendering. It's a serious mess wrapping a couple of minecraft versions. The texture problem in 1.11 is most likely caused by it. Flipping it might work, but it's guaranteed to break other stuff. Like we still have the problem that facades are flipped on some sides. But the moment we fix that, cables suddenly have their textures flipped on some sides...

And that applies to some of the forks on a quick glance. Like some comparisons against Items.AIR

Indeed, I see no need to compare to AIR, should be handled by IS.isEmpty() anyway

Cable renders - I'd be setting it to 0 and display as if no channels were going through it.

Controller / Grid type - I imagine the check for a controller would need to be adapted to stay in ad-hoc when channels disabled.

Unless it has changed since I last looked, the TEs don't have to be rendered (EDIT: registered) in the Block/Item events, should still be possible to do after config loaded.

@yueh Can you elaborate on that? I've had no (unsolvable) issues in dev environments with other mods & AE2

I have not really an idea what is causing it. Just that the classloader or asm patcher is unable to load/patch classes when launched in debug. And then failing with a ton of ClassNotFoundException. Launching it via a gradle task is totaly fine, but they are not debugable. It is just a fancy way for gradle build && cp build/libs/*.jar /path/to/instance/mods && minecraft launcher. So completely unusable.

In other news water is wet...? 1.11 should be in non-breaking changes stage, but yes it's natural if something changes in the core code things might break...

This is not about forge/vanilla breaking something during with a new major version. These are intentionally caused by violating the contract or at least intention of something because "but it works".
Like using a randon function in forge, which clearly states returns 1 for negative numbers, -1 for positive, but happens to use Math.signum(), which you need. So instead of simply using -Math.signum(), you are using the forge wrapper and then start to whine, once they change it to return i < 0 ? 1 : -1 for performance reason, while still maintaining the original contract.

Just because they're registered, doesn't mean there has to be a way to craft it (i.e. don't register the recipe, have there be a condition that depends on config, etc). If someone cheats it in, well that's on them. Otherwise you're trying to 'balance' creative, which seems a fool's errand to me.

So you find it ok, if the game crashes in creative mod just because you placed a random block?
Also there are still things like minetweaker/crafttweaker or others. Should we crash on launch when detecting one of them because they could allow to add a recipe for a disabled item? Wait.. even minecraft has a custom recipe system... should we crash when detecting the mod being loaded in a minecraft environment?

Only in the sense that there won't be a release from the original team due to their personal time constraints. As it is open source others (myself being one of them) are working on "unofficial" ports independently which by the terms of the licence should mean that the original team can integrate that code in the future should they so desire.

While the code is technically open source, there are further limitations for the assets. Which for example forbid any monetisation. So the obvious ones are you cannot participate in the curse reward program, use ads in any way or accept donations for developing it. But these are just the easy ones. There is also a good chance that hosting it for example on curse might violate it, because curse itself uses it commercially. But a fork will not be able to give curse a license for it. At least not without new textures, models or other assets. Which also cannot be based at all on the current ones.

So while it sounds nice on paper, actually forking it and also being able to distribute it might be tricky. Like you could use the github releases or your own website (as long as no ads, sponsoring etc), or simply build from source. But that is certainly very inconvenient for any actual player as no modpack could really include it without having the players manually download AE2.

In other words, wouldn't it be a better idea to provide a working 1.11.2 port, and then think about rewriting parts of the mod? It seems to me that it's a bit premature to think about all the possible ways 1.12, 1.13 or forge can break AE2 in the future.

1.12 is already released and most mods will start moving towards it. Thus there will be not many reasons for a 1.11.2 modpack. It is really not ideal with having the community split into 4 versions (1.7, 1.10, 1.11, 1.12). As like each one is missing some mods, so you cannot simply move your pack from 1.10 to 1.11 without losing some mods.

Isn't it a matter of crossing those bridges when we get to them, and work with what there is at this moment and at least make it so players can enjoy AE2 in 1.11.2 playthroughs?

I hear that a lot. But it usually means "let's run away from the bridge as long as possible". Of course long enough so the original bridge no longer exist and you have to build your own.
While it is true, that planning for 1.13 is pretty useless, at least we should get rid of the stuff, which is just 1.7.10 ballast and dragging us down. Sure we could make a direct port to 1.11 solve all the fixes and then skip straight to a direct port to 1.12 (which is already released) and fix everything with workarounds again. Once that is done, 1.13 is probably near its release and so on. At some point we have to stop and rewrite stuff in a major way. Otherwise it will sink the mod at some point.

The main problem is that we simply lack man power. Sure there are people around, who claim they want to help. But it usually dries out once they realise is not like 20 LoC and we also have to enforce some requirements. Like not pulling every change someone proposes. While fixing their issue/feature, it will break every other existing solution. Which is simply not an option.

I'm sure there are enough people who would be willing to to help, even if it's a lot of work. But if there isn't a central figure within the owner group of the repo to actually lead the endeavour, there will never be enough manpower. That'll probably sink the mod before anything else.

And then failing with a ton of ClassNotFoundException

Very likely means that for non-deobfed mods that they aren't handling the Forge runtime deobf (for modern Forge anyway). Or, in the case of deobf builds that the mcp mappings used were a different snapshot, which the deobfCompile dependency handles and needs to manually be done for non-maven deps.

So instead of simply using -Math.signum(), you are using the forge wrapper and then start to whine, once they change it to return i < 0 ? 1 : -1 for performance reason, while still maintaining the original contract.

This specific example sounds like a failure in the coder using the function. If you need Math.Signum, why not use it? Unless the wrapper method mentions in its javadoc the exact same output for positive/negative zero, you cannot depend on it being the same as a function it so happens to call in the version where you looked at the code.

So you find it ok, if the game crashes in creative mod just because you placed a random block?

What on Earth would be causing a crash in this instance?! If you block is registered like it is supposed to be there would be no Forge crash. Are you suggesting AE throw an exception if a block disabled in config is placed? That would be a dick move.

Which for example forbid any monetisation. So the obvious ones are you cannot participate in the curse reward program, use ads in any way or accept donations for developing it.

Not explicitly, no. The CC NonCommercial clause prohibits uses that are "primarily intended for or directed toward commercial advantage or monetary compensation."

Granted, it does say that's essentially up to the rights holder to decide, but do you really consider being part of a version port mod a primary intention for monetary compensation? If I took those textures and put them in a resource pack targeting another storage mod, and then gained money from that, then yeah I would consider your rights violated. Compensation for effort put into porting and maintaining a mod would be the primary purpose in AE2 as a whole's case.

Also at the end of the day it's pretty much a non-issue unless you, another member of the original team, or the texture creator decide to pursue action.

1.12 is already released and most mods will start moving towards it. ... snip

Largely this is a philosophical issue, some people prefer jumping straight to the latest version and dealing with everything at once, others find benefit in doing it incrementally and having extra version support as a positive. To each their own. Same with the running away from the bridge part.

at least we should get rid of the stuff, which is just 1.7.10 ballast and dragging us down.

Is this listed somewhere? Can it please be? Sounds like useful information to me.

Wow, I didn't expect yueh describe the issue so extensively, but it is very useful to know what he thinks about the project.
Although as I see he mostly wrote about problems and not solutions.

I can also understand while a lot of people saying they could help with the port, why yueh thinks they will dry out quickly.
What I think is somewhat inline with JelmarG. There needs to be someone who conducts people what should be/shouldn't be done. If yueh doesn't have the time for this, he should let someone else do it.
(someone else with push/PR accept permissions?)
(If I knew Java I would also help with the rewrites, but fortunately (in this case un*) I only know C++ well enough))

@Ommina http://www.minecraftforge.net/forum/topic/58991-forge-14211-minecraft-112/
Those guys are working fast these days.

About the checks against AIR, I should indeed redo those checks, or rework them. I was planning on redoing the inventory stuff indeed anyway. It's a garbled mess at best.

Rendering is not my forte (ATM), so I'll probably leave that to other people.

But as I stated in a previous commit. My first intention was getting something up and running, after which we can "clean up" or even do some required rewrites whilst the playerbase at least has something to play with. That might lead to ugly code, but I'd rather have a happy playerbase than one that has to wait for 5 months to get something released because there's no dev around to rewrite 75% of the mod.

The debugging is also quite weird. I'm using IntelliJ myself (community version to be precise), and have had no real issues with debugging. Other than the bytecode not matching the source sometimes at least.

@GuntherDW there is a difference between a rewrite to solve long standing issues, and needing a rewrite because you ported things incorrectly. The point is that you shouldn't have needed to check for AIR in the first place, as you're just asking for hidden bugs that are going to pop up for you later - for example AIR is not the only thing that makes a stack empty.

And that's just one example of bad band-aid code. In another instance you changed a core Platform method to make something that uses it work, instead of fixing the actual problem.

@yueh good news for the config discussion earlier (added emphasis mine)

Modders: It is now recommended and HIGHLY encouraged that you use the RegistryEvent.Register functions when creating your block, items, potions, recipes, etc... These events have changed to being fired after pre-init.

I know that "Items.AIR" is not the only thing that makes a stack represent itself as "empty".
I also know that a couple methods and "band-aids" that I applied are bad. That's why I tagged them as such. They are not meant to stay like that.

I only did that to get something up and running. That "Platform" change is the first thing I did in the codebase before I even got something up and running, I was planning on going back on a couple of the things that I hastily did to fix it up correctly.

Also, the rewrite is not only because I ported stuff incorrectly, it's as yueh said clear as day that big parts are in need of a rewrite because they got patched up continuously instead of receiving the care they needed.
The "AIR" thing is because my IDE was complaining on it never being null, and a quick glance at the code that it was calling showed that it, like an ItemStack, could never reach "null", but gets a default value assigned as well. I am far from finished on those regards.

I should maybe not have committed everything, in spite of some prying eyes blaming everything on some hastily done code that's probably get "fixed" in the end. I should maybe have kept my stuff hidden as well then, or at least not in such great volume as this.

What really saddens me though is the vitriol towards each other instead of trying to get AE2 back up and running in a playable state.

Hasty fixes are what leads to a mod getting a reputation for being buggy and unstable (and there will always be someone who gets that impression even from an unofficial release from Github). Github is a form of peer review, so yes your code is going to be critiqued, especially if you're offering it up for people to actually use as a release.

In some cases it might actually have to be compared against AIR and not isEmpty(). Technically there might be no difference, but it has a different semantic. That is certainly a small advantage with 1.11. But that only applies once it is ported correctly.

Also I would not ignore the IDE doing bullshit. Especially with Intellij, we are at a point where the IDE thinks it is better than the developer and starts doing all sorts of stupid things. Like reformating a string (say block id) from 'ae2.blocks.foobar' to "ae2 . blocks . foobar" because it likes to put spaces around dots...
Thus I would not be surprisedm should it suggest AIR as replacement for null in certain cases.

Regarding the "vitriol", that is certainly not the case. Nobody will write perfect code and therefore at some point will commit something stupid. Of course the port is not done. But it is a pretty large amount of work, so reviewing it once it is near completing is way more work than some incremental feedback here and there.
Better have someone say it is really stupid, even if it might hurt someones feelings, than staying silent and watch it break.

Quick update as I had a bit time to look over the forks.

GuntherDW's is pretty much a straight port to 1.11. There might be a few bugs here and there or maybe a bit too quick'n'dirty. But these should be easy to iron out.

thiakil's is nearly at a point, where merging it back is no longer an option. It reintroduces already fixed bugs. Removes code we actually need for various reasons, like forge being lackluster or it might simply not be obvious why it is needed. Yes it could be simply copied back, but that destroys the whole history. Which is already a nightmare because it happened when AE2 went open source and reconstructing a specific case and why or how something was fixed/changed/etc (or not) is very tedious. Further it tries to add features back, which we deliberately hold back in anticipation of Lex fucking with coremods. Which of course did not happen in 1.11, but now in 1.12. Especially with FTB now being even more restrictive as forge itself. Ultimately it will result making a port to 1.12 even harder as we might not be able port these features at all.

FYI: There was a 'Townhall' meeting on 1.12 /forge/coremods with Lex, cpw, and others, on FTB's official twitch channel. You can watch the whole thing here: https://www.twitch.tv/videos/155878312
Unfortunately a bit long and no transscripts yet.

It reintroduces already fixed bugs.

Could you give an example?

Removes code we actually need for various reasons,

The update checker is the only thing I can think of that I straight up removed.

As for for "tries to add features back, which we deliberately hold back in anticipation of Lex fucking with coremods", which I can only assume refers to the integrations, only a couple of small parts of that actually NEED the coremod, and even then, only because of how it's coded.

@yueh don't blame the guys for adding/removing things they don't know they shouldn't have.

Instead let them know what is the direction/what is the condition to accept a pull request, also document those "various reasons" for not removing/removing code, because noone can see inside your head to find out why they shouldn't have done what they've done.

Make a development section on the wiki or something and document! Write everything down you have in your head about the project.

@mydexterid I certainly won't waste nearly 2 hours to watch them ramble about some useless stuff. If they are not able to write the requirements down as text, I pretty much don't care and simply consider it as "core mods banned". Yes, I know you can bundle them as .jar inside your .jar. But they need to be signed and what not. Which the current build server does not support. Changing it might not be possible or if it could take a long time. Replacing it completely is of course also an option. But that also requires a new website/wiki or a better ingame documentation (like the botania book). Nothing which can be done in an hour.

Could you give an example?

Off the top of my head some rendering related stuff like flipped textures. Because the obvious fixes were already tested and dropped because correct rotated facades means incorrectly flipped textures on some parts of cables. That is why I listed it as needing a rewrite. I would not be surprised, if the original code is from AE1, which included all weird 1.5/1.6 behaviour. Which then is wrapped somehow to accommodate to counteract rendering changes/fixes in 1.7 and so on. I am just making that up, but imagine something like 1.5 having a bug that the top texture was always mirrored, because the vertices were ordered backwards, so AE1 had a workaround for 1.5. 1.6 then fixed it but now had it rotated by 180 degree instead of mirror. So it was wrapped somehow to mirror it twice and rotate it by 180 degree again. Then add whatever you can imagine the port to 1.8/1.8.9 did break or add to it.

The update checker is the only thing I can think of that I straight up removed.

That (because we need it as the forge one will not work). Also API things like the MEMonitorThingy. It might still be needed for addons. Therefore it was still part of the API as long as there is no alternative.

As for for "tries to add features back, which we deliberately hold back in anticipation of Lex fucking with coremods", which I can only assume refers to the integrations, only a couple of small parts of that actually NEED the coremod, and even then, only because of how it's coded.

Pretty much all integrations, which are not based on caps. So OC tunnels (which where always a bit broken). Or the IC2 tunnels (these might actually work without coremod or optional, but the whole P2P design does not really fit perfectly).
Also pretty much all wrench integrations. thirdparty needs to go away. A public maven repo is a requirement to be considerd as integration. Ideally with an api artifact to avoid polluting the dev enviroment, increasing loadtimes and so on. (And this also includes no ivy workarounds pointing to a fixed curse forge url or similar)

@yueh don't blame the guys for adding/removing things they don't know they shouldn't have.

Instead let them know what is the direction/what is the condition to accept a pull request, also document those "various reasons" for not removing/removing code, because noone can see inside your head to find out why they shouldn't have done what they've done.

Make a development section on the wiki or something and document! Write everything down you have in your head about the project.

This would pretty much be the perfect approach. But it takes time I do not really want to waste, should nobody actually decide to contribute something. Ideally continuously and not a one time port. Of course I cannot expect it, reallife can always change and make it hard to continue. But AE2 is also not a project, which can cycle through a new "intern" every 2-3 months. It is a bit too complex for it. Or at least not in a state that you can easily hand to someone, who might not have the knowledge about AE2, but is firm enough with forge/minecraft to maintain decorative blocks or simple tools. Maybe also add new ones, if there is a need (and we actually have someone for textures).

I can also understand, should someone not want to work under someone, who just makes up the user stories and hands it off to them for the actual work. I personally do not like the idea that much considering it is still a pet project, but it is probably necessary at least in the beginning to give a direction and keep the design ideas behind AE2.

As I didn't get any response to offering some free time for project management, which a wiki, better contribution guidelines and so on could include, I can pretty much only watch 2 (or maybe more forks) competing instead of combining their resources and judge a potential merge candiate on some some internal requirements, goals, etc.

@yueh There are of course written requrements here: http://www.minecraftforge.net/forum/topic/58706-regarding-minecraft-112-and-policy-changes/
They were just discussing this in the video I've linked, which you can listen only to like a podcast.

Regarding project management/wiki. First and foremost I think written guidelines would be much appreciated, and the wiki is a good place for it. There were numerous useful and detailed info in this issue and I remember other issues containing other bits and pieces of info. So all of these should go on a wiki.
If you just dump it on I can make sure to sort it out if you don't have time for it.
But it first needs those text to be written and it seems noone can do this but you.

And also please don't feel like you're wasting your time documenting this project. There will always be people interested in AE2 and this will make those people's life much-much easier.

I have yet to see a working solution. One of the main problems are the inset parts of smart/dense cables.

My solution seems to work at least for the tested Bookshelf block. Wouldn't surprise me if there are still edge cases though, I haven't tested absolutely every block. Bookshelves were simply the easiest due to the asymmetry.

Cache probably needs some testing, no idea if the memory consumption is worth it as it should only be needed on chunk updates and it could easily contain severel hundred of blocks.

Currently it's marked in the source as a TODO, and sounds like a good idea to me (its basically the point of the baked model system). At the very least caching blockstate+side -> texture would prevent having to do an extra quad generation (to use getQuads) each time.

It simply cannot compare the version.

I beg to differ.
[Forge Version Check/INFO] [ForgeVersionCheck]: [appliedenergistics2] Found status: OUTDATED Target: rv5-alpha-1
ComparableVersion tokenises the version and will compare integer values. String values must match exactly. Indeed it could fail if you had say different RV versions on the one MC version, but that is currently not the case. Should that become an issue codenames instead of rvX would be an easy solution.

This is extremely limited and can easily break.

You would only need to strip them if the interfaces don't exist. For cable bus, the layers simply need not be added (e.g. when I had neglected to re-enable the IC2 layer, the cable did not connect), and nothing should load them. As for AERootPoweredTile, RF would need to be refactored, possibly like what is done to the cable bus layers. I can't see where IC2 power is externally exposed externally either.

As for that RedstoneFlux class, I'm not even sure it's needed, as FE is widely supported, even by TE/TF itself.

Like you could still have a X P2P tunnel and it will render as successfully connected, but simply does not work, because the only condition to render a connection is an instanceof X

Completely incorrect, if the integration is not enabled, the layer is not added, and it is not an instanceof. Additionally the tunnel item/part should not exist or otherwise throw an exception when it is created.

One reason is simply that ForgeGradle does not handle multiple sourcesets that well. So anytime you rebuild the project, it messes with the IDE config and you have to manually fix it. So pretty annoying, even with a single file.

I'm not exactly sure what you're getting at here, never experienced such a thing myself. The only issue I have with adding the files to git (either directly or as a submodule) is that they can be a pain to update. But thankfully they don't really change often. I've been meaning to ask KL if he'll make a pre-1.12 api jar too.

As said, it kinda depends on the interest for it. I won't be able to guarantee I can spend a fixed amount per day/week/month on it or that I am able to give you feedback on the same day/hour. It might take a few days or maybe a week depending on how complex it is.

I'm happy either way honestly; I don't mind handling all that myself - even if that means requiring a fork. If users don't like it being a fork and interest drops in favour of an 'official' copy, then so be it. I also certainly don't expect to create a pull-request with my branch as-is, that would indeed be silly as I've specifically marked a couple of things as not suitable for reintegration.

Indeed I messed up the UVs initially, but that was fixed in a later commit that made it do the different stuff only for facades.

Facades use a baked model, from the new rendering system. Currently only lacking caching, which is pretty trivial.

What won't work about the forge updater? All it needs is a json file, which can be loaded via github. Which is exactly what I have done for my fork. I even wrote a gradle task to generate it.

I moved MEMonitor because it was marked to be moved and rv5 is a new api version and as such I believe api breaking changes are fine. Sure, you might not want to reintegrate that, but I got the impression it was unlikely to happen even if you did like the code.

Yes the p2p tunnels require a bit of modification, however forge can strip interfaces as far as I know, and the layers don't need to be added if the integration is disabled. Nb: no I haven't looked much into this yet, as I have been focussed on other stuff, so lack of knowledge may show. Coremod can stay for as long as it needs to. I can setup my dev server to do whatever I want.

I use gradle deps whenever possible. I didn't check if build craft had one no, but that's only one file, and I personally don't see the problem. Cofh has to be done via gradle for 1.12 by their rules.

As for the project management comment, I think it got lost in all the rest of what we were talking about because it didn't sound definite that you could spare the time. Thats just my view on it anyway.

Indeed I messed up the UVs initially, but that was fixed in a later commit that made it do the different stuff only for facades.

I have yet to see a working solution. One of the main problems are the inset parts of smart/dense cables. On some sides they are flipped with pretty much every fix we have tried before. I am pretty much at the point blaming minecraft itself for it. Like instead of rendering the inset part, it is actually a qube with a transparent side and we see the backside rendered, therefore the textures are actually flipped.

Facades use a baked model, from the new rendering system. Currently only lacking caching, which is pretty trivial.

We had a couple of ideas for facades. Like stop rendering the 2px sides as the block texture. Which should make it way easier to render blocks with multiple texture passes (which is not that trivial to render on a non full side). Cache probably needs some testing, no idea if the memory consumption is worth it as it should only be needed on chunk updates and it could easily contain severel hundred of blocks.

What won't work about the forge updater? All it needs is a json file, which can be loaded via github. Which is exactly what I have done for my fork. I even wrote a gradle task to generate it.

It simply cannot compare the version. So it could report an older version as "new". Or not work at all. So pretty much useless when the only use is to show if there is an update, but actually failing at it. Maybe it is possible to integrate the result somehow into the forge one instead of printing it to the log or integrate into other updater mods.

Yes the p2p tunnels require a bit of modification, however forge can strip interfaces as far as I know

This is extremely limited and can easily break. Like EnderIO pushed a RF beta release in 1.7.10 as release, thus forcing everyone to update their mods and release a new version before every player could resume playing as it crashed constantly. Our system at least allows it to be deactivated in the config, so it does not stop you from playing. It also gives a modpack maker the option to restrict for example the energy type a player can use to power RF. Like maybe they want to force a player to use IC2 reactors as only power source for AE, while still having some RF mods. Of course you can wrap every method into an if(integrationsX.isEnabled()) and try to provide a disabled implementation, but that might be not possible. Like you could still have a X P2P tunnel and it will render as sucessfully connected, but simply does not work, because the only condition to render a connection is an instanceof X

I use gradle deps whenever possible. I didn't check if build craft had one no, but that's only one file, and I personally don't see the problem. Cofh has to be done via gradle for 1.12 by their rules.

One reason is simply that ForgeGradle does not handle multiple sourcesets that well. So anytime you rebuild the project, it messes with the IDE config and you have to manually fix it. So pretty annoying, even with a single file.

As for the project management comment, I think it got lost in all the rest of what we were talking about because it didn't sound definite that you could spare the time. Thats just my view on it anyway.

As said, it kinda depends on the interest for it. I won't be able to guarantee I can spend a fixed amount per day/week/month on it or that I am able to give you feedback on the same day/hour. It might take a few days or maybe a week depending on how complex it is.

Currently it's marked in the source as a TODO, and sounds like a good idea to me (its basically the point of the baked model system). At the very least caching blockstate+side -> texture would prevent having to do an extra quad generation (to use getQuads) each time.

TODOs are not "this must be done exactly as written". Instead these are mostly ideas that these things might be nice, but need further evaluation.

I beg to differ. [Forge Version Check/INFO] [ForgeVersionCheck]: [appliedenergistics2] Found status: OUTDATED Target: rv5-alpha-1 ComparableVersion tokenises the version and will compare integer values. String values must match exactly. Indeed it could fail if you had say different RV versions on the one MC version, but that is currently not the case. Should that become an issue codenames instead of rvX would be an easy solution.

You cannot pick the one case, where it does not fail. There are tests for it, which need to succeed. If not, it is simply broken. I would even consider the tests being incomplete in regards of testing against a completely broken implementation. Cases like 2 > 10 are missing and I would not be surprised should forge fail here, too.

It is the usual example of Forge lacking any foresight. Instead of also providing a way to register different version schemes. Either by allowing to point to a class to reflect it (meh), or have a version scheme registry so you can register them. Which would also solve issues regarding the mod dependencies on specific version ranges. Instead the fallback to the usual "I do not see any need for something different than semver". Even when most mods do not even use semver, but still try to enforce it. While the sentence before did state "We do not want to enforce any standards, we just consider the project as some sort of abstraction layer on top of Minecraft, not a real library for making it easier to develop mods"

Integrations/Tunnels.

This is not only about tunnels. These are way more forgiving towards missing dependencies, stripping and so on. It is mostly about the full support. Like we can easily add RF tunnels, even without using our coremod. But we cannot add RF to power AE itself. So we would end up with a RF tunnel, but the player is not able to use RF to power an energy acceptor. There is no way to explain that to a normal player.

Further the it comes with massive downsides. Like not being able to debug anything related to tunnels. It is just guessing or debugging it on a piece of paper and then completely missing something obvious, which would immediately pop up when debugging it with an IDE.

Weren't we talking about forge's version check not working? Those tests test your version checker.

These are for any version checker. Regardless of the implementation. Even the forge one has to pass all tests.

It compare integers as integers - if it didn't Semver would not parse, as last I knew 1.2.1 < 1.12.1

rvX-channel-b is not an integer. Maybe it parses the last one as int and compares it. But then we have the issue of rv5-alpha-1 > rv5-beta-0, which is simply false. Maybe it tokenizes it. But then does it only tokenize on .? Thus failing at -?. It probably also does not know anything about stable > beta > alpha. Regardless. The implementation is not relevant. If it passes the tests, it's ok. If not it's simply broken.

TODOs are not "this must be done exactly as written". Instead these are mostly ideas that these things might be nice, but need further evaluation.

And I'm of the opinion it should be done. You seem not convinced, that's fine.

You cannot pick the one case, where it does not fail.

I can't fault that. Though I'm struggling to understand where this failure state you're certain of comes from. Which tests exactly are you referring to?

But we cannot add RF to power AE itself. So we would end up with a RF tunnel, but the player is not able to use RF to power an energy acceptor.

I'm going to assume here you mean "whilst retaining the ability to disable with config and the only other option acceptable to me is to omit it entirely" (please do correct me if I'm mistaken) as otherwise it doesn't make sense due to Forge's own stripping avenues. Your statement only holds true if AE is not modified to accommodate the no coremod state.

I can't fault that. Though I'm struggling to understand where this failure state you're certain of comes from. Which tests exactly are you referring to?

The unittests you deleted, that might be the reason you don't find them. For example it must follow rules like rv5-stable-1 > rv5-beta-10 > rv5-beta-2 > rv6-alpha-0. If it just falls back to a string comparison because it is neither a semver nor an integer, it might do the usual char by char comparsion, thus rv5-beta-10 < rv5-beta-2 or report a rv6-alpha as update for a rv5-stable, which should never happen. Except when subscribed to an alpha or beta channel. And no, assuming there will only be a single rv per minecraft release is false. Technically it should still be rv4 for 1.11 or even 1.12, while we could easily have rv4 and a rv5 for 1.12, while also having a rv5 and rv6 for 1.12.4. rv just indicates the API version and as long as there is no beta release for one, we can break it at any time.

I'm going to assume here you mean "whilst retaining the ability to disable with config and the only other option acceptable to me is to omit it entirely" (please do correct me if I'm mistaken) as otherwise it doesn't make sense due to Forge's own stripping avenues. Your statement only holds true if AE is not modified to accommodate the no coremod state.

Requirements are simply:

• Can be disabled by a config setting
• Need to be automatically disabled on faulty or unsupported API versions (no crashing)
• Can still be debugged with a normal debugger and breakpoints, regardless of "But IDE X has a special plugin for it"
• Supports generics
• Nice to have would be
  • Some visible notification, when disabled due to faulty/unsupported API outside the usual log spam.

The unittests you deleted, that might be the reason you don't find them.

Weren't we talking about forge's version check not working? Those tests test your version checker.

If it just falls back to a string comparison because it is neither a semver nor an integer, it might do the usual char by char comparsion

It compare integers as integers - if it didn't Semver would not parse, as last I knew 1.2.1 < 1.12.1

@yueh That requirements you just wrote. Now that should be on that Wiki page I mentioned.

Now we're getting somewhere.

From what I can gather

• You assume things are broken until they are proven working or you understand the implementation
• You have not looked at how Forge actually parses and compares versions (there are still so many 'maybe's and assumptions in your comments)
• If tests are present any features that replace the tested component need to have equivalent tests, especially/even when replaced with a Forge feature, in order to be accepted in PR

That last one sounds like what mydexterid is talking about with listing the requirements. I agree with listing them, though they should probably go in Contributing.md rather than a new wiki.

Now, talking about the version checker specifically has got us side tracked. I have removed the AE update checker from my fork, because I don't want it. As I have mentioned previously I have no intention to PR that branch as-is. I will remember to not include the updater commits in that if I do make a PR.

If you are curious (or want to contribute to allowing a custom parser), the relevant code is @ https://github.com/MinecraftForge/MinecraftForge/tree/1.11.x/src/main/java/net/minecraftforge/fml/common/versioning

The version checker is just an example. It is simply easier to argue about it as it has some well defined requirements and not touches some vague game balancing ideas. Simply liking something, might still not be a good idea. Like I am very certain many player would like the terminals to simply open the creative inventory and you can cheat in anything you like in survival. It would still be totally broken on terms of game balancing.

You assume things are broken until they are proven working or you understand the implementation
You have not looked at how Forge actually parses and compares versions (there are still so many 'maybe's and assumptions in your comments)

No, it is not me guessing or not knowing the implementation. The maybe are based on something different. The reason I consider it broken are a couple different ones.

The first simply the documentation for it. Which states it splits along . or -, compares either ints or strings or a sequence of them. In case of strings it also has some well defined keywords being prefered, as last option simply case insensitive lexical order.
So in other words rv5-beta-0 will be split into [rv5, beta, 0]. rv5 is not a well defined keyword, so lexical. This means rv10 < rv2. So already false. Then beta will it will work fine with alpha as both are well defined keywords and ordered in such a way that beta > alpha is true, it means finally it is beta > alpha > stable. Also wrong. The build number is the only thing it can actually compare correctly. While it can even compare rv6 > rv5, it will not allow the option to not consider an alpha as upgrade for a stable.

The next part is that the versioning is actually pretty old and predates even our own version checker. (I am not aware at which point the actual checker was added to forge). But our one was simply added as it was necessary due to the requirements. Not because we liked having to add our own.

The maybe are actually based in experiences like the forge documentation not always being correct or simply being outdated. But on first glance it exactly does like described (minus potential bugs).
Further as it does a case insensitive lexical ordering, this can get pretty interesting when not using enUS as locale. As they can have different rules for converting a char to lowercase. Thus with bad luck it could inverse the ordering in some cases. And that is not something technically, it already happend to a many mods when being used in a turkish locale.

Additionally it does not even follow semver itself. It is just the basic MAJOR.MINOR.PATCH with the addition of hyphens to work with the forge custom scheme and some special keywords (which semver does not define).

If tests are present any features that replace the tested component need to have equivalent tests, especially/even when replaced with a Forge feature, in order to be accepted in PR

We do not have many tests. But if they exist, they have a reason. Not because it is fun to add them.
There is of course also the option to completely change something when moving to another system. Like we do not have to keep the current version scheme. Semver would also be fine.

But the website and buildserver are working together and only support the current one. As it uses some closed source libs, only Algo has access to it, thus every modification has to go through him and of course can only be done once he has free time for it. So it is not something we can decide to implement tomorrow. It might simply take a couple of months.

There is of course also the option to change the buildserver/website. But that means finding and maybe paying for a host. Or hope that travis&co support every feature we need. Including deploying to CF, our website, etc. Of course also a new website. Or even better a good ingame documentation as alternative.

I am pretty convinced, you will agree that simply keeping the version scheme and have a small custom update checker for it is clearly the better option in terms of time efficiency.

That last one sounds like what mydexterid is talking about with listing the requirements. I agree with listing them, though they should probably go in Contributing.md rather than a new wiki.

Depends on how much info it is. You do not want to have a 200 page long Contributing.md. It should be more abstract and if needed point to more specific pages. Like there should be a mention about "All tests must pass. If possible include unittests.". But it should not explain every unit test in detail.
Similar the version scheme is not really important for any contributor. It is something the team decides. But it would be helpful to have a specific page explaining it for devs and players.

... (or want to contribute to allowing a custom parser) ...

This is pretty easy. I cannot contribute to forge at all.

The first is just my personal decision, so that is not really important. But I do not intend to deal with "I, Lex, do not need this.".

The actual important ones are that I cannot sign the required CLA at all. As it is simply illegal. I raised that concern when they switched to it. But the response was pretty much "Look, ubuntu and other projects also use a CLA, so it is fine to have a CLA as long as we call it a CLA." But the important part that the ubuntu CLA or pretty much any other is written in a way to avoid legal issues, the forge ideas is pretty much "As long as it is called CLA, we can put anything in it. Even when being illegal".

Which of course is also pretty interesting, because someone could sign it. But being illegal means it is pretty much void. Thus they could simply claim that forge stops to claim the contributed code to be under their ownership and either comply with the gpl, which for some bullshit reasons they want to avoid, or stop distributing forge as long as it contains the contributed code. But that is not the only way to deal a major blow like the bukkit drama to forge. Regardless that gets seriously off topic, but just to give an idea why I will most likely never contribute anything to forge.

No, it is not me guessing or not knowing the implementation. The maybe are based on something different. The reason I consider it broken are a couple different ones.

You said categorically it doesn't work, but then include things like "oh it might do this or that", to me implying that you don't know and mistrust it.

So in other words rv5-beta-0 will be split into [rv5, beta, 0].

Nope. From the javadoc, the very 2nd point:

transition between characters and digits also constitutes a separator: 1.0alpha1 => [1, 0, alpha, 1]

I added some tests for giggles, all of them pass. So lemme know if I did it wrong. Never written java tests before.
https://github.com/thiakil/Applied-Energistics-2/blob/rv5-1.11/src/test/java/fml/VersionParserTest.java

Then beta will it will work fine with alpha as both are well defined keywords and ordered in such a way that beta > alpha is true, it means finally it is beta > alpha > stable. Also wrong.

My tests seem to say that's not what happens.

While it can even compare rv6 > rv5, it will not allow the option to not consider an alpha as upgrade for a stable.

If you have an alpha/beta in recommended then that's a developer error. Forge checks against the recommended key, and compares that. Only if recommended is null, or the current evaluates to newer does it check the latest key.

You said categorically it doesn't work, but then include things like "oh it might do this or that", to me implying that you don't know and mistrust it.

Mostly because I have dealed enough with forge and their shortcomings once it is no longer trivial to implement. Like claiming to only load the latest API version, which simply is missing and it will fallback to first come, first serve. Or even not loading the classes from the .jar it actually claims.

Nope. From the javadoc, the very 2nd point:

Might solve it for rv, but can easily break other approaches. Like once you have a base36 encoded value and actually need lexical ordering for it. Not broken up into multiple segments of strings and numbers.
Luckily it does not affect AE2 (currently).

Also as said it does not comply with semver and there is no "But it works in 80% of the cases". Either it is compatible or not. The easiest test is using versions like 1.0-beta+commitHash. Semver does not allow anything after + to be considered as comparable. So 1.0-beta+a and 1.0-beta+f are the same version. Forge will of course claim one being outdated.

If you have an alpha/beta in recommended then that's a developer error. Forge checks against the recommended key, and compares that. Only if recommended is null, or the current evaluates to newer does it check the latest key.

recommended is not something we choose, but the actual player. stable for AE2 is pretty much "finished development, only breaking bugs will be fixed". Thus beta is not rarely a better option to follow the development (API stable, feature stable, only bugfixes) or even alpha in some cases.
Which means that is has to recommend rv6-beta-0 as update when playing rv5-stable-2 depending on the players choice. While not showing rv6-alpha-0 as update when only subscribed to the beta but not alpha channel. Which also means should someone still play on rv5-beta-123 it cannot choose rv5-stable-0 as target should they choose beta and there is a rv6-beta-0 release.

Even if everything else does luckily work for now, this part is still missing.

I am currently sick, so I am looking around to say hi o/
I am glad, that there is still progress (slowly but surely)

Cheers,
ich

Nice seeing you still around.

Just for an update for the people who want to use AE2 on 1.11+ you can use/download thiakil's fork from here:

Please refrain from linking to license violations.

Would be really nice to have this on the original code, but it does not look like it'll happen in the near future. :/

@yueh please refrain from playing a jurist when you're clearly not one, and you don't know what you are talking about.

You already gave them that permission by having Applied Energistics 2 on Curse/Twitch, so I'm not sure its actually relicencing (but IANAL etc etc)

It is sadly not that easy. The GPL kinda works by forbidding everything, but then granting the permisssions under certain conditions. Which also includes that you cannot explicitly give these permissions again like the Twitch ToS requests.

There are a couple of ways around, but none really applies to AE2.

The easist one is having only a single author, then they can choose whatever license they want and relicense as they see fit. In this case Twitch could itself take over the mod and maintain it themselves or contract it to someone. But nobody else could modify it as the license is only granted to Twitch.
This is simply not the case here due to many contributors.

The next would be similar but using a CLA which grants the single author full permissions, potentially even exclusive. But that is really tedious. These CLA services are a bit dubious and might not be valid at all. Any large project with CLA handles them via printed and signed documents send via snailmail. So easily a couple of weeks to contribute the first line of code. After that is is pretty much like 1. This can also include other licenses not prohibiting relicenses. E.g. MIT only, but these have their own issues like not covering contributions => CLA again. This goes even further as you cannot simply hand over these CLAs to someone else otherwise stated and that might be even legally questionable depending on your local laws. So we are speaking about incorporating a "AE Software Development, Ltd", so the CLA can use this company and if needed "sell" it or hire a new "CEO" to keep maintaining it. Pretty tedious for a minecraft mod and probably also not cheap.
Also does not apply to AE2.

In case of AE2 we have mainly LGPL and many contributors. This is all fine. Forks, contributions, distribution, modifications are all covered. But the moment we hit Twitch and their ToS, we actually have a huge issue. The upload is done by a single person, in this case Algo. But Algo cannot grant the permissions as stated in the ToS as he does not own the contributions. And nobody else has agreeded to their ToS. So actually every single contributor would have to agree, in writing, that they allow it to be uploaded to Twitch (Meh, CLA again). Which we are of course not doing. So technically AE2 itself is violating the GPL already and any contributor could request us to take it down on Twitch. So even the option of Twitch giving the permission to someone else does not work as they simply do not have it.

This does not apply to only AE2, but pretty much any project using (L)GPL, CC SA/BY or the less frequently used MPL or EPL and probably others I forgot. Depending on how they handle Forge (LGPL) it might even apply to every modpack out there. They are aware of it and want to change it. But I honestly doubt there legal team would support it. The basically have to flat out accept every license a mod would throw at them. Until someone adds 10 bucks per download to it. Just imagine their already overwhelmed review process now also requires a full legal review each time. Or they have to restrict it to a set of acceptable licenses to be used for mods.
But even these might be pretty limited. Like they cannot allow every CC licenses and maybe even (L)GPL as these can be pretty costly to handle on a case by case basis. CC BY-ND could be a real problem. Using work licensed under it for moving images with music explicitly counts as adaptation and is forbidden to share it with others. I might be wrong, but the last time I looked a very small part of Twitch was about showing moving images, often with background music to some viewers. So they might face some funny situations about recommending a modpack and then having their streamers being taken down for it.

@mydexterid I recommend reading the Twitch ToS. They explicitly state that you grant them permission to modify, adapt, sublicense, etc without any limitations. Yes, the fork is perfectly fine. Putting it anywhere else while adhering (L)GPL/CC BY-SA-NC is also fine. But by uploading it to Twitch you relicensed it under a non GPL license, which is explicitly forbidden. There is no "but they do not intend to use it", just request it is sufficient. It is pretty much a textbook GPL violation.

They are aware of it and claim planning on changing their ToS. Due last week according to my informations. But nothing changed and certainly any lawyer would have major concerns about allowing any license out there to be used. But until then, any GPL based project cannot be hosted on Twitch except by the original authors. I know it sucks, but if you have an issue with it, forward your complains to Twitch.

@yueh ok, so we're now going somewhere.
You are not arguing about the license violation of lgplv3/nc-sa (not talking about api, which is still in debate whether it can be licensed at all or not) and alike, but uploading it to curse, which uses Twitch's ToS which - unfortunately - explicitly states: "unrestricted, worldwide, perpetual, irrevocable, fully sub-licenseable, nonexclusive, and royalty-free right to (a) use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform and display such User Content" (the uploaded user content that is).

So we all know that noone (no any other license, nothing) can invalidate lgplv3, but by uploading it to curse the uploadees themselves are violating the licenses. (Which unfortunately true). So the updated content should be distributed by other means (not curse) up until they modify their ToS.

Yes, just the Twitch project is an issue. The fork on github is fine including hosting compiled jars there or buying your own server to host it or find any other file host not violating the GPL or CC. CC NC adds some additional limitations, so compensation the hosting costs with ads or donations is out and making it a net loss, which could be an issue for some.

It is the usual example of using GPL in a corporate environment. You have to embrace it completely and it will pretty much get rid of any license questions at the cost of having everything open source, which reduces your revenue to things like support or bounties for specific features should the customer not have the resources for it (or if they have it, you can just port their stuff back for free)
Once you try to fit any copyleft license into your usual work, it just becomes a clusterfuck as well as a nightmare for most business people. Making the source public is like their greatest nightmare.

That is also why I doubt Twitch will actually update their ToS. Their business model is simple not designed to work that way. They do not have the resources to deal with the additional requirements enforced by certain licenses. Therefore they go for a broad permission to cover their butts and should an issue arise, they can throw their hands up and claim it is the users fault and not theirs as the acted in good faith.
Mods are simply not a large enough part to justify their own special case. It is actually an example of something you want to get rid of. Thus I expect them to simply ignore it and hope nobody pulls a bukkit and takes the majority of modpacks down.

In terms of AE2 it is even more complicated. The current releases are all done under the old Curse ToS, which did not state these permissions. Iirc it was only about granting them permissions to distribute/display it. Which technically also violates GPL. They already have it through the license itself, but it cannot be granted again as that makes it no longer "distributed under GPL". But that is really something for a lawyer.
The more important part is that Curse could not simply switch their ToS. They have to notify everyone and let them accept the new terms. Iirc it also has to be an opt-in for at least EU citizens, otherwise they have to consider it being rejected and would have to remove the content. Which of course never happened. Probably because they have no idea about any other person than the project owner.

So yeah. A huge clusterfuck currently.

Regarding the API, you cannot really protect the interface (not java interfaces), but the actual implementation is protected by whatever license. Depending on your country, you might already have the rights to reimplement/reverse-engineer any software you like as long as you do not use the original code. But it can still use the same interfaces to ensure compatibility with addons or other 3rd party integration.
In Java terms, you can pretty much use the method signature of public methods but not their method body to create a clone. But then other IP stuff might still apply like patents (meh). E.g. you have to use a quicksort instead of some patented, but proven to be faster algorithm for these particular use cases.

@yueh It seems I have to agree with you on this one.
(and not mentioning the debates between v2 and v3 version of GPL, and Stallman will of course make v4 if needbe)

Hi everyone :) just joining in and (kinda out of context, but) mentioning this fork: https://github.com/AEModernMCPort/Applied-Energistics-3-ReOver

Although it's a complete do-over, I think it has potential.

Short Disclaimer: I am neither endorsing, nor helping that port.

All in all what I'm saying is this project has like 3-5 forks already. I think everyone involved in this whole thing should "agree" on a central repo where they can work from now on. Because having multiple people work on the same thing without helping out each other is a total waste of time and code.

(I'd also like to help develop in the future. For now, I just have to perfect my Java skills.)

Judging by the fact that a 1.12 branch is now visible on this repo, I'd say that a central repo has been established. :) Yueh and GuntherDW are working on it atm.

@JelmarG Oh, sorry, my bad. It seem to have slipped my mind to actually check this repo. In the meantime, I still think that all the forkers should help out this project.

Also, I'm looking forward to a Code of Conduct. Currently this link points to nowhere.

Wtf. Why is this missing? Since github allows to pollute your repo with like 10 different files for the contribution guidelines, issue templates and what not, they also allow you to put it into .github to keep it tidy. This is the correct one.
So the question is how did you reach it?

@forcemagic Just to put it into a perspective. They spent more than a year to rewrite the part which registers blocks and items to forge and the best part is that forge might make it completely obsolete. So go figure how long they will take to add any real functionality.

The more important part is that Curse could not simply switch their ToS. They have to notify everyone and let them accept the new terms. Iirc it also has to be an opt-in for at least EU citizens, otherwise they have to consider it being rejected and would have to remove the content.

They would have notified everyone via email and presumably mentioned that continued usage (e.g. leaving your files up there) implies acceptance of the terms. The EU point is likely moot, because the terms have a Governing Law clause, which quite probably existed in the old terms.

@yueh Forge, forge. Yeah. I actually know that feeling cause I wrote a mod in 1.7.10 and... Guess what forge did? A big @Deprecated over the top of everything. (I could not even figure out how to send a chat message with all that ChatComponent mess)

Btw, the readme should really be updated :D

@forcemagic I think that ample opportunity was given to people involved to work together, but without naming names, it was clear that some individuals treated it as a competition to see who could beat the other in getting a working port. A certain degree of arrogance was also noticeable. I don't think that is the way to go forward, and I think it was clear that cooperation wasn't going anywhere. Especially when code is kept local so any form of criticism or input is impossible.

@JelmarG Oh. Now I understand. Thanks for clearing that up for me. And I'm sorry for the inconvenience, didn't want to interrupt with something that... Was already clear. :) I was just surprised that there are sooo many forks :D

@forcemagic No worries, didn't mean to come off harsh. It would've been much better if everyone had worked together. And I think @GuntherDW would still be up for it. But it might be too late, dunno. Then again, I think Gunther's port is pretty far along already, so AE2's future is quite secure. :)

@JelmarG It is @GuntherDW fork, we basically worked together the last weeks, but he simply did not feel it to be in a state to pull it back. Which left me to basically just giving some feedback, but no actual coding. At least now it's way easier for me to also fix stuff here and there when possible.

Also we would have not issues about accepting others contributing. We just won't go around and cherry pick stuff back. But should someone wish to contribute specific features, sure go for it. It is probably a good idea to give a basic outline first, so there is a chance to provide feedback or maybe even reject it for various reasons (balancing, performance, etc). But this is mostly to avoid someone spending weeks implementing something and then getting it rejected. There are certainly some good ideas around, some might need a bit of additional work as they feel more like a proof of concept and do not feel right in relation to everything else. But would still be a great addition, once given more time.

@forcemagic Feel free to make an issue about it. Trying to guess it is a bit tedious. Like I could easily assume something like "Omg. There is a stupid typo somewhere, but I cannot find it". But I might delay it until we switch the 1.12 to master. Either I forget to cherry pick the changes back or I apply it to 1.12 and everyone keeps reporting it for the current (outdated) master.

But a code of conduct.. Please no. These things are usually just awful.

Like they begin with explicitly stating common sense about harassment and similar things. To me this is just plain wrong. It sounds like they admit being defeated and accept that this is everywhere and they are fine with it. They just want to have their small safe haven. But that is not how it should work. It should simply be a given without having to constantly remind everyone.

The other points sound nice at first. They do not really led to something constructive. Sure it will be nice and comfy for everyone. Ultimately it ends up with saved replies like "Thanks for your feedback. We will forward it to the responsible person/team. Please wait for more feedback." While it actually means "Ah. Nice. Another one for /dev/null". As quite often just facing a direct but short reply feels like they being somewhat insulted. E.g. for feeling their ideas are neglected. Mostly because putting a tag on it is quite complex. It is simply something very personal.

For example I have no issue with stating an idea is just stupid/bullshit/broken/whatever. This is purely about the idea, but I never assume it being on a personal level. And I have no issue about getting the same thing back. Still some person cannot separate between both. Certainly always getting something along the line of "That sounds like a interesting idea. I certainly would not have considered it, but it is still intriguing" does not help in the long run. Because it can either mean what they say or they avoid everything slightly insulting and hope they get the hint. Which they probably are not, spend a month to implement something and then get it immediately rejected because it does not fit. I simply want to be honest and say "No", even if I have to consider something could be slightly insulted because they feel neglected or various other reasons.

Which then brings me to things like constructive criticism. If you actually care about your suggestion and get a no, it should be easy to give some constructive feedback about why you still think it would be a good addition, It might even be to test, if someone actually cares for it and it is not some showerthought. Also feel free to call it a stupid decision to reject it, if you can also state why. But it is not uncommon that someone just puts "This sucks" in quotes, adds "Consider it constructive feedback" and considers that is enough for actual constructive criticism. Until they then get insulted, if you say "Sorry, but no that does not fit it". This this then causes others to jump onto it, it circling around the interpretation of the code of conduct. Until you then have to lock it and like 10 people run of to twitter/reddit/whatever to complain about how unfair they are being treated. Minecraft is simply a bit to toxic for it. Which then lets me loop back to the insulted part and that you basically have to restrict any communication to be as vague as possible so noone could be offended by it, but it is still possible to claim "We are sorry, but it seems you have misinterpreted it".