Taverius

I was going through my NAS the other day and found a bunch of source files for B9. Might be of use to someone, maybe. Here's the archive. https://1drv.ms/u/s!AiVflldG5zMSh-QFAu-LUneJ_PD80g?e=gVh8lh

The burst screenshot feature is also still useful.

PorkJet sent us the source for the new MK2 meshes, but its going to take several weeks before we release an update that converts to that.

You don't need it with 0.25 any longer, if you're only using the supersampling functionality. Open settings.cfg and set "SCREENSHOT_SUPERSIZE" to whatever you want.

Yeah, you copied a modified fuel hatch .cfg for the crew hatch, but you forgot to the change part.name Also, add it to the DRE config - copy the Fuel hatch bit and change its name to the new part name.

Oh that. The stock engines curves do it too though (badly) so I'm not sure how you never noticed before

Works for me with MJ2. B9 sabres often wont switch mode like the RAPIER, because they have different air usage parameters and MultiModeEngine can't be tuned in how it decides to switch.

Plenty of examples in the wheels, but essentially you pass the PartModule a GameObject name to rotate and one it needs to look at, and repeat for every single GO that needs to be constrained that way. It'll rotate around/point to the origin of each. Porkjet is working with that too (I hope its ok if I post this):

You need custom fx for that, though.

bac9 packages the releases, i guess he forgets to remove the deprecated file. the mode switch is a black box from the stock module we cant affect, nothing I can do about that. No issues getting into orbit with it, though - in FAR/NEAR obviously. Climb to 22-23k, hold until speed tops out (~2000m/s?, mach 5.6), pull up to 15-20 pitch and switch mode at 26-28k.

Currently intakes in FAR don't create drag. That's likely to change in FAR 0.14.2, ferram4 has been doing research into it.

If you're interested in the /correctness/ of it w.r.t a real rocket engine, ask NathanKell. Other than that ... looks good to me. Remember to model for a possible change in gimbal angles to more realistic values - the RD-180 used on the Atlas III and V have a gimbal range of 8 degrees, for example. Also, real engines don't gimbal at the nozzle - the whole assembly moves. Example (SpaceX Merlin 1D):

Works here? Cannot reproduce.

And I've had some fail, don't ask me why that works.

try this: -MODULE[BioGen]:HAS[#tag[Photosynthesis]] {} Note the space before the {} ...

You're correct, assuming you're searching for a value. If its a node, the negation is !nodename

None of that happens here. You have some other mod interfering.

I'm not sure what kind of mods you people are running, but none of that happens here. I can sit in the Van Vogt (3x TFE731s) stopped on the runway with the engines at full throttle, and while they do get /hot/ they dont blow up - working as intended. Works the same with or without DRE, so long as you RTFM and make sure to nuke any and all patch files in other mods that edit B9, like HotRockets, MFT, RF, DRE, etc. And I've never seen this transparency thing, no idea what mod is causing it but it ain't b9.

No. This is the mod we want to make. We'll probably add more. Want us to stop using so many plugins? Tell Squad to fix their bugs, half our work is working around stock issues. You must construct additional information. Like, for example, is this with DRE? Did you try it with just B9? I have no idea what could be going on, there's absolutely nothing special going on in the part, they're just a boring docking node.

Yeah, but those SCRAMs were intentionally hobbled so they could build a test vehicle that didn't have to built out of unobtanium in order to not melt from the compression heating They worked ... about 50% of the time ... and managed to accelerate from mach 4.8 @ ignition to mach 5.1 (because the engine was terribly inefficient due to being designed for the lowest of the hypersonic range). If you want an engine that does that, I can whip you one up, but its a curiosity at best, and certainly no use whatsoever.

Because you're shooting yourself in the foot. FSfuelSwitch does not lend itself to being edited via MM, unless you're a grandmaster of MM 2.4.x variable references and regular expressions. Use MFT, and it will already be done for you. Or, y'know, enjoy reinventing the wheel and maintaining stuff like this: eChargeAmount = #$resourceAmounts[2,;]$ @eChargeAmount *= 60 @resourceNames ^= :$:ElectricCharge: @resourceAmounts = #$resourceAmounts[0,;]$; $resourceAmounts[1,;]$; $resourceAmounts[2,;]$; $eChargeAmount$ eChargeMass = #$eChargeAmount$ @eChargeMass *= 0.162 @tankMass = #$tankMass[0,;]$; $tankMass[1,;]; $tankMass[2,;]; $eChargeMass$ @tankCost = #$tankCost[0,;]$; $tankCost[1,;]; $tankCost[2,;]; $eChargeAmount$

Its easy - a scramjet produces 0 thrust until you're going mach 8, and peaks at about mach 20. So they'll start producing thrust when you're about 30km outside kerbin's atmosphere. The TWR is about 2 orders of magnitude less than the turbojet, and the fuel consumption about 2 higher. The 1960s are waving at you, and want their tech back. Its just packages in a funky-looking mesh, but its the same old .... Von Braun and crew were working on back then. Its all been made, tested, fired, and in the case of the close-cycle mode, flown thousands of times. Don't be an child, SCRamjets are useless in KSP (and real life, it looks like) unless you make them magical friendship-powered unicorn-riding engines, and badgering us over and over won't change that reality. If you want magical engines that work like a fairytale, this ain't the mod for you.

Nah. 1 Upscaled Mainsail 1 Upscaled LV-N Both using the same exponents Squad uses, and with a mass penalty on top of the combined mass. There's just a lot of technobabble description, and the extra mass of the upscaled LV-N is split into the generator so you can go conventional-only, but the numbers are boring like baby food.

You probably want the Firespitter docs

Here are the fixes for 1.2. MM class is in session again! Squad/sepMotor1: Don't add an old-style FX when you're switching to the Part to ModuleEnginesFX. Well, the new module will ignore it, but if you want be neat, delete the old ones. Wipe EFFECTS with !EFFECTS {} if you're going to re-create it - and EFFECTS is a mess to edit so its best to just wipe and replace unless you know exactly what's getting handed to you. No need to kill the old ModuleEngines, and anyway you do that with !MODULE[ModuleEngines] {}. No need to re-create ModuleEnginesFX. Edit ModuleEngines* - in case Squad changes it to ModuleEnginesFX on their side, this catches both and you don't even need to update - change the module name to ModuleEnginesFX, and change only what you need. I've got it down to 2 lines (could be 1, the engineID isn't used unless its a MultiModeEngine), bar the clearing of any custom FX names. The latter generally a good idea, since many people don't know the default FX nodes - see below - unless you're making a MultiModeEngine, you can just give your FX nodes the default names and never specify them in ModuleEnginesFX. StructuralPylon: This one is mine *blush*. It must have been late, because instead of @name = ModuleAnchoredDecoupler, I'm doing | = ModuleAnchoredDecoupler, which changes the node type. So instead of this: MODULE { name = ModuleAnchoredDecoupler It was doing this: ModuleAnchoredDecoupler { name = ModuleDecouple Which ooobviously doesn't work ... Extras: First thing first: Save yourself grief later and avoid spaces in folder names as well as part names. I speak from bitter experience. Snubotron: No need to recreate the whole damn thing. Make a new part based on another part with +PART[<original partName]. Once you've done that, this is essentially the stock part edit with a few more bits. Since you cant be 100% sure people will run it with your edit to the stock separatron installed, you have to make sure it would work with both, but this isn't very hard Clear old-style FX groups for neatness, like the stock edit. Target ModuleEngines* in when editing the engine so it works either way. Like the stock edit, wipe the EFFECTS node and re-create, use stock effect node names, and clear any custom effect names from ModuleEngines* [*]Since its just half a separatron, use /= 2 to just divide mass, cost and resource amounts by 2 - that way if Squad changes those values, yours are still correct. Work smart, not hard Parachutes: Rehash of the above. Fork the exiting part with +PART, and only edit what's needed. P.S. Since all textures get loaded regardless of their being used in a model, you're best off naming the replacement textures with the same name & extension as the stock ones P.P.S. Updated the file with some fixes for the extra parts. Hit me up on IRC if you have any questions, #kspmodders on espernet