ksp-ro / proceduralfairings Goto Github PK

I remember that in the previous version there's no limit...

It's very easy to forget about fairings tech upgrade when loading a design from a previous save. This leads to inadvertent cheating.
There should be a validation of fairings tech level, similar to avionics and tanks.

Add a heatshield module to a FB/IB with adequate texture (for example pp heatshield)
Used to contain something like rovers

Hi! I have a problem ussing the interstage fairing:
https://imgur.com/a/DWZRbJM
I want to "create" the Vega fairing between stage 1 and 2 but the fairing seems to be fixed to the top stage. Im using ksp 1.12.4 and tweakscale. This is an issue that happens with the stock fairings too and i dont know how to make it.
Thanks for the attention!

In Version 1.6.2 under ProceduralFairings/Parts/ there is no Assets folder. All the textures are in the consolidated Assets folder under ProceduralFairins/Assets/Adapters.

i.e. RSBRibbed.cfg:
MODEL
{
name = Rib75
model = ProceduralFairings/Assets/Adapters/RSB75Ribbed
texture = RSBpslv-Specular, ProceduralFairings/Parts/Assets/Adapters/RSBpslv-Specular
scale = 1.0, 1.609, 1.0
}

Easiest way for me to workaround was to lazily copy the Assets folder to ProceduralFairings/Parts/ ;-)

When adding a new fairing base to a vessel, and with or without moving the slider for side nodes count before attaching a side, makes some of the nodes or even all but one disappear.
Detaching the side, moving the slider away and back; the nodes reappear and the base works as intended.

I had this now for weeks in my RO RP-1 setup.

I will provide a log as soon as I reproduced this issue.

KSP 1.8.1
ProceduralFairings 1.8.3
ProceduralFairings - For Everything! 0.3.0

• Place a payload fairing base and 2 sides, open base PAW, click 'toggle open/closed'
• click the PAW's # button to switch from sliders to keyboard input mode
• click it again to go back to sliders
  -> fairing spontaneously closes
  -> clicking 'toggle open/closed' once does nothing; clicking it again opens the fairings (so the button didn't know about the unexpected close)

trivial issue, but maybe interesting enough to fix

As reported on the forum a couple of weeks ago, I am led to understand that the path to the shader referenced for the blue fairing guidelines changed in KSP 1.8 so is currently showing a default pink texture.

Ref line 370 here

https://github.com/KSP-RO/ProceduralFairings/blob/master/Source/ProceduralFairings/FairingBase.cs#L370%60

Seen with v6.0_RC1 (#fb0326f), don't know how long it's been there

https://discord.com/channels/319857228905447436/620690446540341261/845710042883948574

Place an interstage base with 1 side part, give the base a top & bottom diameter < 1m (say 0.5m). Then place a procparts tank on the base's middle node, and change its diameter.

Expected: with a tank diameter <0.5m, the fairing is a straight cylinder. Tank diameters > 0.5m make the fairing swell out
Actual: fairing diameter swells out to ~1m diameter even with a smaller tank. >1m tanks inflate the fairing as expected

Extra note: the fairing doesn't act as if the full height of the tank is 1m, only its middle(ish) section

When scaling proc fairings, the collider is prety accurate with smaller shapes, but with bigger ones it's not.

As the fairing base's size increases, the difference between fairing's size and collider size also increases, leading to wildly incorrect colliders with sizes as low as 10m. This can lead to clipping, and Rapid Unscheduled Dissassemblies.

How to reproduce:
Sadly no screenshot, as it won't capture the mouse pointer, but to replicate, place a fairing base, attach the fairing to it.
Position the camera perpendicurarly to the node, and move the cursor towards the fairing. Take note of how close the fairing selects.

Now increase the base & top size to something big. Repeat the experiment.

Per DebugTools, a Hollow Interstage Ring has a hollow collider matching the ring, but also a tiny spherical collider right in the middle. One case where this cause a problem is if an engine is intended to thrust "through" the adapter, and ends up being occluded by that small dot. (there's probably other cases)

All the payload/interstage bases have that same central collider; arguably it's only a problem for the Hollow Ring and Hollow Truss variants, as they're the ones that seem to invite sticking something through the hole.

(the Hollow Truss is an odd case; Debug Tools shows the colliders for all variants at once. if they really are all active at once, that adds more potential for unseen clipping)

The Decoupler: Enabled toggle in the VAB doesn't actually disable the decoupler; it only removes it from the staging order. In flight, the decoupler can still be operated.

Per discord discussion, the intent was to make the decoupler non-functional in flight as well.

Main known impact is that in rp-1, disabling it reduces the base cost; this doesn't make sense if the decoupler remains functional.

https://discord.com/channels/319857228905447436/620690446540341261/895437148134731777

An old issue, I think; but I'd never pinned it down to a specific case.

2 payload fairings with identical shapes obtained 2 different ways: cylstart==0 and cylstart==cylend. Everything else is identical; in particular, both have ejection power 100%, torque 1%:

Ejecting the cylstart=0 version (bottom) behaves as one would expect from those settings; sides go out mostly straight sideways. The cylstart=cylend version (top) clearly gets much less sideways impulse (it seems it does get _some); enough that the torque effect is much clearer

In a real flight, with an engine pushing, the cylstart=cylend version with default forces (32%/1%) tends to fail to get the sides out of the way of the stage fast enough

cylstart=cylend doesn't seem to be the only necessary condition; the Size being smaller than the base diameter seems to also play a role. A straight cylinder behaves closer to expectation.

Merge all of the various shape presets from ProceduralFairingsForEverything into a single part.
Possibly implement through B9PS or the PartVariant system. Or just custom PAW selector?
CFG-specifiable presets for the shapes.

I love the thrust plate. It lets me put on multiple engines onto a tank, and a custom interstage, without resorting to jank.

However, I do have to deal with some jank when wanting a custom interstage with a single engine. This situation usually comes about when I want to use an engine with custom engine mount, but 2 engines is too powerful. To do this, I need to:

1. Set the node count to 1 only.
2. Place the interstage, overlength, onto the center node.
3. Place the engine, then translate with snapping on so it lines up in the center of the stack.
4. Shrink the interstage so that it properly fits.

Having to translate the single engine every single time because the minimum offset allowed (by default) is off-center from the stack center.

It would be great if we could set the offset to 0 to allow for this.

PF fairing side seem to have an area of drag around or below the attach node. This is enough to cause small launch vehicles ( sub 1.25m size) to flip out quite easily. The drag is negligible with larger more powerful rockets but seriously affects these small vehicles.

I am linking to a twitter thread with some more details

https://twitter.com/Undeadfake/status/1207235865447145472

Gif showing the cluprit:

https://twitter.com/Undeadfake/status/1207248220641996801

If the part is attached to the fairing base, and moved, then after that fairing base is updated (e.g. value changed, craft loaded, etc.) that moved part moves back to the node, thus negating the usefulness of the "Move" gizmo.

How to reproduce:

• Place a fairing base.
• Place any part on any of the nodes of that fairing (top, bottom, stage, sides).
• Move the part (via "Move" gizmo)
• Do either either one of:
  • Edit one of the values of the fairing base (size, height, etc).
  • Save and reload the craft.

Test contract requires part to be tested through staging sequence, but staging the fairings doesn't complete test. So seems no way to complete Test Contract.
Also part mentions enabling of decoupler in PF module description but there is no button to enable the decoupler in VAB.
Not sure if this part is part of Bluedog DB or PF, since there is a "(PF)" in part title I'm guessing it's probably PF so submitted the issue here.

When this happening, my rocket is on about 45km hight, and I installed FAR.
Here is my .ckan file
{
"kind": "metapackage",
"abstract": "A list of modules installed on the portable KSP instance",
"name": "installed-portable",
"license": "unknown",
"version": "2019.11.13.09.47.22",
"identifier": "installed-portable",
"spec_version": "v1.6",
"recommends": [
{
"name": "AirlockPlus"
},
{
"name": "AnimatedAttachment"
},
{
"name": "AnimatedDecouplers"
},
{
"name": "B9AnimationModules"
},
{
"name": "B9PartSwitch"
},
{
"name": "B9-PWings-Fork"
},
{
"name": "BDArmoryContinued"
},
{
"name": "CommunityResourcePack"
},
{
"name": "DecouplerShroud"
},
{
"name": "DistantObject"
},
{
"name": "DistantObject-RealSolarSystem"
},
{
"name": "DMagicOrbitalScience"
},
{
"name": "DockingCamKURS"
},
{
"name": "DockingPortDescriptions"
},
{
"name": "DockingPortSoundFX"
},
{
"name": "EasyVesselSwitch"
},
{
"name": "EditorExtensionsRedux"
},
{
"name": "CommunityTraitIcons"
},
{
"name": "JanitorsCloset"
},
{
"name": "SCANsat"
},
{
"name": "CommunityTechTree"
},
{
"name": "KIS"
},
{
"name": "KerbalJointReinforcementContinued"
},
{
"name": "PhysicsRangeExtender"
},
{
"name": "ToolbarController"
},
{
"name": "ClickThroughBlocker"
},
{
"name": "FerramAerospaceResearchContinued"
},
{
"name": "HangerExtenderExtended"
},
{
"name": "HyperEdit"
},
{
"name": "ModularFlightIntegrator"
},
{
"name": "Kopernicus"
},
{
"name": "KS3P"
},
{
"name": "KWRocketryRebalanced"
},
{
"name": "MechJeb2"
},
{
"name": "MechJebForAll"
},
{
"name": "KerbalEngineerRedux"
},
{
"name": "Mk1PrototypeCockpit"
},
{
"name": "Mk2Expansion"
},
{
"name": "Mk3Expansion"
},
{
"name": "Mk-X"
},
{
"name": "RaginCaucasian"
},
{
"name": "PatchManager"
},
{
"name": "NearFutureConstruction"
},
{
"name": "NearFutureElectrical"
},
{
"name": "NearFutureElectrical-Core"
},
{
"name": "NearFutureElectrical-DecayingRTGs"
},
{
"name": "NearFutureLaunchVehicles"
},
{
"name": "NearFutureProps"
},
{
"name": "NearFuturePropulsion"
},
{
"name": "NearFuturePropulsion-XenonHETs"
},
{
"name": "NearFutureSolar"
},
{
"name": "NearFutureSolar-Core"
},
{
"name": "NearFutureSpacecraft"
},
{
"name": "NearFutureSpacecraft-OrbitalLFOEngines"
},
{
"name": "StationPartsExpansionRedux"
},
{
"name": "CryoEngines"
},
{
"name": "KerbalAtomics"
},
{
"name": "DynamicBatteryStorage"
},
{
"name": "CryoTanks"
},
{
"name": "CryoTanks-Core"
},
{
"name": "DeployableEngines"
},
{
"name": "HazardTanksTextures"
},
{
"name": "MainSailorTextures-Complete"
},
{
"name": "ProceduralAirships"
},
{
"name": "ProceduralFairings"
},
{
"name": "ProceduralFairings-ForEverything"
},
{
"name": "ProceduralParts"
},
{
"name": "ProceduralParts-Textures-SaturnNova"
},
{
"name": "VensStylePPTextures"
},
{
"name": "MainSailorTextures-Essentials"
},
{
"name": "ProceduralParts-Textures-SCCKSCS"
},
{
"name": "FreedomTex"
},
{
"name": "BasicProceduralTextures"
},
{
"name": "RealChute"
},
{
"name": "SolverEngines"
},
{
"name": "RealHeat"
},
{
"name": "RFStockalike"
},
{
"name": "CommunityPartsTitlesExtrasCategory"
},
{
"name": "RealFuels"
},
{
"name": "RealSolarSystem"
},
{
"name": "ReCoupler"
},
{
"name": "RSSTextures8192"
},
{
"name": "KSP-AVC"
},
{
"name": "RCSBuildAidCont"
},
{
"name": "KSCSwitcher"
},
{
"name": "AllTweak"
},
{
"name": "TACLS"
},
{
"name": "CommunityCategoryKit"
},
{
"name": "RSSDateTimeFormatter"
},
{
"name": "ALCOR"
},
{
"name": "ATKPropulsionPack"
},
{
"name": "SpaceXLaunchVehicles"
},
{
"name": "FilterExtensions"
},
{
"name": "AntaresCygnus"
},
{
"name": "RN-SovietRockets"
},
{
"name": "RN-SalyutStations"
},
{
"name": "RN-Skylab"
},
{
"name": "RN-SovietProbes"
},
{
"name": "RN-SovietSpacecraft"
},
{
"name": "RN-USProbesPack"
},
{
"name": "RN-USRockets"
},
{
"name": "SXTContinued"
},
{
"name": "Taerobee"
},
{
"name": "NewTantares"
},
{
"name": "SmokeScreen"
},
{
"name": "RealPlume"
},
{
"name": "AdvancedJetEngine"
},
{
"name": "BackgroundResources"
},
{
"name": "ASETAgency"
},
{
"name": "BDAnimationModules"
},
{
"name": "FirespitterCore"
},
{
"name": "FirespitterResourcesConfig"
},
{
"name": "RetractableLiftingSurface"
},
{
"name": "VesselMoverContinued"
},
{
"name": "TweakScale"
},
{
"name": "TacFuelBalancer"
},
{
"name": "TacSelfDestructContinued"
},
{
"name": "Trajectories"
},
{
"name": "PADContinued"
},
{
"name": "SafeChute"
},
{
"name": "EnvironmentalVisualEnhancements"
},
{
"name": "TextureReplacer"
},
{
"name": "RSS-Airports"
},
{
"name": "RSS-FictionalKSC"
},
{
"name": "SAVE"
},
{
"name": "CommunityPartsTitles"
},
{
"name": "CommunityPartsTitlesExtrasNoCCKDup"
},
{
"name": "FASA"
},
{
"name": "FilterExtensionsDefaultConfig"
},
{
"name": "MoarFEConfigs"
},
{
"name": "TrackingStationEvolved"
},
{
"name": "BetterTimeWarpCont"
},
{
"name": "TarsierSpaceTechnologyWithGalaxies"
},
{
"name": "WasdEditorCameraContinued"
},
{
"name": "surfacelights"
},
{
"name": "MalemuteRover"
},
{
"name": "USITools"
},
{
"name": "BetterBurnTime"
},
{
"name": "SpaceXLegs"
},
{
"name": "FMRSContinued"
},
{
"name": "RecoveryController"
},
{
"name": "ReStock"
},
{
"name": "ReStockPlus"
},
{
"name": "KerbalPlanetaryBaseSystems"
},
{
"name": "KAS"
}
]
}

These calculations create incorrect node sizes for 1.875m parts, that appeared in addons
sorry, cant make pool request :)
ProceduralFairings/FairingBase.cs

126: public int TopNodeSize => Mathf.RoundToInt((Mode == BaseMode.Adapter ? topSize : baseSize) / diameterStepLarge);
public int BottomNodeSize => Mathf.RoundToInt(baseSize / diameterStepLarge);
public int InterstageNodeSize => Math.Max(1, TopNodeSize - 1);
public int FairingBaseNodeSize => Math.Max(1, TopNodeSize - 1);

Gamma Recolor, Black Arrow Recolor, Angara Recolor textures are showing the kind of behavior I think is caused by incorrect normals: instead of reflecting what's behind the camera, they're reflecting what's beyond the fairing. Example:

Easiest seen with a white color, max specular, max metallic

No way to increase the size of the narrowed part :(

Version 6.0.1 on 1.10.1

Hi RO team. Really enjoying the new PF. However am wondering if its possible to add an additional curve point to the nose shape settings to enable realistic looking biconic shapes. Right now this is only doable by reducing nose segments or making the tip a sharp point.

ideal biconic with curved tip

I believe this is on ProceduralParts' side, but please refer to this issue.

This mod only supports English, without mult-languages support.
for example: RSBRibbed.cfg

Using "#LOC" format with en_us.cfg is better.

for example:
"title = #LOC_Procedural_Ribbed_Payload_Adapter_Title"
"manufacturer = #LOC_Generic"
"title = #LOC_Procedural_Ribbed_Payload_Adapter_Description"

Otherwise things that care about vessel dimensions won't update. This is not just a problem for RP-1, although it's particularly a problem for RP-1.

This is a better approach than having the PF side itself fire when the coroutine ends because in that case you'll get one event per side, whereas if you set a dirty flag on the base (and have the base fire on the next update, or something) you'll get only one event.

Regenerating the meshes for perhaps every fairing base/side whenever OnVesselModified occurs might be excessive. Investigate not updating locked shapes, or adapters, or really anything that isn't involved in scanning a payload.

This gap in the mesh seems to be something that happens when the fairing shell starts on the top of the base, instead of on the outside, maybe to do with the geometry of the particular curves on those fairings:

In-flight it's not transparent, but has an odd black colour on that part of the mesh:

And in the VAB, changing the part variant/colour scheme updates it and the transparent part becomes viable with the dark colour:

Some profiles have larger transparent sections than others:
https://user-images.githubusercontent.com/2611674/199508663-5a68041c-dd17-4baa-88c9-5db7b42d0fd8.mp4