[1.12] Is this mod still 'alive'?

[electrofloat]

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 ?

[yueh]

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.

[thiakil]

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

[yueh]

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.

[thiakil]

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.

[yueh]

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.

[thatsIch]

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

[yueh]

Nice seeing you still around.

[electrofloat]

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. :/

[electrofloat]

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

[yueh]

@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.

[thiakil]

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)

[yueh]

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.

[electrofloat]

@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.

[yueh]

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.

[electrofloat]

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

[forcemagic]

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

[JelmarG]

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.

[forcemagic]

@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.

[yueh]

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.

[thiakil]

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.

[forcemagic]

@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

[JelmarG]

@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.

[forcemagic]

@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

[JelmarG]

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

[yueh]

@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".