Nnimrod

Could someone point out to me what I've done wrong with this? @MODULE[ModuleEnginesFX]{ name = ModuleEnginesFX @useAtmCurve = False @velCurve{ %key,0 = 0.0000 1.0000 0.0000 -0.0039 %key,1 = 0.0500 0.9998 -0.0039 -0.0058 %key,2 = 0.1000 0.9995 -0.0058 -0.0086 %key,3 = 0.1500 0.9991 -0.0086 -0.0127 %key,4 = 0.2000 0.9984 -0.0127 -0.0187 %key,5 = 0.2500 0.9975 -0.0187 -0.0277 %key,6 = 0.3000 0.9961 -0.0277 -0.0409 %key,7 = 0.3500 0.9941 -0.0409 -0.0604 %key,8 = 0.4000 0.9911 -0.0604 -0.0891 %key,9 = 0.4500 0.9866 -0.0891 -0.1317 %key,10 = 0.5000 0.9800 -0.1317 -0.1945 %key,11 = 0.5500 0.9703 -0.1945 -0.2872 %key,12 = 0.6000 0.9559 -0.2872 -0.4242 %key,13 = 0.6500 0.9347 -0.4242 -0.6265 %key,14 = 0.7000 0.9034 -0.6265 -0.9253 %key,15 = 0.7500 0.8571 -0.9253 -1.3666 %key,16 = 0.8000 0.7888 -1.3666 -2.0184 %key,17 = 0.8500 0.6879 -2.0184 -2.9810 %key,18 = 0.9000 0.5389 -2.9810 -4.4028 %key,19 = 0.9500 0.3187 -4.4028 -6.3743 %key,20 = 1.0000 0.0000 -6.3743 -0.0000 } } Does "name = ModuleEnginesFX" need to be in there? For some reason the rest of the patch is applying, but not the changes that I'm trying to make to ModuleEnginesFX.

How can I modify the mass, rigidity, and strength of the wing part from the .cfg? In game there is a "Mass/strength multiplier", and I'd like to remove that and have a fixed mass, rigidity, and strength. The point being to split the single procedural wing part, with adjustable mass/strength, into multiple procedural wing parts, each with fixed mass/strength. And the point of that is to have progression for the tech tree. I.E. early on you have a procedural wood and fabric wing part, later on you get a procedural aluminum wing part, then a stainless steel version, and finally a composite part. An alternative to this would be to have one part with multiple configurations, and you simply unlock new configurations for the same part. I ask because I don't see anything in the .cfgs that seems to allow me to do this, but perhaps I'm missing it. Thanks for your help!

I don't suppose there's a way to make the wings stiffness proportional to their thickness is there? And if I want to modify stiffness and strength, what should I look for in the .cfg? Specifically to set limits at for tech nodes, I.E. you get spruce and canvas wings at node A, with appropriate properties, and at node B you get an upgraded wing material with better properties. Point being to make it so that you can't build a U-2 while you're at a point in the tech tree that's roughly analogous with the 1920s. Even more basic question - how do you change the mass of the wing? I figured you would just change the mass of the wing part, and that it calculated the mass of your shaped wing off of the mass of the base part, but that doesn't seem to do it? It changed the mass of the wing part that you select on the left, but when you shape it into a wing it has the same mass that it otherwise would have.

clap

Amazing! This will be the first mod to add an angled launch rail as far as I know.

Have you got any plans to make an angled launch rail for sounding rockets? They typically don't have TVC, so they rely on the rail to keep them going in the right direction until they're moving fast enough for their fins to keep them going straight. Of course this really isn't necessary in KSP because there's no wind, the vector of thrust is always perfect, etc. But a rail like they used for WAC Corporal or the later ones sure would be awesome to have. They are angled mostly because what goes up must come down, and it would be best if it comes down in a safe designated area, I.E. not in the immediate vicinity of the launch facilities. This is a Black Brant, ~1960 And a modern launch rail made by "Amateurs"

Thanks, I appreciate your work

Where might I find the new assets for realplume? Somehow I haven't been able to find them...

Good idea, I'll give that a try tomorrow. I haven't messed with real fuels in some time, but perhaps I'll go back and check it out. As far as whether it's worth it or not from an additional gameplay vs. tedium perspective... eh... That will be become clear enough in retrospect.

I suppose it's worth mentioning that one way of accomplishing this would be to rebuild the tech tree entirely, such that individual part lines have their own nodes/progressions of nodes. This is a pretty big departure from stock tho, and would require a lot of tech nodes. I'd prefer a different way of getting it done. Another way of doing it is to just make the upgrade available as a separate part, in a later node, and have the entryCost as you normally would for an upgrade, and then just put in the part's description "Only available if you bought into the preceding parent engine" And then rely on the honor system. After all, anyone playing a heavily modded KSP is after a challenge anyways, and is likely to be ok with "House rules". The honor system would be an acceptable, if not optimal way of getting it done. Not as good as properly working part upgrades tho as it does tend to clutter the tech tree/VAB. Although Janitor's closet can alleviate the VAB clutter.

One of the things KSP does not model, which I think would add valuable decision making/gameplay, is how in real life, companies are committed to existing architectures because of financial reasons. In real life you see that almost no orbital launch vehicles are clean sheet, modern designs. They are overwhelmingly the most modern iteration of a series of launch vehicles that go back to the 60s, with development started in the 50s. The reason for this is pretty much common knowledge in the KSP crowd, but KSP does not model this at all. So, I'm looking for ways to accomplish this. When I started with my project I assumed I could do this with the inbuilt part upgrades module, but unfortunately that really does not seem to be the prince that was promised. I can modify mass and cost, and maybe more, but I can't say... modify the contents of a RESOURCE node, or add a new module. Or make a ModuleEnginesFX use different propellants. Let's say I want to make a redstone missile engine, first iteration, and put in in the 20 science level, and make an upgraded version in the 45 science node that has better Isp, thrust, and uses a different propellant. Upgrade nodes allow me to accomplish the thrust and Isp, but not the propellant change. So instead of upgrades, how about I just make a new part and have it's availability or entryCost depend on whether or not the first engine at the 20 science level was purchased? Is there a way for me to hide parts in the tech tree, and make them show up when the player pays the entryCost for a different part?

Google doesn't seem to know anything about that either

Thank you I'm in the process of making a better mod pack atm, and this career is on hiatus. I will resume it tho, with the same story.

@OhioBob Holy excrements are you the author/owner of Braeunig.us? I have spent a looooooooot of time on that site. Thank you very much for taking the time to make that available.

Ok, I've had some success. This shows up properly in the tech tree, and the upgrade shows up properly in the Electrics node. I tried editing the mass inside the partStatsUpgradeModule, and that worked, but I haven't been able to make the upgrade work on stuff inside the StoredCharge RESOURCE or inside the BatteryFailureModule. That's where I'm stuck atm. @PART[batteryPack]:FINAL { @mass = .0004 @rescaleFactor = .3333 @cost = .08 !entryCost = 800 @title = Small Hg-Zn Battery Pack @TechRequired = start @description = A little non-rechargable battery pack. @PhysicsSignificance = 0 !RESOURCE[ElectricCharge]{} %MODULE { name = BatteryFailureModule baseChanceOfFailure = 0.01 expectedLifetime = 10 UPGRADES { UPGRADE { name__ = Hg-Zn Battery Upgrade description__ = Improves capacity and expected life expectedLifetime = 12 } } } %RESOURCE { name = StoredCharge amount = 3.332 maxAmount = 3.332 UPGRADES { UPGRADE { name__ = Hg-Zn Battery Upgrade description__ = Improves capacity and expected life amount = 4.704 maxAmount = 4.704 } } } MODULE { name = ModuleResourceConverter ConverterName = Battery StartActionName = Connect Battery StopActionName = Disconnect Battery ToggleActionName = Toggle Battery FillAmount = 0.95 AutoShutdown = false GeneratesHeat = false UseSpecialistBonus = false INPUT_RESOURCE { ResourceName = StoredCharge Ratio = .0111 FlowMode = None } OUTPUT_RESOURCE { ResourceName = ElectricCharge Ratio = .0111 DumpExcess = false } } //MODULE //{ // name = ModuleResourceConverter // ConverterName = Charger // StartActionName = Allow Charging // StopActionName = Disable Charging // ToggleActionName = Toggle Charging // FillAmount = 0.95 // AutoShutdown = false // GeneratesHeat = false // UseSpecialistBonus = false // INPUT_RESOURCE // { // ResourceName = ElectricCharge // Ratio = .0083 // FlowMode = None // } // OUTPUT_RESOURCE // { // ResourceName = StoredCharge // Ratio = .0083 // DumpExcess = false // } //} MODULE { name = PartStatsUpgradeModule UPGRADES { UPGRADE { name__ = Hg-Zn Battery Upgrade description__ = Improves capacity and expected life techRequired__ = electrics IsAdditiveUpgrade__ = true } } } } PARTUPGRADE { name = Hg-Zn Battery Upgrade partIcon = batteryPack techRequired = electrics entryCost = 30 cost = 0 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = Hg-Zn Battery Upgrade basicInfo = <color=green>Advancements allow for about 41% greater energy density and 20% longer life</color> manufacturer = Zaltonic Electronics description = Applies to all Mercuric oxide-Zinc batteries. }

I don't know where I'm erring When right clicking on the part on the tech tree, it shows that it has upgrades, and says they're available at #autoLOC_501052, but as you can see I didn't use that dictionary entry when I specified where to put the PARTUPGRADE - I just typed the id of the tech node. And on top of that, there's no upgrade at the electrics node. @PART[part1]:FINAL{ MODULE { name = PartStatsUpgradeModule showUpgradesInModuleInfo = true UPGRADES { UPGRADE { name__ = 4x2x1 MZ Upgrade techRequired__ = electrics IsAdditiveUpgrade__ = true PartStats { mass = .1 } } } } } PARTUPGRADE { name = 4x2x1 MZ Upgrade partIcon = LiquidEngine2 techRequired = electrics entryCost = 30 title = Improved Hg-Zn batteries basicInfo = Battery technology has improved description = The small Hg-Zn Battery Pack has gotten a little better. }

Ok, if BDB doesn't do anything special for battery mass then I'll figure something out. What does BDB normally do for other payload parts mass like parachutes or solar panels?

How do you go about statting your parts? Since they are not just rescaled versions of real life parts... With engines for instance, you normally copy the real Isp, but the thrust is a new number, potentially just real world thrust times a multiplier? Like real thrust x 1/2.7? And what about mass? I'm making a mod that reworks batteries, and I want the batteries to work nicely with BDB and JNSQ. And to do that I need to know how you guys determine mass.

Hi, I want SRBs to be able to spontaneously and catastrophically fail while in use. You have liquid engines doing just that, although it's preceded by the "Fuel line leak". Also, is there a way that you could make liquid engines fail catastrophically some of the? So there is no "Fuel line leak"? Or at least no message about the leak. Also, how exactly does expectedLifetime work?

What triggers a part to fail? Can a rocket engine suddenly fail while it's sitting there not doing anything, or only when you activate it with spacebar? Can it fail during the burn? Can ModuleGimbal fail and leave you with a function engine but a broken gimbal? What about engines with multiple ModuleEngines such as an engine from BDB that had a main engine and some verniers? I'm trying to decide between this and Oh Scrap for a parts failure mod.

Ok, another question. I looked at the docs and it seems that the placement of the van allen belts is dependent on body radius, the belts at least should be compatible with JNSQ, if not the rest of the mod. How do you see the belts or know where they are? In the OP they are shown graphically, but not in my game.

Thursday, 4 August, 430 Hole spacing was good. No burrs in sight. Good. Tails were perfect. "DDDDDDDDD" The riveter wasn't that loud of a tool but the noise reverberated terribly in here, Cambo Kerman's riveting looked excellent tho. Bill was watching over his shoulder as he was finishing up with riveting the new fins to the fin flanges on the rocket body. Big sucker. The new rockets had arrived here earlier in the week, and this one was almost completely assembled and ready for tomorrow's launch. It lacked only the last fin, and Cambo would be finished with the riveting in time to get home for dinner. Bill would be staying later tho, he wanted to inspect all of Cambo's riveting, but didn't want to make it look like he didn't trust his work, so he would just hang around and inspect it after he left for the day. He also had to measure again, for the fifth or sixth time to make sure the fins were completely identical. Asymmetrical fins would make an asymmetrical flight, and there was to be no more of that. And these fins were hand made by Bill himself, so consistency absolutely could not be assumed. The old fins used on RR-1, 2, and 3 were the fins that came on the rocket, mass produced stamped sheet steel, welded to the rocket body. Conveniently, the new longer rocket that would be used for RR-4 didn't have any fins yet - if it had, they would have had to cut them off and replace them. Bill didn't have time or a wind tunnel for the kind of analysis that should have been done to reveal whether the fins were really part of the problem that caused RR-3 to veer off course, but he had a strong hunch that they were. They were sufficient to keep the rocket pointed straight for the RR-1 mission, and all the times they were fired during the war, with heavy explosive warheads, but For RR-2 and 3 they had been a problem. The fairing was half the problem, but he thought his redesign had fixed it. At least, fixed it as good as he could given the 1 launch per week cadence that someone paid way more than him thought was a good idea. The other half of the supersonic aerodynamic instability problem was the fins. With only days to go from design to having them attached to the rocket, Bill was unable to purchase ready made fins, so he made these out of 3/8ths inch aluminum plate, with extra layers of 1/8th inch aluminum at the root for added rigidity. Even being aluminum, they were quite a bit heavier than the original steel fins because they were thick and had about twice the chord. But the new rocket should easily make up for the weight. Gabnas had contacted the defense contractor that they bought the lot of 20 artillery rockets from years ago, and asked if they had anything larger. No, that was the biggest rocket they made, and since then they had shifted to making mostly artillery shells. Well, sort of. There was that bunch of prototypes, but they were locked up at the R&D facility and no one seemed to know anything about them. Gabnas had called him and within 20 minutes they were on the road in his pickup truck driving to this R&D facility to hopefully look at some bigger rockets. "Yeah, supposedly, I haven't seen them myself. Richbee might know." The facility manager walked with them to the grounds keeper's "office" and found Richbee Kerman munching little canned sausages and not doing much else. He took them to a small warehouse with vines growing up the side and cut a rusted lock off the double doors. Inside were some dusty, tall artillery rockets that looked exactly like the ones they had back at the KSA launch facility - but twice as long. These were about 14 and a half feet long. There were eight of them. Gabnas leaned over to Bill - "Why don't you have a look while I talk to him". So he set about inspecting the rockets while Gabnas was presumably asking for some sort of information about them. You can't just look at a rocket and decide to use it in a mission that's going to launch in 4 days without some sort of specifications or performance data. The rockets were fine, just stretched versions of the same thing they had already launched 3 of. And the rocket motors had not been an issue for RR-1, 2, or 3. After the inspection Richbee came up driving a big forklift and they took one of the rockets a quarter mile out to a small field with a big earth dam on one end and some concrete fixtures in the middle. They did a static test then and there - the manager had assured them they had permission for this sort of thing. Before they left Gabnas had worked out a purchase agreement and to have the remaining seven rockets loaded on trucks and shipped to the launch facility this same evening. Friday, 5 August, 430 RR-4 lifted off the ground a lot slower than the previous, shorter rockets. It's fuel grain was configured to deliver 24,000lbs of thrust at launch, and to burn for 16 seconds. The shorter version delivered 22,000lbs of thrust, and burned for 8 seconds. Since it also weighed twice as much, this had the welcome effect of not forcing the rocket to go supersonic a mere mile above ground like RR-2 and 3 had. Aerodynamic drag that low in the atmosphere is immense. At T+16 seconds the motor burned out and RR-4 was at 26,250 feet and sailing upwards at mach 3.5. It went up to 120,554 feet before tipping over, and Gabnas gave the word for the thermometer readings to be transmitted. Nothing. Telemetry continued as normal, but the scientific data transmitter was totally unresponsive. Harcan Kerman, the operator, tried again and again, but all he could do was press a button to send a signal to RR-4, and for whatever reason nothing was happening. The tension only lasted for another minute tho, as RR-4 reached the end of it's mission as it nose dived into the West Kerbin Sea. In truth, it was a somewhat trivial failure. They didn't really care that much about what the temperature was at 120,000 feet, weather rockets and balloons reported that kind of info regularly anyways. The goal was just to demonstrate that they were capable of recording data with a scientific instrument and transmitting it back. Incidentally, they were apparently not capable of doing that. "Bill" Gabnas said, as the jeep bounced along the short drive back from the observation hut, "The rocket ran hot straight and normal, it looks like an electrical component failure." "Well we've got the backup probe, I'll start with that." Bill was referring to a second probe they had assembled identically to the one that had just malfunctioned aboard RR-4. The probes were actually quite inexpensive - the whole rocket was pretty inexpensive, relatively speaking. The duplicate probe was intended partly to serve as RR-5's probe in the event that RR-4 failed catastrophically and had to be flown again. As it happened, RR-4 did fail, but not catastrophically. The duplicate probe allowed them to find any design problems that may have led to the failure to transmit the thermometer data. And they did find something, and quickly. The first thing they did was to turn it on and send the "Transmit science data" signal, and they got nothing. So, whatever was wrong with RR-4 was almost certainly also wrong with the duplicate, which meant they would probably find the culprit. That might be encouraging, Bill wasn't sure. He spliced in a relay and activated the data transmission circuit manually, and got a signal back telling him the assembly room's temperature. Excellent! That narrowed it down further. Within an hour he had the problem isolated to the receiving antenna assembly, which they had purchased from Zaltonic Electronics. Of course finding a failure on the backup probe didn't mean that it was the same failure experienced by RR-4, so he unwrapped a few more of the antenna assemblies from their packaging, and tested them as well. Dead on arrival. Didn't matter too much what specifically about it was bad, just that the problem was in the antenna and not wiring that he had done. This meant that Gabnas and those above him had Zaltonic Electronics to direct their anger at. Gabnas didn't seem that angry tho. "Yes, it would be even better if it had all worked perfectly, like RR-1, but the bottom line is that we built a rocket that flew like it was supposed to. Not our fault that Zaltonic sent us a batch of bad antennas. Although... we should have tested them." "We tested the thermometer, and the battery circuit, and everything about the telemetry package, just not the receiving antenna itself" continued Bill. "Well now we know Bill, test everything. And I won't source so much as a coffee machine from Zaltonic." After Bill had finished with the diagnostics, he tested everything again and found no faults. So he installed a new antenna, and a new redundant backup antenna, and on the 12th of August, RR-5 flew to 120,000 feet, recorded temperature information, and transmitted it back. The Kerbal Space Agency's second wholly successful mission.

Oh, ok. So this is all that modifies the comms system? Except for things like reliabilty/part failure ofc. DataRateDampingExponent = 6 // stock commnet: exponent by which antenna bandwidth decreases with distance. rescaled systems will require a smaller value DataRateDampingExponentRT = 6 // RemoteTech: exponent by which antenna bandwidth decreases with distance. rescaled systems will require a smaller value TransmitterActiveEcFactor = 1.5 // factor to the nominal ec consumption rate while antenna is active (transmitting) TransmitterPassiveEcFactor = 0.2

Alright so I want to disable the science and signal modules, and I see how to disable science in /Kerbalismconfigs/settings.cfg but not signal. How can I disable the entire signal module, as I'd rather use the vanilla system?

Wow this is some work Taking notes