[1.10] Porting

[lehjr]

I've started porting to 1.9.4. I've Got Numina mostly up and running . I still have to update the sound handler since sounds are now event based, and I need to see how TileEntities are synced since getDescriptionPacket() is no longer a thing. I'd like to bring back the customizations and the models from 1.7.10, but I'm not sure if it's even possible with the rendering/model changes.

All that said, 1.9.4 is already a disappointment for me so far. This is with Numina up and running with no other mods installed, leaving nothing but Vanilla rendering and worldgen:

Edit: TODO List/progress: Numina porting:

• [ ] Figure out the new sound system once MPS gets that far
• [ ] Networking tweaks
• [ ] Rendering? (figure out what is and isn't possible)
• [ ] JEI recipe handler tweaks

MPS porting:

• [ ] New Power Fist models (one with normal pose and one with open hand for firing plasma cannon) - partially done in OBJ format, needs coloring
• [ ] Armor Rendering + customization (see Numina rendering above)
• [ ] Lux Capacitor model rendering and colorization (in 1.8.9 I had issues with the OBJ models and had to make my own in JSON format. Even then, I could not get the texture to stay aligned and had to use a single color texture for the thrown entity part).
• [x] Power Tool tips - These were missing in 1.8.9. I really need to bring this back in 1.9.4 since without them, it's nearly impossible to figure out how much charge each armor piece has.
• [ ] Power Systems Compatibility - depending on what the mod landscape looks like, I might implement other forms of power. I don't even know if there's an official RF API yet.
• [ ] EV Capacitor - There's been a texture for it for some time now. As far as I can tell, it was an idea that was never implemented, probably because the armor has such a massive amount of power storage at its top tier already. It might be an idea though to use this as the top tier storage and rescale the lower tiers.
• [x] Running in Dev environment - in 1.7.10 building the mod from source was rather straight forward. Getting it to run in a dev environment was a nightmare. Going forward, it will be easier to use repos (maven/ivy/whatever) and update as needed.
• [ ] Addons and external mod support - Supporting external mods through modules made running in a dev environment extremely difficult and heavy at times. For instance, the Chisel module supporting 2 conflicting versions of the mod required disabling one to get MPS to run in a dev environment (this was actually in MPS and not the addons). The Forestry plugin couldn't be updated because the newer version disabled support for some bee addon for Forestry. The EC2 and AE modules were RV1, then RV2/RV3 but had some issues when EC2 finally dropped the old AE API. The OmniWrench suddenly caused crashing after what appears to be CoFH-Lib being in CoFH-Core. Railcraft caused issues with running in a dev environment because they often bundle outdated API's of CoFH, IC2, and Buildcraft. On and on.. In summary, the Addons may see a return out of necessity, depending on the lifespan of 1.9.4.

[lehjr]

It's a vanilla bug: https://bugs.mojang.com/browse/MC-90602

[Lordmau5]

getUpdateTag() is for the initial packet and onDataPacket() is for when you receive new packets. Keep in mind that you need to write the NBT in getUpdatePacket()

https://github.com/Lordmau5/FFS/blob/1.9/src/main/java/com/lordmau5/ffs/tile/abstracts/AbstractTankTile.java#L98

[lehjr]

@Lordmau5 thanks! That just leaves sound, which I'll figure out later. I'm hoping I can bring back the models from 1.7.10, but the rendering system is quite alien to me.

[Lordmau5]

https://mcforge.readthedocs.io/en/latest/effects/sounds/

I was looking for this for the past 30 minutes on Google just to find out that there was something on the Wiki about it, haha.

[lehjr]

Thanks again. Looks like I'll put that off until I start working on MPS itself.

[lehjr]

Looks like I'll need another pair of models for the power fist thanks to being able to switch the main hand. On a side note, I just love it when Scala tells me that a method overrides "some base member" but won't tell me where. I know the syntax isn't always easy to read, but that's just pointless.

[Lordmau5]

I just noticed this part:

[...] the Chisel module supporting 2 conflicting versions of the mod [...]

Just play it safe and go for support of Chisel-Team's Chisel. :)

//EDIT: Or just don't implement any addon-stuff at all and make a custom "base-addons" mod, which includes Chisel, Forestry, ... support :P That way MPS can stay clean and other people can include the mod if they need / want it.

[Xen1290]

@lehjr For chisel @Lordmau5 is right, Chisel-Team Chisel is the right version to support.

For the dev environment: i think that Numina need to be incorporated into MPS like mps addons. In the past was necessary this division because MachineMuse developed Anima, but now isn't the case. Results: less problems for the dependencies, only one project, easy to run in a dev environment.

[lehjr]

The chisel module itself isn't even a consideration atm as I'm still working on getting the base of MPS itself ported. It wasn't even enabled in 1.8.9. Having Numina as a separate mod is not really an issue as it's just one dependency. The issue is having modules that support mods that either update and change their API's frequently or are slow to update between Minecraft releases (or don't update at all) such as Railcraft, BluePower, Applied Energistics/Extra Cells, Mekanism, Project Red, Thermal Expansion, MFR, probably others as well. Mod interaction is a great experience for the end user, but for the developer, it can be hell to deal with, especially when MC versions have shorter life spans. In order to move faster between versions, you have to travel lighter. As such, some of the modules may either be dropped or moved out into an addon package.

[Xen1290]

@lehjr I think that now addons are the last thing to do. As you said, MC versions have shorter life and not all mods update to newest versions, so you don't need to update those addons. Once the main mod is done, you can focuss to addons. For now you can disable those addons.

[Xen1290]

For Numina, i tried to setup a dev environment, and it was a pain, I've never got a working dev environment, instead for example immersive engineering was very easy, and this mod has a lot of dependencies to deal with, like MPS. Keep in mind that i don't know java very well. Maybe it's only me.

[lehjr]

Any addons will depend on the mod ecosystem and the life span of the current version of MC. I have a feeling a few popular mods might have spent too much time milking 1.7.10 for all it's worth and adding even more things that will make porting even harder instead of focusing on the future.

Integrating Numina back into MPS wouldn't make it any easier to run in a dev environment. It would just make more of a mess by increasing the size and complexity of MPS itself.

[lehjr]

If you're referring to getting the 1.7.10 dev environment setup for MPS, that's a different animal. The dependencies were only met for building, not running. On top of that, there were some issues like Railcraft using outdated API's and one of the SmartMoving libs had an incorrect reference that made it crash Minecraft. Then there were the 2 conflicting Chisel mods as dependencies, so you had to comment out one in the code. All of that is just another reason why I want to cut down the dependencies for MPS and go with addons where possible.

[Xen1290]

Yeah I'm referring to 1.7.10 and for trying to running a dev evironment. Anyway for the rest, I'll see what you will do. I will follow your work. Good Luck!

[lehjr]

And... Forge builds for MC1.10 have already started showing up.

[Xen1290]

Yeah, and MCMultipart will be included. So.. Directly 1.10?

[lehjr]

I'll probably finish a working build on 1.9.4 first mainly because almost everything I have left is rendering stuff and the sound changes. I also have to create 2 more models for the power fist because of the ability to change the main hand and because of dual wielding. I still haven't textured the first 2. https://github.com/lehjr/PowersuitsModels/tree/master/PowerFist

[lirannl]

I heard that 1.10 is a very, very easy transition and that the Forge API barely changed at all.

[lehjr]

I'll probably start working on the sound stuff this week. After that I'll do the other 2 models I need followed by the rendering. Once I can get a working build done I'll look at 1.10. It just makes more sense for me to focus on getting a working build to port rather than porting untested code.

[lehjr]

OK, so on to 1.10 porting. No more MC version changes until I get everything ported over to the new rendering system.

[lehjr]

Numina is on 1.10 now, not quite finished as I still need to finish up the sound changes and clean up some old 1.7.10 code, but it's usable now.

[lehjr]

Working on weeding out the depreciated stuff, then it's time to experiment with Forge's working example of using Obj models with IModelPart to toggle visibility of model parts.

[lehjr]

Currently working on applying the original powerfist texture to the new OBJ models. I should be able to apply the texture to one model and reuse the mapping for the other 4.

[lehjr]

Finally got the power fist models rendering. I ported TheGreyGhost's Item Transform Helper to 1.10.2 to help with the job. I still have to work on the textures, since model textures all have to be square now. (Edit: yes, this is the left hand equipped model since main hand can now be right or left hand. Right hand models is the same but for the right hand)

[Xen1290]

Wow! Very good work lehjr

[lehjr]

In case anyone is wondering what the holdup is, it's the rendering, specifically the color customization. Due to changes in how models are handled and rendered, it's a bit more challenging than I would like. In 1.7.10, models were rendered "raw" and it was easy to change the color of a model or a part at render time. However, the "baked" model system is a static model system that doesn't play well with changing things after the models are already "baked". That said, I'm still pressing forward and trying to get things as close to what they were in 1.7.10. It's just taking far more time than it really should.

[azurewyvern]

All I can say is.....amazing. I can't wait for you to finish as this mod was one I have been missing for a very long time.

[lehjr]

Lux Capacitor finally done, colors and rotation finally working. I scaled down the original models and created a new texture. The frame is being rendered with the builtin setup while the lens is being rendered with a TESR. Lens color change is done through material color change. Each uniquely colored lens model is cached for each model rotation. Now to get the armor to render.

[lehjr]

I really hate to do it, but it looks l like I'm going to have to port some of the scala code back to Java. It's given me nothing but issues and it's costing me time, not to mention it's damned hard to read at times.

[lehjr]

I guess while I'm at it, I'll see if I can optimize the network bandwidth a bit by using smaller data types where possible. For instance, instead of using 3 doubles (64 bits each) for each color, use 1 int (32 bits) for all 3 (8 bits each plus 8 bits for alpha).

Edit: This change was made for Lux Capacitors, the armor is much more tricky, but much of that was already optimized.

[lehjr]

Looks like I haven't complained about the rendering system in a few days, so let me start off with an epic rant on that < insert epic rant here>. Moving on...

[eyeonus]

Considering all the awful that is the 1.8+ rendering system, have you looked in to render APIs?

This one https://github.com/jaquadro/Chameleon is apparently more like the 1.7.10 render method.

[lehjr]

Thanks. No, was actually trying to avoid relying on external API's as much as possible just because I have to wait on those API's in order to port to the next version. This is why I'm ditching SmartMoving.

However, given how much time I have spent on rendering code and still working on it, I will check this API out. Anything that simplifies things is welcome.

[eyeonus]

All I know is, it's by the guy that does the Storage Drawers mod for 1.10, it's a required library for that.

According to him, "Chameleon Mod 1.10.2,1.10, 1.9.4,1.9, 1.8.9, 1.8 is a shared code library for Minecraft 1.8 and later. Although it does not currently provide rendering hooks to restore the 1.7 render pipeline, it does provide a more comprehensive RenderBlocks replacement that is also suited for TESR rendering."

I linked to the github. If it's [open source|permission granted], you could internalize the code you need, assuming you wanted to put the effort in, or could show me what is you need to do. (I'm much better with code than graphics, but I don't know scala at all.)

[lehjr]

Well, I'm not good with Scala either and it's one of the things that has slowed down porting. I've actually toyed with the idea of porting everything to Java for that reason. However, the mod is much larger and more complex than it looks, and there are some areas where Scala is actually much simpler and easier to read, especially when dealing with traits and sealed traits.

The big obstacle with rendering is that the old method used "raw" models and you could interchange them with ModelBase models. Models now have to have everything applied before baking, meaning that parts have to be colored by changing material colors, and parts have to be toggled on or off and then the model is "baked" and the rendering is done by a completely different setup that uses quads. Then you have to figure out a new key-value system to store these things because every change you make is a new model. Every change someone else makes is a new model too. Then you have to sync all this stuff between players.

[eyeonus]

Does the texture have to be baked in as well? It is possible to re-bake the models?

[lehjr]

When using the built in loader and baking system, textures are cached for you, but not if you are calling the load/bake system yourself. In that case you have to cache the textures before baking. I don't have the code in front of me ATM, but textures are cached then a reference to the texture is baked in, I think. The texture must be cached using the texture stitch event. I think I ran into some issues with this because of the model bake event firing first. You can however bake models without the event. Rebaking the models causes the model in the model cache to change, so this is pretty useless.

Currently I'm working on porting The 1.7.10 version of Numina to Java. I'm gonna see if I can port both MPS and Numina 1.7.10 versions over this week and go from there. This way it will be easier for people to contribute to the project.

On Monday, October 10, 2016, Jonathan Jones notifications@github.com wrote:

Does the texture have to be baked in as well? It is possible to re-bake the models?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MachineMuse/MachineMusePowersuits/issues/725#issuecomment-252701909, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCLzyHHsNWA7Ro0tva0hZqp5Uk3-WjSks5qyoQsgaJpZM4IxjWD .

[eyeonus]

I ask because, if the renderer gets the texture externally, you could change the texture without needing to re-bake the model. If, on the other hand, the texture is part of the baked model, I got no ideas.

[lehjr]

texture is mapped as part of the model when it's baked. You can in some instances change the texture, but for MPS, textures don't change, just the part colors and the part visibility. But for every one of those changes, it requires a new baked model.

[eyeonus]

If it's possible to change the texture without re-baking the model, then you can do the color changing without needing to re-bake. A red texture is different than a blue texture, just apply the color values to the texture directly.

As far as part visibility is concerned, the only thing I can think of is to pre-bake every possible combination of pieces with a default white texture. Depending on how many parts, that could be a lot of models, but that's not nearly so bad as having to make a new model for every combination of parts and every possible color for every part.

[lehjr]

The colors aren't simple colors, they're 4 bytes meaning millions of textures would be needed for that and they would have to be done as a translucent overlay because the models already have textures.

On Monday, October 10, 2016, Jonathan Jones notifications@github.com wrote:

If it's possible to change the texture without re-baking the model, then you can do the color changing without needing to re-bake. A red texture is different than a blue texture, just apply the color values to the texture directly.

As far as part visibility is concerned, the only thing I can think of is to pre-bake every possible combination of pieces with a default white texture. Depending on how many parts, that could be a lot of models, but that's not nearly so bad as having to make a new model for every combination of parts and every possible color for every part.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MachineMuse/MachineMusePowersuits/issues/725#issuecomment-252738140, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCLzzDvdG2oZTqJy6e4IsyJ628E52tMks5qyqDxgaJpZM4IxjWD .

[lehjr]

basically there are no simple solutions. I'm hoping to come up with some ideas while porting the mode fully over to Java.

[eyeonus]

Okay, I'm sorry, I must not be explaining things correctly. Use ONE texture, do the texture stitch caching thing, apply the color changes directly to THAT texture. All you need is the memory location of the cached texture, the original texture, and the ability to write to memory.

White texture -> Baked model texture cache white texture (sample pixel = [0xff,0xff,0xff])-> color changes -> blue texture [sample pixel = [0x00,0x00,0xff]) blue texture -> write to cached memory location

Baked model texture cache = blue texture.

[lehjr]

If you change the color of the cached texture, it would be changed globally. Models use a single texture for all of the parts. Every part is able to be colored independently. By changing the texture color, you change them for every player model that your player sees.

[eyeonus]

What I'm suggesting would work for all of that except possible SMP-related issues with other people also having the armor, and I'm betting I could solve that too, but I'd need to look at the code. It would be easier if each piece had its own texture, but still possible without that, just more annoying code-wise.

Point me out to the code that does the texture making. I obviously don't have enough information on exactly how texturing works.

[lehjr]

All the textures are stitched into a single global sheet, including Minecraft textures. These textures are then accessed through a TextureAtlasSprite which contains coordinates and a name. What you're looking for is IRetexturableModel. I don't have anything working on that at the moment because everything is in Scala, which is why I'm porting it over to Java in the first place. However, thinking back, IRetexturableModel I believe is an IModel, and if that's the case, then it does have to be baked anyway.

In 1.7.10 the code is completely different. The colors are applied through openGL calls and each part is rendered individually. In 1.10.2, models are rendered as baked quads, and you normally use built in methods which are either an itemRenderer or a blockRenderer because even rendering is threaded now.

[eyeonus]

Okay. SMP would be difficult, it could be done for up to 'x' sets of armor, but I don't have any idea for unlimited sets.

One texture per piece per set, direct memory access to the sheet, replace the texture for the specific piece on the fly by modifying the source texture and overwriting that spot on the sheet with the modification, leaving the source texture unchanged.

Multiple pieces could use the same spot on the sheet if they're too small to need a full one to themselves. Any parts that were a single color could be represented by a single pixel in the source texture, for example.

On Oct 10, 2016 16:00, "lehjr" notifications@github.com wrote:

All the textures are stitched into a single global sheet, including Minecraft textures. These textures are then accessed through a TextureAtlasSprite which contains coordinates and a name. What you're looking for is IRetexturableModel. I don't have anything working on that at the moment because everything is in Scala, which is why I'm porting it over to Java in the first place. However, thinking back, IRetexturableModel I believe is an IModel, and if that's the case, then it does have to be baked anyway.

In 1.7.10 the code is completely different. The colors are applied through openGL calls and each part is rendered individually. In 1.10.2, models are rendered as baked quads, and you normally use built in methods which are either an itemRenderer or a blockRenderer because even rendering is threaded now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MachineMuse/MachineMusePowersuits/issues/725#issuecomment-252757598, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpz4JH1IdmU6d2zGvPIksuJbL_U3eHyks5qyrVsgaJpZM4IxjWD .

[lehjr]

You can't change the sheet after the stitch event, and the stitch event is only fired once. It's not impossible to recolor models, but it's not easy. I did finish the Lux Capacitor, but I haven't uploaded the code because I started working on the armor, figuring it wouldn't be that horrible and the code blew up from there.

Basically for the LuxCapacitor I'm using a hashmap and storing by color and model rotation. That's easy because there are only 2 parts and only one gets colored. The armor models have multiple parts, and multiple models. There are actually 2 sets of armor models with parts mapped to different parts of the player, at least in 1.7.10. In 1.10.2, nothing for that is working yet because all of it needs to change. At the moment, I'm still trying to think of a key-value setup for the map to store the baked models. I came up with a couple ideas but nothing concrete yet.

[lehjr]

I've made some pretty good progress porting the Scala code to Java. I'm doing this in 1.7.10 rather than 1.10.2 because it's easier to try something that already works. The biggest obstacles will be Scala Traits, especially those that extend other traits and interfaces and have working code because Java interfaces can do neither. Other issues include just deciphering some of the weird syntax and figuring out equivalent data types.

This is an unexpected delay, but unavoidable. Scala is great for those that are great with it. But it limits the amount of help available because not everyone is proficient with Scala. It also does not decompile well at all in the IDE but gives vague references to code at best. On top of that, Scala errors do not show up until Java errors are fixed. So during porting, you may have 100 or so java errors to deal with, then find 500 more Scala errors afterwards. Scala does provide ways of doing things that Java still cannot, but as many as when the original code was written. There are also many Java to Scala converters available, but none going the other way around. I'll be switching to Java 1.7 support for Minecraft 1.7.10, since no one should be using Java 6 anymore. After that, it's Java 8.

[lehjr]

Porting from Scala to Java is taking longer than expected, however it has given me a better idea of what the code is actually doing. And the more of it I port to Java, the easier it is to read. I'm about 2/3 the way through at the moment. I did most of it by hand but in the past few days I have fallen on using a decompiler to help speed things along.