It needs to be done.

@unpairedbracket, what all is left to do in the 1.8.9 port you started? I'd like to start work on a port to 1.9 and I figure it'd be best to use the files you already have somewhat updated. Any strange issues that I should know about?

ChickenBones has announced he's not going to update Forge Multipart past 1.7.10 and is instead passing the torch onto MCMultipart (https://github.com/amadornes/MCMultiPart), so we'll likely need to do some serious multipart and rendering changes for transmitters.

To-do:

• Minor fixes:
  • Electrolytic Separator/Metallurgic Infuser right face mirroring
  • Transmitter item render cull face (block render too?)
  • Get transmitter collision/occlusion/ray tracing fixed up
• 1.8.9 -> 1.9

I had it working to a reasonable level a while back, but merge conflicts are a killer and updated rendering is a lot of work. I've got exams starting in a few weeks, but I'll see if I can get the update into shape before they stop me having any time to do anything.

The transmitter systems are all currently commented out/excluded in my workspace, and I was planning to get the main part of the mod working before embarking on porting them to amadornes' MCMultiPart. Also will at some point need to investigate Forge's new Capability system (MinecraftForge/MinecraftForge@17db34a and https://gist.github.com/williewillus/c8dc2a1e7963b57ef436c699f25a710d) and IItemHandler (MinecraftForge/MinecraftForge@a1e41f5). Will also need to update some of the stuff I did over a year ago before 1.8 was mature in Forge, as per this, which may be helpful in general, as will this when we get to 1.9

Ah, cool. If you can just get things working in 1.8.9 I'll finish the job for 1.9.

will mekanism v9 be for 1.7.10/1.8.9 & 1.9 at same time? or just +1.8.9/1.9?

I believe it is just for 1.8.9 +

v9 will be on 1.7.10 as well, as far as I know.

@unpairedbracket, what's your ETA right now on the 1.8.9 port? I'm about done with new content and would be happy to help.

I've gone ahead and set up my workspace for 1.8.9- it looks like there's a lot to be done, especially in terms of rendering. What areas are you going to be working in? I don't want my commits to collide with yours.

Current state of rendering: Most blocks render, except from some of the newer BasicBlock blocks, but that's only because I couldn't be bothered to make them work. I think most ItemBlock renders work, apart from those BasicBlock states that don't render as in-world blocks, too. Item renders are largely not working - those that do just seem to happen to work on their own, because I've put very little time into working on that side of things.

Block render testing can be seen in the screenshots here — Some blocks have duplicated rendering currently. This is because I'm trying to move as much TESR rendering as possible into the new static block rendering system, but I've kept most of the TESRs rendering at an offset position for comparison and testing. Things like the new configurable sides on energy cubes should be possible using Forge's submodel system, though it's not something I've explored yet. Blocks with many different things going on (the many tiers of gas tanks and 20-something kinds of factory) aren't properly implemented yet, and I'm not sure how best to account for the many many different textures required.

Submodules: Tools compiles, but nothing is rendering yet and I've not tested whether anything works either. Generators doesn't even compile at all; it's a fairly large and non-trivial codebase, and I felt it would be better to focus my efforts on the core mod before tackling it.

Multipart: transmitters and glow panels exist in game and can be placed. Neither even try to render yet. Transmitters won't work properly until we've got the relevant interfaces represented as Capabilities and use them in that way instead of as raw interfaces.

Capabilities: Would probably be a good idea to create these for each of our inter-block interaction interfaces (Energy interfaces are sort-of partly implemented already, but gas interfaces will need doing to. Also will need to replace instanceof IFoo with relevant capability calls where possible, and Capability-ising ITransmitter and all of the interfaces formerly registered as passthroughs in CB's FMP will be necessary to restore the passthrough behaviour. Eventually it might be a good idea to change all our (for example) IEnergyStorage implementing tiles to just have an instance of EnergyStorage they can use as their capability — I believe this is how the system is supposed to be used. Also, because hasCapability and getCapability are side-sensitive we should eventually be able to remove side-dependence from our interfaces, and implement side-configuration logic in our hasCapability and getCapability functions.

I'll probably have less time to work on the port in coming weeks, but I hope this has all the information you'll need to carry on the port even if I largely drop out. Until I do, working on getting the items working as they should again and getting Generators into shape would probably be a good place to start, as I don't think I'll be working on that stuff very much at all.

Sounds great, thanks for the detailed update.

I'm in the process of updating the json files to match the new assets we've received over the past few weeks, hopefully that will fix up a good bit of the block rendering. I'm also going to try my hand at updating the CTM library.

If you could focus on getting transmitters working with the new capability system, that would be awesome- it seems like you already have the hang of that and I'm only just now understanding the way rendering works :)

Will you be able to continue your work after finals? I'm graduating in less than two weeks and should have a lot more time to work soon.

Also, another question- how are you converting the java-based models to json?

Sounds good :)

I'm not sure how the new CTM code will work in conjunction with the normal model system on the same block - it may be the case that factoring all of our CTM blocks out separately from our non-CTM blocks (and especially those with non-cube models) will end up being necessary, but I haven't seen their code so it's hard to say.

I'll see what I can do with transmitters - it shouldn't be too hard to get them to render (in at least some form) and get their functionality working to some degree.

I think I'll be fairly free after my exams (late June/July and after) to give some more help, yeah :)

I've been using this perl script (it's at mekanism/client/model/modelbase_to_json.perl in our source tree) to generate our json models. It's used like perl modelbase_to_json.perl ModelSolarNeutronActivator.java > ../../../../resources/assets/mekanism/models/block/solar_neutron_activator.json, assuming you're on something with a bash-like shell. It's pretty good but has some caveats: You'll need to add the names of the textures into the json model file after it's generated, and make sure they're all square textures. Some of the models give it some problems (the digital miner model was for some reason trying to render a whole block over from where it actually is) so require slight modifications to the script to make them work. It doesn't currently support rotations, as the json format only supports increments of 22.5 degrees. Parts of models that are rotated will require manual fiddling, and failing that we can render just those parts with a TESR, I guess. Resizing our textures from (often) 2:1 aspect ratio to square leaves the bottom blank. This doesn't cause problems but uses up video memory unnecessarily - I'd suggest either combining pairs of textures (one above, one below) or splitting them into smaller units like the transmitter textures currently are; I wouldn't suggest bothering with this until the rendering is fairly finalised though, it'll just give us more work in future if we do it prematurely.

Oh, and something else I expect might come up - we might need to move generators' and tools' assets into assets/mekanismgenerators and assets/mekanismtools respectively, as I think this is where the game will look for things like models and variant files.

Have you talked to @CyanideX about the models? The limits of 22.5° rotations might screw up some of them models. JSON shouldn't be a must, in Blood Magic we are using OBJs too.

@Yulife, I will just use TCN2 to convert the models to wavefront (OBJ).

@unpairedbracket, how long do you think it'll take you to get multipart functionality and rendering set up? I've almost finished the rest of the rendering, it'd be cool to at least get some kind of beta 1.8.9 release ready before I push v9.

I might have a chance to do a bit more work on it in the next few days - they seem to be sort of working now, but I haven't looked at rendering them yet. Don't think that should be too hard though.

Alright @unpairedbracket, we're down to just transmitters and glow panels. Are you working on them right now or should I start working on getting them rendering?

I think they just need rendering work done now? The Glow Panels are rendering, but not in the correct colours just yet, and I've got Universal Cables rendering a placeholder model (only center box, no texture); I think the transmitters will all need extended states to avoid having 16000+ states registered per transmitter type. If you want to take a look, go for it - I'll hold off on them for a while.

Honestly, I'm more scared than I'd like to admit of getting transmitters and glow panels to render properly- I haven't done any research on dynamically rendering .obj models. If you think you have some idea of what you're doing I'll let you work on that- I can start on a compatibility layer with JEI. Otherwise, if you're just as clueless as me- well, I guess I can take a look :)

I've completed the rendering of Glow Panels utilizing a custom model loader as well as an ISmartItemModel/ISmartBlockModel combination which sets the color tint of the faces specific to the "light" element of the Glow Panel model. Though I wish the Glow Panels rendered a little brighter in item form, everything else works perfectly. I'm going to start looking into JEI (which will likely require a Forge version bump), let me know if I can help at all with any elements of the transmitter rendering.

I'm actually going to go ahead and try to get Glow Panels to render properly by utilizing a custom model loader and transforming the baked model with the defined color. I won't touch any of the transmitter code in case you have work in progress.

I think I might have something resembling an idea of how to do transmitters - I'll take a look at it now.

Alright, I've just about finished the JEI support in full. @unpairedbracket, what's the status of transmitter rendering?

You should support Tesla, people say it's the power API of the future.

I think it's time to begin the port from 1.8.9 to 1.9- I'm going to start now using Forge 1.9.4 latest (1919)

@unpairedbracket, I'll leave the 1.8.9 branch around but let's focus development on 1.9, I don't plan on releasing any build for 1.8.9.

hmm, bad to hear that you port mekanism v9 to minecraft 1.9
will you release a bug fixed version for 1.7.10?
or fix the bugs on 1.9?

some of the mods i use are not portet to 1.9 or 1.8, so i stick around for some time in 1.7.10

@HadesDurin how a port to 1.9 could be a bad thing ? It's normal to have things moving and @aidancbrady shouldn't be blamed about other mods not upgrading ;-)

Ho, wasn't a 1.7.10 upgrade released a few days ago ?

@cambierr moving on is good thing, no question about that.
But mods like railcraft, ae2 and others (like the team cofh mods) that i use are not ported to 1.8 or 1.9.
Mekanism v9 is a good moving on from mekansim v8, but bugfixing in 1.7.10 makes more sence for existing version than moving on to 1.9 where many bugs don't count as heavy as they did for 1.7.10, especially when i see the team cofh mods not ported and there are some issues at the moment.

I am far away to blame @aidancbrady for mods not be upgraded, i just want to make my point clear and give arguments to move on, but not port to 1.9 right now.

@HadesDurin I understand your situation but afaik railcraft & ae2 are on their way to 1.9 (but you're right about cofh mods :/ ) I guess it's the reason why Tesla API was developed!

What are the bugs you encounters with 1.7.10 ? I don't see any right now ?

There is almost no point in porting a mod to 1.8.9 now and to 1.9 shortly afterwards, especially for big mods like Mekanism. Railcraft is about to get ported strait to 1.9.

The following is out of topic character
after moving from v8 to v9 i encounter energy problems and tracking down the issue reveals that mek v9 and team cofh mods does no longer work together, so as a bypass i have to find a solution and make this report of the issue (#3252). at the moment i make preporations to say goodbye to some 1.7.10 mods i use like big reactors, team cofh mods and some others to be ready for 1.9, when i have to move on with my world. my biggest problem is the loosing of ores and the empty holes they leave, so maybe you have a solution for me for that.

@aidancbrady I noticed there aren't any builds on the dev branch yet. Plans to add the 1.9 CI to that? All I see is 1.7.10 at the moment

Once I've fixed the majority of the v9 bugs and the 1.9 port is playable I'm gonna merge it into the development branch.

Thanks. What about indiewikis?

@XFactHD, I ported to 1.8.9 first so that I would not be overwhelmed with the changes by two major Minecraft versions; it has proven to be very helpful, as the 1.9.4 port has (so far) been reasonable.

I'm planning on continuing to maintain and update the 1.7.10 release until further notice, I'm just currently occupied by the port.

Thanks @aidancbrady, it's nice to see that there are some people out there also thinking like me and not saying "get fucked 1.7.10 users" 😏

Assuming you're a premium subscriber, yeah, you'll get it as soon as it's ready :)

The "port" side of 1.9.4 is now complete, I'm going to give myself a while to do some testing and then I'll push a build for the development server for all premium users to test. I'm excited :)

@aidancbrady us too!