[1.05] Fusebox - electric charge tracker and build helper. 1.52 released 24th Jan 16

[KocLobster]

20 hours ago, Ratzap said:

Updates were planned but Factorio happened. With 1.1 in experimentals and a full rewrite on the cards when that comes out, I'm afraid it's a case of use what there is for now. Once they announce the pre-release I can get started on a new version. The version for 1.05 doesn't integrate with the stock toolbar no, it works with blizzys but with stock your milage may vary (and by the sound of it, does).

On stock if you click the top part of the window it should minimise to a small black bar.

I installed the toolbar mod so that Fusebox wasn't acting glitchy and displayed correctly; it looks a thousand times better. However, I have noticed that it seems to calculate the total drain of all my different parts that require EC incorrectly. It calculates the EC generated correctly, but even when I fiddle with the settings of what it is taking into account for the drain calculation, and make it is simple as possible with only one or two parts that use EC, it doesn't seem correct to me.

For example, I'll slap on two of the entry level solar panels, they generate 21 EC per minute, or .35 EC per second. It calculates this and says I will generate .35/sec perfectly fine. However, even keeping it simple and just adding a single part that uses EC, like the Mk1 command pod, it says it will need far more EC than the game says it uses. KSP says that the Mk1 command pod uses 14.4/min or .24/sec of ElectricCharge, and yet Fusebox claims that I will be draining EC at a rate of much more than .24/sec. When I test this in an actual flight, I am able to confirm that I definitely am generating enough EC to always power the Mk1. This leads me to further my belief that it's just an error with Fusebox displaying the incorrect amount of EC that will be drained. What am I misunderstanding and why doesn't this seem correct? Am I doing something wrong?

[Ratzap]

The pod contains reaction wheels, those when active use EC. To show the possible maximum usage, reaction wheel activation is added to the pods EC use. Open filters and turn off the reaction wheels, the output will change. Of course the wheels are not always on but if it's wasn't shown it would be hiding an EC drain you might not know about. The in flight drain display will only show the wheel drain if they are actually being used.

The other possibility is if you're using TACLS, that adds a constant drain to all pods. You don't say what mods you have.

The VAB display is as the OP says, a best estimation. It doesn't show the actual running totals because the craft is not actually running. Once 1.1 is here and the mod is working again I had planned to look at adding support for the flight sim mod so you could build something then do a 'flight simulation' to see how it pans out in reality. The in flight readings will always be more accurate as they are coming from a live craft.

[KocLobster]

I'm not using TACLS. I have done that and disabled the reaction wheels in the filters, it barely makes a difference to the EC drain and still says the drain is far far higher than it should be. I can't figure out what would explain this.

[Ratzap]

What mods are you using and can you link the craft file? Mods should only be relevant if they're parts the craft uses.

[Ratzap]

The good news is that after a peek into the pre-release KSP libraries, I think it should be possible at last to do this mod the way I've wanted. That is they've implemented the resource request code in a way so that mods can intercept calls, use the information as desired and pass the call on so it can be satisfied.

That means Fusebox in flight mode can show what everything is actually doing rather than show what the parts say they will do. If the new UI code allows it, I'll be able to show a real time list of charge parts and exact numbers. The VAB is going to still have to be guesswork though. If the flight simulator mod gets ported I'll look into using that to allow sims from the VAB to check the numbers - flight mode is going to be where it's at for getting accurate stats.

[StahnAileron]

Oh~! That's sounds exciting! Since I usually play with SCANSat and RemoteTech, that sounds like massive improvements. Here's hoping things go the way you hope and plan!

On a side note: I've noticed SCANSat support for some reason seems to break every time they release a new version. (i.e. Newest ScanSat isn't on the filter list with current Fusebox.) Does this this mean Fusebox is hardcoded to version numbers of supported DLLs? Last time I asked you about this (like 6-7 month ago), it was essentially just a recompile with the latest DLLs from the requisite mods. Support for RT doesn't seem to function like that, so maybe it's on the other mod's side? Just curious.

[Ratzap]

1 hour ago, StahnAileron said:

Oh~! That's sounds exciting! Since I usually play with SCANSat and RemoteTech, that sounds like massive improvements. Here's hoping things go the way you hope and plan!

On a side note: I've noticed SCANSat support for some reason seems to break every time they release a new version. (i.e. Newest ScanSat isn't on the filter list with current Fusebox.) Does this this mean Fusebox is hardcoded to version numbers of supported DLLs? Last time I asked you about this (like 6-7 month ago), it was essentially just a recompile with the latest DLLs from the requisite mods. Support for RT doesn't seem to function like that, so maybe it's on the other mod's side? Just curious.

Scansat I had to query the DLL functions for information, so every time they did a new release it broke yes. RT on the other had was in the part config which I could read off in game after a part was instantiated, no recompile required. Curiosity satisfied?

[StahnAileron]

Oh, quite satisfied. Makes a lot of sense. Though to make sure I actually understood this correctly:

ScanSat basically required you to actually do a direct call to the DLL to pull info. RT conversely had static numbers in the part configs; you could just read them and not worry about it. I find it odd that the ScanSat numbers aren't more static. (I'm kinda curious about that now, but that's for them and not you.)

... ... ...

... Huh... I just took a look at the ScanSat part configs after typing up the above. I see a "power" attribute in the Scansat module. Don't recall if the numbers line up with what the game states each part uses. e.g. SAR part has "power = 1.5", which seems about right for in-game EC usage. (I'd have to verify in-game at some point...) Wonder if that could work for a long-term solution?

Well, with KSP 1.1 rounding the corner, everyone is scrambling to get time in for their mods (if they can afford to do so; real life happens after all). Changes will be coming left and right anyway. You're not the only one taking the opportunity to revamp stuff . Best of luck. Fusebox is one of my must-have mods.

[Ratzap]

8 hours ago, StahnAileron said:

Oh, quite satisfied. Makes a lot of sense. Though to make sure I actually understood this correctly:

ScanSat basically required you to actually do a direct call to the DLL to pull info. RT conversely had static numbers in the part configs; you could just read them and not worry about it. I find it odd that the ScanSat numbers aren't more static. (I'm kinda curious about that now, but that's for them and not you.)

... ... ...

... Huh... I just took a look at the ScanSat part configs after typing up the above. I see a "power" attribute in the Scansat module. Don't recall if the numbers line up with what the game states each part uses. e.g. SAR part has "power = 1.5", which seems about right for in-game EC usage. (I'd have to verify in-game at some point...) Wonder if that could work for a long-term solution?

Well, with KSP 1.1 rounding the corner, everyone is scrambling to get time in for their mods (if they can afford to do so; real life happens after all). Changes will be coming left and right anyway. You're not the only one taking the opportunity to revamp stuff . Best of luck. Fusebox is one of my must-have mods.

Not the numbers from the config file but from the in memory image of the part when it's in your ship. Basically Fusebox says: yo KSP, give me a list of pointers to all the parts in this current ship. Then armed with the list it knocks at each one and asks questions about charge: do you store any? If yes how much and what have you got right now. Then it tries to find out if the part uses charge, how much and is it doing it right now. That's where the problems hit. If the mod uses the standard part module parameters like RT, it can answer right off the bat. If it's an extension of the standard part module like SCANsat then it has to create one and copy data to it in order to query it. That's where it has to call the SCANsat library and say 'Hey, just how do I build one of your part extensions?'

The new version should be able to simply skip the door to door survey and spy on their electricity meters without them knowing. I'm glad you like Fusebox but don't hold your breath for v2, it's going to take some time to get this going. I'll keep the thread briefed with milestones so you know I haven't given up.

[StahnAileron]

Oh, now I get it. That explains the difference in the attribute names between the two mods I'm comparing. Now I really wonder why the ScanSat devs decided to go that route instead of adhering to whatever standard KSP has. KSP limitations? Hold-over from earlier times (and they don't feel like breaking what works for them; I know what that feels like.) Well, whatever. I'd have to haul over to the ScanSat thread if I want to figure that out.

Thanks for taking the time to explain the backend a bit. I've taken rudimentary classes in C and Visual Basic, plus having done basic Windows Batch files and Excel spreadsheet formulas. I've been exposed to programming in the basic abstract, but haven't had any exposure to REAL programming that entails API usage. Again, thanks for the insight!

As for Fusebox v2 (maybe rename to BreakerBox?), I know any mod takes time to be done. Plug-in based mods even more so, due to inherent programming issues. (Parts mods can be complex as well, but I think they're a LITTLE less likely to possibly break a game.) Take your time. Quality work is always worth the patience and wait. If no one else has thanked you recently, you (and every other modder in the world, really) have my gratitude. Thanks for helping make a good game an even greater one!

[leocrumb]

Is there a way to hide the window when you dont want to see it?

[Ratzap]

10 hours ago, leocrumb said:

Is there a way to hide the window when you dont want to see it?

I assume you're not using blizzy's toolbar, clicking the top bar should minimize it. With 1.1 though all bets are off (it probably won't even load).

[Voodoo8648]

Does anybody know if the dev of Fusebox has a plan to update this for 1.1? I have become dependent upon this mod to play KSP.

[Stone Blue]

28 minutes ago, Voodoo8648 said:

Does anybody know if the dev of Fusebox has a plan to update this for 1.1? I have become dependent upon this mod to play KSP.

Four (4) posts above yours, last paragraph

Edited April 30, 2016 by Stone Blue

[Voodoo8648]

2 minutes ago, Stone Blue said:

Four (4) posts above yours

Wow... doesn't sound optimistic 

[Ratzap]

17 hours ago, Voodoo8648 said:

Wow... doesn't sound optimistic 

Read further back. I'm doing a full rewrite. Currently on hold until KSP settles down Going on past experience I'd say another patch or two may be coming to 1.1.X

[Voodoo8648]

12 minutes ago, Ratzap said:

Read further back. I'm doing a full rewrite. Currently on hold until KSP settles down Going on past experience I'd say another patch or two may be coming to 1.1.X

Awesome man! I cant tell you how much I appreciate your ongoing support to this mod. It really enhances the experience to the game play, as everyone already knows 

[Drew Kerman]

1 hour ago, Ratzap said:

Read further back. I'm doing a full rewrite. Currently on hold until KSP settles down Going on past experience I'd say another patch or two may be coming to 1.1.X

yup, good call. Thankfully tho it sounds like unless the community throws a hissy fit over something hugely breaking this weekend after dropping v1.1.2 Squad is on vacation starting next week

Edited April 30, 2016 by Gaiiden

[GroundControl2MajorTom]

Any word yet when Fusebox V2 will be ready for 1.1.2?

[Red Iron Crown]

On 4/30/2016 at 5:58 PM, Ratzap said:

Read further back. I'm doing a full rewrite. Currently on hold until KSP settles down Going on past experience I'd say another patch or two may be coming to 1.1.X

 

On 5/27/2016 at 0:48 PM, GroundControl2MajorTom said:

Any word yet when Fusebox V2 will be ready for 1.1.2?

We have a rule regarding repetitive requests for updates, it will be ready when it's ready.

[Ratzap]

I've been busy with some health issues and 1.1.3 is due out soon anyway. As the man said, patience, it'll come.

[TK421d]

On 6/7/2016 at 5:21 PM, Ratzap said:

I've been busy with some health issues and 1.1.3 is due out soon anyway. As the man said, patience, it'll come.

hope it wasnt/isnt anything severe.   real life comes first!

what is this word though "paayyytennce"  i have no understanding of this word?!?

[gerishnakov]

Sorry to read @Ratzap has been laid low by health issues - I hope it's nothing you can't overcome

[Ratzap]

Still not great but coming back to this may help take my mind off things.

Reading through the dev blogs, it seems I would have been rewriting again anyway as they're overhauling the resource system anew in 1.2. I've got the pre-release and I'll poke about a bit. No promises but I'll keep you informed.

[CarnageINC]

31 minutes ago, Ratzap said:

Still not great but coming back to this may help take my mind off things.

Reading through the dev blogs, it seems I would have been rewriting again anyway as they're overhauling the resource system anew in 1.2. I've got the pre-release and I'll poke about a bit. No promises but I'll keep you informed.

Good to see you stirring around a bit Ratzap, hope things get better for you mate.