danfarnsy

Cosimas, The knee-jerk "you're doing it wrong" is common around here, but there's no reason to believe you suddenly forgot how to dock. Alshain is very likely correct regarding the graphics card having nothing to do with it. While I have no idea what's causing the problem, here's how I would approach finding it: Copy your KSP folder to somewhere else (desktop for easy access?). Remove all the non-Squad mods from the GameData folder in the copied KSP folder. Launch KSP from that folder, and since your saved game will now almost certainly be broken, create a new sandbox game and test out docking in there. If it works correctly, exit the game and add one of the mods. Test again, and keep adding new mods and testing until the problem comes back. If it doesn't work with all mods removed, then the next step is to try an updated KSP (remember you can keep a copied 0.90 elsewhere) and see if the issue persists there. That's a pain in the backside fix, but from here it looks like your best bet.

You are running out of memory available to KSP because the client is 32-bit, even if you still have unused memory. The best workaround is reducing your number of mods, particularly those which have many parts, models, and textures, or those with a few high-quality textures. Also, if you don't have Kerbokatz Utilities' "DisableTempGauges," http://forum.kerbalspaceprogram.com/threads/116034-1-0-X-KerboKatz-SmallUtilities-V1-2-2-07-08-2015-Now-with-AutoBalancingLandingLeg!#DisableTempGauges that tiny mod will address a memory leak associated with the temperature gauges (which memory leak nearly guarantees you run out of memory while flying any high part-count craft). Bottom line, you're going to have to make some sacrifices in terms of which mods you use.

Such optimism! It's refreshing... I come from the "don't believe anything anybody tells you until you see it, and even then only half the time" school of thought.

Yes, this is as it should be. Community Tech Tree is a separate mod created as an architecture for many mods to plug their mod parts in reasonable places, while having a more challenging career (it's several thousand more science points to unlock everything). KSP-I doesn't use all of these nodes. I have a mod list stacked to the sky which use CTT, and I still have a couple of empty nodes. - - - Updated - - - I think leaving it as a "suggested" or "recommended" mod on the CKAN config file is a good idea. Answering a question or two here is better than not letting people know this mod goes hand-in-hand with KSP-I rather well.

Davidy, it's harder to use. Right now, we have a lot of speculation about how stable KSP will be under Unity 5, but as it is there isn't a separate OS X 64-bit client. That means you'll still be capped at 32-bit style RAM usage, meaning you're going to have to pick and choose which mods are important enough to you. Otherwise, if your list exceeds 3.5 GB worth, it *will* crash on loading. And forget about using Astronomer's Visual Pack or others that take the game from "cool" to "awe inspiring." I have an iMac, but I'm trial-booting with Linux and Windows too, which isn't for the feint of heart. The Windows side with Bootcamp is straightforward enough, but Linux requires a certain amount of expertise in witchcraft and modifying your partition table. Apple doesn't make it easy. That said, if your mod list is stable in 32-bit Windows KSP, it should usually be fine in OS X.

I have a station in orbit of Minmus, with parts from MKS, Near Future Tech, TAC-LS, Nertea's Station Expansion, and more. My mod list is ginormous. This craft was working just fine for a while, but now the skin temperatures for all parts are rising persistently without any conduction from skin to internal. The parts vary in skin temps, with my highest temperature part (a planetary survey camera) having reached a skin temperature of ~1200 K but an internal temperature of ~190 K. It also continued to have positive radiative flux until I turned SolarLuminosityAtHome almost all the way down to keep it from exploding. I had a FTT Honeybadger freighter docked, and it was showing the same behavior until I undocked it, and then the freighter was fine. The behavior on the station is persistent upon loading, unloading, saving, quitting, etc. The radiative flux is still positive in the shadow of Minmus, which is odd too. Has anybody seen this before? I've seen plenty of the numerical instability of small parts exploding (most of the time eliminated with conduction factor turned down to 12), but parts receiving flux but not transferring it from skin to internal is very odd. The fact that it isn't happening for other craft suggests to me it has something to do with a particular part, but *all* the parts on this station have the same divergence of temperatures (~200 K internal with ~400-1200 K skin).

I've never seen this, and I have heavily modded my install. What mods do you use?

One of the major memory leaks is with the temperature displays. You can turn them off by pressing F10, which will delay it. KerboKatz utilities also has a mod which automatically turns them off (so you don't have to do it every time). I have 16 GB of RAM and still occasionally have my 64-bit Linux install balloon to 13.5 GB of usage (usually I'm hanging out around 6.5 GB for KSP).

While I respect what Yafeshan is advocating here, I think it's an unnecessary complication to have a special resource for hot anti-matter that is then converted into cold anti-matter. These anti-protons do have a lot of kinetic energy after they're produced, and in the real world we have to slow them down first. But I think that, for KSP-I, it's just a bit too much to have two separate types of anti-matter. If we want to have/require toroidal storage tanks which represent a process of both cooling and magnetic storage, that would be awesome. We lose something of the *game* by trying to so meticulously represent reality, particularly when "hot antimatter" is a resource which will never be directly used. It's an intermediate step, and players will only ever use "cold antimatter" in their reactors. So let's just generate antimatter, not have separate types, but let's use special tanks like FreeThinker's excellent toroid models to store it, with the idea that the toroidal tanks represent both cooling and storage of produced antimatter. I like the direction overall, and this system does need an overhaul. My vote is for simplicity. By the way, are those toroid models from Talisar's old spherical tanks mod? I miss that mod. - - - Updated - - - And I have to revise my feedback: Using a crewed science lab as a requirement for the "cooling down" of produced anti-matter or exotic particles sounds great to me. No science lab with your particle accelerator, then no stored antimatter. I like it.

The Space.com article referring to "strange" matter as exotic matter is not the same exotic matter as that required for warp drives or stabilizing worm holes. Sometimes I get really annoyed with science writers who majored in journalism instead of a science. The exotic matter for warp drives has "negative" mass. Yafeshan referred to it with the Casimir effect, but the Casimir effect involves a special region where the quantized electromagnetic vacuum has a lower energy density than open vacuum. Where vacuum is arbitrarily defined as "zero" energy density (nevermind that the sum of the energy over all possible modes is infinite, unless you include a Plank-length wavelength cutoff, then it's just ridiculously large), a Casimir cavity has a negative energy density. Because the energy of the quantized vacuum doesn't gravitate (one of the huge contradictions between general relativity and quantum mechanics), the negative energy of the Casimir cavity is treated by general relativity as a negative mass, being gravitationally repelled by normal mass-energy. *This* is the exotic matter needed for bizarre solutions of GR which involve stabilized worm holes and warp drives. Ultimately, there are no predicted particles, from particle accelerators or otherwise, which have this feature of negative mass-energy. There are only special regions of modified boundary conditions (like two conductive plates) which have effective negative mass. TL,DR: It's fine to use a particle accelerator to create exotic matter for your plug-in, but an Alcubierre Warp Drive's required exotic matter is not known to be producible through any process in a particle accelerator. In fact, it's not known to be producible at all. Edit: FWIW, my research emphasis is Quantum Optics and Quantum Information. Also, I previously wrote "stabilizing black holes" instead of "stabilizing worm holes." Oops.

Look to his coming, at first light, on the fifth day. At dawn, look to the east.

Flashblade! Welcome back! I am looking at making a patch/mod for the heat system. Basically, because the heat issue comes from small thermal masses adjacent to large ones and the Euler approximation method using too large of a step size, the system swaps too much heat for even small differences in temperature, then it swaps even more, repeatedly, until BOOM! Right now, I've got it worked around by modifying the physics.cfg file to change "conductionFactor = 20" to "conductionFactor = 12". What I would prefer to do is have a thermal mass comparison between two parts that scales the heat transferred down by some constant times the ratio of the thermal masses. It's not especially realistic, but neither is the current heat system. Regarding wing area: I quickly put the two side-by-side as a double check in the SPH. The 4x4 delta wing is definitely not the same area as the 4x4 square wing, and same for the others in the SH wingset (delta vs square). Of course, the leading and trailing edges add to the surface areas and chords of both, which is why the FAR values are different from what you would calculate for a "strict" 4x4m square wing ("strict" MAC = 4, whereas "actual" MAC = 5, implying 1 m added by leading and trailing edges and a wing area of 20 m^2 instead of 16 m^2). So my proposal to simply cut the deflection lift coefficients in half for the delta wings was off (thanks for making me check), but the deflection lift coefficients for the 4x4 delta wing vs 4x4 square and 4x2 delta wing vs 4x2 square should absolutely be different values from each other. That's a lot of energy we're putting into rearranging deck chairs on the Titanic. Before I change any of these values for stock aero, I'll be careful and derive areas from the provided FAR values of MAC, sweep, taper ratio, etc. I'll also see if I can check other parts for the magic number Porkjet mentioned, as you're right about the shuttle delta wing using a value of 3.3 instead of 3.52. Nothing can ever be simple, can it? - - - Updated - - - Yes, it's stable! Sabre away! - - - Updated - - - Nansuchao, I would eventually like to take a look at this myself. Much of the config information in the interstellar parts using Interstellar Fuel Switch is the same as for FSfuelswitch, so writing a patch file for MM shouldn't be *too* hard. Famous last words, right? - - - Updated - - - Sorry this post got lost in the sauce. Right now it's hard to say. Our efforts are focused on updating the pack to be compatible (nearly done) and balanced/consistent (not so nearly done) with the current version of KSP. Bac9 still owns the mod. Beyond updating the Mk2 system to be compatible with stock, but prettier, and maybe trimming B9 down a bit, I don't know what his intentions are. Extrapolating from his recent bout of real life, I expect this mod will be in maintenance mode rather than growing, though I've been wrong (a lot) before.

You're right. Oops. Once upon a time, I got a really good score for reading comprehension on the ACT. You wouldn't know it, lately.

That certainly makes life easier. Now that I'm deep in them, I've realized they're jacked up six ways from Sunday, at least for stock aero, but their masses are nonsensical too. It's good FAR overrides their masses, since that means if I do make any changes to bring them in line with stock, I won't be killing everybody's .craft files. The ctrlSurfFrac from the FAR module was copied as the ctrlSurfaceArea (CSA), but CSA is a raw area value (in m^2) instead of a fraction of the total area. I imagine, time permitting, that it would still be good to have updated parts that are consistent with stock values so an eventual legacy parts pack is *functional*, but it's not high on the priority list.

Actually, all the deflection lift coefficients are off. The magic number is supposed to be Area/3.52. Yay! More work! Edit: Just saw your reply. I'll double-check and update all the coefficients by PorkJet's numbers. Additional Edit: I'm hesitant to change any wing masses, even though they don't follow PorkJet's formula. I can, but it will break a *lot* of spacecraft. - - - Updated - - - You know what? My reasoning above is bogus. This mod hasn't been updated to 1.0 officially, so while it may screw with the aircraft and spaceplanes people have in their saves with the dev version, that's not enough reason to avoid updating the masses. They'll certainly be more consistent with stock performance (FAR-less) of stock parts. What we ought to look at, however, is a slight adjustment to Porkjet's mass numbers. Those numbers are fine, but the SH wing system is clearly heavier/thicker than the stock wings. Do you know how it's calculated for B9 Procedural Wings?

Blowfish, Quick thing on the wings: the 4x2m Delta Wings should have 4 m^2 surface area, while the 4x2m Square Wings have 8 m^2 area, right? The deflection lift coefficients are the same for both, but one ought to be double the other. I'm going to change these to be self-consistent (cutting the delta wings deflection lift coefficients in half) unless you tell me otherwise. This is a non-issue with FAR, so I never would have noticed without combing through the parts. Also, while I'm not planning to change any masses, I was wondering about the SH wing masses: these parts don't scale anywhere close to linearly. SH A35 Delta Wing has area of 12 m^2, A45 has 8 m^2, and A65 has 4 m^2, but their masses are 0.113, 0.099, and 0.082, respectively. Is this supposed to reflect most of the mass being in mount-point structure?

Vegemite, In addition to the points made already, there's an issue of time. Some of us are contributing to the update, with Blowfish taking the lead, as the owners of this mod have real life going on. I responded on the previous page with the same zeal as Run and Obsessed, but I understand your (and others') frustration. Many other mods, some of them with similar complexity, were brought fully up-to-date quite a while ago. I'll freely admit to some procrastination: some of my KSP time is spent actually playing the game, while balancing parts gets BORING. It gives me a lot of appreciation for other mod developers like RoverDude and Nertea, with their wide variety of parts which they are very good about keeping up to date. In the mean time, in my post right above yours, I have linked to the current dev version. Most things in it are working, so you can enjoy most of this mod! Also, I would recommend in the future voicing your encouragement in more... encouraging ways. It helps mod developers with their motivation to set aside their free time while avoiding (justified) responses like ObsessedWithKSP's and Run1235's. Otherwise, thank you for your interest! - - - Updated - - - Nalfz, Sure, I can find and replace values willy nilly. It takes a little more time to figure out what values to replace them with.

The WIP version is available in a link in blowfish's signature block. Here it is as well: https://bitbucket.org/blowfishpro/b9-aerospace/downloads While the page there says the download is 735 MB, that's the size of the entire repository. When you click the download link, the actual download is around 73 MB. Install by opening the .zip file and copying the contents of /GameData into your KSP folder, minus B9_Aerospace_DEPRECATED. Most everything is working, with a few exceptions. Air brakes might be one of those exceptions. I haven't finished my price-balancing project for career mode yet, either.

I have a bug that has a lot of similarities, but isn't identical. I put Jeb in an external command seat on a space station. After I focused somewhere else, did some time warping too, I came back, and he was stuck in the chair but wasn't sitting in it. In the save file, he isn't a separate vessel. He's considered as part of the station! I can right click on him, and I can turn his RCS on and off, but he can't go anywhere. His EVA-ness is also listed as a part of the space station, but its mid differs from the others parts that are on the station. I'm going to pull snippets from my persistent.sfs as it contains about 200k lines: ... PART { name = kerbalEVA cid = 4290782026 uid = 337871138 mid = 2550075542 launchID = 29 parent = 22 position = -4.82648611068726E-05,2.13600254058838,1.50091171264648 rotation = -2.093764E-05,-0.7071021,-0.7071115,-1.2376E-05 mirror = 1,1,1 symMethod = Radial istg = 0 dstg = 0 sqor = -1 sepI = 0 sidx = -1 attm = 0 srfN = , -1 mass = 0.108808 temp = 202.340237725379 tempExt = 202.372394204076 expt = 0 state = 0 connected = True attached = True flag = Squad/Flags/marathon rTrf = referenceTransform modCost = 108.4533 crew = Jebediah Kerman EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = KerbalEVA isEnabled = True state = Idle (Floating) step = 1.208333 packExt = False lightOn = False flags = 1 ... He is also no longer associated with the external command seat in the .sfs file: ... PART { name = seatExternalCmd cid = 4283717204 uid = 1040512581 mid = 3889663570 launchID = 40 parent = 3 position = -1.25317868082675E-07,2.05902099609375,-1.4409453868866 rotation = 2.38337E-07,0,0,-1 mirror = 1,1,1 symMethod = Radial istg = 0 dstg = 0 sqor = -1 sepI = 0 sidx = -1 attm = 1 sym = 22 srfN = srfAttach, 3 mass = 0.05 temp = 203.379101717382 tempExt = 203.377217173194 expt = 0.5 state = 0 connected = True attached = True flag = Squad/Flags/marathon rTrf = seatExternalCmd modCost = 0 EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = KerbalSeat isEnabled = True EVENTS { BoardSeat { active = True guiActive = False guiIcon = Board guiName = Board category = Board guiActiveUnfocused = True unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { } ... These are both under this vessel in the hierarchy: ... VESSEL { pid = f421d245eb9943e1bbaa5e36ec30c2a0 name = Aleph One type = Station sit = ORBITING landed = False landedAt = splashed = False met = 2692987.71640962 lct = 3223147.12489085 root = 0 lat = -0.0020686399463425 lon = 14.0110517332069 alt = 2871808.35731683 hgt = -1 nrm = 0.9876834,0.004829683,0.1563923 rot = 0.004771356,-0.04372516,-0.001511637,0.9990311 CoM = -0.0003251135,9.324334,0.02644522 stg = 5 prst = False ref = 4210457764 ctrl = True cPch = cHdg = cMod = 0 ORBIT { SMA = 3474083.30259326 ECC = 0.00094608892313072 INC = 0.00278973762619378 LPE = 177.102882003972 LAN = 203.317217672553 MNA = 0.805679382706733 EPH = 5916134.84130047 REF = 1 } PART { name = mk2LanderCabin cid = 4287576876 uid = 4210457764 mid = 3889663570 launchID = 40 ... So Jeb is a part of the station, (and TAC-LS is still feeding him from the station supply), but he has a non-matching 'mid' and 'launchID' from the rest of the parts, and he's in an 'idle' EVA state radially attached to the station. He doesn't seem to mind, of course. This is Jeb we're talking about! But I've got some work for him to do and I need him to get back in the boat. I've tried editing the station, removing the EVA part completely and adding the line "crew = Jebediah Kerman" to one of the other crew parts with a seat free. It didn't work, and the save just plain wouldn't load. I also tried removing the command seats because I thought maybe Jeb was stuck on it. It turned weird, leaving most of the station just gone, though the two or three remaining visible parts (including the Mk2 Lander Can and a solar panel) were still rigid in relation to each other. I suspect that my problem is in how the parts link to each other, and that maybe if one part is referencing the command chairs or the radially attached EVA and it no longer exists when I load the save, it gets confused. But I don't really know. Thoughts? I suppose I could try your patch, Claw, but it seemed like these were possibly different issues and I wanted to be careful.

From my understanding of the heat system, during a physics update, adjacent parts check each other for their relative temperatures, and based on their mutual heat conductivity values, shared surface area, and the magnitude of their temperature difference, the hotter part will "give" a portion of its heat to the cooler part. But because heat isn't the same thing as temperature, larger mass parts store a lot more heat than smaller ones for a given change in temperature, just like it takes more energy to raise a large block of copper 1 K than it takes to raise a small block of copper by 1 K. Unlike real blocks of copper (or some special material which Kerbals make all of their parts from, since most of them have the same heat capacity per unit mass), heat in a part is distributed evenly throughout the part, instantly. So if a small part is next to a large one, and they aren't at the same temperature, the heat system gets confused, and here's how: When the system is deciding how much heat to transfer during a step, like I mentioned above, it calculates a certain amount of heat to transfer. If the parts are similar in thermal mass, this usually isn't an issue, as they'll transfer a certain amount, and then a little less, and a little less, until they come into equilibrium. If the parts are different enough in thermal mass, the system can overshoot in how much heat it transfers during the update. For example, if you have an FLT-800 fuel tank connected to an octagonal strut, and the fuel tank is a few K warmer than the strut, the fuel tank will try to transfer a small portion of the heat that makes up the difference in their temperature. The strut doesn't have much heat capacity because it is so small, so while the FLT-800 cools slightly, the strut's temperature increases a lot more. If the new temperature difference between the parts is smaller than the first difference, it may continue to oscillate back and forth, but it will get smaller and they'll eventually reach an equilibrium. But it is possible for the new difference in temperatures, if the difference in heat capacities is large enough, to be larger than the first one, and then the next update transfers even more heat to correct the first one, and then it transfers even more, with the small part fluctuating wildly at ever increasing amounts, until on the low end it is at 0 K and on the high end it is nuclear fusion. Add multiple parts interacting at the same time, like engines generating heat, solar irradiance, special parts like service and cargo bays which protect their contents from the heat system until they're opened (then the temperature difference can be significant enough to make this runaway oscillation happen very quickly and reproducibly), and Roverdude's radiator module in the stock radiators which conceivably adds to the instability once the high end of the temperature is hot enough (25% of the part's max temperature). The active heat management module from the stock radiators (the deployable ones, not the static radiators) checks all parts in the ship to see if they are above a certain temperature (unless otherwise specified in the part config file, it's 25% of the maximum temperature). If the part is above this temperature, the radiator pulls heat from the hot part and then gets hotter itself, eventually radiating the heat away. But the way the update works, and Roverdude or somebody with enough familiarity with the system can correct me if I'm wrong, the heat system updates the temperatures during a step. Then the radiator checks the parts to see if their temperatures are above a certain value. If so, it actively pulls heat from the too-hot part, but if the part was also giving too much of its heat away to neighboring parts through conductivity, because it didn't have much capacity to begin with, it will cool off too much. During the next update, the radiator sees that the part is no longer too hot, and it doesn't do anything, but the now-cold part will absorb a large amount of heat from its neighbors, becoming even hotter. This oscillation will, again, grow larger until the part exceeds its max temperature and explodes. This is numerical instability. The time step in the game has to be larger than a certain size, because the system gets bogged down with high part counts. Our CPUs, even the high-end ones, already are crying for mercy without making it work even harder to have a better fidelity with what heat transport should do in real life by having a smaller step size. So here's what I propose: create a slight change to the way heat is conducted to adjacent parts. Before the amount of heat to transfer between parts is calculated, have a parameter composed of some tunable factor 's' and the ratio 'R' of the parts' heat capacities 'c1' and 'c2', where c1 > c2 and R = c1/c2. Take your current system that calculates the amount of heat to transfer and simply multiply it by s/R. This effectively reduces the mutual conductivity between large and small parts, allowing what would have previously been oscillating overshoots that grow larger with time (like a resonant driven oscillator) to damp out toward equilibrium instead. It is an added unrealism, but because it is necessary to treat parts as single items with single temperatures (well, two, skin and internal, but you get the idea) to avoid serious computational complexity, we have the unrealism of entire Rockomax Jumbo-64s comparing their temperature differences with attached octagonal struts and alternately dumping and retrieving too much heat in successive physics updates, with small computational errors that quickly become large ones because of the limitations of Euler's method. Another solution is to reduce the stepsize, though this will hurt CPUs which are frequently tapped out as it is. The error in the Euler method is proportional to the square of the step size, implying that if the step size was reduced by about 30%, we could cut the magnitude of errors in half, which could conceivably reduce the number of anomalously exploding parts by much more than 50%, if many of the circumstances which lead to growing oscillating errors were fairly close to borderline and instead are brought far below the threshold for runaway instability.

I'm glad you figured it out! I use FAR, and I spent a good few days trying to figure out why all my spacecraft were oscillating in bizarre ways, until I realized I had turned on FAR's roll-assistance for a spaceplane much earlier. It wasn't so much a bug as the computer remembering what I told it to do, even if I didn't. It sounds like that is the case here as well. And your plane looks awesome, by the way.

ModuleManager: 9179 patches applied But I don't really need to cut back yet. KSP is only using 5.4 GB of memory, and I've got plenty more! I also understand why it takes so long to update the price and temp values: it's REALLY boring. I went through Squad's parts, put together as good of statistical information as I could on various comparisons of price, entry price, tech tier, mass, etc. Fuel tanks are easy, they have a consistent enough price/mass ratio. Structural parts, not so much. I tried to categorize some parts as "general aerodynamics," but that was useless too. Essentially, if on a particular measure, such as cost/(techtier*mass), the standard deviation is small enough compared to the average, then I can fit B9's parts that way. But that requires some selective filtering, as "liquid rocket engines" sound good as a category, but the 0.625m engines are way outside the scaling values of any of the larger engines, and it throws the values off. I can also look at other features of parts (intake air radius and speed, electric charge, deflection coefficients, thrust-to-weight ratio, ISP, etc.) and using some sort of multi-dimensional scaling to those values. Maybe. Doing those kinds of statistical fits is both time consuming and often misleading. There are three types of lies: lies, damned lies, and statistics. And I can't even come up with a good lie/guideline for one-of-a-kind-in-stock parts like the RAPIER which I can use for the SABRE. I'll have to decide how the advantages and disadvantages of the SABRE ought to be weighted in the price. On the plus side, some of the wide variations on Squad's parts gives me latitude to pick a price that sounds reasonable, make sure it falls within a standard deviation of stock's scaling, and move on.

Watching Squad's bugtracker, they still seem to be having trouble reproducing this consistently. Grr. I have stuff blowing up all the time. I also get parts flashing white without the thermal overlay, which until I started digging into this I thought was just a lighting/graphics issue instead of an optical heat deal (like the red of the engines when they've been running two minutes). Small parts adjacent to larger ones with higher thermal multipliers, especially when something is loaded or opened, seem to be the most likely triggers. Suddenly it dumps a bunch of heat into a part it didn't have thermal access to before. The worst is small parts inside a service bay or adjacent/near one. Things have exploded on the launch pad so often, before I even get a chance to press the spacebar, that I've given up on launching the craft. And I NEVER put anything in a service bay which I intend to interact with again, because if I open it, my slightly larger ship turns into two smaller ones. DaMichel's suggestion of numerical instability makes a lot of sense, especially looking at how a part which is thermally isolated by a service bay is suddenly exposed to a sharp temperature differential by opening the service bay (usually the diff in temp with the service bay itself). The thermal system looks at the temperatures of two adjacent parts, what the mutual heat conductivity between them is, and appears to transfer a certain amount of heat over regardless of the heat capacity it's dumping into. And real physics doesn't care about your heat capacity either, but real physics gets to use significantly smaller time steps, which is why we don't explode like Assimilated Bobs from Marathon when we step from an air-conditioned building into the summer heat. Big tank to little stabilizer: "Hey, little guy, I've got a large surface area and just took some solar irradiance, increasing my temperature by 2 K compared to yours. I'll give you 1 K's worth of my heat!" BOOM! I'll be tweaking small parts in the mean time in my own install to have this line: thermalMassModifier = 5 Edit: This points to a relatively simple fix, though I don't know how much comparative overhead this would be, but before shuffling a quantity of joules from one part to the adjacent one, use some scale of the ratio of heat capacities of adjacent parts for conduction, and pre-emptively use that scale to gimp the amount of heat transferred. It would still scale up with temperature difference, of course, but if the thermal system is going to use a monolithic *temperature* for a Rockomax Jumbo Tank, then the system ought to scale back when the capacity differential between adjacent parts is so large. Conductivity is already supposed to take care of part of this, but the fact that a battery or an OKTO2 has such a small thickness and is then placed next to a large part that *isn't* treated as small pieces of sequential thermal mass, combined with the infeasibility of dynamically changing the step-size per unit-time, leaves us with a lot of exploding things that ought not to explode.

I'm going through Squad's parts. It's going to be fun using them as guidelines when they're totally self-inconsistent and schizophrenic. Did Squad have guidelines? Why does this tank have a crash tolerance of kleenex while this other one can survive the apocalypse? Why are porkjet's parts nearly perfect radiators (which can also survive 50 m/s crashes)? Why are so many airplane wings able to handle temperatures up to 2500 K or more, way past the melting point of steel, but the basic fin explodes at aluminum's meltpoint? Sometimes they want to be sensible or realistic, and sometimes they're like, "This is goofy green men and I'm designing this to be fun!" It depends who is on shift that day. I'll see if I can identify, for different categories (pods vs structural vs engines vs reaction wheels, etc.), scaling relationships with mass, tech level, and so on. But as it looks from here, I could pick numbers via Magic 8-Ball and it would make as much sense. Edit: Here's my spreadsheet in progress: https://docs.google.com/spreadsheets/d/1PBo_8ZKvkzaozKsQ3Gw3AT_XKDBsXF6ANr6iyMzRyuc/edit?usp=sharing

I don't see a list of completed / to-do items in the bitbucket stuff. Have some of the parts already been done, or can I just start at the top of the parts list and work my way down? - - - Updated - - - And THIS, sir, is supremely rude. I'm glad you love this mod. I love it too. Bac9, K3|Chris, and Taverius (with some other talented contributors too) made something awesome, and Blowfish has stepped up to the plate, taking the lead, and spending his free time to work on making it up-to-date. And every once in a while, some bystanding non-contributor steps up to voice their opinion that some stranger they never met, who owes them nothing, is going too slow. Contribute, or voice your thanks for the effort that somebody else is doing to bring awesomeness back into your life. But expressing your eagerness like this reminds me too much of my young children when they need a nap.