NathanKell

@NaturalHeadphone that sounds like a serious install issue. If you have the current version of the required mods (and no unsupported mods) you will not encounter that. @Wolfair corp. sorry? Don't get what you're saying.

https://en.wikipedia.org/wiki/E_(mathematical_constant) The formula quoted explains how each of the values is used, excepting two. ablationTempThresh sets the threshold at which ablation begins; below that, no ablation occurs (the loss evaluation is skipped). reentryConductivity is used rather than the part's own heatConductivity when the part has nothing attached to its bottom node, IIRC (this is to prevent heat shields conducting too much to other parts). Really not sure what else you're asking--it's a simple mathematical formula, and the names of everything match what's in the cfg.

yeah, I think it's worth adding to the OP, at the time RO was the only game in town.

I explicitly added support for prop engines in 1.0.5's ModuleEngines changes, actually, so you can tune performance quite closely. You can vary fuel flow based on altitude and speed (to simulate turbo/superchargers) and thrust based on altitude and speed (thrust should be linear with density and taper off with speed with a sharp drop as the tips go supersonic--which is about M=0.6 to M=0.8 as said above).

@Agathorn RealScience klaxon! @nightingale RP-0 is gonna _love_ this. All of this.

That is, shocker of shockers, a procedural part, ferram's nemesis... :\

I specifically mentioned, at the start of this thread, which values to use.

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

@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 :\

Sorry, wasn't clear. I do mean why, not how. I get the how.

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

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.

Sorry, I have more to do than I have time for as it is.

So, what's required for this is: 1. Lunar heat shields 2. Either a throttling engine or one with unlimited relights 3. Disgustingly large number of batteries to deal with the 530W draw of the Mk1 pod (or solar panels, but you need Improved Instrumentation IIRC for non-sucky ones and that's deep in the tree). 4. If doing batteries, probably ~20t TLI. If doing solars, 12t? So I think the minimal bits required would be: 1. Enough funds to upgrade the launchpad (and, ideally, MC and TS as well so you get nodes and patched conics). 2. Basic Capsules unlocked. 3. Basic Orbital Rocketry unlocked 4. General Construction (for the shields). Finally, you need enough cash to research the pod, the engines, and the shield, and to pay for the launch vehicle (and the BP upgrades to the VAB so it doesn't take forever to build). That should easily be doable by 1957 or so even on Hard. My guess is 1955 on Hard would still be doable, there's just not that much to research. EDIT: Revision. You could do LOR-LOR without docking, relying on an EVA to change vessels. That would lower TLI requirements to two 5t lots, I think, assuming solars, or maybe 7 and 5 using batteries. (Assuming 5t for the lander either way, since it's just an hour's stay before launch--use an unpressurized plane cockpit to save mass, and 7t for the CSM with 1600m/s delta V and 7 days of batteries).

@Sol Invictus update SolverEngines from CKAN, there was a packaging error that broke AJE.

@EliasDanger Remove the following mods: Filter Extensions - 2.6 Toolbar - 1.7.12 B9 Part Switch - 1.4.3 <<< what even is this? Chatterer - 0.9.90.1289 CC-CP-SCANSat - 0.6.0.1 << RP-0 doesn't support contract packs CapCom Mission Control On The Go - 1.0.2.3 Contracts Window Plus - 1.0.6.4 Contract Parser - 1.0.4 <<< what is this? Progress Parser - 1.0.5 << ditto Firespitter - 7.3 <<< you want the core only plus the resources, not the whole mod Kerbal Attachment System - 0.5.9 Kerbal Engineer Redux - 1.1.1 <<< this has serious issues with RF. Use MechJeb. All NearFuture mods SafeChute <<< eh? Also, not sure it plays nice with RealChute Filter Extensions, Chatterer, and the other GUI related stuff (maybe not toolbar) can go back after confirming things work. KAS...does KAS even _work_ or is everything KIS now? Best not try. Some of those things I don't even know what they are though.

All fairing sides should be available at start with RP-0. If you're playing RO career without RP-0, you have worse problems.

It's all doable with modulemanager now, no need for a plugin.

Can someone explain why this destroys RSS's inclinations?

Until https://github.com/magico13/MagiCore/pull/2 is merged I have submitted a PR to netkan to override versioning. One way or the other KCT should be on CKAN soon.

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

Thanks to Raidernick, Agathorn, SirKeplan, Zarbizaure, and NathanKell. Place and price Raidernick engines. Place and price SmartParts. Place S5.79, S5.66, RD-0225, and KRD-442. Place the 2-person Mk1 can. Fix VA LAS. Place and price two SSTU premade clusters. Place Soyuz LEO Heatshield. Support FRE's FRE-1 and FRE-2 (really!) engines. Update HSF station and lunar milestone contract rewards to balanced them better against each other. Fix level 3 runway sizing typo. Update KSP 1.1.3.

v0.2.0 for KSP 1.x and 1.1.x. Sound patch and don't-create-unloadable-parts patch by khr15714n Saturn-Nova stringers texture and the inclusion of working normal maps generally by ferram4 Repackaged without bundled dependencies--get them separately! Oh and we have a readme now. https://github.com/KSP-RO/ProceduralFairings-ForEverything/releases/tag/v0.2.0

Ahhhh right you are, I fail at packing. Sorry all! EDIT: Repacked with latest Kopernicus (and the missing MFI).

At this point you're probably best served asking in the Stockalike RF Configs thread, tbh--I haven't used that system in ages, RO doesn't touch it except for RCS. @Raptor831 will have a better working knowledge than I (not least because it has literally been 2.5 years since I wrote the code). Regarding the PLUME bit--yep, if you have RealPlume installed, it will recognize that node and add the whole EFFECTS setup for you.