EDIT:

So, you have a chance to affect our decisions concerning port for 1.10.2 / 1.11:
Version: http://www.strawpoll.me/11011521
Modularity: http://www.strawpoll.me/11011528
Versioning: http://www.strawpoll.me/11011534
Minimum java: http://www.strawpoll.me/11011536
_{^{Results of the polls, taken 31st august, aren't deterministic, but will affect decisions made by teams, which are final.
If you're wondering, yes, there was a single poll previously, but i split it up, because of too many combinations.}}

Also, we are now working in 1.10.2! Our fork can be found here and if you want to contribute, go here AEModernMCPort#22.

A few minutes ago, i finished porting AE2-rv3 for 1.8.9 to 1.9.4. AE2 in 1.9.4 can be used. Me system (not completely), Spatial IO, world gen and most of things are working, except for... You guessed it - rendering. You can find ported code in my fork.

I did NOT port and fix rendering system over for few reasons that started to stack, and gave a conclusion which i will speak of in a minute. First reason was that internally it changed again and model generators have to be rewritten (not completely, but a good bit). Looking at rendering classes (and names of commits 😛), we can see that rendering in 1.8.9 was never finished. Looking at it again, and you already notice, that because 1.8.9 json models system was a lot worse than 1.9.4 json, all blocks used dynamic model generation, while ALL of them, except for multipart cables, can be done with jsons.
Now, what about cables? Well, we have no more 3000 multipart mods with own API each, but mc multipart, soon (tm) to be merged into forge, so official mutipart platform with simpified rendering. Which will, make cables rendering easier.

Whoa, that's loats of rendering changes relative to 1.7.10. Let's add even more to it: dual wielding (~10% of all files changed), changes to bounding boxes, loot tables, block states...

While, things above concerned porting to newer mc version, new forge gave us new systems, such as capabilities system, which can be used to change current AE systems to be more dynamic, mod compatible and better overall.

--So, what now?
--A lot of things had changed and a lot more will, if 1.9.4 update progress will proceed. Personally, i wouldn't call it rv3 anymore. At lease AE2-rv4. But major API changes (yes, it touched good part of API and with rendering, will change a lot more), usually cause major version increase...
--So Applied Energistics 3???
--I don't know. I'm here to ask what AE2 team and community thinks about all this. If AE3 will come, we/they/whoever takes it should consider implementing suggestions made to AE2 and/or taking authors of AE2 addons and pulling them into AE3.

Concidering AE2 team hasn't been active on AE2 for 2 months, (and more than 2 weeks on github), i don't know if i will get something from them. But you are reading this already, so why not drop a comment?

EDIT (+24h): I went github surfing over AE2 team members and 2 that have been last active on Applied Energistics 2 months ago, currently work on new projects. Because i know that they try to keep them secret, i will not tell here what they are working on. From some other sources i know that they are working more on their projects too. Conclusion? They seem to leave AE2 behind.

Yup, it appears that AE2 has been abandoned by its dev team. Maybe your port can get them out of hibernation.

Maybe, but as i said major part of port, rendering, isn't done, simply because i want to know what's next.
Because if they take it and abandon it again next day - it's kinda useless.
While i know how and can port all of rendering to 1.9.4 (which will take a lot of time) and then find out that in AE3 (or whatever), 50% are to be removed and replaced by other 50%... That's a complete waste of time.

If someone is willing put in the effort to port the mod I don't see any reason why that wouldn't be accepted.

I'm no longer actively working on AE2 for a number of reasons ( mostly the reasons I retired from modding originally, and that won't be changing, I realized this when I attempted to port the mod to 1.8 in the first place 38afde7 ) but maybe we should consider adding members to the team that can help keep the mod alive, especially since those who are on the team do not have the time to devote to the project any longer.

Regardless of TeamAE's stagnation because of RL or other factors, this mod is open source, and if there is a community willing to work on it then I don't see any problem with that.

We either have to add members to current team, or create a new one (in this case, old AE2 team members can join new team whenever they want). Because rendering will cause quite a big code overhaul, so if big changes to other things can be done, they should be done. Hence it will probably be necessary to up version number to AE3.

I would love to help out with simpler things if that is needed.

What is important to note, is that we are not just talking about some rendering changes.
We need a full blown multipart system to also cover addons.

My goal was always to use MCMP once it was merged into forge (as FMP), but this was continuously pushed back again and again. Thus being one of the main blockers for now about 6 months. Like it took nearly half a year to even make the first attempt for a merge and nearly a month for Lex to finally respond "not happening".

Further FMP will never be merged into 1.9.4 and there is a good chance to not even see a merge happening for 1.10. It is current scheduled for a redesign, which will take much more time to be done and compared to the MCMP development nowhere near as open. So we simply cannot estimate how Lex might ama to cripple it (or not). But as long as there is no release, we cannot even plan for it and it is extremely uncertain when it might happen. Maybe in a month, maybe in a year.
Further the approach of forge is to keep it as is once it was merged. Should there be major issues with it after merging it, they will likely stay forever.
So FMP is pretty much out of the question, if you want a port now.

Using MCMP is also not an option. 1.9.4 did not see an official release, thus it already blocked a couple of 1.9 mods from moving to 1.9.4. Some of them started to ship their own custom build, which is incompatible to everyone else and pretty much making the idea of having a single shared lib pointless. They will start to fragment even further, do their own changes to it and end up in a situation where they might be unable to ever move back to a common lib without redesigning everything. Some will probably not even shade it correctly and just ship it as MCMP and cause major incompatiblities.
There might be a MCMP version for 1.10 after 1.11 is released, so if you want to stay one version behind, it would be an option. But everyone else will move on, except the ones blocked by MCMP.

This pretty much leaves the only option of writing our own and give up on things like C&B as facades. (What would be awesome).
One question is then, should it only cover cables? How about keeping dynamic models for commonly used addon things, like allow them to use a custom cell model inside a chest or drive. This could further extend to upgrades cards, which could also be somehow shown on the block without having to open a GUI.
The whole thing also needs to be pretty stable, as many addon devs do not even read the docs fully and potentially crash it somehow. We are probably speaking about a couple of months to design a good multipart system, without even actually using it to port AE, besides some basic dummy tests.

The next part would be about how should we use Caps? Do we move to a single one or multiple ones? A single one would clearly be easier, but in this case we still had to maintain a similar system on our own to allow addons to add new grid types. Multiple ones might be better for this case, but have many issues in others.
Probably also a couple of weeks to design and port.

Then the whole inventory system needs a complete redesign.
At first we can remove our own inventory handlers and replace them with the new forge ones. Should be pretty straigthforward and move some time and effort to forge as we no longer have to maintain it. But this means we can lose compatibility with mods not support these new forge handlers. So should we still have a backup solution? Or just say we do not care about them?
Secondly we need to redesign the current internal inventory handling completely, as it is pretty much the only major performance issue currently. Mainly because it is extremely defensive and pretty much impossible for addons to break it. But moving to a faster solution, would but more responsiblity on addon devs to not fuck with it. Which sadly is pretty likely.
Last but not least, how should we deal with fluids? The handling is still a bit messy and could maybe moved to its own grid. But then what about ExtraCells? I do not want to encroach on them and kill it, but then it is also known to be buggy, a bit inactive and quite hacky on how it integrates into AE.

Another question would be what energy system should we support? Personally I think we should only support Cap based ones to rely less on ASM trickery. But this means no RF, as this is not available as Cap, but is a major one. We could support it a second class citizen and say just support it with the energy acceptor. But this still means ASM trickery and we still need to maintain our own system for it. As @Optional is broken since a year and cannot be really be used reliably.

And these are just the basic issues. We still have not exploited any of the new systems. Like it might be possible to use loottables to guarantee finding all presses with the second meteor at like 80% and 100% with a third on. Or use the new NBT based structures for something more interesting. Like replace meteor clusters with a crashed spaceship, containing presses and a few blocks/cables to quickstart a player.

Most of these changes are really not simple, many even need a good knowledge about programming. Not just "I know some java", but topics like datastructures, understanding of Big O Notation, etc. It is pretty common that mod devs just throw an ArrayList at it and end up with something like O(n^2). This might work for our test setup with 10 items and 0.001ms per item for a total of 0.1 ms. But players will not stop at 10 items, they will throw thousand at it and suddenly it no longer takes 0.1ms per tick (of 1/20 second), it is now taking over a second.
Sadly this pool of devs is not a particular large one and the devs I know and who offered help more or less quite modding due to Lex. We/I could probably train some new ones, but this will take a good portion of our/my very limited time. Probably even more than just doing it by ourselves/myself.

We might even have to consider a thread safe implementation as it is likely that each dimension ends up in their own thread. Maybe with 1.11 already. So if we want to keep QNBs being interdimensonal and not just intradimensional, this also needs to be considered.

Regarding the version. AE3 is simply pointless, the only exception would be major gameplay changes, but not code ones. The version scheme currently used is more like AE2 1.3.7.
Currently there are not really any API changes, except the ones forced by a new minecraft version.
So rv3 could still be an option. Maybe rv4, should there be really massive API changes like a new multipart system, complete move to be cap based etc.
We could maybe even move to a real semver based one and just call it AE2 2.0.0. There were always issues with players not being able to understand the difference between rv1 and rv2, or alpha/beta etc. (Or just read the release date to determine how it it might be...)
So semver might be a bit better to understand, but then there are still the ones who will not understand the difference between 2.2.1 and 2.2.10.

If we use RF as grid's power? Bad things will happen.
If AE drops it's own power system and selects one to use, good bye all the others.

Bad idea. These APIs are designed to exchange power, but are highly inefficent to use internally.
Currently AE uses a semi static system, so each block,cable,part more or less just report their idle consumption and the sum is subtracted once per tick. Some machines can still still actively extract energy, but that could be redesigned to a more reactive system. Like announcing that it now requires 5 AE/t more and then decrease it like 40 ticks later. So pretty much just 42 additions instead of 40 ticks, simulating if there is enough power to extract, actually extracting, dealing with not enough energy, etc.
With RF every fucking piece would have to tick and constantly suck like 0.1 RF/t, it is plain stupid in terms of performance.

recipe stuff.

That is how it works already. But it can only be applied to assemblers, or machines implementing our interface and just act as assembler.
Otherwise not possible. Because the next mod will use this as slots for their crafters:
[0][3][6]
[1][4][7] -> [9]
[2][5][8]
And the next one
[2][3][4]
[5][6][7] -> [1]
[8][9][10]

Also keep in mind that recipe lookup are really really bad in terms of performance. They are somewhat ok for crafting manually like 1 block/5 secs. But if you need to lookup like 50 blocks/t it will pretty much lookup the server and some crafters will use a very naive implementation and tank a server. (and you can pretty much assume that they will blame AE and not the broken SimpleCrafterMod)

Bad idea. These APIs are designed to exchange power, but are highly inefficent to use internally.
Currently AE uses a semi static system, so each block,cable,part more or less just report their idle consumption and the sum is subtracted once per tick. Some machines can still still actively extract energy, but that could be redesigned to a more reactive system. Like announcing that it now requires 5 AE/t more and then decrease it like 40 ticks later. So pretty much just 42 additions instead of 40 ticks, simulating if there is enough power to extract, actually extracting, dealing with not enough energy, etc.
With RF every fucking piece would have to tick and constantly suck like 0.1 RF/t, it is plain stupid in terms of performance.

Meant it to be bad, somehow it sounded good, redited.

That is how it works already. But it can only be applied to assemblers, or machines implementing our interface and just act as assembler.
Otherwise not possible. Because the next mod will use this as slots for their crafters:
[0][3][6]
[1][4][7] -> [9]
[2][5][8]
And the next one
[2][3][4]
[5][6][7] -> [1]
[8][9][10]

Also keep in mind that recipe lookup are really really bad in terms of performance. They are somewhat ok for crafting manually like 1 block/5 secs. But if you need to lookup like 50 blocks/t it will pretty much lookup the server and some crafters will use a very naive implementation and tank a server. (and you can pretty much assume that they will blame AE and not the broken SimpleCrafterMod)

That was Molecular Assembler example.

Now, let's say that mods "Boned Lava" adds a machine that with torches, bone and water creates lava and flint. Slots: 0-3,5 - items 4,6 - fluids, 0-4 - input, 5-6 - output
[0][1] [4] -> [5] [6]
[2][3] [4] [6]

Pattern instructions:
minecraft:bone -> [0]
minecraft:torch -> [3]
minecraft:water_1000 -> [4]
[5] -> minecraft:flint
[6] -> minecraft:lava_1000

Note, that these instructions are made by user. And that what makes system more dynaminc, user chooses slot ids himself depending on machine that he is going to be using (the only problem left is to make user able to link te slot ids to slots he sees in GUI).

Note, that these instructions are made by user. And that what makes system more dynaminc, user chooses slot number himself depending on machine that he is going to be using (the only problem left is to make user able to link te slot ids to slots he sees in GUI).

A user will not know that bone needs to be in slot[0]. The index is never exposed by any machine. 0 might be the top left or. Or the bottom right. Or no visible GUI slot at all. The only option to not have special case for every fucking machine and hope that it does not break with every update is to simply consider them as bag. Stick everything in them at once and hope the machine will sort it correclty. Or hope that the machine has configurable input/outputs and the user can sort it by themselves. Either with using AE as pipe mod or choose some other.
Everything else is not feasible, except we introduce an API and ever other mod has to confirm to it and implement support for AE. Leaving the user in the situation that some machines work, some not, and some are horribly buggy.

A user will not know that bone needs to be in slot[0]. The index is never exposed by any machine. 0 might be the top left or. Or the bottom right. Or no visible GUI slot at all. The only option to not have special case for every fucking machine and hope that it does not break with every update is to simply consider them as bag. Stick everything in them at once and hope the machine will sort it correclty. Or hope that the machine has configurable input/outputs and the user can sort it by themselves. Either with using AE as pipe mod or choose some other.
Everything else is not feasible, except we introduce an API and ever other mod has to confirm to it and implement support for AE. Leaving the user in the situation that some machines work, some not, and some are horribly buggy.

Unless we find a way to understand which slot in machine is which in gui, we will have to consider it as a bag. Or yes, we could implement API and use it if possible before figuring out slots.

Just stay with KISS. It is a bag, which pretty much restricts it to 3 cases

1. It just works
2. The user can route the items correctly somehow with a bit more effort like the mod author wanted.
3. The mod author does not want the machine to be automated and we should respect it.

Everything else just introdues more issues, like it worked with the old version or it only works if the machine points north, the mod does implement it wrongly, the mod ships the whole AE api from 2 years ago and breaks everything, whateverelse. It will just occupy our time with fixing some mod interaction code instead of actually being able to spend it on real improvments.

Just stay with KISS. It is a bag, which pretty much restricts it to 3 cases

It just works
The user can route the items correctly somehow with a bit more effort like the mod author wanted.
The mod author does not want the machine to be automated and we should respect it.
Everything else just introdues more issues, like it worked with the old version or it only works if the machine points north, the mod does implement it wrongly, the mod ships the whole AE api from 2 years ago and breaks everything, whateverelse. It will just occupy our time with fixing some mod interaction code instead of actually being able to spend it on real improvments.

Ok, then.
But anyways, AE patterns should have fluids (and other APIed caps) support.

As long as there is no common fluid recipe system in forge, it is simply not feasible to make the autocrafting aware of it every mod uses their own system with their one exceptions and what not. At least not without killing every addon and limiting the support to certain mods. Some for anything else.

I personally never had the need to use fluid based autocrafting. It was pretty much always possible by just specify the required items as most fluid uses are simply "convert these items into a fluid, then proceed" or "dump bucket here to get bucket of X and use that to craft".

As long as there is no common fluid recipe system in forge, it is simply not feasible to make the autocrafting aware of it every mod uses their own system with their one exceptions and what not. At least not without killing every addon and limiting the support to certain mods. Some for anything else.

I personally never had the need to use fluid based autocrafting. It was pretty much always possible by just specify the required items as most fluid uses are simply "convert these items into a fluid, then proceed" or "dump bucket here to get bucket of X and use that to craft".

First, i think ExtraCells managed to do crafting with fluids, although it is not perfect.
Second, if not for crafting, at least for cutom machines / user setups.

EC crafting is a buggy mess and will always be one. There is simply no sane to handle every stupid exception for fluids or other things. At least not spending years on developing a full blown planning software.

AE itself will pretty much always be limited to item based autocrafting. It is still ridiculous complex but at least it does not blow the complexity out of the water once you add fluids.

The only option would be to open CraftingJobs a bit and allow addons to submit their custom implementation. So at least a crafting cpu can handle them, but it is still up to the addon dev to implement their custom logic. Because they are the only ones being able to know and handle the prereqs for their custom stuff.

EC crafting is a buggy mess and will always be one. There is simply no sane to handle every stupid exception for fluids or other things. At least not spending years on developing a full blown planning software.

AE itself will pretty much always be limited to item based autocrafting. It is still ridiculous complex but at least it does not blow the complexity out of the water once you add fluids.

The only option would be to open CraftingJobs a bit and allow addons to submit their custom implementation. So at least a crafting cpu can handle them, but it is still up to the addon dev to implement their custom logic. Because they are the only ones being able to know and handle the prereqs for their custom stuff

Then what happens is:
-Items can be used in crafting and in processing
-Fluids can be used in processing only
-Other CraftingJobs can be added by modders via API, so they can support processing of their own stuff.

@yueh i'm not sure why AE2 needs a multi-part system? It has never needed one, its always done that fine by itself, FMP ( 1.7 ) support was added after the fact and can simply be removed, or that integration could be ported to MCMP if someone wants to do that instead.

There seems to be a lot of talk about rewriting 90% of the mod going on in here, I know that there is plenty of places that could use work, and things that could be re-written but wouldn't it make more sense to prioritize getting the mod working to some reasonable completeness on a post 1.8 version?

I mean if you force the next version to incorporate the entire "wishlist" then it will never exist.

Once the mod has a build for say 1.9.4 or 1.10 effort could be applied to try and make some of those other things a reality, or maybe prioritize the changes that need to happen because of existing issues?

Once the mod has a build for say 1.9.4 or 1.10 effort could be applied to try and make some of those other things a reality, or maybe prioritize the changes that need to happen because of existing issues?

"Never quote yourself, but ..."

While i know how and can port all of rendering to 1.9.4 (which will take a lot of time) and then find out that in AE3 (or whatever), 50% are to be removed and replaced by other 50%... That's a complete waste of time.

PS: On my fork server side logic and world gen are working, rendering is not. I can port rendering, but if later we decide that we wanna remove something, make drives display cells, buses upgrades... It will have to be changed again (not very much, but enough to waste good bit of time).

I think porting rendering is the best choice in this, because then you have working rendering like it used to, and if the new ideas appear to fail, you have working stuff you can fall back on.

We probably do not need a full blown multipart system like MCMP. Some multipart light with 7 locations to allow addons to place parts would be enough. But I want C&B facades 😉
It would surely be nice to go the extra way to support our own system and afterwards add MCMP support, but as long as it not certain that we have enough time/manpower to do it, we should stick with one.

It is mostly about how much time would it take to implement, test and refine it compared to relying on a well tested working implementation and invest the time into something else.
Like the current model gen is still a bit broken and can run into concurrency issues.
I have always consider that NIH-syndrome is way to common in modded minecraft and wastes too much time.

In some cases like the inventory handling I also would want to have it done before some addons start using it. It would suck for them, if we keep the current one and halfway through 1.10 say "nice knowing you, but we will now drop fluid support completely."

@yueh, @AlgorithmX2:

We probably do not need a full blown multipart system like MCMP. Some multipart light with 7 locations to allow addons to place parts would be enough. But I want C&B facades 😉

2 things come to my mind:

• Chisel And Bits has API.
• @AlgorithmX2 is here speaking with us 🎉 !

It would surely be nice to go the extra way to support our own system and afterwards add MCMP support, but as long as it not certain that we have enough time/manpower to do it, we should stick with one.

It is mostly about how much time would it take to implement, test and refine it compared to relying on a well tested working implementation and invest the time into something else.
Like the current model gen is still a bit broken and can run into concurrency issues.
I have always consider that NIH-syndrome is way to common in modded minecraft and wastes too much time.

This plus what @AlgorithmX2 said, we should go for own "partial microblock system". Microblock to allow parts, partial, because we don't need every 1/16th of block (we basically need to divide block only to 3 parts in each dimension - part, cable, part. Covers go with parts).

In some cases like the inventory handling I also would want to have it done before some addons start using it. It would suck for them, if we keep the current one and halfway through 1.10 say "nice knowing you, but we will now drop fluid support completely."

External inventory & fluid handling, as we spoke already - based on caps. They are forced to switch on to new standarts by forge anyway.
Internal handling - also based on caps, although caps are used only for identifying type. The rest handled by... CapabilityToGridProcessorInterfaces?

@Dhvagra:

I think porting rendering is the best choice in this, because then you have working rendering like it used to, and if the new ideas appear to fail, you have working stuff you can fall back on.

Current bakery is not working. Vertex format and new rendering reformatting broke it. I have tried to fix it in multiple different ways... It didn't work so well (most crashed mc, the one currently in my fork does not, but blocks are still invisible).

I agree with @AlgorithmX2. I also think priority should be to get a working version for post 1.8 versions. It is a mod that many people are eagerly waiting for, and has kinda become the basic mod that everything else is build around for a lot of modded mc players. We've all seen wishlists of AE2 features, but those can still be implemented when people have time or when the opportunity presents itself. Getting a working version out there at least means that people can enjoy one of the most fantastic mods available, and also prevent it from becoming obsolete.

In some cases like the inventory handling I also would want to have it done before some addons start using it. It would suck for them, if we keep the current one and halfway through 1.10 say "nice knowing you, but we will now drop fluid support completely."

Of course that would be annoying, but should the solidarity with potential addon developers really mean that a working version of AE2 be delayed indefinitely? I can also imagine that even those devs would like a somewhat working port to 1.9 onwards so they can get to work on their own stuff to begin with, even if that means they might have to rewrite portions of it if AE2 decides to implement a different method of inventory handling later down the road. Maybe it's an idea to get the input of those devs to see what they would prefer?

Sure, I'd love to see C&B Facades work with AE2, it might happen one day, but in the mean time the Facades AE2 implements are a reasonable solution already.

If someone were to make a AE2 renderer for 1.9 or beyond I imagine that the "wasted effort" would be pretty marginal, the majority of the rendering is around network and its components, and those are pretty ingrained into what AE2 is, and if the goal is to port AE2, that won't be changing that much, if it would we wouldn't really be talking about "AE2" but rather some other mod that is based on AE2.

Just my thoughts on the matter, I know rendering isn't a small challenge, several of the simpler blocks could be done with models and rotation, but there are also things like the drive which have considerable states and conditions, as well as glowing parts.

The parts system will always require some dynamic elements, but might be able to use models in some regard.

Also if someone wants to make the models, C&B has an export to JSON Feature which might help, I did make AE2's renders all pixel snapped, so the output should be roughly identical. ( maybe better because of C&B's proper face culling )

I realize that its not a small task, but I don't think its an insurmountable hurdle.

What is important to note, is that we are not just talking about some rendering changes.
We need a full blown multipart system to also cover addons.

My goal was always to use MCMP once it was merged into forge (as FMP), but this was continuously pushed back again and again. Thus being one of the main blockers for now about 6 months. Like it took nearly half a year to even make the first attempt for a merge and nearly a month for Lex to finally respond "not happening".

Further FMP will never be merged into 1.9.4 and there is a good chance to not even see a merge happening for 1.10. It is current scheduled for a redesign, which will take much more time to be done and compared to the MCMP development nowhere near as open. So we simply cannot estimate how Lex might ama to cripple it (or not). But as long as there is no release, we cannot even plan for it and it is extremely uncertain when it might happen. Maybe in a month, maybe in a year.
Further the approach of forge is to keep it as is once it was merged. Should there be major issues with it after merging it, they will likely stay forever.
So FMP is pretty much out of the question, if you want a port now.

Using MCMP is also not an option. 1.9.4 did not see an official release, thus it already blocked a couple of 1.9 mods from moving to 1.9.4. Some of them started to ship their own custom build, which is incompatible to everyone else and pretty much making the idea of having a single shared lib pointless. They will start to fragment even further, do their own changes to it and end up in a situation where they might be unable to ever move back to a common lib without redesigning everything. Some will probably not even shade it correctly and just ship it as MCMP and cause major incompatiblities.
There might be a MCMP version for 1.10 after 1.11 is released, so if you want to stay one version behind, it would be an option. But everyone else will move on, except the ones blocked by MCMP.

This pretty much leaves the only option of writing our own and give up on things like C&B as facades. (What would be awesome).
One question is then, should it only cover cables? How about keeping dynamic models for commonly used addon things, like allow them to use a custom cell model inside a chest or drive. This could further extend to upgrades cards, which could also be somehow shown on the block without having to open a GUI.
The whole thing also needs to be pretty stable, as many addon devs do not even read the docs fully and potentially crash it somehow. We are probably speaking about a couple of months to design a good multipart system, without even actually using it to port AE, besides some basic dummy tests.

Mods that used MCMP in 1.9, moved to 1.9.4 and dropped it. Yes, we don't know if it will ever be merged and when into forge, but in any case (use we MCMP / FMP or create our own), current rendering system needs redesign. Especially, if we want to show cards in parts, for example. This can still be done without vertex by vertex model bakery (model for cable + model for part + model for card => state transforms => multimodel).

The next part would be about how should we use Caps? Do we move to a single one or multiple ones? A single one would clearly be easier, but in this case we still had to maintain a similar system on our own to allow addons to add new grid types. Multiple ones might be better for this case, but have many issues in others.
Probably also a couple of weeks to design and port.

Then the whole inventory system needs a complete redesign.
At first we can remove our own inventory handlers and replace them with the new forge ones. Should be pretty straigthforward and move some time and effort to forge as we no longer have to maintain it. But this means we can lose compatibility with mods not support these new forge handlers. So should we still have a backup solution? Or just say we do not care about them?
Secondly we need to redesign the current internal inventory handling completely, as it is pretty much the only major performance issue currently. Mainly because it is extremely defensive and pretty much impossible for addons to break it. But moving to a faster solution, would but more responsiblity on addon devs to not fuck with it. Which sadly is pretty likely.
Last but not least, how should we deal with fluids? The handling is still a bit messy and could maybe moved to its own grid. But then what about ExtraCells? I do not want to encroach on them and kill it, but then it is also known to be buggy, a bit inactive and quite hacky on how it integrates into AE.

By saying implementing caps, i did not mean changing current grid handling to use caps, i meant world interactions (with blocks, tes or entities). For example, having import and export busses capability specific (internally, for end users they are simply different blocks), and what they do is by calling cap's methods, export or import from/to tes. This simply generalizes items & fluids and makes their handling sowewhat similar. As the result, grid handling has to be changed also, as AE2 experience shows that players don't only want to store items this way, but everything else they can think of (fluids, aspects, mana, LP...). Because far not everybody has migrated to caps, grid must be designed in a way to support both caps and interface based interactions.

Another question would be what energy system should we support? Personally I think we should only support Cap based ones to rely less on ASM trickery. But this means no RF, as this is not available as Cap, but is a major one. We could support it a second class citizen and say just support it with the energy acceptor. But this still means ASM trickery and we still need to maintain our own system for it. As @Optional is broken since a year and cannot be really be used reliably.

Cap is probably the way to go, but concerning RF, nearly all mods out there that use it, repackage it. Not only the ones that are based on it (like BC or EIO), but also the ones where RF is optional. All simply for the same reason - @Optional bein broken and RF being more and more standart and universal.

We might even have to consider a thread safe implementation as it is likely that each dimension ends up in their own thread. Maybe with 1.11 already. So if we want to keep QNBs being interdimensonal and not just intradimensional, this also needs to be considered.

As networking already is on separate thread, they will probably continue multithreading mc.

Regarding the version. AE3 is simply pointless, the only exception would be major gameplay changes, but not code ones. The version scheme currently used is more like AE2 1.3.7.
And these are just the basic issues. We still have not exploited any of the new systems. Like it might be possible to use loottables to guarantee finding all presses with the second meteor at like 80% and 100% with a third on. Or use the new NBT based structures for something more interesting. Like replace meteor clusters with a crashed spaceship, containing presses and a few blocks/cables to quickstart a player.

Sure, renaming is pointless, unless we change gameplay, which we may likely do.

Loot tables, while not having that "weight" parameter anymore, have new ones, and more than simply one. They also have conditions and player dependance (because of luck introduced, they made it depend on player), so for example to make sure that 3rd meteorite contins processor, if first 2 didn't, we can log loot results into caps and reuse them to determine next loot.

Adding world gen may or may not be a good idea, depending on how it is implemented and how it affectes gameplay / forces us to go explore. For example, making Spatial IO components only craftable with special item (consumable/damageable/infinite) only found in spaceship crashes might force people to look for them.

Currently there are not really any API changes, except the ones forced by a new minecraft version.
So rv3 could still be an option. Maybe rv4, should there be really massive API changes like a new multipart system, complete move to be cap based etc.
We could maybe even move to a real semver based one and just call it AE2 2.0.0. There were always issues with players not being able to understand the difference between rv1 and rv2, or alpha/beta etc. (Or just read the release date to determine how it it might be...)
So semver might be a bit better to understand, but then there are still the ones who will not understand the difference between 2.2.1 and 2.2.10.

Semver might be simplier, might not. That's not a problem right now, though (but it may be one day).

Most of these changes are really not simple, many even need a good knowledge about programming. Not just "I know some java", but topics like datastructures, understanding of Big O Notation, etc. It is pretty common that mod devs just throw an ArrayList at it and end up with something like O(n^2). This might work for our test setup with 10 items and 0.001ms per item for a total of 0.1 ms. But players will not stop at 10 items, they will throw thousand at it and suddenly it no longer takes 0.1ms per tick (of 1/20 second), it is now taking over a second.
Sadly this pool of devs is not a particular large one and the devs I know and who offered help more or less quite modding due to Lex. We/I could probably train some new ones, but this will take a good portion of our/my very limited time. Probably even more than just doing it by ourselves/myself.

A good idea might be to pull people that were involved in AE2 somehow in. For example, @DrummerMC from extracells to work on fluids and caps migration. Work on grid, should be done by ones who understand threading, loads and data structures, sure. But they (who work on grid) may not be able to do rendering as well as others would. So it's not the question of finding very experinced people to work on mod, it's more a question of finding a bunch of enough experienced people, each in own category, and distributing workload corresponding to their specifications.

Mods that used MCMP in 1.9, moved to 1.9.4 and dropped it. Yes, we don't know if it will ever be merged and when into forge, but in any case (use we MCMP / FMP or create or own), current rendering system needs redesign. Especially, if we want to show cards in parts, for example. This can still be done without vertex by vertex model bakery (model for cable + model for part + model for card => state transforms => multimodel).

Yes, whatever we do it requires a rewrite of the rendering itself. The question is just would it be stupid to ignore MCMP and all nice features, is designing our own system faster then hoping on MCMP or will it be done at about the same time once we start rewriting the rendering. We might just have wasted a couple of months of work when switching to MCMP then.

By saying implementing caps, i did not mean changing current grid handling to use caps, i meant world interactions (with blocks, tes or entities). For example, having import and export busses capability specific (internally, for end users they are simply different blocks), and what they do is by calling cap's methods, export or import from/to tes. This simply generalizes items & fluids and makes their handling sowewhat similar. As the result, grid handling has to be changed also, as AE2 experience shows that players don't only want to store items this way, but everything else they can think of (fluids, aspects, mana, LP...). Because far not everybody has migrated to caps, grid must be designed in a way to support both caps and interface based interactions.

The change is not that large. It is more or less replacing IGridHost with a Cap<MEGrid(Host(> or so. Nothing fancy. Just no stupid casting or instanceof anymore. Moving to different caps per grid is something different at all.
Using caps should be pretty important. That should simple be handled by the forge item/fluid handlers for basic inventories. Should someone make their custom inventory and not provide support for the inventory handlers, I would say ignore them. There is a common helper, which anyone can use and not be forced to handle everything on their own.

Cap is probably the way to go, but concerning RF, nearly all mods out there that use it, repackage it. Not only the ones that are based on it (like BC or EIO), but also the ones where RF is optional. All simply for the same reason - @optional bein broken and RF being more and more standart and universal.

Repacking will get very interesting. Expect horrible API breaks. With 1.7.10 you could just ship some interfaces and it would be fine as they would not change often. With 1.8+ you have to ship internal implementations with your API. Thus expect someone shipping a very outdated version breaking everyone else. On top of that forge can still not sort by the latest API in some packages. It is pure luck which one is loaded and the one reported by forge might not even be the one the class loading uses.
The players will have some fun with now having to keep track of dozen of small API jars and a environment without any dependency management.

As networking already is on separate thread, they will probably continue multithreading mc.

Networking is pretty simple. A naive implemention would just reschedule the packet for the main thread and message passing in general applies pretty easily. But this is no longer the case for multi threaded dimension. The whole system pretty much would have to deal with futures/promises/whateverasyncstuff.

Adding world gen may or may not be a good idea, depending on how it is implemented and how it affectes gameplay / forces us to go explore. For example, making Spatial IO components only craftable with special item (consumable/damageable/infinite) only found in spaceship crashes might force people to look for them.

That would be stupid. I cannot remember the cluster chance currently. But it is pretty low. A player would just have the option of finding a meteor and some presses. Or finding another structure allowing them a quickstart, like a terminal, 2-3 chests with 1k or 4k cells and a few cables. But it would require some more decorative blocks..

A good idea might be to pull people that were involved in AE2 somehow in. For example, @DrummerMC from extracells to work on fluids and caps migration. Work on grid, should be done by ones who understand threading, loads and data structures, sure. But they (who work on grid) may not be able to do rendering as well as others would. So it's not the question of finding very experinced people to work on mod, it's more a question of finding a bunch of enough experienced people, each in own category, and distributing workload corresponding to their specifications.

Afaik @DrummerMC is also pretty busy currently and a good part of the fluid handling is done in AE2 already. It is mostly about adding buses and cells. Maybe we could even combine the item buses with fluid ones. Or have it as upgrade card, like a FPU (Fluid Processing Upgrade). Maybe even use TE as example with default upgrade cards like an item upgrade already. But that would require parts now keep their state when broken. Something we avoided to not end up with an inventory full of unstackable import buses.

Yes, whatever we do it requires a rewrite of the rendering itself. The question is just would it be stupid to ignore MCMP and all nice features, is designing our own system faster then hoping on MCMP or will it be done at about the same time once we start rewriting the rendering. We might just have wasted a couple of months of work when switching to MCMP then.

Then we have to start with something different.
On my fork, i haven't ported rendering, but meanwhile all (nearly) AE2 blocks are working, they are simply invisible.

The change is not that large. It is more or less replacing IGridHost with a Cap<MEGrid(Host(> or so. Nothing fancy. Just no stupid casting or instanceof anymore. Moving to different caps per grid is something different at all.
Using caps should be pretty important. That should simple be handled by the forge item/fluid handlers for basic inventories. Should someone make their custom inventory and not provide support for the inventory handlers, I would say ignore them. There is a common helper, which anyone can use and not be forced to handle everything on their own.

That's for sure. We should not even consider ones using deprecated IInventory, as they were told a thousand times to switch to caps.

Repacking will get very interesting. Expect horrible API breaks. With 1.7.10 you could just ship some interfaces and it would be fine as they would not change often. With 1.8+ you have to ship internal implementations with your API. Thus expect someone shipping a very outdated version breaking everyone else. On top of that forge can still not sort by the latest API in some packages. It is pure luck which one is loaded and the one reported by forge might not even be the one the class loading uses.
The players will have some fun with now having to keep track of dozen of small API jars and a environment without any dependency management.

Well, RF API is relatively stable, 1.8+ hasn't changed for 5 months after it's release. Although, it may switch to caps one day, but nobody knows if it will ever happen.

Networking is pretty simple. A naive implemention would just reschedule the packet for the main thread and message passing in general applies pretty easily. But this is no longer the case for multi threaded dimension. The whole system pretty much would have to deal with futures/promises/whateverasyncstuff.

My point here, was to say that mc will probably be multi threaded as they have already to multithread things with network.
Separatly threaded networking is indeed a lot simplier than dimensions.

That would be stupid. I cannot remember the cluster chance currently. But it is pretty low. A player would just have the option of finding a meteor and some presses. Or finding another structure allowing them a quickstart, like a terminal, 2-3 chests with 1k or 4k cells and a few cables. But it would require some more decorative blocks..

Some structures may be a very good idea for quick start, meanwhile they can wait till 1.10, because they will be a lot simplier to implement with structure block (even though it already was in 1.9, it is better in 1.10 and has features like structure integrity).

Afaik @DrummerMC is also pretty busy currently and a good part of the fluid handling is done in AE2 already. It is mostly about adding buses and cells. Maybe we could even combine the item buses with fluid ones. Or have it as upgrade card, like a FPU (Fluid Processing Upgrade). Maybe even use TE as example with default upgrade cards like an item upgrade already. But that would require parts now keep their state when broken. Something we avoided to not end up with an inventory full of unstackable import buses.

I think that separate parts are better for that, or at least make them similar to P2Ps, when right clicked, they are tuned, but internally, part is changed.

I also had some ideas on how processing can be reworked, especially with caps and fluids - based on slots. Then molecular assembler could be treated as any other machine or other mods' auto crafters could be used instead.

Well, RF API is relatively stable, 1.8+ hasn't changed for 5 months after it's release. Although, it may switch to caps one day, but nobody knows if it will ever happen.

Except it would still require ASM stripping. Something @Optional cannot do currently in a reliable way for AE2. (It fails on generics and 1.8+ now actually introduces way more of them).
So we have to still maintain our system, instead of just dropping it and spend the effort somewhere better.

My point here, was to say that mc will probably be multi threaded as they have already to multithread things with network.
Separatly threaded networking is indeed a lot simplier than dimensions.

The render, saving and probablzy a few others are also multithreaded. Or you can even write your own multithreaded support like C&B for baking models. Otherwise multithreaded MC is really really hard. 1 thread per dimension is pretty much the best solution for a short term goal.

I think that separate parts are better for that, or at least make them similar to P2Ps, when right clicked, they are tuned, but internally, part is changed.

Depends, I am usually a fan of requiring a compromise. Say limit an export bus to 3 upgrade cards. So a player could choose an item + fluid + capacity card to export items and fluid, but pretty slowly.
Adding a speed upgrade would not add anything, as the bus would only export 1 item or fluid but might be handy for a manual export bus. Say to quickly fill a tank or chest with a specific item (but still select it manually). Thus a fast export bus would be limited to either items or fluids and also limited in the amount.
3 might actually be too limited, but just for an idea.

Internally, no idea currently. Maybe some sort of strategy pattern a card could provide for the machines it supports. Which would also required should allow addons to add more cards. (Which would still have a huge ? above it)

I also had some ideas on how processing can be reworked, especially with caps and fluids - based on slots. Then molecular assembler could be treated as any other machine or other mods' auto crafters could be used instead.

Not possible or at least not for crafting patterns as we need to push the pattern into the assembler and only afterwards inject the items. Processing patterns already work exactly like this and can use any machine, even a assembler with a dedicated pattern (But that would require 2 patterns in total)
Also we cannot support every block out there, it has to be a generic way. So either the machine just accepts items as basic inventory or they are simply not supported directly. Everything else just makes it harder to maintain and port.

may i throw my two cents on this upgrade cards stuff here!?
i already wrote in a long forgotten issue that those unstackable busses with stored cards(and config) are the key feature that is yet missing in AE! Normally you would craft the configured bus in you inventory and remove all stored data this way but i am uncertain if it is possible to also return the installed cards in a well fashioned way to the player when using the crafting mechanism to remove the stored data

to make a comparision, whenever i break a configured block of other mods i get the default one and upgrades will spill out(like the busses do yet), when i wrench it, it keeps its items and configuration

Except it would still require ASM stripping. Something @optional cannot do currently in a reliable way for AE2. (It fails on generics and 1.8+ now actually introduces way more of them).
So we have to still maintain our system, instead of just dropping it and spend the effort somewhere better.

If we use RF as grid's power? Bad things will happen.
If AE drops it's own power system and selects one to use, good bye all the others (no good).

The render, saving and probablzy a few others are also multithreaded. Or you can even write your own multithreaded support like C&B for baking models. Otherwise multithreaded MC is really really hard. 1 thread per dimension is pretty much the best solution for a short term goal.

Currently, client logic & rendering, audio, server logic, server net, client net, saving are on different threads.

Depends, I am usually a fan of requiring a compromise. Say limit an export bus to 3 upgrade cards. So a player could choose an item + fluid + capacity card to export items and fluid, but pretty slowly.
Adding a speed upgrade would not add anything, as the bus would only export 1 item or fluid but might be handy for a manual export bus. Say to quickly fill a tank or chest with a specific item (but still select it manually). Thus a fast export bus would be limited to either items or fluids and also limited in the amount.
3 might actually be too limited, but just for an idea.

Internally, no idea currently. Maybe some sort of strategy pattern a card could provide for the machines it supports. Which would also required should allow addons to add more cards. (Which would still have a huge ? above it)

What could be implemented in this case, is different drops on wrenching. For example, on shift right clicking, part with all cards will be saved. But breaking (left clicking) block with wrench will drop all components, so they can be stacked.

I was about to say what @mindforger said. It could be used for disassembling saved parts.

Litterally, exactly what @mindforger said.

Not possible or at least not for crafting patterns as we need to push the pattern into the assembler and only afterwards inject the items. Processing patterns already work exactly like this and can use any machine, even a assembler with a dedicated pattern (But that would require 2 patterns in total)
Also we cannot support every block out there, it has to be a generic way. So either the machine just accepts items as basic inventory or they are simply not supported directly. Everything else just makes it harder to maintain and port.

The way it works right now, yes it is not. But if you use slot-order way, it is doable.

For example id input slots 0-8 and output slot 9 (molecular assembler):
[0][1][2]
[3][4][5] -> [9]
[6][7][8]

And pattern now uses instructions. For example, to craft beacon:
minecraft:glass -> [0]
minecraft:glass -> [1]
minecraft:glass -> [2]
minecraft:glass -> [3]
minecraft:glass -> [5]
minecraft:obsidian -> [6]
minecraft:obsidian -> [7]
minecraft:obsidian -> [8]
minecraft:nether_star -> [4]
[9] -> minecraft:beacon

Molecular Assembler simply analyzes grid puts result in [9].

Everything, of course in fancy GUI

@mindforger might be an idea, but for we have to redesign how a player interacts with blocks/parts. There is already an open issue for it. Like also move the interaction with storage monitors more towards barrels. And probably start rewriting the recipe system to support NBT data.

@Elix-x We have ways to summon Algo. We just prefer to avoid it for a couple of reasons.

Afaik the C&B API is not really designed towards it being used as facades and MCMP support would mean every other mod out there will work. Not just C&B.

Regarding addon devs. I cannot remember any of them reaching out to us about offering help or even asking about possible port. So they might not even be interested in porting theirs. So we should take care of potential new ones and not scare them away immediately.

I would really like to help, because I want to start 1.9 modded map with friends and we really need AE 2 (or what version it will be).
I could help with the models and the textures. I don’t know too much of Java, but I have great knowledge of C# so I think I can easily learn Java.

Ok, so the idea is to finish porting rendering over, release version with (barely) vanilla support and then adding new content and changing things?
I could work on rendering, i'm familiar with rendering system, jsons & block states... And i have 1.9.4 branch. If so, which mc version should i use (1.9.4 / 1.10)?

@AlgorithmX2 Parts system will require custom IBakedModel, jsons aren't enough for that, but individual parts themselves can use jsons. General part (block in world) IBakedModel will simply take all parts' (part of this in world block) models and combine them together, while applying rotations and transformations.

@JelmarG, @yueh all addon devs with github (that aren't part of AE2 team): @DrummerMC, @bdew, @Nividica, @Mordenkainen and @p455w0rd. Most of them wrote AE2 addons in scala.

@yueh i understand that you have ways to summon him, i just don't know who he is 😕 .

@Elix-x I realize, however I was adding that glowing parts cannot be done with simple JSONs, there are simply no options for that

@yueh i understand that you have ways to summon him, i just don't know who he is 😮 😕 .

Me?

@Elix-x I realize, however I was adding that glowing parts cannot be done with simple JSONs, there are simply no options for that

Glowing parts? Like glowing render effect or world illumination? Like which parts? (Sorry, but google didn't help... except for illumination planes).

@yueh i understand that you have ways to summon him, i just don't know who he is .
Me?

Oh, that Algo? Damnit, i thougt of some kind of bot-program-code-eater 😆 (Few years ago, i've seen bot-thing-something called algo, but don't remember what it was anymore, hence i was bit confused).

By glowing I mean,

This is used for all the monitor type parts, drive lights, and controllers. ( I might have forgotten a few )

Are there any glowing things that can be used as parts?

Yes, Terminals, and the various monitor parts all glow in the dark as well.

This obviously needs some kinda of solution, but whatever that is might be usable for all of them, for instance maybe some kinda of model preprocessor that loads other JSONs?

[ {"model":"json/glowypart.json", glow: 8}, {"model":"json/solid.json"} ]

or maybe some sort of secondary model loader that can be triggered by the blockstate file for a given json.

ICustomModelLoader is a thing. And can be used instead to load models jsons, if placed before in pipeline or invoked by yourself and passed IBakedModel instance to bakery. These IBakedModels can be reused anywhere, including IBakedModel baking cables & parts.

One question, though: in 1.8.9 AE2 code, brightness/glow you speak of was set by this field?

Might have been, I'm pretty sure that it was never properly implemented in the 1.8 codebase because I did that renderer before it was possible, it of course is possible with an IBakedModel now.

The Lightmap coords are a second UV parameter that can be set you could transform an exactly model and add the lightmap data as you swap to a supported vert format,
https://github.com/AlgorithmX2/FlatColoredBlocks/blob/1.9.4/src/main/java/mod/flatcoloredblocks/model/BakedVarientBlock.java#L179

It may or may not explain this field now. If this glow is done with light map, then it's very easily doable by adding luv to json (or not) and loading json with ICustomModelLoader.

I would certainly port my mods if a 1.9.4 version were available. I am currently neck deep in a rewrite from scratch of Equivalent Energistics. ( I cheated and used some internal AE classes, a crime I am working to rectify!)

I also would be happy to offer whatever help I can for AE2 itself. While I am still learning the niceties of Java, I have ~25 years programming experiance in 12 or so languages. In addition I am a Development Test Engineer by trade, so am familiar with development methodologies, software project management, and testing development with little to no documentation.

All that said, I have little experiance with OpenGL rendering, and have not even looked at forge for 1.9 4 yet.

if a 1.9.4 version were available

Uhhhm. What? They (forge 1.9.4) are where all versions are for over 2 moths now.

Clarification: "A 1.9.4 version of AE were available". Both my mods are AE addons.

Oh, you meant AE, sorry. Yes, they are not yet avaible.

Personally I think if the port is to continue it should be for 1.10. A lot of the mods that were out for 1.9.4 work on 1.10 already (whether the code just worked, or minimal porting was required). However it is up to you, if you continue work on 1.9.4, you could finish the code on that, have a release, and then port to 1.10, which probably won't take long.

Yeah, I'm here. I'm waiting for a working version which I can use for testing (and a short tutorial on the glowing effect). Can you recommend a program for modelling?

You could use Mr. Crayfish's Model Creator to make the base models for the terminal, etc. and then make all the models that are used later have those base models as parents.

I am willing to help if the AE2 team quits work on it

@dpeter99 Ok, thanks, i'll telll you when there will be. Glowing effect is not something possible in vanilla, so i'm currently writing custom model loader that will allow to do it. It's not yet finished, so you can't yet create models.

@XFactHD yeah, why not. That's a good modelling program and i'm not against using it.

@JOSEPHRYMER we will consider this. Thanks.

Well if you want im willing to start working on it today just need to setup the environment and get it going and ill make a pull request for the 1.9.4 branch you have also what if we decided to maybe incorporate some of the ad-dons from ae2 like AE2 stuff and others and start a team that references this team and all of its work

@JOSEPHRYMER first, read ALL of the comments, if you want to get involved. Then, you'll understand solutions and path taken by me, yueh and Algorithmx2.

right i will first thing in a couple of hours need to get some rest like 4:00 am

Good idea. Then you read all of 66 comments and then you will understand what's already happening and what will.

@XFactHD I am not certain that it would actually help us. Most of the blocks are simple blocks and most parts are not even that complicated.

But many of them require an absurd amount of different dynamic states, that might be something it cannot do reasonably well. Like a drive needs a whopping amount of nearly 10 million different versions. And that is the unfinished version. It also needs a good support for parent/child models.
It might be nice the get something going, but at the end it might be a waste of time, if you need to manually change every single model instead of just a shared submodel.

Further is it even for 1.9/1.10? Including the forge blockstates and not just vanilla? Currently I would assume it is nice for static and intricate models, but we need a tool which supports just some basic rectangular shapes, but highly dynamic ones. There is also really no difference between writing openGLRenderer.drawRectangle(x1,y1,z1,x2,y2,z2) and jsonRenderer.drawRectangle(x1,y1,z1,x2,y2,z2). I honestly never understand the whining about json models. If you do not like writing data files by hand that is fine. But if you cannot write a simple programm just to generate them, you basically fail as developer.

Also does it support animations? We need them for things like the grinder, inscriber and maybe something else. Forge has a specific subsystem for it. Not sure, if it works for our use case, but at least why not look at it?

@Elix-x Vanilla certainly has glowing blocks. Just look at the magma blocks.
Maybe they fake it by emitting a low light level (2 or 3). But the effect certainly does not match it.
Should it actually require at least a light level of 1, I do not think having AE2 blocks emit that would be a problem. With some parts like terminals being based on panels, it does not even make sense to not let them emit light. Maybe forge is simply missing the support for it?

@JOSEPHRYMER I do not see any reasons to include anything from addons. Maybe except ExtraCells.
Most if them are just there do dumb down AE2. Which is fine, but it was never a goal of AE2. It was pretty much always to force the players to think about it and also plan ahead. Some players certainly do not like it. But none of them are forced to play AE2. They can still use some of the addons to get some magic blocks, which do everything for them or even choose a completely different mod for their storage needs.
ExtraCells is somewhat of an exception, because AE2 internally already supports fluids. But it left the the actual handling to ExtraCells to not compete with it. Otherwise it would just add a few larger cells and nothing else. The reason some things might move to AE2 is mostly because the devs are also pretty busy currently. But even then we need to discuss it first with them. There is no reason to kill their mod, if they still want to develop it.

@Elix-x Vanilla certainly has glowing blocks. Just look at the magma blocks.
Maybe they fake it by emitting a low light level (2 or 3). But the effect certainly does not match it.
Should it actually require at least a light level of 1, I do not think having AE2 blocks emit that would be a problem. With some parts like terminals being based on panels, it does not even make sense to not let them emit light. Maybe forge is simply missing the support for it?

It uses getPackedLightmapCoords, which we could use (and i already tried), but it will affect entire block (so everyhing will glow, not just specific layer).

Also, crayfish's model creator is useful even in this case. It can be used to create a simply json model, you can do anything with it after. Like take all needed based on block state and assemble them. No need to make all 1 billion possible combinations with it, you make 1 model for drive bay empty and 1 model for each drive. Then in code, you assemble it in IBakedModel override. That's it.

The issue with these tools is that using them will allow you to ignore the JSON models at all. If you need to manually change them, you will not have any idea about them. Or in the case of tool messing it up.
Therefore a good understanding of them should be a prerequisite and with that writing a model file for a flat 2x5 px texture and 4 or 5 states is certainly faster than starting the tool, clicking around, exporting to the correct folder etc.

What is the meaning of coords in getPackedLightmapCoords? The coords inside the texture sprite for this block or local block coords? Also what happens with transparent areas of the lightmap? Are they ignored or could the be used to limit what is glowing?

Magma block does 2 thigns: it's emitting light of level 3 and it's overriding getPackedLightmapCoords.
Packed Lightmap Coords, are well, packed coords. It's skyLight << 20 | blockLight << 4, where lights are max of light levels for block itself and in each EnumFacing.
BTW, thanks for reminding me of magma block, that light level is exactly what i was missing (for some reason without this it wasn't working). I finally finished basic light mapping and can already change glow per face. Now i have to rewrite it in a better way, so it does not kill my FPS 😆.

In this screenshot glow is EnumFace.ordinal() * 2:I just noticed that creeper staring at me, i think his up to something...

We actually need glowing per pixel.

Personally I think if the port is to continue it should be for 1.10. A lot of the mods that were out for 1.9.4 work on 1.10 already (whether the code just worked, or minimal porting was required). However it is up to you, if you continue work on 1.9.4, you could finish the code on that, have a release, and then port to 1.10, which probably won't take long.

I already ported to 1.10 😉. Some changes to dispensers were made in between, so 1.10 AE isn't compatible with 1.9.4. I made separate branch for 1.10, and didn't publish it yet, so you can't yet see the changes.

I just want to say thank you to @Elix-x for doing this. If you didn't, I don't think it would have ever happened. I forked your 1.9 branch and I will do my own rendering. Sadly, it won't use MCMP/FMP as I just don't have time to learn them. It will use CCL for 1.9.4 which has an IItemRenderer interface that is amazing if you're used to 1.7.10 IItemRenderer. This means a shit ton of models (JSON). @covers1624 is planning a rewrite of the pipeline as well, so it should get even better in the near future.

@p455w0rd No, need to the rendering on your own, i'm into it already. And i'm trying to make everything with jsons. There's a reason, why it was this way. Although you can't see it for long time, one day, you're like ohhh... wow! And even though i made IItem Renderer libraray myself (without coremods), it was only after i realised how jsons were useful and only for things that can't be done with.

BTW, i think AE is trying to avoid 3rd party libraries anyway, so using CCL might not be the best idea.

AE isn't doing anything...the team is too busy with life or w/e...so I can sit here and let AE2 die, or do whatever is necessary to get it going..I didn't know you were working on rendering though..I thought that's where you were needing help. So if you got this, then awesome. It definitely can be done with JSONs (I've already made some stuff to test, it's just the ugly cuboid hitboxes that bug me and I haven't looked into how to do this without the need for something like CCL in 1.9+). So for now, I'll wait on you..but if nothing happens soon, I'll just do it to get something functional going and changes can be made from there to convert to whatever system and drop CCL dependency. I'm not saying I would release it or anything (I believe there's a huge legality issue there), I'm saying just for personal purposes so I know everything will work in 1.9.4+

@p455w0rd you know what, @dpeter99 offered his help, and i'll ask him to soon. I'll consider yours offer too, so when i'll need help with internal rendering, i know who to ask.

@dpeter99 are you still up for help? Right? If you don't know java, no problem, no java knowledge required (you can work on models).

Just for everybody, i'm currently writing uvl loader (somethign we talked with Algo recently). Not sure of final design yet, but i accidentaly wasted yesterday by making very dumb and small mistake in test block. I found it, so i'm back working on uvl loader.

The discussion about port it to 1.8.0/1.8.9/1.9.0/1.9.4/1.10/1.11 is pointless. The changes after 1.9 are pretty small and as long as there is no working version, targeting current forge is the best option.

I would recommend staying away any chickenbones lib. They are known to be a bit finnicky and more or less unmaintained. Should you find a bug, it will probably not be fixed. @covers1624 might have the intention to update or fix it. But as long as there is no released version, it can disappear tomorrow and leave you alone with a buggy lib, locking you to an outdated minecraft version. (Just look at MCMP).
I know NIH syndrome sucks, but the way minecraft modding works and people rather fork a lib and end up with 12 incompatible ones instead of contributing to the original one, it is pretty much impossible to avoid doing it yourself.

Is the CCL item render not even an artifact from 1.8? Either 1.9 or 1.10 introduces states for item(stacks), which should be sufficient for most use cases.

The way I understood it MCMP/FMP didn't disappear?

so for now, probably better to take Algo's advice..use/write a custom renderer and add FMP support later

it didn't afiak..kinda in limbo atm ..talks went private from what I've heard so only the core team of ppl involved know about the actual progress of the MCMP merge to FMP..

It disappears in the context of FMP not being merged for a potentially long time and thus being literally non existing. As long as there is a chance it might get merged, MCMP will not be released for the current minecraft version to avoid confussion. So either you choose between waiting for a merge or you are locked to a previous minecraft version, nobody wants to play.

A custom render should probably just load part models and rotate and combine them correctly.
Many parts even shared similar structures, like all terminals share everything besides the front texture and nearly all of them share the channel/power indicator on the back. Thus it should be a good idea to even split parts further and be able to combine them. MAYBE this could even be extended to allow addons to reuse them, but only should it be viable to safeguard it enough and not let the first addon completely crash it.

Loading normal JSON models would even allow resource pack makers to modify them. It might not the completely straigthforward, but the option would exist.

I can agree there..and making models is the easy part..so if someone wants to handle the rendering..I'll be here when models are needed..I just don't have time to figure out how to use extended properties or w/e the current system involves. Also, parts of CCL are broken and covers is the only person actively maintaining CB's mods, so things can take a while sometimes. I just don't want AE2 to die and I'd rather have it working sooner than later. If I can help contribute to that, I'm more than willing. It's what got me playing modded MC...

@p455w0rd First, i'll ask you to read all this topic from top to bottom, pretty please. That's very important for understanding of decisions we made and way we went. Yes, it's 57 comments, but if you want to help, it's very important to understand our choices. yueh told you some of stuff discusssed here (which it seems you didn't read) and i'll tell you only part of rendering & parts:
Instead of depending on specific library, AE will have it's own parts system. It's not very easy, but's not hard either, as AE does not need every 1/16th of block. When MCMP/FMP/WHATEVERMP merges into forge, does not merge into forge... AE will add optional support for it, meaning that it's not required, but AE is compatible.
Here we also discussed future of AE and order of things. I'll not reaxplain it.

@yueh, @AlgorithmX2 first 1.11 snapshots or 1.11 itself will come out this september during minecon. Considering 1.9.4 -> 1.10 is extremely easy update, mods will stabilize on this version. So that's the version we should work on (and i am currently working on).
PS: Oh and 1.10 updated required to update forge gradle. Just so you know.

So something Like this is good?
http://pastebin.com/ZfUeHp5K
and of course the glow layer later.

This is drive bay, right? I think you'll have to wait a bit until i can import it in game and take a look, but looking at json so far, it seems good.
We should be able to begin importing json models tomorrow. LUV loader is 90% complete and when i'll finish it, all i have to do is tear down current rendering system (it's not gonna be used anyway) and we are good to go.

Ok. Thats sounds good.
But under tomorrow what do you mean? (Witch time zone?)

UTC.

I have not really followed how the json definitions changed. But that one looks horrible for a full block with 5 sides using the same texture and a separate front one plus extra layer for cells. Especially as we need 24 rotations in total.

@yueh Block can be rotated in blockstate file. Also, he didn't make simply block, @dpeter99 actually made detailled model with casing, ranks...

Which does not really fit into the AE artstyle (not even really into minecraft). Having the option to allow resource packs changing it would be very nice, but the default one should keep the current look.

I... can't say much about that. I can only say that more dynamic models will be, more hardcoded they will be. For example, if we want for drives to be seen in drive bay, drive locations (in drive bay in world) will have to be hard coded, as they are too much for jsons to handle. But drive models and dirve bay model will be modifiable via resource packs.

There are a lots of mods do this:

• http://wiki.enderio.com/Soul_Binder
• http://minecraft.curseforge.com/projects/blood-magic

They only do this now, because it became easy. Personally, i'm not against this. If things can be done with jsons, why not? Time of 1x1x1 cubes was back in 1.7.

Multi texture layer models are basically multiple quads sittung on top of each other, each with one of textures. I can't do per pixel glow, but i can do per quad / texture layer.

Per quad is fine. Like on terminals only the screen is glowing, iirc 10x10 pixel or so.
Using full pixels is just easier to align it correctly with a texture.

Not sure about the multi layered texturing, but I know asie had a couple of issues with writing a multi layered rendering for the charset barrels using textures from other mods. This is something we could encounter with facades.

Per quad will be enough. If not, we will make every quad per pixel.
I'm experimenting with multi layer texturing & lighting right now.

@yueh you could for example make the drive and the storage cells with this tool and then copy the element information into a forge blockstate file. I think this would be easier because of the uv coordinates.

@XFactHD even simpler. You create model for empty drive bay and model for each of drives (jsons). Then you create dynamic model (in code, without json), which simply combines drive bay and drives models.
But yes, it may be easier to create empty drive bay and drive models (in this case) with this. it may not in others.

@dpeter99 could you post a screenshot of the drive, I would really like to see it :).

Here it is.

Looks awesome, great work.

"Other mods are doing it" is usally one of the worst arguments for something. If we go down this route, we can argue that AE should be able to turn cobble into every item existing in minecraft like EE.

In most example I would even argue most of them look like eyesores, that might be caused by bad models/textures and not because more detailed blocks, but once you start with more complex ones it certainly is easiert to mess it up. Out of my head I can not really name many mods with good models and textures. Even the inscribers and chargers already look a bit off in my opinion.
Or you end up with something like CyanideX's redesigns, which look all the same regardless of the mod.

Further AE is one huge multiblock, which is not the case for most other mods. We still have to render cable connections etc. So either the cables need to have special cases for every block out there (impossible due to addons or other mods) and slightly extend over their block, or every block needs to also handle cable connections (impossible due to other mods adding cables like EnderIO). Otherwise it would end up with gaps everywhere. Or limit connections to a fixed side, but I am sure players would be pissed, should drives only connect on the back. If they even understand it.

You can also expect that every second player will claim that anything but full blocks will cut over 90% of your performance.

Could we just do this (c# but should be similar in Java):
http://pastebin.com/YEzMugCJ
Or similar.

Could we just do this (c# but should be similar in Java):
http://pastebin.com/YEzMugCJ
Or similar.

Someting similar is done, not exactly like this.

@yueh, @dpeter99 cables are completely different thing and has nothing to do with drive bays or pylons or anything else. I'll also say that with jsons, it is easier to display drives inside in 3D (~what @dpeter99 did) than flat texture overlays we had in 1.7.10. Flat layers will require more time and more performance.

I think I can make both:

• The 3D (the picture)
• And flat. with offsetted planes for the drives

I don't think that many people would connect a cable to the front of a drive bay anyway.

As i already said, flat models will require more work (with jsons and internally) and will eat more performance. So design is to consider.

@XFactHD you just derped. This is not to be closed. Thanks.

Yep, that was not intended...

But if I make the models the same way Drive and Cells than it is possible to make a resource pack witch just flattens the drives and makes the cells just a bit longer (0.001 or so). So when the program moves the cell models it would put it into the right position.

Update on the models

Cables are not something different. Currently a cable can connect to a drive from the front, that could change, but for now let us keep it. But if the front is inset one pixel, there will be a gap between the cable connection and the drive. Maybe not many will connect it that way, but that is no reason to have it look ugly.

Also one important thing is consistency. Like you cannot display cells as square items and then render them as rectangle inside a drive. So a drive should be around 6x6x2 pixel and the slot maybe 5 pixel deep.
I do not think it is bad, but neither is it really great. It looks more about it was done because it is possible and not because it actually improves the look. A filled one would probably also look strange because the cells would touch the borders. It would certainly be better, if a drive would only hold 8 cells and a cell would be 5x5x2 pixel, so they could have a bit more room around them.

Considering consistency, cells in hand will have rectangular model, that's will simply be added to drive bay when baking. Thus drive's model is the same in hand and in bay and we don't need 2 separate models.

Considering cables and block depth - that's something that should be looked into. Simpliest way would be to disable connections to not full (or at least ones that extend up to block's border) sides. Logically, in real world, you do not plug in all cables in front of your PC (you may plug headphones / a few USB devices, but not 2 screens, power and a printer... unless...). If we simply extend cable by say 1/16th of a block, this will work for some models, while it will be not enough for ones and too much for others. Detecting how much to extend is nearly impossible with only model. It can be done, but method / special interface implementations will be required.

Couldn’t we just put a parameter in the Json so you can read that and put the cabel accordingly.