1.10.2 - Applied Energistics 3 / rv4 / rv3 ?

[Elix-x]

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/Applied-Energistics-2#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 :stuck_outtongue:), 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](https://github.com/MinecraftForge/MinecraftForge/pull/2984), 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.

[JelmarG]

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

[Elix-x]

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.

[AlgorithmX2]

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 https://github.com/AppliedEnergistics/Applied-Energistics-2/commit/38afde724b9e5158637c91502e02719ebcdc4ee5 ) 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.

[Elix-x]

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.

[Meller127]

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

[yueh]

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.

[Elix-x]

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.

[yueh]

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.

[Elix-x]

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.

[yueh]

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.

[mindforger]

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

[Elix-x]

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

[yueh]

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

[yueh]

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)

[Elix-x]

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

[yueh]

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.

[Elix-x]

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.

[yueh]

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.

[Elix-x]

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.

[yueh]

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

[Elix-x]

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.

[yueh]

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.

[Elix-x]

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.

[AlgorithmX2]

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

[Elix-x]

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

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

[yueh]

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 :wink: 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."

[Elix-x]

@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 :wink:

2 things come to my mind:

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

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

[JelmarG]

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?

[AlgorithmX2]

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.

[yueh]

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

[dpeter99]

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.

[Elix-x]

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

[AlgorithmX2]

@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 :open_mouth: :confused: .

Me?

[Elix-x]

@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 :laughing: (Few years ago, i've seen bot-thing-something called algo, but don't remember what it was anymore, hence i was bit confused).

[AlgorithmX2]

By glowing I mean,

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

[Elix-x]

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

[AlgorithmX2]

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.

[Elix-x]

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?

[AlgorithmX2]

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

[Elix-x]

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.

[Mordenkainen]

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.

[Elix-x]

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.

[Mordenkainen]

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

[Elix-x]

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

[61352151511]

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.

[Elix-x]

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

[p455w0rd]

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.

[Elix-x]

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

[p455w0rd]

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+