Merill

Engine cooler update v1.1: Rewriting all systems used by this mod (heating, ablating, black body radiation) as the stock system stop working sometimes. Now it's custom made, it do exactly what i expect. Now radiative cooling is usable with throttling, with all rocket configuration (even if it's a bit unrealistic sometimes) Ablative cooling work smoother, reliably and use all ablator before exploding. it's backward compatible, using a new module. Ps: someone know why (for my two kerbal stuff mod) people download mostly the second revision instead of the last one?

On ssd. I tried on a flash usb3 stick but the loading time made me cry. You can upgrade your storage. A laptop it's easy. a screwdriver is enough. An old zenbook with a special connector is more tricky, but it's manageable. A tablet with soldered flash, that's a "can't upgrade" hardware.

Ohh It seem to be a useful mod (so much better syntax than stock). I wish this existed months ago.. I have a feature request: - to be able to define multiple tree (with unique id) and be able to assign one (other than the default) at a savegame (via a ScenarioModule field, for example) Use-case: to create scenario with dedicated small tech tree, in the same game installation than normal games (i don"t want to force people to clone their ksp for each scenario i make). (When/if i have time, i may look into it to add this feature, it shouldn't be too hard)

you can check this add-on, to see how it's done: https://github.com/StupidChris/KSPX/tree/master/Output/GameData

Perfect! thanks

Hi i'm using the GameStates.TotalUpgradePoints before to add upgrades points. (inside a PartModule & a ContractConfigurator Behaviour) I need to use MiscellaneousTempUpgrades instead? i can't find a field for this inside the new savefile. (sad)

"the pull of gravity on that object increases/decreases" => no it doesn't. If your mass is /2, Force(g) is /2 => they work against each other so : same acceleration. To change your orbit, you need to change the mass of Kerbin. My assumption was that you added the "persistent" flag to counteract this effect => persistent is true by default => already existing vessel didn't upgrade by magic. If you want to create a "software update", you may want to change this parameter to false. @Aknar : I whsh you great success with your tech tree mod. Don't forget the game designer mantra: Follow The Fun! My tech tree is already done. I think every player has his own vision of the "best" tech tree, anyway.

Hi For the "bulkheadProfiles" of your 1.875 part, FilterExtension use "size1p5" (cf Kerbas_ad_astra cross-sections community effort) Without FilterExtension, it show a well-placed (?) with FilterExtension, it show a good icon. Just pointing it out, in case of.

Quick answer: no, ( i don"t understand what you mean by 'compensate'). Long answer: Orbits are "on rails" when your make researchs. Vessels are not loaded, and their new position is computed when you load it or need it. And the only way i see to have a research done when you're flying a craft is to use KCT. (ps: i play with KCT, it's compatible with my mods) And even, you need to "launch" mass to gain DV to change your orbit (ie a running engine). Modifying the mass of a free-falling object do nothing. (http://www.physicsclassroom.com/mmedia/newtlaws/efff.cfm) And even, (unless you set the flag) the flying part should retain their initial mass (and other properties they have at launch). ps: i don't understand "I was just curious if that was why". I'm sorry, my English level is not excellent.

Eva are not already unlocked via a building upgrade? And the pods sas level is upgraded via the experience of the pilot.

You should test with albany's add-on, as i removed the "basic example" from the zip. I add some links in the first post to the mods using it (or my extremely crude example). Maybe. I created all these plug-in (and a lot more) to create a career mod. Maybe i can push an early beta release in few weeks. Anyway, you make me think of an other way to upgrade parts: just replace them: New release of PartUpgrader (v0.5) - new ModuleUpgradeCategory, useful to change the category to none for hiding the part from the partList (works even with FilterExtensions). Release of ObsoleteParts It's basically ModuleUpgradeCategory but simpler. To define when a part is obsolete, it's the same for defining the research tech: PART { [...] TechResearch = start TechObsolete = electrics [...] }

@albany : nice! (ps: the licence is not mit, i've updated the first post to be clearier) Released an other update: beta_v0.4 - add ModuleUpgradeModuleSetField, to have a simplier and prettier way to update a module if we only have a little field to change. But i discover it's a very rare things, as modules are messing themselves in plenty of ways with their fields. ModuleUpgradeModule is much more useful. - add a warning log if ParUpgrade discover that the version running is not the last one placed inside GameData.

I've published a new release (betav0.3). You can now publish it with your mod, just put it in the GameData folder and not in an inner one (to ensure the last version will be run in case of conflicts). I add ModuleUpgradeDescription. I should be safe, as the description is only sed in the vab. I add ModuleUpgradeReflexion to modify simple fields inside Part (like crashTolerance) I corrected the how to for the ModuleUpgradeTitle (i made an error when i write it). I'm still working on it. if you need something else, feel free to ask.

Hi I've add some ground stations to my RT install. They work great. STATION { Guid = 514242a9-d628-41c6-ad4b-21154e8fc442 Name = Karabole 2 Latitude = -0.131331503391266 Longitude = 106 Height = 75 Body = 1 MarkColor = 0.996078,0,0.5,1 Antennas { ANTENNA { Omni = 1E+16 } } } But the antenna range isn't set. The only way i've found is to modify the MissionControlAntenna omni field (and recompile). They're something i'm doing wrong? thanks

Hi (sorry for the last answer, return from holidays) Right now, it's nowhere near a release state, so i didn't add a version-check thing like modulemanger, but i may consider adding it. For the title thing, i tried it but it's a more complicated thing: The name of a part is shared by all parts, even these created before the upgrade (it's the same for cost, but it's less problematic). If you want to try : MODULE { name = ModuleUpgradeTitle TECH-VALUE { tech = new title tech2 = new title 2 } } MODULE { name = ModuleUpgradeTitle newTitle = new title addSuffix = . add at the end tech = heavyRocketry } To change the description it's the same thing: it's not easy.