ialdabaoth

Hrm. Regarding the multiple launch sites: Is there any way to integrate with KerbTown so that each launch site has its own model (and so that KSP-2 and the island hangar can be used without replacing them with a KSP-a-like)? If so, you should consider giving each launch site TWO quality ratings - one for its VAB, and one for its SPH.

That's exactly what :NEEDS[] is for.

This may sound crazy, but can you include options for adding a 7.5m and 10m scale?

Incidentally, who's currently giving feedback on that? Because I really feel like some of those resources could have simpler / shorter names (specifically, CryoFuel / CryOx instead of LiquidHydrogen / LiquidOxygen, and keeping LiquidFuel - Kerosene - RP1 all as 'LiquidFuel', and keeping N2O2 as 'Oxidizer')

+1 Please implement.

is anyone else experiencing the cargo bays being slightly misaligned ( a little further down compared to the other parts )? EDIT: Ah, I see; it's connecting to the internal bay nodes instead of the actual connection nodes. hmm.

Well, I kinda wanted to make a stockalike redistribution pack for my RKS release.

Any chance you'll be making a mk3 set, considering TT is discussing taking his ball and going home?

I'm pretty sure his example is missing; it should look like this: node_stack_atend = 0.0, 7.21461, 0.0, 0.0, 1.0, 0.0 node_stack_atstart,0 =0.0, -7.21461, 0.0, 0.0, -1.0, 0.0

Bleh. Between that and TohouTorpedo taking his ball and going home, I'm losing all my stockalikes.

How would one get in touch with ClairaLyrae for redistribution permission?

So, I'm about to delve into my first foray with multi-threaded Unity development. Here's my roadmap so far: Mission Plan Create a MonoBehaviour which will spawn a second thread, and synchronize between KSP and that thread. The MonoBehavior will contain a MemoryStream for passing information between another Part, PartModule, or MonoBehaviour and the spawned thread during OnStart, and will contain a ConcurrentDictionary<PartUID, struct T> for synchronizing information during FixedUpdate. Use Case Ferram Aerospace Research would like to do a lot of really complex calculations during FixedUpdate without impacting performance. So, ferram4 creates an app using my ThreadedKSP API. He defines a new ThreadedMonoBehaviour called "AerodynamicCalculations", a new PartModule called PartAeroFX, and a new struct called AeroForces. AeroForces looks like this: { int vesselID; float timestamp_out; float timestamp_in; Vector3D atmVelocity; float atmDensity; float atmTemperature; bool atmCompressible; Vector3D dragForce; vector3D partCoD; } AerodynamicsCalculations has the following methods and fields exposed: int AerodynamicsCalculations.StreamToThread(MeshDataStruct meshData); ConcurrentDictionary<PartUID, AeroForces> AerodynamicsCalculations.UpdateData; And then PartAeroFX has the following behavior: - PartAeroFX.OnStart(StartState.FLIGHT) grabs the Part's entire mesh, builds it into a struct that he decides to name meshData, and shoves it through the MemoryStream by calling AerodynamicCalculations.StreamToThread(meshData). - PartAeroFX.Update then does: if(this.lastUpdate < Aerodynamics.UpdateData[this.part.uid].timestamp_in) { this.lastUpdate = Aerodynamics.UpdateData[this.part.uid].timestamp_in; part.rigidBody.AddForceAtPosition(Aerodynamics.UpdateData[this.part.uid].dragForce, Aerodynamics.UpdateData[this.part.uid].partCoD); } - PartAeroFX.LateUpdate then does: Aerodynamics.UpdateData[this.part.uid].vesselID = vessel.rootpart.uid; Aerodynamics.UpdateData[this.part.uid].atmVelocity = part.rigidBody.velocity + Krakensbane.GetFrameVelocity(); Aerodynamics.UpdateData[this.part.uid].atmDensity = vessel.atmDensity; Aerodynamics.UpdateData[this.part.uid].atmTemperature = vessel.flightIntegrator.getExternalTemperature(); Aerodynamics.UpdateData[this.part.uid].atmCompressible = CheckUnderwater(part); Aerodynamics.UpdateData[this.part.uid].timestamp_out = Planetarium.fetch.time; Meanwhile, the thread is spinning merrily away, using all that data to calculate the next dragForce and partCoD for each part, based on the last available UpdateData[part_uid]. Whenever it finishes calculating those values for a part, it just updates UpdateData[part_uid].timestamp_in, and that part will asynchronously apply the force on the next Update! This technique should be useable for just about anything that needs to do a lot of heavy calculation; since the thread doesn't recognize any Unity objects, it should ignore Unity's lack of thread-safeness.

Well dayam. Salutes swamp_ig.

Check and see if you have two copies of a DLL loaded, and if that DLL is mentioned in the configNode's :FOR, :BEFORE, :AFTER or :NEEDS. If so, this is a bug that will need to be addressed.

Well, most of these problem could be solved by callbacks, but I think that making a lot of methods public and overridable is the best way to go. DeadlyReentry-relevant example: If the FixedUpdate() method on Part() was overridable, it would be trivially easy to replace KSP's heat model and its aerodynamics model.

There are so many things... SO MANY THINGS... that I would gladly fix for free for Squad, if they would be slightly less paranoid about people 'stealing' their code. I understand the desire to protect your Intellectual Property; I really do. But there are so many things mod authors could do if some of Squad's classes were more permissive.

To repeat my syntax request: Is it possible to make '+' an alias for '$', and '-' an alias for '!' as node prefix pragmas? It might make things easier to read.

I'm taking a short break from modding; I'll see if I can get to it in the next few weeks.

Alternatively, you can wait for my RealKerbolSystem release, which will have all parts (including the B9) scaled to appropriate masses/thrusts given their size. The real SABRE actually DOES have the 'absurd' TWR given, but it's also nearly 4 meters in diameter. A real one would be about 40% of the mass and thrust (so same absurd TWR, but shrunk down Kerbal-sized.)

I am now preparing my plugin list, and modified config files. I've decided to go ahead and include KSPI, and just use ModuleManager configs to disable fusion, antimatter, and warp technologies. Finalizing resources to: Squad - LiquidFuel (Kerosene) - Oxidizer (N2O4) - SolidFuel (APCP) - MonoPropellant (HAN) - Xenon (Xe) - IntakeAir (ambient atmosphere; engines can set CheckForOxygen = true to only use Air with 15% or greater oxygen) RealFuels / KSPI - CryoFuel (LH2) - CryOx (LOX) - Peroxide (H2O2) - Methane (CH4) - Ammonia (NH3) - Aluminum (Al) - NuclearFuel (Th232) - NuclearWaste (various Actinides) - Water (H2O) - Argon (Ar) Life Support - Biomass - Snacks - BioWaste - Oxygen - CO2 I'm carefully reviewing the license documentation of the mods I'm going to use; so far it looks like I can modify and redistribute as I see fit the following mods, as long as I contain the appropriate license documentation: -B9 Aerospace -KW Rocketry -RealFuels -KSPI

Suggestion: if + isn't an invalid character, make the "duplicate node" op a + instead of a $ - it's MUCH more intuitive. like this: +PART[fueltank] { @name = newFuelTank }

I have a pair of requests for this mod: 1. Currently, air intakes check for whether the incoming air has oxygen, and refuse to intake air if it does not contain oxygen. (This can be disabled with a cfg change). This is clearly wrong; the engine itself should be what's doing the check for oxygen. Could you please add a checkForOxygen flag, which causes the engine to produce no thrust (but still consume fuel) if this.vessel.mainBody.atmosphereContainsOxygen is false? 2. Could the mod check for fuel density, and change the engine's thermal and performance characteristics if (for example) liquid hydrogen is being used instead of kerosene?

And now, a diversion: Kerbal biology and evolutionary history. Evolution Kerbol is a significantly older star than our own; K-class orange dwarfs are notoriously long-lived. That said, Kerbin's 6.5 billion year history has been much less eventful than Earth's. Part of this is due to the milder weather patterns on Kerbin - without axial tilt, Kerbin's seasons are almost imperceptibly mild, which allows Kerbin's atmospheric dynamics to stabilize more rapidly than our own. This, in combination with other factors, has tended to produce a slower evolutionary process. The Kerbal proto-ancestor evolved sometimes in the late Kerbaceous period, from a small fuzzy creature something like a cross between a meerkat and a bush-baby. These mostly-herbivorous foragers, called 'meerkerbs', lived in dense underground warrens, where they primarily consumed metamoss and dormant cyanotubers. At some point in their evolution, these creatures developed the ability to 'steal' the cyanotuber's photosynthesizing endosymbionts and maintain colonies in their own bodies. This ability continued to evolve until the furry, black mammals became almost entirely bald and green-skinned. As a result of being able to synthesize sugars directly from sunlight, the meerkerbs slowly developed into more insectovorous and fungivorous eating habits to maintain a proper intake of proteins and micronutrients. Unfortunately, their high concentration of cyanosymbiont-based sugars made them absolutely delicious to predators, of which the Kerbaceous period provided in abundance. A lucky break came for Kerbalkind in BKE 66M, when a massive asteroid ended the Kerbaceous period, and with it all the enormous and fearsome predators. With the ecosystem decimated, the meerkerbs managed to diversify into a multitude of abandoned ecological niches. It was one of these diversifications that led to Kerbals, Kerbin's first sapient(?) species. A Kerbal gets 50% of his oxygen and 90% of his blood l-glucose directly from sunlight, so long as his air supply contains at least 5% carbon dioxide and no more than 30% oxygen. Kerbals can live for extended periods without food or even fresh air, so long as they receive sufficient light. After a few hours, however, they will begin to become very cranky and querrellous if not given an adequate supply of protein-enriched snacks. It is recommended that each Kerbal intake at least 100g of dry snacks per day to prevent temper tantrums, and at least 500mL of water per day to prevent dehydration. Anatomy A Kerbal's general shape is held together more by hydrostatics and muscle tension than by a rigid internal skeleton. In fact, the Kerbal's actual "skeleton" only consists of three keratin "bones": a skull, a mandible, and a pelvis. The spine and limbs are flexible, muscular tubes held in shape with hydrostatic pressure, while the squeedlyspooch (a combined heart, lung, and digestive tract) brachiates into several 'nodules' within the body cavity. Toxin filtration is shared between the squeedlyspooch and the cyanosymbiont nodules of the inner dermis.

I only use it so I can have a radially attachable probe core.

Excellent! Actually, it looks like the radii are already good; all you'd need to update is Kerbol's mass and radius, and the orbital period of all the planets. Looks like you want: Kerbol: Radius = 507715000 Mass = 1.59128e+30 kg and then multiply all the orbital periods by 1.116295 - which gives Kerbin a year that is 181.2 earth-days / 724.8 Kerbin-days. (also, I'd really suggest keeping Kerbin's 6-hour rotational period; it's cute and makes launches easier.)