[Beta] Merill's plugins [PartUpgrade, ObsoleteParts, EngineCooler, NoseConeWithTank]

[Merill]

This post is made for gathering feedback for my plugins in beta state, before a proper release. I made them for an other ksp project, but I think it may be useful for someone else.

All plugins are made & released for ksp 1.0.4

PartUpgrade:

This mod is about unlocking upgrades of existing parts when researching tech nodes.

It's a collection of PartModule to add to a part to create these upgrades options.

Needed: feedback and request about useful UpgradeModule I should make.

donwload demo with upgrades for LV-T15 and T100 in stock tech tree: DOWNLOAD

When use it, please copy it in the GameData folder, to be sure the last version is run (not in a sub-folder)

Javascript is disabled. View full album

Used in : Tech-Based Probe SAS Upgrades

Basic Example: basic POC config for lvt-30

code: https://github.com/supermerill/KspPartUpgrade

This plugin can upgrade a part with these modules (advice: use ModuleManager):

note: most modules save their internal data when in flight, to not be upgraded (as you can't magically upgrade a part already build and flying around the mun). But if you encounter some weird behavior with this, you can disable it by adding the field "persitance = false" in the ModuleUpgradeXXX

//module to change the category of the part in the vab
//if none, it will be inaccessible ( it's a way for updating parts, cf ObsoleteParts)
MODULE
{
name = ModuleUpgradeCategory
TECH-VALUE
{
// move this part to Control category when generalRocketry is researched
generalRocketry = Control
// remove this part from building list when heavyRocketry is researched
heavyRocketry = none
}
}

//module to upgrade the mass
//if multiple tech in the list have been researched, the only one used is the last in this list.
// when a vessel load, this module restore his last mass (because it shouldn't upgrade)
MODULE
{
name = ModuleUpgradeMass

//if you have problems with data persistance, you can set this field to false, to make part in flight magically upgrades when you research a new tech.
//persitance = true //default true

//list of techName / value to set
TECH-VALUE
{
generalRocketry = 1.5
advRocketry = 1.25
heavyRocketry = 1
}
// example: if generalRocketry and heavyRocketry are researched, The lv-t15 mass value will be the one of heavyRocketry because it's below in the list.
}

warning: it's a game-wide modification: it will impact the recovery fund from already launched ship.

MODULE
{
name = ModuleUpgradeCost
TECH-VALUE
{
generalRocketry = 1000
advRocketry = 900
heavyRocketry = 800
}
}

warning: it's a game-wide modification: it will impact also all launch ship (when right-click on a part).

MODULE
{
name = ModuleUpgradeTitle
TECH-VALUE
{
generalRocketry = Ar-200
advRocketry = Ar-210 college new +
}
}

warning: it's a game-wide modification. But as it can only be seen inside the VAB, it's not a big deal.

MODULE
{
name = ModuleUpgradeDescription
TECH-VALUE
{
generalRocketry = It's a good part
advRocketry = It's an amazing part
}
}

It can update all simple fields (string, int, float) inside a Part. It can be used instead of ModuleUpgradeMaxTemp.

It cannot be used for complex type like ModuleUpgradeAttachRules do.

MODULE
{
name = ModuleUpgradeSetField
fieldName = crashTolerance
TECH-VALUE
{
rcsMedium = 50
rcsBig = 100
}
}

//same as the mass, but change the max temp value
MODULE
{
name = ModuleUpgradeMaxTemp
TECH-VALUE
{
generalRocketry = 1200
advRocketry = 1500
heavyRocketry = 2000
}
}

//module to upgrade the attach rules
MODULE
{
name = ModuleUpgradeAttachRules
TECH-VALUE
{
generalRocketry = 1,1,1,1,0
}
}

MODULE
{
name = ModuleUpgradeResource
resourceName = LiquidFuel
TECH-VALUE
{
generalRocketry = 45
//you can add other techname/value after, only the last researched is applied
}
}

//module to upgrade engine (in a more easy way than ModuleUpgradeModule)
MODULE
{
name = ModuleUpgradeEngine
//Here, it's a list of an other type of "TECH-VALUE"
// each TECH-VALUE node contain an upgrade at a tech level.
// like ModuleUpgradeMass, only the last researched is taken.
TECH-VALUE
{
tech = generalRocketry
// the min/max thrust is considered with vaccum isp => it give the min/max fuel flow.
minThrust = 0
maxThrust = 215
atmosphereIsp = 260
vacuumIsp = 310
}
TECH-VALUE
{
tech = advRocketry
minThrust = 0
maxThrust = 230
atmosphereIsp = 280
vacuumIsp = 330
}
TECH-VALUE
{
tech = heavyRocketry
minThrust = 0
maxThrust = 250
atmosphereIsp = 300
vacuumIsp = 350
}
}

It can update some simple fields inside a Module, like ModuleUpgradeSetTitle. It's hard to find a useful use-case, as so little fields works. Use ModuleUpgradeModule if ModuleUpgradeModuleSetField doesn't work.

MODULE
{
name = ModuleUpgradeModuleSetField
moduleName = ModuleEnginesFX
fieldName = heatProduction
TECH-VALUE
{
advRocketry= 150
heavyRocketry= 100
}
}

This module is different from the previous.
The base fields are:
- type : [ create | replace | delete ]
- tech : the tech name. If this teh is research this module is applied
- id : (optional, default = 0) if you want to use more than one ModuleUpgradeModule with same type/tech per part.
It's what define a ModuleUpgradeModule in a part. This combination is their "key"
When upgrading, each of them is applied, in the definition order, so be careful.
Inside , place all the MODULEs as you would define them in a part.
[spoiler="create examples"]
[CODE]
MODULE
{
name = ModuleUpgradeModule
type = create
tech = generalRocketry
MODULE
{
name = ModuleAlternator
RESOURCE
{
name = ElectricCharge
rate = 3
}
}
}

MODULE
{
name = ModuleUpgradeModule
type = create
tech = advRocketry
MODULE
{
name = ModuleGimbal
gimbalTransformName = thrustTransform
gimbalRange = 0.5
useGimbalResponseSpeed = true
gimbalResponseSpeed = 2
}
}

MODULE
{
name = ModuleUpgradeModule
type = replace
tech = advRocketry
MODULE
{
name = ModuleAlternator
RESOURCE
{
name = ElectricCharge
rate = 7
}
}
}

MODULE
{
name = ModuleUpgradeModule
type = replace
tech = heavyRocketry
MODULE
{
name = ModuleGimbal
gimbalTransformName = thrustTransform
gimbalRange = 1
useGimbalResponseSpeed = true
gimbalResponseSpeed = 5
}
//you can upgrade multiple modules
MODULE
{
name = ModuleAlternator
RESOURCE
{
name = ElectricCharge
rate = 10
}
}
}

Licence: Source is GPL v3 ; The released dll is distributed as CC BY-NC 4.0

ObsoleteParts:

This plugin permit to remove parts from the vab building list.

It's a much simpler of way to upgrade your part:

. make clones with upgraded stats, title (and perhaps graphics) , like the stock probe cores.

. set the TechResearch and TechObsolete Fields to the desired values.

PRO : you can set a new name, a new model.

CON : unlike PartUpgrade, players need to rebuild their rocket & preassemblies when a part became obsolete.

DOWNLOAD

code: https://github.com/supermerill/KspObsoleteParts

Example of ModuleManager config:

@PART[probeCoreSphere]
{
    TechObsolete = electrics
}

Licence: Source is GPL v3 ; The released dll is distributed as CC BY-NC 4.0

more plugins are coming, but they need more work before a beta release.

If someone want to help me to improve my english skill, i'm ok (non-native speaker)

Edited October 24, 2015 by Merill

[Merill]

EngineCooler: (ksp v1.04) [update 1.1 @2015/10/24]

This plugin make your engines to explode if they're not cooled by a way.

With radiative cooling, you are forced to reduce the trottle to make long burn.

At General Rocketry, you unlock the ablative coating: it add mass but you can run your engine up to ~4' at full thrust

At Propulsion Systems, you unlock the regenerative cooling: it increase the cost by 75%, but your engine can run infinitely.

See the config file to change all settings. Source includes in the zip file.

Download : Kerbal stuff

v1.1

- Re-writing all heating and cooling stuff to take ownership and undestand how they work.

- Now, all these formulea are automatically scaled by thrust. We assume the surface aera is scaled the same way for the models

- Heating: add {degreePerSecond} degree each second (just after cooling) at full fuel flow

- Radiative cooling : black body radiation (unobscured): z*T^4, with z to be at equilibrium with 80% thrust at maxTemp.

- Ablative cooling: nb of abator scaled by thrust, {ablatorLossConst}% ablator => remove {ablatorPyrolysisLossFactor} degrees

- Regenerative cooling => asymptote to maxtemp*0.75

Licence: Apache2

NoseConeWithTank:

This plugin permit to add rcs, fuel fuel&oxidizer to cone & adapter in the vab. (with added mass, it's not op)

TODO: some MM config to extend config to part mods (now, i made only the stock config).

DOWNLOAD

Javascript is disabled. View full album

code: https://github.com/supermerill/KspNoseConeWithTank

Example of config:

@PART[standardNoseCone]
{
MODULE
{
name = ModuleNoseConeWithTank
maxMonoPropellant = 20
maxOxidizerPer11 = 1
}
}

fields:

//////////////////////////////////////////////////////////
// Parameters for ModuleNoseConeWithTank: (all optional)
//
// maxMonoPropellant : float, number of MonoPropellant, deactivate if <=0 or unset
// massMonoPropellant : float, mass added to base part (default is activated via negative/unset value). Default compute from various rcs tanks.
//
// maxLiquidFuel : float, number of LiquidFuel, deactivate if <=0 or unset
// massLiquidFuel : float, mass added to base part (default is activated via negative/unset value). Default compute from MK1Fuselage.
//
// maxOxidizerPer11 : float, number of Oxidizer/11, deactivate if <=0 or unset (add also 9*maxOxidizerPer11 as LiquidFuel)
// massOxidizerAndLiquidFuel : float, mass added to base part (default is activated via negative/unset value). Default compute from fuelTankSmallFlat (T100).
//
// massAddEmpty : float, mass added to base part if empty. Default 0.
//
/////////////////////////////////////////////////////

Licence: Apache2

How to install: unzip inside your GameData folder.

more plugins are coming, but they need more work before a beta release.

Edited October 24, 2015 by Merill
maj

[Azimech]

Nice job! I was a bit frustrated though, because I didn't really RTFM, playing on hardcore. I'll try again now that I have some regenerative cooling for my head.

[Merill]

Thanks

The first release has a conf file a little harsh. Now, it's more gentle, you can even burn a FL-T800 with a lv-t30!

[albany_]

Hi Merill -- how would you like to handle distribution of your plugin(s) (specifically, PartUpgrade)? I'd like to utilize the plugin for a little part mod I'm working on but I wasn't sure what your desires were in regards to how the plugin should be distributed -- i.e., should the download redirect users to you for downloading the plugin, or should it be bundled with the add-on like ModuleManager?

EDIT: Now that I've had some time to play around with the plugin's features I have to say, this is really neat for OCD folks like myself who hate additional parts. The only thing I'm finding myself wanting would be the ability to update the base non-module part cfg elements with research (e.g., name, description, etc). Is this functionality something you'd consider adding?

Edited July 22, 2015 by albany_
additional question

[Merill]

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.

Edited August 2, 2015 by Merill

[albany_]

No sweat, thanks for the response.

I've already made a neat little modlet that adds SASServiceLevel ranks to unmanned probes as you progress up the tech tree (so you can aim at nodes, prograde/retrograde, normal/anti-normal, etc). I haven't decided if I'll make it available for others but if I do I'll wait until you think it's ready. This is a great idea, I'm glad someone's​ making it.

[Merill]

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.

[albany_]

Wow, you really knocked that out quick!

As far as additional module ideas... I mean, texture/model changes w/ upgrades would be neat. It'd have to be persistent, since you really don't want parts changing dimensions mid-flight, but I'm imagining a neat use case where you get a part that changes visually as you upgrade it -- gets extra little doodads, changes colors, etc.

It's not something I'd have an immediate use for but I bet there are a lot of mod developers who could get a lot of mileage out of that function.

EDIT: Also, I released the SAS module mod today. Thanks for the help.

[Merill]

@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.

Edited August 4, 2015 by Merill

[albany_]

@albany : nice! (ps: this one GPL, not mit, as i invested much more time than the others)

Gotcha. Fixed.

[monstah]

First impressions are good! I'm gonna play around a little on the default config just to get a feeling for it, then probably mess around making my own .cfgs. I'm one of those players that hates more mod parts.

[Aknar]

I envisioned a upgrade-based tech-tree for some time now but I'm no modder. I'm so happy to see this mod come along. I can't find the old thread I started on this but I'll recap in the hope that you might be sharing a similar view of the game play-style:

I've never liked campaign too much because you start off with a sole cockpit+booster. It's somewhat of an excruciating experience for me to make abominations for most of the game and the end result is to be able to make a complete apollo-styled mission. I would envision the game as starting slightly prior to apollo missions and actually having the parts that aren't profoundly technical and thus shouldn't be locked from the start. Instead, those parts should be "primitive" in the beginning, striped of all but their core functionality. They shouldn't have all the features (the modules) from the start. It's by building and flying crafts that you acquire experience to modify the parts to make them more convenient, reliable. That's where the idea of a upgrade-based tech tree comes from. Evolving through it will let you make more reliable crafts that can do more with less and be more performant while still being able to make realistic crafts and interesting missions from the start. Going to the mun would be a dare-devil's challenge in the beginning but would become easier going through the tech tree by:

- improving docking ports with magnetic capabilities

- improving landing lights (intensity for focused beam able to light from afar)

- parachute capabilities carrying more weight and slowing down craft more effectively (for return obviously)

- SAS improves

- engine gimbal control and efficiency

- solar panels more effective

- antenna max range increase

- batteries become rechargeable

- capsules get SAS, ablator sheilding, life support

- ladders include lights, are deployable

- decouplers have higher ejection force

- monopropellant has higher Isp

- wheels get upgraded with motors, become steerable, get fitted with lights, become more durable

- ...

Parts that would remain in tech tree are all high end tech that are just now becoming available (ion engine, hybrid engines => rapier/saber, ...) and pretty much all parts that are deployable, have an animation. They are more compact and complex and are improvements on base parts so shouldn't be unlocked from start.

Edited August 8, 2015 by Aknar

[Merill]

First impressions are good! I'm gonna play around a little on the default config just to get a feeling for it, then probably mess around making my own .cfgs. I'm one of those players that hates more mod parts.

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).

I envisioned a upgrade-based tech-tree for some time now but I'm no modder. I'm so happy to see this mod come along. I can't find the old thread I started on this but I'll recap in the hope that you might be sharing a similar view of the game play-style:

[...]

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
[...]
}

Edited August 11, 2015 by Merill

[albany_]

That's actually what I initially had in mind when I started looking for a solution to what I wanted to make with TBPSASU (I wish I had a catchier name).

Quick question, not sure if you've tested this or not: if you reduce a part's mass through tech, does it affect the orbits of existing craft with that part? Or does it all sort of compensate? I know you have already built a solution to this with the persistence flag but I was just curious if that was why.

[Merill]

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.

[Aknar]

I've started working on what I think the tech tree should look like. It's still far from perfect (and far from finished) but i'd appreciate feedback/ideas. Let me know if that's something you might be looking for in a tech tree.

It's all still WIP but it's starting to look neat

Edited August 14, 2015 by Aknar
Revised tech-tree

[albany_]

ps: i don't understand "I was just curious if that was why". I'm sorry, my English level is not excellent.

Sorry, I should have been more clear. My understanding was that if an object in orbit suddenly gains/loses mass, the pull of gravity on that object increases/decreases, disrupting the object's orbit. My assumption was that you added the "persistent" flag to counteract this effect, but if I understand what you're saying, the game itself compensates for the change in mass and maintains its previous orbital trajectory.

[Merill]

Sorry, I should have been more clear. My understanding was that if an object in orbit suddenly gains/loses mass, the pull of gravity on that object increases/decreases, disrupting the object's orbit. My assumption was that you added the "persistent" flag to counteract this effect, but if I understand what you're saying, the game itself compensates for the change in mass and maintains its previous orbital trajectory.

"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!

if that's something you might be looking for in a tech tree.

My tech tree is already done. I think every player has his own vision of the "best" tech tree, anyway.

[albany_]

Ah, okay, that all makes sense. You learn something every day.

[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?

Edited October 25, 2015 by Merill

[riocrokite]

hey Merill,

I was wandering would it be possible to tweak ObsoleteParts mod to eliminate the drawback you mentioned? For example if part has an obsolete technology specified, the plugin - instead of removing an obsolete item - moved it to separate part tab (for example 'obsolete parts' category). So then player could still use / load older designs. Moreover player could use Testflight mod nicely so i.e. you'd have still access to more reliable older parts if you wanted to use them (as opposed to less reliable new parts).

Edited December 13, 2015 by riocrokite

[Tibio]

Merill thank you for this great plugin.

[Alshain]

By request of @Streetwind I have recompiled PartUpgrade for use in 1.1.  It should function as it did in previous versions.  I really don't plan on maintaining this mod myself, hopefully I'm not feeding a stray cat here

Download Here

Change Notes:

• Attached KSPUtil.dll to references and recompiled.
• Disabled version checker script as it was causing an exception and isn't a critical function.

Known Issues:

• While Testing I found an issue where the plugin ignores initial buy in costs if they are enabled.  The upgrades are unlocked the moment the tech tree node is unlocked, whether you purchase it or not.  I believe this issue to have always been present (not a result of 1.1) and fixing it would require a bigger overhaul than I want to try and tackle myself.