1.12 Planning

[lehjr]

Some thoughts and ideas for 1.11.2

Currently I have a mostly working build for 1.11.2, except for translations. However, I am considering reworking some of the code. I'd like to start looking at "capabilities" as a way to clean up the code. More thoughts later on...

[lehjr]

I did finally get it to come up. It's nowhere in the start menu. And the UI makes me want to end it all but it is in there. Not exactly what it was like since Windows 3.11, but it's there, somewhere. I try not to use Windows anymore than I have to. The more I use it, the more I hate it, especially Windows 10.

[eyeonus]

Agreed. Thank you Valve for helping gaming companies to realize games on Linux is a good idea.

Games are literally the only reason I even have Windows.

[EzerArch]

Of course, I may have misunderstood Ezer, and I expect to be corrected quickly if so. ;)

Sorry I've been really busy these days.

What I mean by "make it harder" approach was punishing just for a module being powerful or useful: it makes you slower, consume more energy or force you to grind more resources or craft more modules. Yet, there are modules to get around those punishments (e.g. High Efficiency Solar Panel, Mechanical Assistance), which means more resource grinding, more tinkering with modules etc. It's like we know the player will craft a very overpowered armor soon or later but we put some obstacles in the way. Story time?

I want this powerful module -> But this requires more energy (added for balancing reasons) -> Oops, more energy requires bigger battery -> But it will make me run slower (added for balancing reasons) -> Solution: found out a module that generates 3x more energy and another module that removes the slower-ness (both added for balancing reasons), now I have an overcomplicated overpowered armor. YAY!

My opinion is, MPS relies too much only on energy consumption and feature bloat as balancing factors. Once you install all modules and keep the armor charged, you are nearly invincible. You got glorified swiss-knife armor that not only tills the soil but also burns the heck of mobs.

Instead of just making things more expensive or complicated, let's introduce a bit of tactical/strategy approach.

I do recommend trying the MatterOverdrive mod. The mod has a handful of quite nifty modules without too much clutter or redundancy. The modules need energy to work but also requires from the player more decision-making. For instance, the MO's Forcefield Shield has a timer and a cooldown between uses and also disables the jump booster module -- this forces the player to choose better when each module must be used.

On the other hand, the MPS's Mob Repulsor just requires energy -- leave it activated, you are untouchable, no decision-making is necessary (note here, this is excellent if you're using armor for building as it keeps mobs away while you focus on the building).

The MO's tinker table induces the player to choose between two profiles: fighting or exploration. In MPS, you can even install a bunch of overleaping and too different modules and use them all at the same time.

The following is quite a brainstorming (I may change my mind afterwards and regret deeply. Please don't take it too seriously). I would:

1. simplify/remove/merge too similar modules.
2. add more decision-making: 2.1. make modules more effective/distinguishable from each other. 2.2. certain modules won't work together.

Per module (includes a few ideas/fixes. I'll detail if asked):

• Batteries: Remove the slides. There are 3 tiers of batteries already. A battery getting heavier as you increase its own energy capacity never made sense to me.
• High Efficiency Solar Panel: 2 tiers are necessary? A single and good Solar Panel module may suffice. Plus, there are too many options of energy supply already (kinetic, thermal, solar, batteries replacement).
• Parachute: Necessary? You have a jetpack, jet boots, glider and shock absorbers already. I'd make it single use for emergency situations, such as all modules fail or the armor shuts down for overheat/out of energy, and you fall to your death. Requires replacement after a use. (Idea: why not a parachute model?)
• Glider: instead of two modules (just guessing), the glider will incorporate the elytra mode/animation. Also makes you fly faster horizontally.
• Active camouflage: mobs are not supposed to notice you (yes they can still spot you). Idea: more transparent -> more energy consumption. 100% transparent would consume a huge amount of energy.
• Magnet: fix please - make it less powerful. Drops are dragged so fast they fly away.
• Liquid Nitrogen Cooling system: Same as solar panels - 2 cooling tiers are necessary? And there's a water tank to help :P
• Mob repulsor: add a timer and/or cool-down. A slider can adjust the duration (and energy consumption). Following the shield vs. sword scheme, certain modules won't work while the mob repulsor is activated (Blink drive, Plasma cannon?).
• Kinetic generator: nitpicking - you use energy to walk, and magically it generates more energy than it consumes, really? Lavoisier is spinning in his grave. XD
• Blade Launcher: currently you have an infinite supply of spinning blades, where are they coming from? Following the bow logic, I'd make it so the module requires iron ingots in your inventory (or in some sort of resupply UI). Gorey-idea: mobs can be cut apart with spinning blades.
• Leaf blower: make it so it can blow away mobs, a la Gravity Gun.
• NEW MODULE - Instant medicine: uses an Instant Health potion if you're too low in HP.
• NEW FEATURE - Resupply UI: a small window where you resupply some modules. For simplicity, not an inventory. You put the items and they're converted into points/ammo: Iron ingot = 10 spinning blades, a few instant health potions, a parachute, food (to free up the inventory) etc.

Sorry for not being brief. My plan was to open an issue only for this.

[lehjr]

Ironically, almost all the games I have are for steam, but yeah, the only reason I have windows is for games ones like Fallout 4 that still has major issues despite several patches.

Anyway, getting back to the mod. While everything is more or less still in planning, this is what the mod will look like based on that planning so far:

• The weight mechanic will probably disappear. It's a good attempt at balance, but relegated to the realm of ridiculous when Minecraft itself does not use weight. Your armor's power storage alone can get heavy enough to slow you down, yet you can stuff an entire mountain in your inventory unhindered.

• consumable modules. Modules like armor plating will take damage and be consumed rather than providing protection forever. There will be different types available, wood (like samurai armor), leather, and so on. Energy based "plating" will need some type of balance mechanism. Other consumable modules would be tools like the classic tools. Weapons instead will have consumable ammo and maybe a condition.

• Limited special module slots. The armor, power fist, and shield will all have a limited number of special purpose slots for modules. For instance, the shield might have a slot for armor plating, the power fist will have a number of slots for weapons and tools, the armor will have slots for energy and armor plating, and both the power fist and the armor will have fluid tanks.

• cooling will be completely different and depend on consumable fluids. Each will be given a cooling coefficient. Additional fluid storage might be available at the expense of some other module slot.

• power storage/sharing. Power will be shared among the equipped armor, shield, and power fist only. No more will you be able to have an inventory full of power storage devices and have nearly unlimited power. On the other hand, you may be able to use these devices directly in a power storage slot. But there has to be a limit. ZPM powered armor would be unstoppable.

• power production will be a bit different. there are planned modules like steam generators, fission and fusion generators, but with some type of balance mechanism in place.

• flight will be reworked. To what end has not yet been determined.

Anyway that's what's been planned so far, but nothing is set in stone as of yet. Much will depend on what is technically feasible within the confines of Minecraft, as well as time and skills available vs what is needed. It's hard enough to port the mod. A complete overhaul is a new level of challenges.

[lehjr]

Guess it's time to stop stalling and take a serious look at capabilities and just see where it leads.

[grturner]

I've been tinkering with the code base a little bit on 1.12 though I seen to have hit a wall in that an interface IModelCustomData is not present in Forge any longer and one of the MPS classes implements it. I can't give much more info at the moment. I'm not at my desk.

[lehjr]

Although porting the mod as is to 1.12.x is possible, that's really not my goal. The mod is in desperate need of a revamp for many reasons, like code updating and cleanup, lag fix, fixing game play related issues, all just to find its place again among the many alternatives. Plus installing the same mod in every version of Minecraft is somewhat disappointing for the end user just as it is for the developer to update the mod for every version of Minecraft just to have the same features.

[lehjr]

Thinking about switching to Forge Energy. Not sure yet. Forge Energy uses integers, which only use 32 bits, while the MPS internal MJ power implementation uses doubles which are 64 bits. Doesn't sound like much, but these things add up.

[Bluexin]

Using FE directly also provides better mod compat out of the box, without you (or other mods) having to write the conversion methods (also less error-prone, I've seen a lot of energy exploits caused by people writing their converters wrong). Also, I feel like 32bits is enough to store a lot already ^-^

[lehjr]

I'm trying to use smaller data types where possible, especially in areas that deal with network traffic. I'm also trying to stay away from bundling any other mod's API, which means IndustrialCraft integration/support will be removed, since it depends on bundling their API, specifically this here: https://github.com/MachineMuse/MachineMusePowersuits/tree/1.10.2-Java/src/main/java/ic2/api/item

[lehjr]

My first attempt at an armor stand, not sure about it yet:

[eyeonus]

The base seems a little big, that face is kind of creepy. It looks more like a robot mannequin than a armor stand, IMO.

Maybe start with the base Minecraft and texture it up?

[lehjr]

LOL, I was thinking the same thing when I was looking at. The large base was to cover a complete block to cover power cables entering from the bottom to allow charging of armor on the stand. The model itself was originally based on the Minecraft armor stand, but I wanted a way to differentiate which direction it was facing. The theme of the stand was trying to mimic that of the Tinker Table which is why it looks so weird.

I can try a retextured version of the vanilla model, but I'm not really certain if an armor stand is the right way to go. I'll try again, but if I don't like the next version, I'll probably just go with a generic workbench to replace the Tinker Table for now.I really don't want to put too much more time into this.

[eyeonus]

Perfectly understandable all around. As for indicating which way it's facing, may I suggest placing an arrow on the base?

[lehjr]

yeah, that's probably better than having some weird face staring at you. Any suggestion for a texture or theme for it? I wanted something to differentiate it from vanilla, but beyond that I have no idea.

[lehjr]

Hmm, off topic, but can't help noticing how Minecraft's model textures are mostly empty space. Surely they would have benefitted from a more optimized layout.

[EzerArch]

My first attempt at an armor stand, not sure about it yet:

I'd remove the poker face. :|

But if you're still open to suggestions:

Armourer's Workshop mannequin (left), Bibliocraft armor stand (right), modified with resource pack.

[eyeonus]

As far as theme is concerned, what you have is good, but too busy. The black and green works well, IMO, but maybe just a few touches here and there, not 50 different lights on the torso.

Something along the lines of the Bibliocraft stand, in terms of how much 'stuff' to put on it.

[lehjr]

So far, still working on the armor stand. I did finish one based on the vanilla stand. However, due to how skinny the arms are, the slightest offset in the item's held location is highly exaggerated, not to mention how the power fist would look on a stick. So I think I'll try a player model instead.

[eyeonus]

Here's some player skins to give you a decent starting point, then:

https://mcskinsearch.com/user/iYunuswie https://mcskinsearch.com/user/xGotzeZk https://mcskinsearch.com/user/Pirad https://mcskinsearch.com/user/creepycritter05 https://mcskinsearch.com/user/Ceoria

Obviously you don't want to use any of these skins themselves, but I thought it might help to give you some design ideas.

[lehjr]

Thanks. I ended up going with a very simple skin. It might be too simplified but should be good enough for now:

[eyeonus]

Yeah, it's pretty simple. The eyes are creepy, but it's still worlds better than the first one. ;-)

[EzerArch]

The eyes are creepy.

I'd use conjoined eyes like.... umm....

... like this!

Wait a sec. That reminds me of The Day The Earth Stood Still. :>

[lehjr]

I think I'm going to shelve the armor stand idea for now. One of the issues is the complexity of the code needed to make it work vs the actual function it provides. The other issue is that the whole thing is pointless for what I wanted it for, which was to show cosmetic changes in real time. The reason is that as soon as you open the GUI, the armor stand is covered anyway. A more practical approach would be to replace the tinker table model with a new simple workbench model and revamp the cosmetic menu to render the player and equipped items like what is done in the player inventory. Since I'll be changing the GUI menus a bit this is probably a better approach anyway.

[lehjr]

Finally got around to fixing some of the Lux Capacitor stuff, like fixing the model scale and rotation to make the code simpler and implementing Guava cache for the baked quads. Code is much simpler to read and should help with performance. All colors will be using an Enum now rather than a full 4 byte int. This will still allow for up to 256 unique colors (because I'm limiting it to a single byte), which is still far beyond what Minecraft uses.

[eyeonus]

Sounds good. Keep it up!

[lehjr]

Currently working on the code for the tinker table GUI's. Only equipped items can be worked on. The cosmetic GUI will show the player wearing the armor instead of just a single piece of armor. This will make it easier to immediately see changes applied to both skinned armor as well as high poly armor. If time allows, the power fist will be able to have individual parts colored instead of just one color for the entire thing.

[lehjr]

[eyeonus]

Me likey.

[simonmeusel]

It looks cool, but why don't you style the GUI in a minecrafty look, more pixelated. It dosen't have the standard grey, you could add some modern looks too. Personally, I like consistency in a game, but it's your mod, so you can make it however you want! 😄

Inspiration (just a quick edit of the inventory, the text would need the minecraft font)

Maybe im a bit late to the discussion, because it would be an awful lot of work changing everything up, but I still wanted to drop this idea

PS: I already liked this mod back in Tekkit Lite (long long time age) and I'm very happy that you update it to newer versions of mc

[lehjr]

There aren't any easy ways of doing that. The GUI for the mod is coded entirely different than the GUI's that use background images and slots and containers.

[simonmeusel]

Yes, you're probably generating the GUI dynamically. But maybe you could just give the edges the minecraft look and make it a bit lower res (just increasing the stroke if that works).

But if it's too much work or you don't like it just keep on going with your design, as it works well!

[lehjr]

Unfortunately, I'm already looking at December for the first 1.12 release. I'd like to put out something before the end of the year.

[lehjr]

Tinker table will be a bit more basic this time around. This is a temporary texture until I have time to come up with something a little less boring. This one uses a 128x128 texture.

[eyeonus]

I suggest the surface of the old table. The one with the blue rectangles.

[lehjr]

Like this?

[eyeonus]

Yeah, that doesn't look half bad.

[lehjr]

Hoping to work on a new "ModelSpec" system this week/weekend, probably using an implementation of IBakedModel. This will handle both power fist and armor model customization as well as armor skins for skinned armor. This way everything can be customized in a single cosmetic window. I also need rework the ModelSpec XML reader a bit for that, and get rid of any hard coded references to the existing models. This way, custom skins and models (wavefront) can be fully supported.

Instead of completely abandoning the original method of customizing armor, I'll probably have to do something where either the old system will still work, or a system of presets can be used instead. This means adding a way of saving those presets. Again, the whole point of the preset system is minimizing the amount of bandwidth needed to track the visibility, color, glow states of every single piece of every single armor model for every render pass. A preset system can store all of those values locally, and only the reference needs to be passed through packets. For a couple of players, it might not even be needed. But on a loaded server, it might mean the difference between the mod itself getting pulled or not.

After that is done, then comes the fun part of "capabilities" for most of the armor and items.

[lehjr]

I set up a config option in Numina for the GameOverPlus menu and enabled it based on that. I don't know when it was used last, but since it get ported with every version of the mod, it might as well be an option.

[eyeonus]

What's the GameOverPlus menu?

[lehjr]

It's just a menu option that allows you to continue from where you died with a reduced amount of health.

[eyeonus]

That would be awesome as a module.

[lehjr]

I'm not really sure how doing it as a module would work. Currently all of the code is in Numina and uses the player death event. Something to think about though I guess. The modules themselves will be getting reworked on some level anyway.

[lehjr]

Unfortunately, it turns out that the whole GameOverPlus thing needs a bit more work than I have time for and I've disabled it for now. The main issue is that the player is still somehow marked as dead after being revived, and cannot pick up anything. Inventory items are lost, on death as well; not lost as in dropped, but lost as in just gone. So I'm going to avoid this for now.

[simonmeusel]

Maybe just teleport him to his death point and reduce his health

Hw will still loose xp, but that would make sense, since he gets's revived

[lehjr]

If I get time later on, I'll go back to it, but there's just too much work to be done to mess with it at the moment.

[lehjr]

Been looking into "capabilities", and so far I actually like it. With it, I can clean this code up a lot.

[eyeonus]

Awesomeness. Are capabilities a 1.12 thing, or is that going to be able to be back-ported to 1.10 or lower as well?

[lehjr]

Once I get to a point where I have something to backport, then I'll start looking at that. But so far, it doesn't look bad at all, at least not for items. For other things a bit more involved, but still probably not too bad.

[eyeonus]

I was just asking because I was curious if capabilities was available before 1.12