[1.2] Procedural Fairings 3.20 (November 8)

[softweir]

1 hour ago, subyng said:

So I'm having an issue with using interstage fairings. Here's my rocket:

<snip>

So, the behaviour I want is for the middle fairings to decouple after I separate the probe at the top. The structural fairings don't have this ability (why not?) If I use the aerodynamic fairings however, there seem to be some structural issues because the nose cone inside of the middle fairing will break off from aerodynamic stresses. This doesn't happen when using the structural fairings. Is this by design, or possibly a bug? How can I get this to work?

Q) "The structural fairings don't have this ability (why not?)"

A) Because that is the point of the structural fairings! They are intended for use when a player wants to permanently enclose a lot of gubbins, for instance when building vehicle sections that contain batteries, RCS tanks etc etc - things that don't get jettisoned or ejected. Users of PF asked quite loudly for a set of fairings that can't be accidentally staged when, for instance, they are in the middle of an aircraft body.

Q) "How can I get this to work?"

A) It appears you only have one fairing base for the lower section of fairings - you need two. Insert a second fairing base upside-down above the command capsule, attaching it to the "floating" node of the lower fairing base. Move the floating node above the top of the capsule tip before trying to attach the upside-down fairing base. Also be sure to connect the fairings to both the upper and lower bases as you form them!

All this will make everything is properly enclosed until you eject the fairings.

I hope this helps!

Edited June 19, 2016 by softweir

[Starwaster]

22 hours ago, softweir said:

Q) "The structural fairings don't have this ability (why not?)"

A) Because that is the point of the structural fairings! They are intended for use when a player wants to permanently enclose a lot of gubbins, for instance when building vehicle sections that contain batteries, RCS tanks etc etc - things that don't get jettisoned or ejected. Users of PF asked quite loudly for a set of fairings that can't be accidentally staged when, for instance, they are in the middle of an aircraft body.

Q) "How can I get this to work?"

A) It appears you only have one fairing base for the lower section of fairings - you need two. Insert a second fairing base upside-down above the command capsule, attaching it to the "floating" node of the lower fairing base. Move the floating node above the top of the capsule tip before trying to attach the upside-down fairing base. Also be sure to connect the fairings to both the upper and lower bases as you form them!

All this will make everything is properly enclosed until you eject the fairings.

I hope this helps!

Having to use a second upside down base has never been a requirement for the interstage. In fact it was created so that player didn't have to use upside down bases anymore. If he's losing the nosecone then he can probably prevent that by raising the height of the floating node that the upper half is attached to. There's not much clearance and there's probably some clipping going on with the colliders.

[SilverlightPony]

I've got the fairing base, but I can't find the decoupling side panels anywhere.  The only sides I have are the non-decoupling fuselage panels.

Every "Aerodynamics" part I have access to: http://i.imgur.com/VeA4U4b.png http://i.imgur.com/xmIX6IU.png

Tech tree:  http://i.imgur.com/efndIL6.png http://i.imgur.com/SusUgMh.png

Halp?

[Gryphon]

@SilverlightPony You need the "Aviation" tech to access the "Egg Shaped Fairing" and the "Conic Fairing" ... and it looks like you skipped that one.

[SilverlightPony]

33 minutes ago, Gryphon said:

@SilverlightPony You need the "Aviation" tech to access the "Egg Shaped Fairing" and the "Conic Fairing" ... and it looks like you skipped that one.

That strikes me as unintuitive (these are mainly for rockets, not planes), and it's not mentioned in the FAQ--but you're right, that's where they were.

[JohnWittle]

So i'm having some trouble with the thrust plate multiadapter. My configuration is: Thrust plate, 4 Engines, then an Interstage Fairing. I'm not exactly sure which part of the configuration is breaking, but when I put the rocket on the launchpad, the fairings fall off, the engines become unattached, and the whole thing collapses. Am I doing it wrong?



Do I need the engines to be attached to the bottom fairing base somehow, perhaps with struts? Or have I completely misinterpreted something? (Obviously I put side fairings on, i just took them off for the screenshot)

Edited June 27, 2016 by JohnWittle

[undercoveryankee]

2 hours ago, JohnWittle said:

So i'm having some trouble with the thrust plate multiadapter. My configuration is: Thrust plate, 4 Engines, then an Interstage Fairing. I'm not exactly sure which part of the configuration is breaking, but when I put the rocket on the launchpad, the fairings fall off, the engines become unattached, and the whole thing collapses. Am I doing it wrong?

Do I need the engines to be attached to the bottom fairing base somehow, perhaps with struts? Or have I completely misinterpreted something? (Obviously I put side fairings on, i just took them off for the screenshot)

You've put that together correctly. I use that configuration all the time. Most likely some kind of plugin issue. What version of KSP are you on?

[Starwaster]

6 hours ago, JohnWittle said:

So i'm having some trouble with the thrust plate multiadapter. My configuration is: Thrust plate, 4 Engines, then an Interstage Fairing. I'm not exactly sure which part of the configuration is breaking, but when I put the rocket on the launchpad, the fairings fall off, the engines become unattached, and the whole thing collapses. Am I doing it wrong?



Do I need the engines to be attached to the bottom fairing base somehow, perhaps with struts? Or have I completely misinterpreted something? (Obviously I put side fairings on, i just took them off for the screenshot)

Turn off auto strutting on the interstage

[Sol Invictus]

Does the current version work with KSP 1.1.3?

[StickyScissors]

14 hours ago, Sol Invictus said:

Does the current version work with KSP 1.1.3?

Working fine for me.

[drtedastro]

That's good to know.

Cheers.

[Starman4308]

On 5/11/2016 at 2:31 PM, garwel said:

It looks like the fairings have negative costs. See this .craft file: https://drive.google.com/file/d/0B74Ezn51tCNpZEtfbjB2cTNGMW8/view?usp=sharing

 

I'm pretty sure I've tracked down the source of that issue.

It's from, A, a Deadly Reentry config which adds 800 cost to the part*, and B, what I believe to be a coding goof made when NathanKell fixed the fairing masses.

Code-wise, the issue is at all instances of 'public float GetModuleCost(float defcost, ModifierStagingSituation sit)'; that method subtracts defcost when it should add defcost. I'm 99% sure I know why it crept in, too; Nathan probably fixed the mass by subtracting base mass, which is how it should be (mass should be area * density/area), and then applied the same "fix" to cost, which is a different case (which should be base cost + (cost/area * area)).

I'd submit the pull request myself, but, A, I have GitHub issues (can't have a separate personal account for KSP modding and a professional account), and B, I have only limited capacity to test it (I've tried to compile the .dll locally, and the cost works... but then other parts of the mod break).

*That solves an issue with how KSP calculates price costs; the "cost" field in a config is for a fully loaded tank. So, when DRE adds capacity for 800 funds' worth of ablative shielding to the fairing, it needs to add 800 funds to the base cost, so the fairing doesn't wind up costing -700 when empty of ablator.

EDIT: Also, I double-checked, the mass fix is working as intended, so kudos to NathanKell there.

EDIT 2: Also, if/when it gets fixed, would you mind releasing it for both 1.1.2 and 1.1.3? I'm still on 1.1.2, as not everything I want is updated to 1.1.3 yet. Again, I haven't figured out how to successfully compile the mod, probably because I'm trying to use VS 2013 and you're using a .bat script.

Edited July 3, 2016 by Starman4308
Double-checked something

[Starwaster]

On 7/3/2016 at 4:58 PM, Starman4308 said:

I'm pretty sure I've tracked down the source of that issue.

It's from, A, a Deadly Reentry config which adds 800 cost to the part*, and B, what I believe to be a coding goof made when NathanKell fixed the fairing masses.

Code-wise, the issue is at all instances of 'public float GetModuleCost(float defcost, ModifierStagingSituation sit)'; that method subtracts defcost when it should add defcost. I'm 99% sure I know why it crept in, too; Nathan probably fixed the mass by subtracting base mass, which is how it should be (mass should be area * density/area), and then applied the same "fix" to cost, which is a different case (which should be base cost + (cost/area * area)).

I'd submit the pull request myself, but, A, I have GitHub issues (can't have a separate personal account for KSP modding and a professional account), and B, I have only limited capacity to test it (I've tried to compile the .dll locally, and the cost works... but then other parts of the mod break).

*That solves an issue with how KSP calculates price costs; the "cost" field in a config is for a fully loaded tank. So, when DRE adds capacity for 800 funds' worth of ablative shielding to the fairing, it needs to add 800 funds to the base cost, so the fairing doesn't wind up costing -700 when empty of ablator.

EDIT: Also, I double-checked, the mass fix is working as intended, so kudos to NathanKell there.

EDIT 2: Also, if/when it gets fixed, would you mind releasing it for both 1.1.2 and 1.1.3? I'm still on 1.1.2, as not everything I want is updated to 1.1.3 yet. Again, I haven't figured out how to successfully compile the mod, probably because I'm trying to use VS 2013 and you're using a .bat script.

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

Edited July 6, 2016 by Starwaster

[NathanKell]

That is patently incorrect. GetModuleXXX works the same for both mass and cost: the module cost is added to the prefab cost. If you make the above change, then instead of the method returning an offset to end up with the _desired_ final cost, instead you will get (PF's calculated cost) + (prefab cost) + (prefab cost).

[Starwaster]

48 minutes ago, NathanKell said:

That is patently incorrect. GetModuleXXX works the same for both mass and cost: the module cost is added to the prefab cost. If you make the above change, then instead of the method returning an offset to end up with the _desired_ final cost, instead you will get (PF's calculated cost) + (prefab cost) + (prefab cost).

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

[NathanKell]

That depends on what PF cost is.

If that is the cost above the base cost, then just return it.

If it is the final cost you want the entire part to cost, no more, no less, then subtract base cost, because KSP will add the base cost back in again. By definition.

Now, if you go ahead and add a crapton of a resource without then modifying the base cost to account for it (remember, the base cost is the full/wet cost, not the dry cost) then you will get some weird things happening. But that is because you didn't modify the base cost to account for the resource you're adding.

[Starman4308]

1 hour ago, NathanKell said:

That is patently incorrect. GetModuleXXX works the same for both mass and cost: the module cost is added to the prefab cost. If you make the above change, then instead of the method returning an offset to end up with the _desired_ final cost, instead you will get (PF's calculated cost) + (prefab cost) + (prefab cost).

There is something really wonky going on. As the code is, it was returning negative costs, an obviously incorrect result that was almost certainly caused by subtracting a base mass. Again, it seems to behave properly for mass but not for cost

Testing out a 0.75m fairing base underneath an OKTO and a conic fairing:

Without fairing sides:

470 cost (450 for OKTO, +115 for PF cost, -100 for base cost)

0.115t (0.1 for OKTO, 0.015 for PF mass, seems about right)

With 2 fairing sides:

-1102 cost (450 for OKTO, +115 + 32 for PF cost, (-100 -1600) for base cost, probably a roundoff error to get to -1102)

0.122t (0.1 for OKTO, 0.015t + 0.006493t for PF mass, probable roundoff error to get to 0.122t)

EDIT: The primary mysteries to me is why the cost isn't -1302, as the subtracted base cost should be 100 (fairing base) + 200 (side base) + 2*800 ("missing" ablative shielding resources), and why the masses seem correct with a calculation that doesn't work for cost.

Edited July 6, 2016 by Starman4308

[NathanKell]

@Starwaster having thought about it a bit more, I think I see the issue.

You want to add something to a PF part. You want to add cost to account for that.

The way PF is written, however, it is written to _set_ the cost of the part rather than _add_ to the cost of the part.

If you want to add your resource to the part, yes, that will require a design change on PF's part. But that is a design change, not a fix of a bug--it's working exactly as it should be working, because it assumes (correctly, until you add your resource) that it is the only changing the part's cost, and therefore it can set, rather than modify, the part's cost.

 

Instead you will need to ask @e-dog if it would be OK to have PF change to merely adding to the part's cost, and set the default cost to be near-0 (so in effect costs won't change for existing PF players). Then, when you add your resource (and increase the base cost to account for it when you do--please don't forget to do that part) it will be a base which the PF modulecosting sits above rather than replacing. That would involve returning just the PF cost, no adding or subtracting.

 

@Starman4308 I wrote this interface, at least in its current guise. I dare say I know how it works.

[Starman4308]

@NathanKell, I am trying to make sense of how the code is arriving at a clearly broken result, without having figured out where the KSP side code is. No need to be snippy.

I've tested one other thing out, by the way, which was to set the egg fairing's mass to 1000 tonnes in the .cfg (where it was previously 0). The result is still correct, and a rocket flies as it should, so again, somehow, there must be a difference in how cost and mass are being handled.

[Starwaster]

19 minutes ago, NathanKell said:

@Starwaster having thought about it a bit more, I think I see the issue.

You want to add something to a PF part. You want to add cost to account for that.

The way PF is written, however, it is written to _set_ the cost of the part rather than _add_ to the cost of the part.

If you want to add your resource to the part, yes, that will require a design change on PF's part. But that is a design change, not a fix of a bug--it's working exactly as it should be working, because it assumes (correctly, until you add your resource) that it is the only changing the part's cost, and therefore it can set, rather than modify, the part's cost.

 

Instead you will need to ask @e-dog if it would be OK to have PF change to merely adding to the part's cost, and set the default cost to be near-0 (so in effect costs won't change for existing PF players). Then, when you add your resource (and increase the base cost to account for it when you do--please don't forget to do that part) it will be a base which the PF modulecosting sits above rather than replacing. That would involve returning just the PF cost, no adding or subtracting.

 

@Starman4308 I wrote this interface, at least in its current guise. I dare say I know how it works.

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?

[Starwaster]

@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.

[NathanKell]

@Starwaster Yeah, that is 100% working as expected. Remember what I said above: Proc Fairings is currently designed to set the part cost. To do that, it reports the offset between the prefab cost and the desired cost. After that, the resource costing is being applied.

Let's trace how this works.

cost = aP.cost + GetModuleCost(all modules);

foreach resource, cost -= (resource.maxAmount - resource.amount) * resource.cost

return cost.

 

This is because, as I said, PF made a design decision: that it would be the only thing on the part changing cost, and therefore that it _set_ rather than _modified_ cost. If that design constraint is not followed (something else changes cost afterwards, namely resources) then bad things happen. This is because, again by design, PF is written to work around base cost, whatever it is.

 

So again, the solution here is to request a change in PF. Instead of counteracting the base cost, whatever it is, because PF wants to _set_ the cost, set the base cost very low by default and then don't do anything with it at all in the method, just report the calculated cost as the delta. Then when DRE adds resources and ups the base cost, PF will happily carry on increasing that cost by whatever it has calculated.

But again, that's a design decision, not an issue in how the code is currently implemented; for the design goal (setting cost rather than playing nice with other things that modify cost) it's correct code. That code makes it harder to mod PF, very true. But it fulfills its purpose.

 

So the correct way to PR it, IMO, is to remove the subtraction from GetModuleCost() [just return the calc'd cost] and then set the cost of the things to 0.01 in the part.cfgs. That should lead to the desired behavior.

(To be clear I mean the GetModuleCost for fairing sides, and probably fairing bases too, so anybody can add resources and mess with base cost to compensate. That changes the design assumptions in Proc Fairings from "this module will set the cost of the part, and so no one else should touch it" to "this module will add to the cost of the part").

 

And finally, @Starwaster apologies for not realizing you did modify base cost; IIRC at one point that was not the case, and I had to fix it in RO to avoid some issues, but perhaps I am just remembering wrong. I had thought that was still the case.

What is concerning though is that the change went from 614 to -986, which is a 1600 fund shift. Can you check configcache and make sure unitCost for the shielding is 0.5? Could it possibly be 1? Otherwise it does sound like there's maybe a bug somewhere in stock code :\

[Starwaster]

20 minutes ago, NathanKell said:

And finally, @Starwaster apologies for not realizing you did modify base cost; IIRC at one point that was not the case, and I had to fix it in RO to avoid some issues, but perhaps I am just remembering wrong. I had thought that was still the case.

What is concerning though is that the change went from 614 to -986, which is a 1600 fund shift. Can you check configcache and make sure unitCost for the shielding is 0.5? Could it possibly be 1? Otherwise it does sound like there's maybe a bug somewhere in stock code :\

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.

[NathanKell]

@Starwaster

Ah, right. Doh!

 

I agree there are no DRE workarounds possible. It requires a change in PF. I disagree that the issue is it is being passed the wrong cost, because even if it were being passed the cost you want, it wouldn't make things work the way you want, it's still PF's decision to set rather than modify, it just would result in the cost always being 614 and the amount of ablator having no effect whatsoever. And that would make things even worse from an interface and modding standpoint. The solution here is to change PF's design so it _is_ designed to interoperate with other mods that vary the cost.

[LordOfMinecraft99]

I have a problem playing this with R.O:

• Only the fairing walls appear in the parts menu, not the fairing bases
• The fairing wall's title says they are in diffrent colors but they are not
• The normal, stock/R.O fairings are not there anymore.

Can you plz help? i uninstalled it, but i really really want my interstage fairings! Thanks!