Glider sound effect doesn't stop if MPS is not in use

[EzerArch]

The glider.ogg is played if MPS is in use (that is, if the player is wearing one of the armor pieces, or if the player is holding the power fist or any armor piece) and if the player is moving fast enough (flying or falling).

The problem is, the same condition is required to stop playing the glider.ogg. This is most noticeable when the player dies of fall damage while using MPS and comes back to collect his drops; it is still possible to hear the glider noise from the death point.

Video (2:00): https://youtu.be/sPs-9MO-s94

• 1st try: OK. Falling with MPS armor.
• 2nd try: OK. Falling only with Power Fist selected in the hotbar.
• 3rd try: Bug. Falling only with Power Fist selected in the hotbar and unselected mid-fall.
• 4th try: Bug. Falling to death; and the player is not there to "stop" the glider sound. Stops if the player puts on or holds an MPS item.

Bug affects versions from 1.7.10 to 1.10.2.

Tested:

• ModularPowersuits-0.11.1.109 (1.7.10)
• ModularPowersuits-1.8.9-0.11.0-7 (1.8.9)
• ModularPowersuits-0.12.2-009 (1.10.2)*

* -- wouldn't it be better if MPS files kept the minecraft version in the file name? Like ModularPowersuits-1.10.2-0.12.2-009? You know people, they like to mix up versions. ;-)

---

PS/Off-topic: by the way, how to charge the batteries? o.O'

As you can see in the video, my total energy storage is zero, but I have installed Elite Batteries in all MPS set, and generators too.

[lehjr]

Sound: that's the result of an odd set of code that checks to see if the item is equipped and player is gliding or falling. It doesn't account for the loss of those items during the sound being played. I'll experiment with it and see if can come up with something better for now. https://github.com/MachineMuse/MachineMusePowersuits/blob/1.10.2-Java/src/main/java/net/machinemuse/powersuits/event/PlayerUpdateHandler.java#L79-L87 That code will probably change when Elytra flight becomes a thing but I'll add it to the list.

Version numbers: needs to be addressed. People mix up versions no matter how they are labeled, but having a clearer numbering pattern certainly would help. Also, my numbers are off in the files list on Curseforge, like 0.12.2-009 shows up as 0.11.2-009 on the list.

charging: the built in charging options are really limited, mainly because there hasn't been much demand to improve them with all the external charging options like EnderIO capacitor banks or Mechanism charging pads or even charging options from IC2. I'd like to add different power options like portable fission and fusion reactors and finish the coal generator, but the problem is the mod is already considered over powered despite being able to use the config file to set limits and disable modules.

[lehjr]

• next build will have new version numbering like : ModularPowersuits-1.10.2-1.2.<buildNumber>.jar
• I think I fixed the sound issue.
• charging still requires external mods for any serious amount of charge

[EzerArch]

but the problem is the mod is already considered over powered despite being able to use the config file to set limits and disable modules.

• charging still requires external mods for any serious amount of charge

What I meant is I can't use the armor in 1.10.2 at all. Not that I want better/faster recharging. :<

At least in 1.8.9, 1.7.10, 1.6 etc, I can install 1 module and 1 battery and it's ready to use (ok, that only 1 module will work, but you might've got the idea), and then a MPS generator to recharge -- it's a slow recharge, ok, but it will -- I didn't need to install any extra mod just to be able to use MPS.

Now in 1.10.2, the batteries are installed empty (0 MJ) and MPS generator modules don't charge them. New issue?

Mod list: ModularPowersuits-0.12.2-009.jar OptiFine_1.10.2_HD_U_D7.jar

---

EDIT: As to being too OP, I agree with this too. In my opinion, the main source of OP-ness is that, so long as you keep the MPS armor fully charged, all modules will work with no restraints. Let me open an issue for this as this one went too off-topic.

[lehjr]

according to my testing, the last 1.7.10 build has the same power issue. And being that the 1.10.2 builds are based on the Java ports of 1.7.10, that was something that I had hoped would have been reported so that I could have fixed it before doing all of this work on 1.10.2. One of the issue with the development environment is that any optional dependencies are hard dependencies in the development environment, so it's impossible to do any real testing without those dependencies. So something like this would not be apparent to me. Unfortunately, fixing this will take quite a bit of time just to track down. So in order to make up for that time, I will have to end all 1.7.10 support today.

[EzerArch]

according to my testing, the last 1.7.10 build has the same power issue. And being that the 1.10.2 builds are based on the Java ports of 1.7.10

I honestly still can't understand how I am able to use MPS alone, without the need of extra mods, in 1.8.9 but not in 1.10.2 (see edit). I must be doing something wrong in 1.10.2, or something has changed between 1.8.9 and 1.10.2 that I'm not aware of.

EDIT: * -- really the late 1.7.10 builds require other mods to work but I don't know which, that's something new to me (I've been playing with MPS since 1.4 or 1.5). Just I don't understand the magic behind the 1.8.9 build. :S

[lehjr]

Maybe if I can find the cause soon enough I can backport a fix. I dunno. Kinda frustrating, but I do appreciate the feedback. Without it, the mod would still be on it's first alpha.

[lehjr]

The 1.8.9 build was based on the Scala version. It was the reason why I ported the mod from Scala to Java, to have a working base that was easy to read and understand in order to make changes or "repairs" as needed. The Scala code was elegant, but often took too much time to troubleshoot due to the function of the code being lost in the syntax. Some of it I could not figure out at all and had to guess what it did.

Edit: The one place where I did like the Scala code better was for the "Interfaces". Java's interfaces are like C's headers, and contain no working code (meaning no function/method implementations, only declarations). This means that ever class that implements that interface has to implement those methods and makes things messy. For instance the power fist code. My god that is a mess now.

Scala has "Traits" which are like an extended version of interfaces because they are implemented like interfaces, but also can have working code and you can actually have less code that does the same thing because you only have to declare that you don't have to implement those methods from the trait in ever class that uses it.

I've been debating it, but I might actually reintroduce some Scala code, at least for the interfaces just to clean things up.

[lehjr]

Oh, yeah, now I remember. At the time, Scala was incompatible with Java 8. I literally spent weeks trying to get it to work in my development environment because I needed some Java 8 only features like lambdas.

[EzerArch]

1.7.10 backport? While I could for a while benefit with getting a 1.7.10 backport, me moving onto 1.10.2 is kind of unavoidable, it's matter of other very few remaining mods being ported as well. ^^

[For example: there's a horrible bug in MPS that disables fall damage in any Galacticraft dimension in 1.7.10. I found out this bug still happens in Galacticraft 1.8.9. I'll wait for a 1.10.2 port to see how it turns out and maybe I report it.]

Long story short: when I tested MPS alone in 1.10.2, the batteries not working was unexpected for me; for a moment I thought you had implemented something new, thus I asked "how to charge the batteries?". I didn't know they have been broken since late 1.7.10 (I guess my private mod pack somewhat masked this bug). But there's something working right in 1.8.9 -- that you might want to give a look at -- but not working right in 1.10.2.

In short yet, getting batteries to work like in early 1.7.10 and 1.8.9 in 1.10.2 is way more important. Not that I'm telling you what to prioritize. *covers head*

(N.B.: While I was typing this, you've replied twice.)

[lehjr]

yeah, well, I appreciate you finding it and taking the time to report the issue because I never would have found it. If more people would take the time to report the bugs they find the mod would be at beta by now. I'm just glad you found it when you did. Now that I know about it, the bug will get my immediate and relatively undivided attention.

[eyeonus]

Funny thing is, I didn't have any problem with the batteries yet in my testing.

Then again, I'm testing it live in a modpack and I've an ender io wireless charger, so I probably never would've noticed.

[lehjr]

The issue only seems to happen if there is no mod installed with a power API. It would be easy to just say "install a power API like COFH core", but really it should be fixed anyway since it's probably a sign of something bigger broken, plus mod is actually supposed to work with no other mods installed.

[eyeonus]

Yeah, I never would've noticed that with my testing.

But I've been more concerned with mod compatibility testing anyway.

[lehjr]

Oops? https://github.com/MachineMuse/MachineMusePowersuits/blob/1.10.2-Java/src/main/java/net/machinemuse/powersuits/item/ModularItemBase.java#L113

Edit: can't see it now but it was

    @Override
    public void givePlayerEnergy(EntityPlayer player, double joulesToGive) {
        ElectricItemUtils.drainPlayerEnergy(player, joulesToGive);
    }

[eyeonus]

Is it possible to offload the mess caused by interfaces to a custom parent class it inherits from?

[lehjr]

@aionys a little late responding, but no, no chance of that when Java only lets you extend one class and every class already extends something. Originally the inheritance was used through scala traits where most of the code was implemented, and through extending multiple classes.