diomedea

All excellent suggestions. That's really great help to make things right . Have those substances marked, will follow with more research about their properties. Of course N2, O2, Argon are already known (being major components with Earth's atmosphere) and I believe both N2 and Argon really fit with Eve too, molar mass makes them right. He2, H2 are really too light, indeed they may be at the atmosphere top, altitude too high to be considered for weather effects and therefore without a significant role for KWS (but certainly of interest should Eve's ionosphere be studied).

Well, some good thinking and this is exactly what I needed. Must say I never considered the purple tint to come from specific spectral lines, seems a valid alternative. Indeed a reason why I had already considered I2 was its colour. You correctly mentioned it requires some concentration, I believe a few meters of almost pure gaseous I2 are more than enough to give that shade, and even if the remaining atmosphere was colourless, it would diffuse the same colour. Can't however tell what paints purple the ground, iodine would have a strong role making solid compounds but none I found has the right colour: therefore Eve would appear clearly purple where I2 pools (just over the seas probably made of liquid Iodine), but in different colour above the I2 layer. True that good data is scarce, some of the atoms you suggested are certainly good candidates themselves, have to find compounds still showing the correct colour and credible to make Eve's soil. Indeed the multi-layered atmosphere is currently my best bet, it should add some complication to the model but nothing too hard (just one more layer with very specific characteristics, but also clearly separate from both light gas above and liquid/soil below. What is still missing about Eve, in terms of weather model, is the "regulator" stabilizing its atmosphere (above the bottom layer), but isn't definitely clear if any should exist.

Thanks guys. I actually considered both iodine and mercury, but because of molar mass they can't be major atmosphere constituents (mercury (Hg) 200.59, iodine (I2) 253.8 g/mol). Eve's atmosphere mix averages 43 g/mol, any gas 500% heavier than the average should only fill the deepest layers, can't see why it would lift and stay mixed with lighter components. Of all the gas components in Earth's atmosphere (apart minor traces of He), all are within 55-152% of the average molar mass. Clearly those heavyweights have to be a small percentage, or other even lighter components would make their part to bring the average molar mass; therefore the difference between heavy and light components would be even more marked. I can consider Eve to have a layered atmosphere, but then would certainly enjoy some help to devise its characteristics, there would be neat boundaries from one to another layer (not to talk about densities, all of the aerodynamic properties in KSP would seem wrong). E.g., I did venture to consider an atmospheric mix for Eve with I2 at small concentrations: but then the I2 layer would only reach a few tens of meters above sea level (using the correct ScaleHeight for pressure on Eve, 35 mt of I2 would account for 1% of the total pressure). Above that level aerodynamic properties may not be really affected, but I2 would not really affect the atmosphere dynamics too, can only guess at heat exchanges through the layer boundary I2/lighter gas.

Thanks about the initial dewpoint. Of course Kerbin and Laythe, having the same atmospheric mix of Earth, are easier to consider, and with them I'm actually only concerned about water dew. And given their resemblance with Earth's atmosphere, I'm actually using values valid for Earth (such as those for the Magnus formula in dew point calculations, but also Antoine's and Wagner's equations). The other bodies are still a big unknown (must say I've started to consider some plausible mix of gases for them, but the matter requires more research). Eve certainly has liquid on its surface, therefore a mass going through evaporation and dew. Unfortunately I could not yet find what that would be, to stay liquid at 5bar and 360-420°K. However the temperature changes enormously with altitude, I could imagine even water being present (only, water rain would never fall to the surface before evaporating again). Any thought about Eve will be of immense help. Don't think initial dewpoint requires a thought for other stock bodies. Duna only seems affected by sublimation/deposition of CO2, so my effort goes only towards computing the amount changing state and the heat exchanged. Jool seems to only have very light substances, unable to condense in its atmosphere.

Certainly someone with your qualification would be very welcome, should you have time to spend on KWS. About precalculated data. Most of data with each cell are variables, and will have to be refreshed at each update cycle. The initial temperature at each cell and layer's altitude would be made to resemble the current data in KSP (I'm confident they can actually be fetched from KSP, otherwise they should be computed from the same set of values KSP uses at runtime), but then will follow the dynamic from KWS. Initial pressure will be the set base pressure in KSP for altitude=0, but the pressure variance with altitude changes with temperature, so it will be computed for any altitude != 0; and clearly also the base pressure will then dynamically change in KWS. Humidity isn't covered in KSP, my intent is to start with some "credible" values following a simple equation (based on biome and temperature). Of course KWS then will update. Those above are enough to compute any further values, e.g. air density, cloud coverage, reflectivity and absorption. Clouds reflectivity and absorption are probably the best area where values should be precalculated. The math required to compute those values depends on a few variables (amount of water vapor, effective droplets size and cloud thickness; other conditions are averaged for the spectrum of incident light and reflected IR, or the scatter angles, and then assumed constant). However the development of that math would take a significant portion of all the exectuion time in KWS, so the best approach is to use a set of precomputed tables. Silverfox and me both hope to find other areas where values may be precalculated, that will certainly help mightly with KWS performance. When the weather model is finished, I hope to use it to find specific relationships from one or few values and the outcomes. That could come both as a simplification in the internal math used, or as discovery of significant "patterns" (cause-effect relationships in the weather across the modelled body, like e.g. the formation of a specific pressure field in an area associated with presence of humid/warm air, will develop in 80% of cases in a thunderstorm after 6 hours). Though I have yet to consider how KWS could be programmed to deal with those "patterns".

Well, thanks. Any suggestion about practical ways to tame the complexity of the matter is welcome. In the specific case, this covers just one aspect of a very complex field of study. But the specific solution it describes (calculating pressure differentials in a range of cells to generate a velocity field) is correct, and actually already in the weather model to produce wind. The model is actually based on a small subset of the equations and concepts valid for fluid dynamics, e.g. Pressure-gradient force, advection, divergence, Navier-stokes, viscosity, vorticity (sorry for the amount of math, I spent days on that to arrive to something usable).

Pressure gradient and therefore wind is computed separately for each cell (actually, same goes with alll other weather values). With smaller cells, factors influencing pressure are more localized, and the resulting winds too. Sure I expect large areas of cells with a relatively constant pressure gradient, and therefore wind. But often the barometric field will be uneven, and result in local winds (affecting only a small area, and changing in force/direction, therefore moving air in a very different way). Let me consider with large cells, if the conditions exist for a cyclonic low pressure. In the optimal case, it would appear in the center of one cell, so all surrounding cells would show a strong pressure gradient and winds flowing around the central cell (however, changes in windspeed would be averaged for the larger distance). In the worst case, the low is placed at the point where 3 cells meet: each cell than has the same average pressure, and no pressure gradient, no wind: at that scale, it would appear like the cyclone completely disappeared. That would make for fine weather even when it shouldn't be, but if players want fine weather, they don't need KWS. Another thing I hope to see, the jet streams occurring at the top of the boundary of air masses with marked thermal differences: if Earth has intense jet streams a few hundred Km wide, the different scale of Kerbin would make me expect to see them a few tens Km. The streams would be wide as the cells, but also average for the cell size, therefore appear less intense if the cells are too wide.

That's a question worth asking. Indeed is so important, it is considered also in the development of the weather model. Actually, there isn't any answer yet. It would require to test the model in KWS, and conduct some good amount of testing, to see how accurate it is. How much values drifts from what is expected, if stability ensues and how long it takes. Accuracy isn't only about the size of cells actually, is about the time between updates. We need to find the nice spots where accuracy and performance are both achieved. One value that shows this problem of accuracy is horizontal windspeed. Windspeed is the value that allows an equilibrium among the forces acting on air (pressure gradient, coriolis, friction). Pressure gradient requires to compute the average pressure (at each specific reference altitude) in a range of cells, and divide by the distance among cells (the actual mechanic considers all surrounding cells). With larger cells, pressure would have to be the average of a larger area, and that smoothes highs and lows; and dividing for a greater distance, the resulting gradient pressure force would often be too low. Of course wind has major effects on other weather aspects, like the relative movement of air masses, driving to weather fronts and all associated phenomena, but also about the amount of evaporation and convection. With some values, the lack of accuracy could be "adjusted" tuning the model. Windspeed however isn't that simple: if a "tuning" factor was used to bring windspeed to its expected value, with a large cell that would mean hugely more air moving than would naturally occur, and for larger distances. I'd expect than to see humid air over deserts, warm air over the poles (with imaginable consequences). Unfortunately, using large cells for "general weather" could then make the values totally unfit. Isn't like the found values would be known with some lesser accuracy (say, like +/- 1% of the true values) and then some "refinement" process could allow to improve them (e.g. to +/- 0.1%): the found values would bring to a completely different situation instead.

Can't really see the need to make two separate landers. Apart the intrinsic difficulty to land both in the same spot, the small difference in payload would be totally outweighted by the mass of additional required parts (at least a probe core, battery, possibly some solar panel, landing legs, plus propulsion for the science parts lander). Given that some parts are not required to be lifted in orbit again (landing legs, spent tanks...) I generally have such landers detach the unneeded parts at take off. All science parts can stay landed, so they are connected to the detached stage.

Scusa, dove ti risulta che ci sia l'update 1.1? Al momento l'ultima versione rilasciata di KSP è la 1.0.4 (build 861), che mi dicono sia quella ora distribuita anche da GOG. Per la 1.1 occorre avere pazienza, Squad sta lavorandoci sopra e non è ancora nemmeno in fase di test. Se qualche sito "non ufficiale" afferma di avere la 1.1, diffidate perchè con ogni probabilitàsi tratta di malware.

At this stage isn't yet clear what your persistent.sfs trouble is (the savegame, unfortunately the only file as no quicksave exists). Can see the output_log showing a stream of NRE (NullReferenceException), that is certainly a bad sign and points to some issue with parachutes, but would better check what the savegame has that would spring those NREs. Also, about the original query about the incompatibility with the 1.0.4(861) build version of KSP. If (as I understand from the OP) that game was started with the same version, the incompatibility could easily mean KSP can't understand what is in that file (at least in part). If KSP happened to be saving to that file just when the power went off, that file could now hold all kind of garbage (sorry to say, but that's reality with computers). While hopefully examining that savegame could show some easy-to-fix mess, it may also be impossible to recover, or simply too cumbersome to rebuild.

Honestly, doesn't seem an issue tied to KSP, but to hardware/OS. Those symptoms are similar to what would happen if a stream of Alt-Tab was sent from Keyb (or any input device configured in a similar way), but the same would show should the task switcher hang (something I've noticed, other buggy software active on the system can cause this). Also, Windows has "features" like permanent keypresses that always get in the way (activate automatically at the worst of times) and could have a role in this. Anyway, seems clear the actual left mousedown action (the left click) isn't passed to KSP and therefore isn't processed by the game. It is "consumed" at the OS level that responds switching focus in and out repeatedly. Can't tell what caused the OS to behave like that, but my advice is to 1) verify system settings, could be some "feature" is enabled; also, check how the system performs with a mousebutton test; 2) disable peripherals you don't need (should those be shooting events at the OS); 3) stop/close all unnecessary background programs/services (and don't let the unneeded ones to automatically restart until you can be sure they have no effect).

Have you checked SoundTrack Editor? Believe that plugin already does or is planned to include all the features you long for, and best would be if you could work along its author. Also note it already has a collection of pieces available.

Hi scarps, had to move this thread to Support, as your question belongs here. But will probably have to be moved again in case you answer positively to this question: Do you have Add-ons installed? That question could be crucial, as Add-ons can easily change where any part shows in the TechTree. So, knowing which ones you have can easily provide the solution. In case however there are no add-ons involved, it would be better to have your output_log.txt or player.log file. Should you need details, you'll find everything in this thread, where also better instructions are given about reporting issues. Those files show what happened since KSP started, including the loading of any parts. As one possibility if that KSP didn't load those parts at all, something would show (or not) there. Then, you could also access the ingame debug menu (Mod-F12), go to the DataBase tab, Configs, and scroll to find "Squad/Utility/parachuteMk2-R/parachuteMk-2R/parachuteRadial" and "Squad/Parts/Utility/ServiceBay/ServiceBay_125/ServiceBay_125", if they were loaded should be found in the list. Anyway, it is also known rarely KSP can glitch and not load something, but starting up again fixes those temporary issues.

After you run KSP MA, having identified a KSP folder, you should find a "KSPModAdmin_aOS.cfg" file in that root folder where all info about your installed add-ons is stored. I know from messing with install directories, that KSP MA is very tolerant about add-ons listed in that file and not found in the actual gamedata subfolder, but sure would be better to replicate exactly what you also had in gamedata when transferring to another computer.

Welcome Euclide/Andrea. You're studying physics? And like KSP? Sure enough this community is the right place to be then. Oh, while your english doesn't seem too bad, and can only improve the more time you spend with the community, please know there are forum sections for national languages and you'll be welcome should you show there.

About atmosphere heights. Atmosphere height is a practical limit for where atmospheric density gets low enough to not have effects for our purposes. But really depends on what we are interested in, e.g. in case the purpose is to study particles interaction with the Solar wind (at the limits of magnetosphere), the densities are a lot less than what is considered affecting drag and spaceflight. Density is function of Pressure P, Temperature T, and Molar mass M: ÃÂ(z) = P(z) * M / (R * T(z)), where R is the universal gas constant, of course both P and T change with altitude z. The variance of Pressure with altitude is commonly represented with Scale height H. Now, H(z) = Kb * T(z) / ( M/Na * g(z)), where Kb is Boltzmann constant, Na = R/Kb the Avogadro constant. It is clear then Scale height depends from the Temperature profile with altitude, varies (but very slowly) due to gravity change with altitude, and is tied to Molar mass of the atmosphere. Now, computing the Scale height and comparing with values in KSP shows what this atmosphere height issue is really about. Kerbin atmosphere has a Molar mass = 28.9644 g/mol. Its temperature averaged for altitude is = 233.22°K. The true value for H (averaged from ground to 70Km) is then = 6829m. Known that p(z) = P(0)exp(-z/H), P(70km) = 3.58 Pa and ÃÂ(70Km) = 6.57E-5 Kg/m3, a density value still too high to be dismissed when considering drag. To alleviate that, KSP was designed so that atmospheres don't really scale with H, but with a differnt scale height. In the case of Kerbin, the correct data for pressure correspond to a scale height (averaged with altitude) = 5463m, 20% less than the "natural" value. The resulting ÃÂ(70Km) is then = 5.06E-6 Kg/m3 (7.7% of the non-corrected value), considered low enough for practical purposes. But if H was uncorrected, the same density would be found at atmosphere height z= 87500m. Other bodies in KSP are more extreme in the "correction" applied. Laythe has same M as Kerbin = 28.9644 g/mol, an averaged T = 214.42°K, g(0)=7.85m/s2 and P(0)=60795 Pa. The resulting H (averaged) = 7843m would make ÃÂ(50Km) = 1.69E-3 Kg/m3, a lot higher than acceptable. The "corrected" values in KSP are in accordance with H (averaged)=3250m, 58.5% lower than the natural number. Conversely, the atmosphere height with the "natural" H would be = 120.5Km instead of 50Km. Jool has M = 2.8 g/mol, averaged T = 200°K, g(0)= 7.85m/s2, P(0)=1519880 Pa. The resulting "natural" H = 75680m; in KSP the atmosphere is modelled in accordance to a corrected H = 29858m, 60.5% lower. With the "natural" H, the atmosphere limit would be = 507Km, for the same pressure and density found just lower of the limit in KSP (200Km). Duna exhibits a Molar mass = 14g/mol, averaged T = 173.02°K, g(0)= 2.94 m/s2 and P(0)= 20265 Pa. The natural H (averaged) = 34952m, would make for ÃÂ(50Km) = 0.05 Kg/m3. The corrected values in KSP are in accordance with H(averaged)=2750m, 92.13% lower! Here the atmosphere height for the same density limit would be = 635,5Km. Eve M=43 g/mol, averaged T = 233.33°K, g(0)=16.7m/s2, P(0)= 506,625 Pa. Natural (averaged) H = 2701.6m, would result in ÃÂ(90Km) = 3.57E-14 Kg/m3, a lot lower than in KSP. KSP has a pressure profile compatible with a H (averaged) = 4363m, 61.5% larger than the natural. With the natural H, atmosphere limit would be = 55730m. So, to keep those atmospheric properties we know from KSP (in particular density and atmosphere height), there is need to bend the laws of physics in KWS.

Premetto intanto che non posso parlare per esperienza diretta, in quanto il sistema che uso per KSP non è configurato per entrambi gli OS, quindi niente confronti sperimentali. Inoltre, mi scuso anticipatamente coi puristi se dovessero riscontrare inesattezze in quanto segue. Sicuramente ogni OS 64bit è in grado di indirizzare 18 exabytes= 18*10^18 bytes, il limite è relativo alle applicazioni, l'OS gestisce la memoria (virtuale) per loro rendendo disponibile solo quanto le applicazioni possono indirizzare, quindi 4 GB nel caso di programmi a 32 bit. Quindi KSP compilato per girare in ambiente 64bit (su Linux) può utilizzare tutta la memoria (virtuale) che l'OS consente. Circa le prestazioni, occorre però chiarire che la memoria può essere individuata in dispositivi anche molto differenti, comunque mi limito a considerare il caso classico di RAM e Memoria di massa. L'OS riceve richieste di allocazione di memoria da parte di tutte le applicazioni e servizi attivi, e distribuisce la preziosa RAM in base alla priorità. Avere altre applicazioni attive, in particolare se in alta priorità, inevitabilmente causeràl'allocazione di spazio sulla Memoria di massa ritardando le operazioni. Quindi anche KSP potrebbe essere rallentato se altre applicazioni risultano prioritarie. Dato che la CPU può solo utilizzare direttamente RAM, è necessario ricaricare le pagine necessarie dalla Memoria di massa prima di proseguire con le operazioni, se l'applicazione era stata messa a prioritàinferiore. E naturalmente ritravasarle dalla RAM se nuovamente l'OS dovesse dare prioritàad altre applicazioni. In pratica, le applicazioni 64bit non vanno in crash per mancanza di memoria (Access Violation), a meno che si saturi anche la Memoria di massa, ma possono essere rallentate per carenza di RAM. Aumentare la RAM aiuta molto; se proprio non si può avere sufficiente RAM per tutto, potrebbe convenire usare una Memoria di massa molto veloce almeno per velocizzare i travasi. Ovviamente gli SSD sono molto più prestanti degli HDD, ma se utilizzati come unitàdi swap si rovinano anche in fretta. L'altro importante fattore circa la RAM sono quindi le altre applicazioni e servizi attivi. In questo, Linux è molto più parsimonioso di Windows, le sue applicazioni di sistema richiedono meno risorse. Mentre invece Windows pare "compiacersi" nell'aprire ogni genere di servizio in background, all'insaputa dell'utente, servizi che spesso sono configurati in automatico per usare alta priorità(quindi RAM) non appena un evento lo richieda. E purtroppo anche diversi software che girano sotto Windows usano lo stesso concetto. Quindi, Windows richiede una configurazione "ad hoc" per poter far funzionare i nostri programmi al meglio, con prestazioni adeguate; Linux consente all'utente maggiore controllo e (a meno che sia l'utente stesso a voler aprire troppe cose insieme) risultando in tempi di processazione migliori. Dato che KSP comunque usa un unico thread (che sia per Windows o Linux non fa differenza, è il runtime di Unity 4.6 che non consente altrimenti), non ci sono differenze circa l'utilizzo della CPU. E pertanto non occorre nemmeno (per ora) esaminare come i due OS gestiscono il multithreading ed il bilanciamento su processori multipli. Saràda vedere con Unity5 l'effettivo livello di simultaneitàottenibile in KSP. Discorso a parte (ma sicuramente importante) quello relativo al frame rate. Che dipende in sostanza dalla velocitàcon cui la CPU riesce ad alimentare la GPU, e quindi dalla velocitàdella GPU nel realizzare i "frame" richiesti. Qui torna il discorso circa l'occupazione da parte di altre applicazioni e servizi, se si spartiscono gli stessi processori su cui gira il thread di KSP. Ma se sia CPU che GPU sono le stesse per un dato computer, ciò che può cambiare sono le interfacce grafiche. Linux opera con OpenGL; Windows usa di default DirectX, ma può anche passare a OpenGL. In questo, alcuni riportano che OpenGL sia lievemente più lento di DirectX. Nella mia esperienza, non ho trovato alcuna differenza apprezzabile di velocità. Ed anche come qualità, OpenGL è ormai alla pari. Comunque potrebbero essere riscontrati alcuni difetti grafici in particolari condizioni, causa differenza di implementazione delle librerie, su alcune famiglie di GPU (legate agli specifici driver delle case). Conclusione: senz'altro niente più crash per mancanza di memoria, minori rallentamenti nell'esecuzione, che potrebbero anche avere effetto sul framerate. Con forse minori problemi grafici in determinate condizioni.

Eh, this note from Symantec shows how that works. In short, somebody reported that file in the Symantec detection system. Of course (as confirmed by any other antivirus around), that file presents no security risk. More than possible that report to Symantec was done by one or more of the usual FAR haters, and has absolutely no validity. You may try to force your antivirus to accept that file, maybe temporarily disabling that "feature".

If you have (as I 'd expect) KSP 1.0.x, NEAR is no more a n option, was cancelled by the author. If you are really a new player, my advice is to get used to the stock aerodynamics first. The new aerodynamic model in stock KSP 1.0.x is a lot more complex, compelling, accurate (and still as fun) than it was up to KSP 0.90. If however (for some weird reason) you are sticking with a KSP version prior to 1.0.x, steer away from the stock aerodynamic model as soon as you can: it was built on some weird assumption and had lured a lot players into believing in magic lift, fantastic stability, no adverse drag (and thermal) effects. FAR is more complex than stock aerodynamics, and learning to build and fly crafts correctly can be very compelling, however is very satisfying when that "skill" is achieved.

Beh, permettetemi qualche chiarimento. Attualmente, dato che Squad non supporta x64 per Windows (a causa di tanti bug non individuabili e quindi non risolvibili nell'ambiente di sviluppo usato, che fino alla KSP 1.0 è Unity 4.6.1 a 32 bit), per utilizzare KSP in versione Win x64 occorre usare il "community trick" (in pratica, sostituendo alcuni files, tra cui KSP.exe, con quelli distribuiti da Unity, ovviamente da rinominare). Il "trick" non ha alcuna certificazione ufficiale, non è stato testato in ambiente controllato, appare funzionare su alcune configurazioni ma non esiste alcuna garanzia. E men che meno, gli add-ons non sono testati per funzionare con tale "versione", quindi eventali (probabili) bug non sarebbero necessariamente affrontati. Una nota in particolare: ci sono bug, specifici su Win x64, sicuramente ancora esistenti nelle ultime build ufficiali di KSP 64bit. Dato che il codice relativo non è cambiato, sarebbe quantomeno sorprendente se sparissero solo per aver usato il "trick". Ma tali bug si notano solo in modalitàspecifiche: il più serio si ha solo in modalitàcarriera, è facile che passi inosservato. Circa la versione 1.1, che dovrebbe essere riproposta anche in versione Win x64 (grazie al nuovo editor 64-bit di Unity5), per ora è presto per poter indicare quando arriveràe quali bug possano esserci (purtroppo qualcuno scappa sempre). Dato che i test devono ancora iniziare, e le ultime versioni hanno richiesto (+/-) 3 mesi complessivi di test per la 0.90, 5 mesi per la 1.0, sarebbe almeno sorprendente se i test con la prima versione nel nuovo ambiente a 64bit (ancora tutto da vedere) possano richiedere di meno. Date queste premesse, se esiste la possibilitàdi installare anche Linux, ritengo sarebbe al momento la soluzione migliore. Anche Linux ha le sue specifiche fisime, ed ogni tanto saltano fuori bug noiosissimi solo in quell'ambiente. Ma quanto a prestazioni, sicuramente per ora è l'ambiente dove KSP gira al meglio.

I am certainly not one who posts a lot, still reading one of my few posts may not be clear enough what I intended. Language still may be a barrier when the first language is not english, and not only for me while writing, but for others in the community. That is why, since joining the moderation team, I adopted the rule (shown in my sig) to mark what I specifically made as a moderator. But, that is a rule for myself, not a general rule every and all of the moderators are bound to. And sometimes I even forget to apply it. In my view however it helps make clear what needed to be moderated (and generally I show why). No rule exists nor is in general considered necessary about marking moderator actions in any special way. Most of the time those actions are so clear by themselves to not require further explanation. But in case, each one of us is free to choose the way he sees best. While I'm convinced of my system as fitting, others do not, and remain free to do as they like: going on with requesting them to change is not much different than from me to require any member to be posting as I'd like, instead as they would. Oh, perhaps that could require me to take action (eh, not to show other moderators what I do as an example, already did).

Good info for moving this thread where it belongs and add the proper prefix

In realtà, Scott lavora per Apple (sul serio) ed ha accesso a configurazioni non ancora disponibili al pubblico. Non meraviglia quindi che abbia più potenza per far girare al meglio KSP. Nè dovrebbe meravigliare che sappia usare al meglio il computer con KSP, di certo conosce meglio di altri come ottimizzarne le prestazioni.

Ah, there is where that "lookupRadius" value is from (could not find it in the original "ExtraTubes" config, of course). Well, can see all those additional entries were made to replicate the behaviour of the ServiceBays in stock. If you check the two stock ServiceBays (1.25 and 2.50 m, under "GameData/Squad/Parts/Utility/ServiceBay/..."), "lookupRadius" is respectively set to 0.9 and 1.8, bulkheadProfiles = size1 and size2 (all other values same as MeCripp entries, but for maxTemp = 2900). The above tells me proper values for a 3.75m serviceBay, or the extraTubes that are very similar parts, would be "lookupRadius = 2.7" and "bulkheadProfiles = size3". Can't see other changes required.