[1.4.2] Kerbal Research & Development

[lude]

Heya, yes I'm using the 1.6 one but I'm also using several dozens of other mods and just found out that I can't change the drymass for all parts, the OPT cockpit pats seem to be immune even to repicking it (on other command modules like the lithobreak one it changes the dry mass tho I'll try again and see if it might be something that changed this restart)

using x64 1.1

 

-- edit --

it seems to affect the opt objects just doesn't show so in the editor panel but not to the extent it says it'd do in the r&d tab

 

[LOG 16:53:29.792] [INFO] ContractConfigurator.ContractDisabler: Disabled 1 ContractTypes.
[ERR 16:53:30.315] [KRnD] updateGlobalParts(): System.NullReferenceException: Object reference not set to an instance of an object
  at KRnD.KRnD.updateGlobalParts () [0x00000] in <filename unknown>:0 

[LOG 16:53:30.316] [KRnD] updating vessel 'Space Plane I'
[LOG 16:53:30.319] [KRnD] retrieved and applied 811 upgrades in 0.020s

is something i found on fresh load of vessel in orbit after game restart

Edited April 13, 2016 by lude

[Turf]

It is a very good choice to have some money sinks for the overflowing science once you've unlocked the entire tech tree.

It is pointless to reduce the dry mass from a 'physicless' part, though.

If we could increase the maximum temperature, we can (hopefully) fly on Kerbol atmosphere but not landing.

Sadly, the science costs go exponentially, but limited to 2147483647 (it overflows to -2147483648), so if you managed to upgrade about 1 billion sciences cost, you can (theoretically) get free sciences.

[Kerbonaut257]

So I just want to say, I freakin love this mod. It's amazing. Very fun for the kerbal-rocket-master who has everything.

 

However, I find myself wishing I could upgrade FAMILIES of parts, rather than just individual parts. Like, upgrading all 4 of the 1.25m tanks should happen together. As they're the exact same tech, just in different sizes. 

And then the 2.5m tanks would be a family, and get upgraded together. 

Other families would include "small batteries" (the ones with <1000 EC), and then "large batteries" (>1000 EC). Solar panels (1x6 and 2x3 are literally the same thing, should get upgraded together, maybe the gigantor is separate from the rest, etc)

Also, if you've got the time or desire, adding in some mod support would be great. Like being able to upgrade antennas to have greater range for remote tech. 

And would fuel density be a possible upgrade for fuel tanks?

 

[JeffreyCor]

I very much disagree as to the family of parts. Families do not really apply in a way like this. That fits more with the tech tree of unlocking parts themselves, whereas this is applying research to make particular parts better. In a reality standpoint, parts that appear similar can actually be quite different, even in the case of tanks. In a game play standpoint, this would be nearly impossible to implement as it would require an independent database of every part, how it relates to others, and also include not only stock but also parts for every mod. As it stands now every part is supported right out of the box.

Antennae upgrades are already planned for the stock com system that is now scheduled to come in KSP 1.2 This was decided when 1.1 was supposed to have it. Now that there is no idea how long until 1.2 comes around this may be something -MM- may find worth looking into unless we her something new.

Fuel density is an interesting idea, which wound in a game mechanic system be reflected as capacity increase. There could be some difficulties in compatibility with mods that switch fuels such as Interstellar Fuel Switcher, but this idea does sound like something very worth looking into!

[Warezcrawler]

On 3/4/2016 at 9:47 PM, -MM- said:

I've just uploaded a new version of KRnD, which now supports the current 1.1 prerelease version of KSP (see first post). Additionally I've fixed / added the following:

• Multi-Mode engines are now working as expected.
• The ISP of air-breathing engines is now improved by raising the ATM-stats instead of VAC-stats.
• The strength of parachutes (safe deployment-speed) can now be improved.
• The internal- and skin-temperature of all parts can now be improved (re-entry with space planes should be easier now).

I've also tested a few other mods which are already compatible with 1.1 and found no issues. If you stumble upon one, please let me know.
Please remember to also upgrade your version of the Module-Manager, which has a new 1.1 compatible release available as well.

Love that you are updating this mod. A while ago I was planning on a mod like this one, but this one is simply better than what I could have achieved 

Keep up the good work. Happy coding.

[-MM-]

On 12.4.2016 at 10:23 PM, lude said:

[ERR 16:53:30.315] [KRnD] updateGlobalParts(): System.NullReferenceException: Object reference not set to an instance of an object
  at KRnD.KRnD.updateGlobalParts () [0x00000] in <filename unknown>:0 

The "updateGlobalParts" function will run through all available parts. I guess the error has to do with some part provided by one of your installed mods (this doesn't happen with only stock parts). I will try to add a little more information in the exception-message in the next release with which we might be able to track down the issue here.

On 14.4.2016 at 11:59 AM, Anbang11 said:

It is pointless to reduce the dry mass from a 'physicless' part, though.

Sadly, the science costs go exponentially, but limited to 2147483647 (it overflows to -2147483648), so if you managed to upgrade about 1 billion sciences cost, you can (theoretically) get free sciences.

I thought that the thrust to weight ratio of your vessel's engines simply used the sum of all your parts weights, no?
And I will add an upper limit to the science costs in the next release to avoid an overflow, even though I doubt anyone can really gather that much science without cheating ;-)

Quote

However, I find myself wishing I could upgrade FAMILIES of parts, rather than just individual parts.

While this seems quite logical for parts which are simply a shorter version of other parts, it's not that simple. We would have to define those families by hand, we can't simply go by similar names or something. I would have to agree with JeffreyCor: The way it is currently implemented is more transparent, especially when you are using parts added by other mods.

On 16.4.2016 at 11:52 PM, JeffreyCor said:

Antennae upgrades are already planned for the stock com system that is now scheduled to come in KSP 1.2 This was decided when 1.1 was supposed to have it. Now that there is no idea how long until 1.2 comes around this may be something -MM- may find worth looking into unless we her something new.

Fuel density is an interesting idea, which wound in a game mechanic system be reflected as capacity increase. There could be some difficulties in compatibility with mods that switch fuels such as Interstellar Fuel Switcher, but this idea does sound like something very worth looking into!

Once we get the new antennas with ranges and angles as stock-modules I will include improvements for them. Modifying the functionality provided by another mod, like Remote Tech, is kinda hard and would require collaboration with the other mod's author.

Fuel density on the other hand sounds like a great idea. We can simply increase the pressure with which a resource (liquid fuel, oxidizer, solid fuel, mono propellant, etc) is stored in a tank and thus increase the maximum amount the tank can hold. On the backend-side it's the same way battery-improvements are working right now. This won't get too overpowered either, because more fuel in a tank will also have more weight. I will put this in the next release.
What do you think, should we allow upgrading the storage capacity for all resources, even modded ones like ore, uranium, life support, spaceship parts, etc? In reality you can't compress everything ;-)

[JeffreyCor]

While everything couldn't be compressed, most things can be in one way or another. Ease of function would lean toward compressible everything, though more realism would favor exceptions. I can see both sides on this one. Personally I'd favor it be limited to fuels, though allowing for all capacities wouldn't be "breaking" as one can always just not use it for certain things.

[Turf]

Why not add a function to downgrade parts and refund 50%-100% science? Or no refund at all?

[lude]

This Mod is still just a loveing marvel and, it's so simple yet elegant and great. (not in how it's coded properly but how it's usable for my needs)

Downgrading stuff should give cash and prestige for being especially helldevilish evil knivel.

 

Hey Jeb I heard your heatshield barely works in oxygenated atmosphere how about we scrap all those ceramic parts.

 

-- edit --

And you're very likely right with that being caused by mods, despite that most things work like ISP for both, fuel efficiency, heat tolerance (with some release of kspie it didn't reload those settings on vessel load just on r&D usage so now i'm not using it anymore)

 

What things in mods would break this tho? The way you add a module seems very resilient

Edited April 19, 2016 by lude

[JeffreyCor]

There really makes no sense to downgrade anything. No one ever wants to get rid of improvements in order to use outdated technology or intentionally making things bad.

[Warezcrawler]

19 minutes ago, JeffreyCor said:

There really makes no sense to downgrade anything. No one ever wants to get rid of improvements in order to use outdated technology or intentionally making things bad.

Well I could se you would want to go back on a wrong disposition. The thing just is... If you spend time + money on R&D you can't really go back can you? Patents maybe, but not actuals R&D. I like it as it is 

[Warezcrawler]

@-MM- I noticed that when using R&D to increase thrust and ISP on the Rapier engine, the effect is only for the primary (air) mode. Would you consider that a bug? I looked, but I did not find a workaround for that... Maybe the R&D plugin should loop all engines in the part and add the improovement? Alternatively adding feature to select which one to affect, even though I think the latter would be more difficult to add.

What do you think?

[JeffreyCor]

This was a bug in the version for 1.0.5 that has been corrected in the version for 1.1. I just tested it and upgrades apply as appropriate to both airbreathing and closed loop modes (ie no vacuum improvement on airbreathing mode, atm applies to both modes).

[Warezcrawler]

5 minutes ago, JeffreyCor said:

This was a bug in the version for 1.0.5 that has been corrected in the version for 1.1. I just tested it and upgrades apply as appropriate to both airbreathing and closed loop modes (ie no vacuum improvement on airbreathing mode, atm applies to both modes).

Ohh... Great.... I should have mentioned that I'm playing 1.05 currently.... Just waiting for all my core mods to be updated and stable.... Then I'm off to 1.1 for good 

[JeffreyCor]

1 minute ago, Warezcrawler said:

Ohh... Great.... I should have mentioned that I'm playing 1.05 currently.... Just waiting for all my core mods to be updated and stable.... Then I'm off to 1.1 for good 

lol yea that would have saved from testing to make sure it didn't creep back in to the 1.1 build
Same here, this is going to be AWESOME once the main mods are updated

[MisterFister]

On ‎2016‎-‎04‎-‎18 at 4:55 PM, -MM- said:

Fuel density on the other hand sounds like a great idea. We can simply increase the pressure with which a resource (liquid fuel, oxidizer, solid fuel, mono propellant, etc) is stored in a tank and thus increase the maximum amount the tank can hold. On the backend-side it's the same way battery-improvements are working right now. This won't get too overpowered either, because more fuel in a tank will also have more weight. I will put this in the next release.
What do you think, should we allow upgrading the storage capacity for all resources, even modded ones like ore, uranium, life support, spaceship parts, etc? In reality you can't compress everything ;-)

I like the idea of having the up-front either-or choice of: 1.) Compress all resource types, according to gradients predetermined to approximately model "compressibility" of a substance; 2.) Compress a single resource type, affording for greater maximum achievable compressibility of that specific substance given that structural modifications to the tank in question can all be oriented around reinforcing a specific inner pressure vessel exclusively instead of "all of them equally"; 3.) No compression changes, but allow a multi-resource container to be internally reconfigured to accommodate a different loadout of various substances; 4.) Interact with DangIt or other part failure mods -- an upgrade tier can offer an either-or choice as between increasing compression, thereby increasing failure / leak severity and occurrence; or instead, a player can invest to reduce failure likelihood / reduce failure severity / reduce potential repair burden (with no increase in compressed resource capacity as a result of this upgrade purchase.)  This means that future upgrade choices and upgrade effectiveness are profoundly influenced by previous upgrade purchases -- do I keep compressing the material further, subjecting the tank material to greater strains and resulting in reduced structural tolerances, or do I invest in strengthening the tank hull design to increase impact resistance for equipment being sent to hazardous environments such as a land-base on Eve or a Tylo landing?  If I have a very important and profitable orbital station (profitable in terms of science gain, an RT command outpost, or a fuel depot) located in a spot where dV margins are very tight (Eeloo, Moho, Eve, or Kopernicus-modded systems such as RO / RSS) where it's difficult to ensure that incoming craft will have the fuel needed to reduce their closing velocities in time, so upgrading the impact-tolerances of the parts of this station would make the station more resistance to docking-collisions.

 

Examples of #3, above, all starting with Tier-0 KRnD initial part upgrades with a single Stock Big Orange Tank, which has LFO bi-resource in ratio-mix:

3A -- Convert to LF-only or LO-only, preserving the original total internal volume and adjusting the maximum wetmass as a result, or possibly even slightly increasing overall internal volume because of the space freed up by removing the internal bulkhead separating the twin internal compartments, with a proportionally-slight decrease in drymass.  Subsequent upgrades can then compress this mono-tank further, though at a slightly reduced curve of per-upgrade gain opportunities, owing to the fact that the tank has been slightly weakened by the removal of an internal bulkhead and therefore continuing to overpressurize the single larger containment vessel with subsequent upgrades is proportionally less feasible, from a safety and reliability standpoint, than if you were to instead leave the SBOT as a stock-LFO tank and simply pressurize the two compartments equally with each upgrade.  For this option to convert to mono-tank, this must only be cost-effective as a first-tier upgrade purchase.  The only way to reliably remove the internal bulkhead separator as between the internal compartments after first overpressurizing the twin-compartments is to bleed off the now-overpressurized contents and undo the pressure and compression tolerances back to stock (with no refund in original purchase price, perhaps even a nominal purchase price for the labor cost of the undo) before removing the internal bulkhead.  Then subsequent purchases can be purchased as normal, but continuing the exponential cost increases -- in other words, paying to undo the first compression upgrade still counts as the cost-equivalent of a second upgrade, and the now-first compression upgrade of the mono-tank still counts as the cost-equivalent of a third upgrade, etc.  Always: Slight (minor but noticeable for expert craft designers) remodel of CoM as between wet and dry states.  First-upgrade-incentive: Negligible effect on part reliability.  Non-first-upgrade-penalty: Slight, non-negligible effect on part reliability.

3B -- Same as 3A, but convert SBOT to mono-resource of an unrelated type, such as Xe, monoprop, Community Fuel substances such as Water or SolidWaste (life support) or stock-Ore, etc.  I speculate that for this to work, some hand-modeling would be useful to analogize resource default-densities of other substances to figure wetmass / drymass values appropriately, both after initial conversion and after each subsequent compression upgrade.  Similar to 3A, this can be performed at any time, even repeatedly between several resource type changeovers, but each resource-type change resets the compression / capacity values to a sort of "default."  Always: Slight-to-moderate remodel of wet / dry CoM positions depending on circumstances of the selected changes.  First-upgrade-incentive: Negligible-to-slight effect on part reliability, depending on above.  Non-first-upgrade-penalty: An either-or choice at time of upgrade, between "moderate effect on part reliability with highly efficient use of reconfigured overall internal volume" (maximum capacity-benefits combined across all involved resource types) and "negligible effect on part reliability and reduced efficiency in the use of overall internal volume" (special attention to detail and safety will mean that safety valves and sensor wiring will take up pockets of space that cannot also be occupied by tank contents.)

3C -- Same as 3A, but add a third or, at maximum, a fourth resource to the tank, thereby cutting into the capacity levels of the stock contents and increasing drymass.  Wetmass might increase or decrease depending on the changes made.  Always: Moderate to significant remodel of wet / dry CoM positions, depending on resource changes involved, especially when adding a fourth resource compartment.  First-incentive: Slight-to-moderate effect on part reliability.  Non-first-penalty: Choice between "significant effect on reliability with moderately efficient use of internal volume," and "slight effect on part reliability and reduced space efficiency."  Note: perhaps one option is to "add a compartment" for battery power (embed a battery system into the tank hull) allowing for simpler but heavier and lower-fuel-capacity self-contained structures with batteries built right into the fuel tanks.  I imagine peculiar tradeoff considerations for DangIt purposes, especially for un-kerballed missions.  Battery capacity can never be "compressed," but can be "expanded" once and only once at the cost of significant drymass increase, significant loss of resource storage volume available for other compartments (maybe a user-selected decision as to which compartment is cut into?) and significant reliability decrease.

3D -- Maybe tanks have "flow values," representing their valve routing systems.  Overpressurizing a compressed tank would initially result in slightly faster fuel outflow, but as a tank drains, flow rates level off.  An upgrade option could be to expand the flow control valves in a tank to allow for faster or slower resource flow rates.  The inverse would also be true -- on an overpressurized tank, transferring resources INTO a tank above stock-capacity levels results in a REDUCTION of the resource transfer rate.  With a flow-increased capacity-increased tank, you can actually deliver fuel to engines faster, resulting in useful over-thrust scenarios for limited periods -- another DangIt tie-in opportunity as to engines.

All examples above: DangIt failures can result in internal leaks as well as external leaks, which can create sudden heat buildup leading to explosion hazards unless a tank is vented or drained immediately depending on the substance combinations involved (and heat buildup in the resources in v1.1 means that temperature is transferred when those resources are transferred).  An internal or an external leak can also mean a sudden change in CoM position within the tank, which can make attitude control impossible without a lot of attitude control to compensate, engine thrust vectoring, and thrust and throttle limiting.  Untreated leaks can even result on CoM imbalance symptoms that get worse as a leak increases in severity (venting escape of resources into the vacuum of space can cause material erosion in the pressure vessel of the tank, resulting in a pinhole leak that gets bigger and bigger as materials continue venting -- fuel escapes more and more rapidly, begins applying noticeable asymmetrical thrust as an uncontrolled RCS nozzle that can't be turned off, and as the hole progressively widens the thrust-vector changes and gets worse because the direction of the escaping jet of leaking fuel is changing according to the size and shape and placement of the hole... until the tank is drained or offloaded, and then the leak stops applying thrust and stops getting wider.  Some very severe leaks might not be repairable at all in the field, and moderately severe leaks might only be field-repairable with the tank drained first.  This would factor into designs for orbital stations and ground bases, as a prudent thing to do is to include always-empty tanks on hand so that a tank with a sudden leak can always be drained in an emergency without the resource being lost to the environment (remember, v1.1 allows us to consider designs with vastly higher partcounts, this is one of the earliest ways we can take advantage of that in mod design.)

I don't have much programming experience (I can learn, I did some stuff with BASIC and VBASIC in high school, so I understand some of the thought processes involved) but I do know how to design math algorithms and how to balance these changes so no one upgrade is overpowered or underpowered.  I am officially volunteering to help on this project.

[MisterFister]

In organizing and proofreading my post above, I forgot to include another idea: nominal costs for texture changes.  All of my 3-series examples assumed that a player would start with a SBOT.  If we're reconfiguring the internal compartments of a multi-resource tank, excrements's gonna get real confusing real quickly in trying to remember what tank at what location holds what resource.  Either automatic texture decals to indicate resource set (maybe an animated or context-sensitive decal that gets lighter or darker with tank fill level?) or maybe even a user-elective opportunity to simply purchase texture changes at any time.  Would we be able to work with pTanks, and conversions as to tank insulation for cryofuels?

[JeffreyCor]

While I can certainly understand the difficulties with support for mod parts, might you consider looking into what it may talk to giving deployment temperature adjustment for RealChute? Considering it is a very popular and long standing mod for a more realistic and configurable parachute experience. These are defined by material in this case and not the part.

[rasta013]

 

On 4/19/2016 at 11:02 AM, JeffreyCor said:

There really makes no sense to downgrade anything. No one ever wants to get rid of improvements in order to use outdated technology or intentionally making things bad.

 

On 4/19/2016 at 11:23 AM, Warezcrawler said:

Well I could see you would want to go back on a wrong disposition. The thing just is... If you spend time + money on R&D you can't really go back can you? Patents maybe, but not actual R&D. I like it as it is 

 

Well I guess that's why I downgraded the Windows 10 install I tested to Windows 7 because no one ever wants to go backwards to "outdated" technology...

Point being is that sometimes your R&D decision that seemed really good to begin with turns out not to be a wise idea.  I would agree that given the current parts being modified there's no real reason to want to downgrade parts. However, if you get into tank upgrading that makes the entire picture change.  Sure, I might want that SBOT to have a greater fuel capacity at this time...even the next 5 missions.  But all of a sudden I'm starting a new mission that is going to require a tank setup that would  greatly benefit from the pre-upgraded SBOT because the mass increase from the greater fuel capacity is just not going to work nor have I researched enough to have a suitable replacement.  In this case, you would want to have access to the old tank and if there's no way to get it back then you are screwed.  I'll admit this is a bit of a stretch because I think many of us (not all) play with part mods and would have viable tank alternatives in this scenario, but this is an example that instantly popped in my head when I started thinking about downgrade possibilities.

Sometimes you just want to have that old part available to use because it is a better solution or you simply need it.  All this said, I would say that you would need to penalize the player for having to downgrade.  Call it a reconditioning cost to bring out the mothballed tech but to say there's never a reason to downgrade is not entirely accurate.  If the downgrade scenario is WAY too difficult to code though - forget it - you've got a great mod going here and that piece of missing functionality does not detract from you've built.

One other note...if you ever consider changing costs due to upgrades then the downgrade scenario becomes almost necessary if you even think about using this in the early game...

[MisterFister]

10 minutes ago, rasta013 said:

Point being is that sometimes your R&D decision that seemed really good to begin with turns out not to be a wise idea.  I would agree that given the current parts being modified there's no real reason to want to downgrade parts. However, if you get into tank upgrading that makes the entire picture change.  Sure, I might want that SBOT to have a greater fuel capacity at this time...even the next 5 missions.  But all of a sudden I'm starting a new mission that is going to require a tank setup that would  greatly benefit from the pre-upgraded SBOT because the mass increase from the greater fuel capacity is just not going to work nor have I researched enough to have a suitable replacement.  In this case, you would want to have access to the old tank and if there's no way to get it back then you are screwed.  I'll admit this is a bit of a stretch because I think many of us (not all) play with part mods and would have viable tank alternatives in this scenario, but this is an example that instantly popped in my head when I started thinking about downgrade possibilities.

So, are we talking in-field upgrades, like at orbital dockyards?  Or are we talking about adding new production options?  I mean, the Boeing 747 was a new design when it was made, but there've still been 737's made since.  Parts for older 747's are still manufactured for maintenance purposes.  All of a sudden when we improve a design we lose the ability to fabricate the older version?  Why not have both options available for future purchase, with the later-gen design being the default option?

[rasta013]

Right now, the upgrades actually change the base item permanently.  Once upgraded you no longer have the older part available and there is no downgrade path.  With the state of the mod currently regarding what items can be upgraded this is not really a big deal.  All the things being affected have no real reason to get downgraded later since previous iterations would be worse in every way offering no real advantage to using the older version.

I was just making the point that if you get into doing R&D/Upgrading of items like fuel tanks where the intrinsic nature of the upgrade is going to change an important stat like mass then either a downgrade path or previous version should be considered in some way provided it doesn't take a year's worth of coding.  The main reason I could see for not offering copies (which I think would be fairly easy) of the existing part after upgrading would be memory constraints.  It wouldn't affect those of us running Linux/64-bit but could easily play havoc with anyone running 32-bit especially if you upgrade the same item multiple times and end up with 3, 4, 5+ copies of the same item.  It also would make the editor screen annoying trying to determine which one is which since in all likelihood they would look the same no matter which iteration it is.

Just my 2 cents...

[JeffreyCor]

Your own silliness aside which you have just admitted to ( ) lets try an actual, correct analogy. You want to use old Steal from the early 1900s that contained high imperfections and brittleness instead of modern steal which is far higher quality and less prone to breakage in order to intentionally made a less reliable ship, bridge, building, etc. This is what "downgrading" parts that have had R&D done to them actually means. As stated, no one in their right mind would use such. All improvements are exactly like this. In no situation is a part that has not been upgraded via KR&D ever better suited to any situation. Your analogy of downgrading your OS would be like unlocking nuclear engines, but using chemical rockets. You don't re-close your tech tree on the node you just don't use the new device for that purpose.

Greater efficiency, lower weight, higher maximum thrust capability, and greater capacity is always adventitious in every situation. If a particular ship is overthrusted you adjust the max thrust, a stock stetting, as with any engine. If your tank holds too much fuel for your particular mission, same thing you adjust the capacity. As stated, there is never a situation when a non upgraded part would be desired. This would be akin to re-locking tech tree nodes. If you progress beyond the parts it unlocked you just don't use them, but you don't revert to the prior technological state.

[rasta013]

Well at least you caught the joke... 

I'd disagree that your analogy is any better than mine since you're trying to compare early 20th century tech to early 21st century tech.  I was more referring to an idea similar to differences between using cold roll vs. hot roll steel.  Regardless, neither of our analogies is very good in relation to the game or the current state of the mod anyway... LOL

To be perfectly honest, I wasn't arguing in favor of putting downgrade options into the mod; only that I can see a justification for having pre-upgrade technology available in some limited cases.  But, by and large I agree there isn't a reason to do so for the simple reason there are plenty of workarounds as to generally make it a non-issue. The sole reason I would actually want a downgrade path would be if the price/cost of the items get affected because that's something that is far more difficult to engineer around.  In that case, having the option of reducing costs by using older tech becomes a trade off decision between the better performance/design or better economics.

[JeffreyCor]

AH! I see where you're going now. Yes in that case, if upgrades would at some point cause the price for use to also go up then I would agree with you in having a way to either revert or, maybe better, apply a type of manufacturing research making the price lower. This second option could apply at any point in fact. Currently the research into the enhanced technology includes the manufacturing enhancement, making the improvements available without increase in cost. A bit of a two for one deal in the research line which done make some sense as at some upgrades can end up costing as much as high level tech tree nodes  

[rasta013]

That's a pretty good idea actually.  Instead of a downgrade path, expanding the functionality to improve your manufacturing capabilities is pretty much just expanding the existing science based functionality into funds based instead.  This sounds a lot easier than a downgrade path.

Edited April 22, 2016 by rasta013