MachineMusePowersuits
MachineMusePowersuits copied to clipboard
MachineMuse
1.10.2 problems
I noticed a couple things while playing with the suit on 1.10.2
Firstly, the binoculars module doesn't work at all. I'm not sure if it's because I don't have Optifine installed, or if it's something else.
Secondly, even without any armor of any kind on, I don't take damage from fire or lava. Other damage does happen, so maybe it's because I have the water bucket cooling module installed?
Thirdly, the texture for the water bucket cooling module is broken- it's the pink and black squares.
Interesting. Unfortunately there are probably more than a handful of bugs that really need to get fixed. Some of it is just not enough testing.
Yeah, I figured. No worries. I mostly put it up to let you know, I'm not concerned about how long it'll take to fix. I know you're busy with the 1.12 port.
While working on the 1.12 code, I noticed a weird code branch for the PowerArmor which is probably the cause of the issue with the lava damage not working. https://github.com/MachineMuse/MachineMusePowersuits/blob/1.10.2-Java/src/main/java/net/machinemuse/powersuits/item/ItemPowerArmor.java#L60-L73 That should actually be this:
if (source.isFireDamage() && !(source == MuseHeatUtils.overheatDamage)) {
return new ArmorProperties(priority, 0.25, (int) (25 * damage));
}
Basically the way this is supposed to work is that the heat damage doesn't take effect until after the max temperature is reached. That part is working from what I can tell. However, the cooling seems to be working so fast that the armor does not have a chance to heat up. Also, from what I can tell, the heat sink modules aren't even doing anything at the moment.
Currently, the only way to even rack up enough heat to take damage from lava is to be over your head in it.
The only difference I see in the existing code is that it has "ISpecialArmor.ArmorProperties", otherwise it looks the same.
But awesome that you found the problem. 👍
That reminds me. Another problem I found, the auto-feeder doesn't update saturation. MY saturation has been at 0 consistently ever since I installed that module. Looking at the code, it seems that it turns the saturation into hunger bar filler? Am I reading that right? (Also might want to get rid of the "old" feeder since there is no config option for it and I doubt anyone wants the eats the whole stack version anyway.)
I did some experimenting. The heat sink modules are working, but all they do is raise the max temperature before the overheat damage starts happening. Part of the problem is in here, specifically the checking of if the player is in lava. I rewrote the whole thing to look like this:
public static double getPlayerCoolingBasedOnMaterial(EntityPlayer player) {
if (player.isInLava())
return 0;
double cool = ((2.0 - getBiome(player).getFloatTemperature(new BlockPos((int)player.posX, (int)player.posY, (int)player.posZ))/2)); // Algorithm that returns a value from 0.0 -> 1.0. Biome temperature is from 0.0 -> 2.0
if (player.isInWater())
cool += 0.5;
// If high in the air, increase cooling
if ((int)player.posY > 128)
cool += 0.5;
if (!player.worldObj.isDaytime() && "Desert".equals(getBiome(player).getBiomeName())) { // If nighttime and in the desert, increase cooling
cool += 0.8;
}
if (player.worldObj.isRaining()) {
cool += 0.2;
}
return cool;
}
which is now using a different and more precise check for lava and the code is working better. However, the cooling code is still fired too often.
auto feeder? Interesting. That I'll have to look at some other time. For 1.12, I'm going to make the heat sink modules reduce the amount of heat rather than increasing the max heat. I'll probably make the overheat damage increase with the amount of overheat if possible. There are really a lot of different things I want to do, but realistically, time probably won't allow half of it.
I did some more testing, I think I can do a quick and dirty fix for this by reducing the cooling by 75% https://github.com/MachineMuse/MachineMusePowersuits/blob/1.10.2-Java/src/main/java/net/machinemuse/utils/MuseHeatUtils.java#L36-L56
Basically just add a line coolDegrees = coolDegrees * 0.25; in the first line of that. I did test it and it does still build up a slight amount of heat with the liquid nitrogen cooling system. Since they do stack, it's probably good enough.
Rather than having the modules affect the amount of heat, why not have them affect the rate of cooling, as a percentage increase, the same way that being in water gives a 50% increase?
I'm still not really sure how I'm going to do it yet. The biggest issue with heating and cooling is that they happen at significantly different rates. Heat is added through the armor damage mechanic and only fires every second or so while the cooling mechanic I believe fires every tick, or at least several times more often than the damage mechanic.
That explains the huge jumps I see in the heat meter sometimes.
I have an idea: Divorce the heat from damage, (isn't that what the armor is for anyway?) and make it a per tick thing like the cooling. Have each module have a heat generation rating based on how much power it uses, and increase the heat by that amount when they are on. (Or used, in the case of the Fist's modules.) Give each piece a default cooling rating if that hasn't been done already. Optionally give the armor plating modules a higher cooling rating.
The mechanics are a bit complicated. There are several mechanisms in place rather than a single one. The one I was referring to was for the heat based damage for the armor being in a heat source, like lava or fire. That only fires once every second or so. Overheat damage is routed through that. There may be other routes for it as well, I haven't really checked. (Currently fixing up the FOV code a bit).
As far as the cooling ability of armor plating, there are already 3 cooling modules available each using some kind of resource. The plating itself would have more of an insulating characteristic, which is why I was considering reducing the amount of heat it allowed through. But keep in mind that the weight mechanic is gone in 1.12, and with that, any kind of a thickness setting. It's more likely the mechanic will allow multiple plates to be installed, each adding to a total value of whatever properties it has.
Binoculars issue seems to be related to the FOV handler code in Numina. Once I fixed that to how it should work, the issue is still there to some degree. Basically, the binoculars will only work if the FOVFix is turned off. There's a keybind setting for it, but it wasn't even working because when I refactored the code the last time, I didn't spend enough time testing it. So when a player would enable or disable it using the keybind, all they were doing was sending themselves a chat message. In order to fix this properly, this will need a major refactoring, moving that code out of Numina and into MPS so that there aren't 2 competing FOV Event handlers. Also need to add some code to restore the setting state when the player logs back in instead of having a default value.
It makes sense that overheat damage is routed through that, but not that heating itself is.
Giving the armor an insulation rating makes sense, I like it.
Config option was missing because it wasn't being initialized on startup. I fixed that part, but the saturation thing will need to be explored further.
The autofeeder seems pretty broken to me. It's only supposed to consume food if the player is hungry, but it just consumes all of it. I'll have to fix that before I upload a new build. Might be the last 1.10.2 build for awhile.
I think you're looking at the old method. The old method consumes the whole stack, the new method only consumes into the player is full, and any left overs are added to the buffer.
In my game I've been keeping blueberries from Tinker? Natura? Can't remember, that give one point each, and the module's only been grabbing them at need.
Gonna see if I can get this autofeeder fixed today, then that will probably be it for awhile for 1.10.2 updates.
Both the old and new method have the same problem of calculating how food and saturation are used. Everything is done around hunger and food consumed and saturation doesn't get added to the player stats unless food is consumed. Both of these need a rewrite.
After some experimentation and digging, I think I have it all figured out in terms of how to solve it. I'll put it in the next commit.
yes. It will probably be labeled as a final build or something similar. It probably won't be an actual final build, but I probably will only be doing one or 2 more as maintenance releases.
Cool beans.
Also, found another problem: the rototiller is bugged. It has a tendency not to till the dirt block you're clicking on, in that it almost never does, and while it does till the surrounding blocks with the radius set high enough, it won't do any dirt that it previously failed to till.
Unfortunately, it will have to get fixed some other time as I've already spent days on 1.10 and I'm falling further and further behind on 1.12. I still don't even have the modelSpec code finished yet. So after I fix the autofeeder and upload the new version, it's back to 1.12.