Starwaster

maybe they were always like that. I'm getting a weird return on one of the animation names and it can't possibly be right... the tail apparently has two animations and one of them is coming back as OPT/Parts/Stail/OPT_bf_6m_tail... I'm going to try plugging it in anyway but if that works then it's pretty bizarre.

One thing to remember is that certain things are case sensitive. I'm going over these Stail configs and there's some places where that's becoming an issue. (the other issue is that the animation names themselves are wrong so I had to write a small plugin to retrieve the animation names out of the models)

It's written in C# Nothing is written in EBCDIC anymore. (probably) The thing about EBCDIC is a stupid joke that probably nobody gets anymore

It's written in EBCDIC

TIL that there's an engine named after me...

It means 'does not equal' == means equals != means does not equal (1 != 0) would evaluate to true

Use the one in the station pack.

Recompiled for KSP 1.1.3. Update pushed tohttps://github.com/Starwaster/HeatPump/releases/latest Future plans are to allow power generation by converting heat to electricity. That can sort of already be done by setting the resource rate negative but I have the feeling that it would stop providing cooling if it couldn't find somewhere to store generated power since it scales cooling by how successful the resource request is. (basically this would be a Closed Brayton Cycle generator). On the other hand it would probably a waste of time considering the current levels of download activity There were a grand total of 23 downloads of the prior update over slightly more than a 1 month period And 90 downloads of the version before that over a ~7 month period. Not to mention that taking advantage of a feature like that would probably require it to be picked up by other modders. Oh well.

Hey, I'd be lying if I said that bit of insight hadn't been gained in retrospective once or twice myself!

Ok so it's one of the covered panels that's too low. Ok I'll check it out.

I've been thinking for awhile that OPT should have a set of fallback configs to install default resources if no other fueltank management is installed. Not sure that's what @K.Yeon wanted though...

I don't understand what you'er saying the issue is. Are you saying that 1000K is too low or that 2000K is too high? Also WHICH retractable solar panels? The ones that are bare or the ones that have cases? If they are bare then 1000K is probably about right. Though maybe they could be bumped up a bit, especially considering that thermal damage starts happening at 0.85% The ones with covers on the other hand are considered to have TPS coverings when they are closed. When open, they become exposed and their maxTemp actually drops down.

I don't think any OPT parts have any resource in them unless Firespitter is installed. (Exception: Cockpits have ElectricCharge) Assuming FS is installed and working properly (may not if the version you use needs updating for KSP because of a KSP update) then you need to right click the parts in the VAB/SPH and configure them with the part's context menu Without Firespitter there are no resources. Of course, none of that applies to me because I use Real Fuels so I use that instead of Firespitter for my fuel tank needs.

Injuries among KSC VAB technicians has increased 30% due to techs trying to turn the new rocket powered fairing panels into rocket sleds....

Tabs and misaligned brackets are NOT coding errors. They may cause my blood to boil in my veins and my bile to rise in my gorge but they are not coding errors and insertion of tabs and aligning of brackets aren't fixes. Now... if there is a mismatched number of left to right brackets or braces, that will cause problems

They already aren't inflating, I thought? Switching to the stock animator will work. That's how I do it on my machine for this pack.

Firespitter is only used for the Firespitter animation module which isn't even being used for anything that ModuleAnimateGeneric can't handle. Pretty sure I posted a patch earlier that makes it use the stock module and makes use of the layer field so that animations can't interfere with each other. Though layers were mostly useful for the now defunct Centrifuge (RIP)

That's one of the reasons we have Dropbox. Synchronized between machines.

Minor update (configs only) Removed ablator from procedural fairings because of negative cost issue. https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.4.7.1

It's 1600 because that's two fairings. 0.5 * 1600 = 800 The design decisions I'm referring to aren't with PF but rather with the way GetModuleCost() is being passed in the 'gross' cost rather than the net cost. And that happens regardless of whether I even adjust the part cost or not. There is literally zero impact from me doing anything to the part cost at this point. Did you notice that bit? And as far as DRE goes there's not really any workarounds possible either unless I add a zero cost ablator resource and futz around with PF's costpertonne setting. Or scrap the idea of adding ablator at all but there was a reason I did that and that was to make something like this possible: But I guess scrapping the idea of ablator on fairings is the easiest solution to this mess, especially if there's this much drama over it. Someone has to fix it.

@Starman4308 Dood c'mon there's no need to make this personal @NathanKell Apparently I missed one of your replies where you seem to be unclear as to whether I'm adjusting part cost to compensate for adding resource. Just to be clear: I am. This is exactly how things are. DeadlyReentry adds Ablative resource to the fairing amount = 0 / maxAmount = 1600. BASE COST IS BEING ADJUSTED TO COMPENSATE. (unit cost = 0.5 so += 800 to the fairing cost) Here's a cost breakdown of the test craft that was provided before. Without DRE, with DRE (both with 0 resource and full) Default cost of the test craft posted and discussed above: 614 (without DRE) Cost of the craft with DRE + Ablative amount = 0: -986 Cost of the craft with DRE + Ablative amount = 1600: 614 Now, just for ****s and giggles I decided NOT to adjust the part cost to see what sort of wonky behavior might result Cost of the craft with DRE + Ablative amount = 0: -986 (no cost increase) Cost of the craft with DRE + Ablative amount = 1600: 614 (no cost increase) The results are identical to what they were with part cost adjusted +800. TBH I did expect something odd would happen. I kind of HOPED that cost would miraculously be correct since it didn't seem to like me playing with the cost. But I didn't expect the same results as before I don't see how that's not a bug. But if you still maintain that it's not then it's a design decision that needs revisiting because this could happen to any part with a cost that someone wants to make use of ModuleGetCost() on.

Yes you're right, I'm adding to its cost to account for the resource. The resource is set to 0 so its cost at that time in the VAB is now 800 lower. So the part (before GetModuleCost) is now at its original cost. But your previous response hints that GetModuleCost is being passed the prefab cost? And it certainly would have to be getting passed the prefab cost in order to be so much lower. On any part that has resource and therefore actually has variable cost to begin depending on how much the resource is set to by the player? Why pass the prefab cost? How is that not a bug? How can that be correct behavior? What am I missing here?

Then what, return just the PF cost? Because subtracting the base cost from that isn't the way to go.

Well then you did something wrong both installing and uninstalling it and you're not going to be able to get help coming in here the way you are.

Ok, I applied your fix and that does stop the negative cost but I also notice a discrepancy between the price when a fairing is first attached to the base and when it is removed then reattached. It's not a huge problem; the second price is probably the correct one and is the one actually used if the craft is saved or launched. It's also probably a long standing issue and I only mention it in case you might have any idea about how to fix it since we're talking about code fixes anyway. I'll go ahead and do a pull for this one now: https://github.com/e-dog/ProceduralFairings/pull/24