NathanKell

JPRockets: Examine my two posts above yours. Draw your own conclusions as to whether reinstalling something that (oops, my fault) bundles a broken prior release of my mod, is actually going to fix the broken thing. Then get the DLL from the official RealSolarSystem thread.

8.2 has been released, which should fix the remaining loading issue. I think.

Well, sounds like Flight Data needs to be updated then (I assume that's DaMichel's Flight Data mod?) EDIT: Ninja'd by the Master.

While FAR does not support asymmetric lifting bodies, it does support symmetric ones (all non-wing parts without drag model overrides are modeled as conic frustums). You should be able to fly a Mk2 cockpit and Mk2 fuselage as a lifting body. (If you're fast enough a Mk1 fuselage system will work too....)

when e^(-height_in_km / scaleHeight_in_km) < 1e-6, pressure drops to 0. *No matter the pressure multiplier* so Eve will have one *heck* of a sharp transition (because it has a high multiplier but not a terribly high scaleheight).

Changelog v8.2 *Finally fixed (I trust) all remaining issues from the loader rewrite *Borrowed some PQSMod values from 6.4x Kerbin (kudos to Raptor831 et al) jsimmons: per the last few posts there was a loader error, which I have now corrected. See if it works right now?

Asmi's ECLSS mod is based on a (multithreaded) unloaded-vessel-update framework, so while there isn't ingame support for doing stuff to unloaded vessels, there is available a strong library to expand upon for handling tick-based unloaded vessel updates.

Note that at least as far as RSS is concerned (although this is also true for EVE, I just didn't get around to making that file, and is true for ATM see below) you can do what you want by making your *own* RVE folder, putting these cfgs in it, and putting EarthColor.dds (note dds!) in the RVE folder, and EarthSurface.png in RVE\PluginData This way it doesn't require overwriting anything RSS (since any files in PluginData don't get loaded, there's no harm in leaving the original RSS textures lying around). RVE.cfg: @REALSOLARSYSTEM:FOR[RVE] { @Kerbin { %SSFStart = 94000 %SSFEnd = 100000 %PQSfadeStart = 100000 %PQSfadeEnd = 120000 %PQSSecfadeStart = 100000 %PQSSecfadeEnd = 120000 %PQSdeactivateAltitude = 125000 %SSColor32 = RVE/EarthColor %SSBump = GameData/RVE/PluginData/Earth_NRM.png %PQS { @Kerbin { @Add { @PQSMod_VertexColorMapBlend { @vertexColorMap = GameData/RVE/PluginData/EarthSurface.png } } } } @AtmosphereFromGround { %innerRadius = 6357290 // 0.99 %outerRadius = 6496000 // 1.025 %waveLength = 0.65, 0.6, 0.5, 1.0 //invWaveLength = 0.75, 0.82, 0.89, 0.55 %ESun = 20 %Kr = 0.0008 %Km = 0.0006 } } } RVE_ATM.cfg ACTIVE_TEXTURE_MANAGER_CONFIG { folder = RVE enabled = true OVERRIDES { RVE/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = true } } } This is occasioned by my actually, finally getting to try RVE (in very stripped down form--I can only use one cloud mask, and no planet but Earth, and very few mod parts). And HOLY CRAP IT'S AMAZING. But please, please put it up on github so the above could be a pull request, not just posting in the forum

Oh, I guess RedAV8R pulled that out of the alternate config then. Sorry.

Ambient is the ambient temperature, not the shockwave temperature. If you open the DRE debug window, then more displays on right-click will be enabled, including shockwave. (If the shockwave temperature were only -25C, do you really think the part would be heated up to 476C? ) lajoswinkler: as Starwaster mentioned in one of the updates, Jool's atmosphere is not very dense, so while you're going insanely fast and thus flash-heat what air there is, the air being hot doesn't mean lots of heat transfer to you.

Ven: The Pyrios F-1B has a much larger area ratio than what you modeled; I believe it has the same 1:16 area ratio of the F-1/F-1A. For that size turbopump, cumbustion chamber/nozzle throat, and exhaust, it should have a bigger nozzle exit IMO. That was why I immediately thought of very old engines, since they had quite low area ratios (the X-1's XLR11 was underexpanded *at sea level* for example).

Here is all we know (AFAIK) about textures in KSP

Shoot I didn't release 8.2 yet! So yes, it does. Sorry Paul (and everyone else). Current RSS is borked >.>

Um, there's *very good reason* .25 has a higher memory load than .24--it has a new building, new features, new GUI art, new destructable building art...let alone the SP+ parts. And note that only stuff in the GameData folder is scaled by ATM, so everything that .25 added apart from the new parts will not be touched by ATM. Setting textures to half res in the game settings does exactly what ATM aggressive does. If you're tempted to use it, just use scale = 4 instead.

The 0.9.1 release does not work for (some) people without NEAR/FAR. The dll I just posted is a fix for that.

Apologies on my part too; I posted what I did about FAR because I know for a fact old-far doesn't play nice with current pwings, so I wrongfully assumed that was your issue. Glad it's sorted, and *thank you* for bringing the bug to my attention. (Always better to know and fix.)

The old ones (blunt body) were thermal soak; the new (for late 60s+ versions of "new") stuff is ablative (and very pointed).

Here is the fix. Looks like in my test install module initialization order was different than in yours, thus the for you (and in a stock KSP + pwings) the Pwings module is added before the stock control surface module. I have added a workaround. Here is not the fixed DLL. The code change was after Line 473 var mCtrlSrf = part.Modules.OfType<ModuleControlSurface>().FirstOrDefault(); insert if ((object)mCtrlSrf != null) { And then close the if at the end of the three mCtrlSrf lines with a } Again, my apologies for not testing rigorously enough. EDIT: Note that this is only because KSP's module loader doesn't catch; it would have worked fine ingame, just breaks the loader. EDIT EDIT: BAD MODERATOR, BREAKING OWN RULES. BAD.

I was able to confirm the issue. I still have no idea *why*, but it's there. Gaalidas, (and DYJ), apologies.

The engines I added were indeed geared towards people making interesting historical (or pseudo-historical) aircraft, rather than playing KSP in career mode (where you don't get anything plane related until after *orbiting*...)

It does not require FAR. I see no reason why lack of FAR would break things, since FAR-related stuff is run only when FAR is detectd. However, I'm willing to try to replicate.

This is not a thread about support for a modded install of KSP; the best fit we have is Kerbal Network, so off we go...

Whenever a Vessel (which is a collection of Parts, each of which may have any number of PartModules) is put on rails (i.e. is no longer in the 2.5km active zone, or you go into timewarp) it's serialized to confignode and to a ProtoVessel, ProtoParts and ProtoModules. (This is similar to when it's saved to .sfs, or when the editor saves a craft to .craft, although in those cases it's just serialized, no proto-whatever hang around). When the vessel goes off rails (or is read from disk), OnLoad is called for every module to update its status to what was saved in the confignode. What that code is doing is checking to make sure that the serialization is complete (i.e. not just that the event fired, but that the vessel was serialized, and thus no longer has [unserialized] Parts in its Parts list, but instead has protoparts with confignodes for data storage), and if so, to register it with Remotetech as a ProtoVessel (the class used instead of Vessel when a craft goes on rails, just as Parts have ProtoPart etc).

pingopete: why do you think I changed it to allow loading from gamedata? Yes, I converted your new Color map to dds. dlrk: I wasn't calling the final orbit method correctly (coroutines calling other coroutines have to invoke things oddly).

Just as a note, I *am* subscribed to the RftS thread so I'll see it if someone posts there.