RunaDacino

When making patches for turning wings in mods compatible with FAR, what are some easy ways to generate the required data for control and lifting surfaces? The mods in question are firespitter and coldwaraerospace

Hello! There is a user on /r/KerbalAcademy who wishes to build planes with firespitter and ColdwarAerospace. However, it appears they do not work with FAR: using the parts produces the wrong aerodynamic center icon (it has lift) and it causes some nasty aerodynamics issues. I know, in principle, how to fix it by looking at my existing mods and how they created FAR compatibility. I have searched the forums, and the firespitter thread seems non-existent and the ColdWarAerospace thread has no mentions of FAR or Ferram. I am wondering what to do though if, since you aren't the mod author, you do not know how to fill out the chord sweep, chord length and all those details. I see that B9ProcWings does not define such for FAR, and simply says "ForceUseMeshes = True." Would this approach work for the aforementioned 2 mods as a potentially hacky fix to this user's problems?

Thank you very much! This is very different from my past experience of "everything you need is in the same repo with minimal external dependencies", but hey... new experiences.

Hello! I want to fork and modify some annoying hard-coded values in https://github.com/allista/GroundConstruction pertaining to how ground kit size and time are calculated as stuff keeps exploding and becoming kilometers wide and tall. Not ideal. While I havn't worked with Unity/C# before, I trust I can leverage my python, BYOND and fortran/C/C++ experience to figure it out. It's just adjusting variables anyhow. Unfortunately, I ran into an issue on building this project. The project file points to a "CSharp.warnings.xml" in the project directory that does not exist. Most other mods with gits have detailed build requirements, this one stumps me. edit: I found I can edit some of what I want in the .GLOB file without rebuilding, but I still want to rebuild it for capping maximum volume rather than setting density to ... interesting values.

The kOS update is pretty sweet, thank you! I have one question: Spare chutes is a limited number. If I want to set up a fully reusable lander that will operate indefinitely to ferry people from Duna orbit to surface, relying on rovers to allow for high efficiency (but imprecise) descents... Is there a way I can "refuel" the realchute spare chutes?

Why exactly is the orientation of a spacecraft its "attitude"?

Is it possible to write a module manage patch FOR a patch? e.g, There is a patch that edits ALL parts. Can I interrupt this patch, modify it to only edit specific parts, then let it go back to happening WITHOUT editing the patch file itself? At the moment the approach is to make a 0000 that loads before the patch, modify the desired parts with a key:value pair then modify the mod's patch cfgs to check for this key:value pair. I'm wondering if I could do it without touching the mod's files.

I wasn't sure you could add entirely new keys without actual compiled plugins. In that case, that makes life much easier. Thank you! I guess it's now time to go through each of the VexarpIVA near future pods to see if upgrade or non-upgrade works better for them. Edit: Done it like Johnny advised. Definitely feels more elegant. I havn't looked at the vexarpIVAs and some other plane cockpits if they are better with the upgraded ASET parts or not yet.

Ah, I meant hydrogen. Was thinking of multiple things @.@

Just how horrible would a thermal nuclear aeorspike engine burning liquid helium be for health, ecosystem and the environment? In MKS WOLF, I found the most optimal transport credit/payload vehicle to be a medium 7.5m tank, a scylla atomic aerospike engine, a 5 m kontainer and a probe core with batteries to 75 km LKO. I can't help but wonder, if envirionmental damage was a thing... just 3 launches would horribly irradiate KSC. Is this true, or would a thermal aerospike be "cleaner" provided it doesn't explode.

I've found that the OPT J HT flight instruments fail to work without the MAS JSI to MAS and ASET to MAS patches. Unfortunately, these patches break probes before crew and some other IVAs (ALCOR). I've found a very hacky solution to this. In the MAS patches for RPM and ASET (000 JSI TO MAS, 001 ASET TO MAS) slap a big old ":HAS[#NAME[j_6m_cockpit]" onto @INTERNAL and @PART entries in both files. This gives you a working J HT cockpit with usable ILS displays while keeping PBC from breaking.

@Manul I got it to work, thank you! The cfg for whoever else wants to modify the aeorcams with heat resist and doesnt want to hunt stuff down: Now, new challenge: How do I make 001_ASET_TO_MAS.cfg apply only to parts/mods selectively? Issue I've ran into is that the CDI/LOC/VOR in the OPT J HT cockpit does not work with ASET consolidated props as they are fresh off CKAN, which makes IVA landings pretty hard as it otherwise uses MAS MFDs which do NOT have a localizer set up. If using the ASET upgrade patch, the OPT J HT cockpit works amazingly (with the need to go EVA/reenter, but I can live with that). Unfortunately, the RPM/ASET patch breaks probe control room, which I see is a known issue. It also seems to break the ALCOR command module. So I'm wondering how could I make it so that the big ASET/RPM upgrades only apply to specific parts rather than change everything? Or is that impossible. Edit: it seems to work by just going into the MAS patches for RPM and ASET and slapping a big old ":HAS[#NAME[j_6m_cockpit]" onto @INTERNAL and @PART entries in both files. PBC works, ALCOR works. MK1-3 keeps working. CDI/localizer/VOR work (altho I havnt done a full flight around KSC yet, but the CDI moves around as I taxi around while without the upgrade it just stutters weirdly). Now I just gotta find a way to make it apply to multiple parts without having to copy paste the patch for each HAS entry. Wish it had an OR functionality. Maybe a bunch of NOT HAS listing all the pods I know it breaks could work.

https://github.com/MOARdV/AvionicsSystems/blob/c9a8777e7a14d19667d93b17bf3fe2e2430bf68e/GameData/MOARdV/Patches/MAS_HullcamVDS.cfg#L12 I've been looking at the source to understand how the MAS Hullcam patch works, as I tried to use a simple MM patch to add MAS camera to HullCameraVDS/Parts/new_cams/aerocam.cfg and its 180 variant whose part names are DC_aerocam2 and DC_aerocam2_180 respectively. However, I cannot seem to find a way for it to display an image in the MFD, which I assume is because I copied the normal aerocam MAS_camera module in full assuming, given it's basically the same part with a slightly different texture, it would work. I imagine it has to do with "cameraTransformName." I've been looking at HullCam cfgs, but I cannot find the cameraTransformName defined anywhere.

One big advice I have for "weird turning right" is: NEVER ATTACH ANYTHING (except for ailerons, flaps, slats) to your wings. This includes other wings. Attach everything to your heaviest fuselage part (ideally in the centerish) and then use off-set to make space for more attachments. Do this until you have all wing panels (I recommend procedural wings to reduce part count) set up, then add control surfaces. All my planes had really weird rightway turning, even on the runway, until I came to this realization. Super stable eversince. You have also mentioned using FAR. If you are - I recommend either Kerbal Joint Reinforcement Next or Continued. FAR introduces far more aerodynamic stress that will bend and buckle your realistic and otherwise structurally sound designs. Furthermore: I strongly recommend adding control surfaces on the front of your wings too (leading edge flaps/slats). I will forever advocate for them after learning just how much they can affect runway/takeoff/landing stability. It's insane. Although, for your tiny plane it might not be needed. Finally for taxiing: Reduce your frontal wheel friction significantly, and increase your rear wheel friction in turn if you are using wheels that allow such (Kerbal Foundries don't, unfortunately).

Full IVA landing successful. Albeit, with a massive jumpscare of a sneaky mountain.

I think I noticed a weird relationship between Kerbal Construction Time, planes and MAS. On launching MAS-IVA planes, they frequently do not work with KCT. If I return to Space Center and "fly" the craft - suddenly everything works just fine. There might be some initialization step that KCT breaks, I imagine. Alternatively, going EVA and back in also fixes it. I mostly experience this in OPT J HT cockpit (the bus and battery buttons do not work).

Using the OPT J "HT" cockpit, I tried to perform an IVA landing on KSC runway from munar flyby using only flight instruments as it was night. I made 3 passes of the runway (excess deltaV for minmus landing yay! Airbreathing engines yay!) before giving up and using NavUtilities Continued rather than the analogue ILS/CDI/HSI/VOR. Afterwards, I watched a few lectures on analogue flight instruments. Then I went and did an IVA ascent into rendezvous (we were 10 km off! Just had to do a bit of hohmann to get closer) and dock with my LKO (175x175) shipyard (global construction style). I've intentionally designed the station with big docking arms to accomodate big spaceplanes. The plane I used is in the SSTO thread.

Posting it here in case I end up cleaning up my gamedata folder again or just in case anyone else wants them. Patch: Makes MPUs (1.25, 2.5, 3.75) able to produce LqdHydrogen + Oxidizer, Methane + Oxidizer, Lithium from "water", "chemicals" and "rare metals" respectively with not exactly balanced or too deeply considered ratios. For hydrolox, I just went with molar masses. For methalox, I kind of copied liquid fuel. For lithium, I went for small conversion rate since lithium is rare yo. For search term: Patch for Near-Future / Cryoengine Fuel production with MKS Patch: Adds ability to produce Hydrolox, Methalox, Argon and Lithium using "Fuel" from the 2.5 and 2.75 hoppers. For searching: Adds WOLF Near-future fuel compatibility

I'm putting this here, necropost as it is, as I've made the most striking discovery for high-performance/fighter design. Leading edge flaps/slats/etc. If using procedural wings, put the control surfaces all along the leading edge of your wing. Don't have to be big, just use them as a replacement for your leading edge when neutral. Set all their control input to 0, set them as flaps and go wild. Lining my delta-winged V tail fighter's leading edge with leading edge flaps have reduced her landing speed from stalling out around 120 m/s to gently touching down at 60 m/s by allowing me to fly with a pretty high AoA. I didn't realize how utterly critical they are to delta winged designs so - here you are!

Parts with ability to intake air, and also atmosphere that have b9partswitch to replace intakeatm with other fuels cause nullreference exception spam. Linked to original report with logs in the thread.

@Starwaster I've launched a KRASH form of the cockpit in question (J HT) and the nullreference exception persists, it seems to be caused by that part. Maybe its intake set-up? The 5 person J QSo2 cockpit with intakes has no such issues. Edit: Tested a frankenstein's cockpit of all intake-capable K cockpits (TAV, Spaceplane, avatar) and the one J cockpit I never used. No issues there. Seems unique to J HT, which is a shame as I love its IVA. K TAV and the J HT are the closest in shape too. Edit 2: I tracked down the bug. It's the b9fuelswitch for the cockpit. By default, it's on "IntakeAtm". I have changed it to KeroLox, presuming it's storage for those air-based OMS thrusters and... this apparently broke everything. Putting it on IntakeAtm fixes the massive exception spam. Yeah, went through the rest of the cockpits. If you change it from IntakeAtm, everything breaks.

Update: it had successfully landed on Minmus, and actually returned to the runway in one piece! https://imgur.com/a/kdxLoEe Made heavy use of Thrust Controlled Avionics for the VTOL style Minmus landing to ensure thrust is balanced and we're vertical

Hello! I get SEVERE unhandled exception spam about NullReferences while using the OPT J HT cockpit. I have attached all possible relevant logfiles and my modlist: https://drive.google.com/file/d/1KJzuQZ0isNyB7_8YxIPqVoBqzc-O2ibD/view?usp=sharing It seems related to MAS that the cockpit uses. I noticed when I launch the vessel, none of the MFDs work and there's severe flickering. If I EVA and re-enter, the flickering persists unless I zoom the right amount but things work again. By this, I mean I couldn't toggle the Bus and the Bat triggers either, so it's not because i forgot them. I am NOT using the MAS experimental avionics or RPM replacement patches yet I will attempt the beta to see if it changes anything. Edit 1: Downloaded latest beta release, except for "Legacy." The exception nullreference seems to have stopped. MAS still complains of initialization on EVA/enter, but the MFDs work fully. Logs will wait until I land and recover on Kerbin and launch the vessel again for certainity's sake. Edit 2: NullReference started spamming again on launch. I wonder if it might be something to do with Kerbal Construction Time. Logs for with beta: https://drive.google.com/file/d/1lp3kgKmm3o3NN5DKX665SlSNEJOOX8Hf/view?usp=sharing

What does it mean when PVG says "Thrust is off by X%"? In my case, it says 20%. I am using Better SRBs and the 6 slotted special (starts at 150% thrust and decays rapidly to ensure constant TWR from SRBs), is it because of this?

I bring you another SSTO, now with commentated FAR readouts and a test flight! https://imgur.com/a/0kOifrU This one's stated goal is to get to minmus, land and return to Kerbin.