Engineering system to complement Science-based tech tree

[boomerdog2000]

Detect if the vessel was in a valid orbit at least once. => Give Points if true.

At any rate you would most likely get points for the wheels instead since your testing those and not the engines themselves in that case.

So what defines a valid orbit? Are planes exempt from the rule? What about sub-orbital flights?

Sorry if I sound negative. I'm not against this idea at all. This is just how I think.

[DChurchill]

How about points as some combination of distance traveled * burn time? You'd have to adjust it for ISP as well, otherwise efficient engines would gain over inefficient ones.

[NeilC]

So what defines a valid orbit? Are planes exempt from the rule? What about sub-orbital flights?

Sorry if I sound negative. I'm not against this idea at all. This is just how I think.

No offense taken, it's how I think too.

We don't need to debate how these things are defined, KSP's orbital parameters already contain a situation variable "sit = " that the game uses to keep track of the craft's state: PRELAUNCH, LANDED, SPLASHED, SUB_ORBITAL, ORBITING, or ESCAPING. I assume sub_orbital vs orbital is defined "correctly" as periapsis >= atmosphere limit, but it could be >=0 - the details aren't terribly important. The point is it would be trivial to piggyback on this existing system to generate extra EEP for sub-orbital or orbital flights.

The root of your concerns, though, seems to be that it will be easy to "farm" EEP. I want to repeat that I don't think this will be a problem once launches cost money. Test firings, whether on a pad or on a wheeled "farm", whether orbital or not, are a valid way to earn EEP. If things are balanced properly they will also be a wasteful way that you can't afford to do very often, if at all.

[NeilC]

Re: DChurchill -

- I agree there should be a limited number of blocks, and 3-5 sounds reasonable to me. I was thinking of having each one defined specifically rather than some function-based infinite series of upgrades.

- I don't think unlocking a new block design should make the previous ones cheaper - they are already cheaper due to the EEP you had to earn to unlock the block. My design intent was that once you unlock a block, you would have to pay "full price" again to use the improved version - IE, a Block B that you just unlocked would cost roughly the same as a Block A before you earned any EEP. The Block A would be cheaper at that point, so you're always paying more for the new designs. It's all subject to balancing, of course, and playtesting would be the only way to fine tune things.

- I don't like the idea of distance-based EEP gain. I like the idea of "bonus" EEP for using parts in orbit and recovering orbited parts. Test firing an engine in a vacuum for the first time is a big milestone, and being able to inspect that engine afterwards could teach you something valuable. I think these should drop off very quickly, though: using 1EEP per launch, maybe you get an extra 1EEP for the first orbital firing, then 0.5 for the 2nd, then o.5 for the third and you're done. Build a craft with 3 engines? One orbital run with that craft and that's all the bonus EEP. Most EEP should be gained for building and launching the part, EEP should not motivate missions - that's what Science is designed to motivate. There should be no "why" to EEP, only "how".

[Outlander4]

I like the idea; in fact, some people including me have suggested something like this before.

[DChurchill]

- I don't think unlocking a new block design should make the previous ones cheaper - they are already cheaper due to the EEP you had to earn to unlock the block. My design intent was that once you unlock a block, you would have to pay "full price" again to use the improved version - IE, a Block B that you just unlocked would cost roughly the same as a Block A before you earned any EEP. The Block A would be cheaper at that point, so you're always paying more for the new designs. It's all subject to balancing, of course, and playtesting would be the only way to fine tune things.

I think we're saying the same thing.

A costs $100

I develop B, A now costs $90, B costs $100.

I develop C, A now costs $80, B costs $90, C costs $100.

- I don't like the idea of distance-based EEP gain. I like the idea of "bonus" EEP for using parts in orbit and recovering orbited parts. Test firing an engine in a vacuum for the first time is a big milestone, and being able to inspect that engine afterwards could teach you something valuable. I think these should drop off very quickly, though: using 1EEP per launch, maybe you get an extra 1EEP for the first orbital firing, then 0.5 for the 2nd, then o.5 for the third and you're done. Build a craft with 3 engines? One orbital run with that craft and that's all the bonus EEP. Most EEP should be gained for building and launching the part, EEP should not motivate missions - that's what Science is designed to motivate. There should be no "why" to EEP, only "how".

If you're running 3 engines, wouldn't you get 3X the engineering data? And my idea of distance times time is mostly to avoid someone sitting on on the pad and firing it and not going anywhere. I think that probably should be worth something, but something in actual service should be worth more. And recovering spent equipment should be worth even more.

Edited October 14, 2013 by DChurchill

[Zaeo]

I'm impressed. Its so simple, and nicely ties in with the tweakables system we've all heard so much about.

The only thing I can see this being a problem for is new parts. Balancing them will be quite the tough job, and will take a long time.

Rather than give each new version an improved score from the previous, you could have engines simply tuned to the mission it is going to do.

Here are some ideas on how each part would change with each new Iteration

Liquid Engines:

Mass: +/-

Thrust: +/-

ISP: +/-

Example 1: Block A LV-45 -.05 mass,+3% cost. Improves efficiency by reducing mass. More suitable as an upper stage upgrade rather than an isp increase

Example 2: Block B LV-45 +0.1 mass +2% thrust, +2% cost. Reduces efficiency in favor of higher thrust. More suitable as a lower stage engine to lift heavier loads.

Example 3: Block C LV-45 -.05 mass +3% ISP,-5% thrust +4% cost. Greatly improves engine efficiency. More suitable as a Orbital maneuver engine/interplanetary engine

This leaves 4 versions of the engine, Which I think is plenty, and it covers almost every need for an engine.

Fuel Tanks

Mass: +/-

Fuel Crossfeed: on/off

Integrity*the amount of force needed to destroy the part*: +/-

Fuel Amount: *odd one to balance.* +/-

Example 1: Block A "Honeycomb" FT-400 -.1 dry mass, -2% integrity, +2% cost Suitable of upper stages

Example 2: Block B "Hoseline" FT-400 +.05 dry mass, +1% integrity, +Fuel Crossfeed Switch, +3% cost, Suitable for stations/reserve fuel for emergencies/tankers.

Example 3: Block C "Overflowing" FT-400 -.2 dry mass, +X Wet mass*increased fuel amount* -4% integrity, +4% cost, Suitable for long distance/orbital maneuver tanks.

Command Pods

Mass +/-

Electric Charge +/-

Reaction Wheel power use +/-

Reaction Wheel strength +/-

That's all i can think of atm. If people like this example of EEP iterations, Feel free to add to it, debate existing parameters etc.

Lets get this suggestion noticed XD

[NeilC]

I think we're saying the same thing.

<...>

I develop C, A now costs $80, B costs $90, C costs $100.

Yes, precisely. I just don't think it should be "lumpy", so after A#1 at $100, A#2 costs 99 and A#3 costs 98. Then A#20 costs $90, and at that point I just happen to unlock B, which just happens to cost $100. As I continue to use A or B, both get cheaper. Cost decrease is continuous, blocks are lumpy.

If you're running 3 engines, wouldn't you get 3X the engineering data? And my idea of distance times time is mostly to avoid someone sitting on on the pad and firing it and not going anywhere. I think that probably should be worth something, but something in actual service should be worth more. And recovering spent equipment should be worth even more.

You would get 3X EEP for launching 3 engines, because you had to build 3 engines. I agree that recovering equipment contribute to EEP, but I don't think it should be as important as building - IE, more like 1:3 build:recover than 1:1. I'm on the fence as to whether orbital/suborbital flights are worth tracking for EEP purposes, but I'm not against it. I don't think multiple firings is worth tracking, and I don't think that taking an engine along for a ride to Jool should gain you additional EEP.

As I've said before, if you want to sit on the pad and fire an engine just for the EEP, have at 'er. I think that's a perfectly valid way to gain EEP, just like real world test firings are important. But in this game your engine won't spontaneously blow up because of a design oversight, and every engine launched will cost money. I think "farming" EEP by launching missions that do no science should be possible, but result in bankruptcy pretty quick.

[boomerdog2000]

Ooh now that's interesting Zaeo. Not quite the overpowered-ness of straight up procedural parts, but enough to tweak it for the task at hand. I like that a lot.

That would really give you the ability to customize your rockets without requiring tons of new parts. I am somewhat concerned of how it would save the specifics of the part data though. Don't want to cause anymore memory issues than we already have.

[Zaeo]

....I am somewhat concerned of how it would save the specifics of the part data though. Don't want to cause anymore memory issues than we already have.

Not a problem. It can be done with a separate "part config" for the same part, or even a separate parameter in the SAME part config that will load when called, for example:

MODULE
{
	name = ModuleEngines
	thrustVectorTransformName = thrustTransform
	exhaustDamage = True
	ignitionThreshold = 0.1
	minThrust = 0
	maxThrust = 215
	heatProduction = 400
	fxOffset = 0, 0, 0.8
	PROPELLANT
	{
		name = LiquidFuel
       	        ratio = 0.9
		DrawGauge = True
	}
	PROPELLANT
	{
		name = Oxidizer
		ratio = 1.1
	}
	atmosphereCurve
 	{
   	 key = 0 370
  	 key = 1 320
 	}

}

MODULE
{
	*name = ModuleEngines_it1      //modified Values
	thrustVectorTransformName = thrustTransform
	exhaustDamage = True
	ignitionThreshold = 0.1
	minThrust = 0
	*maxThrust = 205         //modified Values
	heatProduction = 400
	fxOffset = 0, 0, 0.8
	PROPELLANT
	{
		name = LiquidFuel
       	        ratio = 0.9
		DrawGauge = True
	}
	PROPELLANT
	{
		name = Oxidizer
		ratio = 1.1
	}
	atmosphereCurve
 	{
   	 *key = 0 380        //modified Values
  	 *key = 1 330        //modified Values
 	}

}

. All there needs to be is a config call of sorts, even if its just right clicking the part in the assembly and selecting the config that you have researched/unlocked. Cost of a rocket shouldn't be applied until it is put on the pad anyways, as there are a bunch of minor changes that happen with each new rocket version. Creating a 3d blueprint doesn't mean you test it, so the cost of the parts is adjusted and displayed beforehand.

Luckily, text files are tiny, I doubt it will be much of a problem until you get to those large mod packs, where each part needs 3-4 configs for 100+ parts.

Edited October 15, 2013 by Zaeo

[boomerdog2000]

Good to hear. Seems to make sense too. The more you use the part the more you can tweak those certain bits.

[NeilC]

I like the suggestion, Zaeo!

I'm a little worried that having Block A/B/C/D parts all doing different things might get confusing and hard to manage. Also, I think it's important that these upgrades are fairly small, nice-to-have things so they don't get gamey - like your Block A LV-T30 with the -.05 mass. Trouble is, this small upgrade really doesn't make it much more suitable as an upper stage, only marginally so. An LV-909 is still going to blow it out of the water on weight and efficiency because it's designed to be an upper stage engine.

I would prefer to see all the blocks do the same things, or at least complementary things for the basic type of engine it is.

LV-T30s are first stage engines - their improvements should focus on more thrust and more ISP at sea level:

A - thrust +5%

B - sea-level ISP +5%, weight +0.05t

C - thrust +10%

D - sea-level ISP +10%, weight +0.1t

LV-909s are upper stage engines, focus on weight and vac ISP:

A - vac ISP +5%

B - weight -0.05t

C - vac ISP +10%

D - weight -0.1t

LV-T45s with their gimballing are often used in sustainer stages - focus on thrust and overall ISP. I think you get the idea.

Cost would always increase for each Block, effects would stack with previous levels but it would take many many more EEP to get to the next level at each stage. Maybe A at 20, B at 50, C at 150, D at 300 EEP (max cost reduction point).

[shoveycat]

I hope someone at Squad reads these...

[Zaeo]

Yeah, but its only hard to manage once you unlock all of them.

there are no options if you have no EEP, thus its scaling complexity*good for new and old players*. Besides, I spend more time in assembly than i do anywhere else in kerbal. I design them based on Aesthetics, not performance if i can afford to.

As you see your setup for an example engine, That is how it is displayed, in a sense.

Tooltip Example of GUI element involving a Standard iteration and a Block A iteration.

LV-909:

*standard tooltip information*

LV-909 "Starcaller"

+3% Cost :+2% Vaccum ISP: -.-5 mass.

Adjusted Values: Cost:320, ISP:290, Mass:1.2

That's all the information available on the iteration, reducing complexity, but giving enough information to show what it changes. This reduces the area needed to display the differences....

They were meant to be examples, and yeah, they don't make MUCH of a difference, but When cost is considered, What is BETTER for the task at hand?

Values are determined by SQUAD if they accept this suggestion, I merely suggested for format for it, and you suggested the core idea for it XD

[boomerdog2000]

Oh I was taking these Block ideas as sliders for each part that you can customize to tweak the individual part for your setup, not entirely new parts.

Like,

Block A: you can modify thrust at the expense of isp, 1% each way on the slider.

modify cost at the expense of weight, same as above.

Block B: same as above only it's a 3% difference

Block C: 5% difference

[leax256]

I like the idea of putting the points into a pool that you could use to upgrade that particular engine. that way you can choose where your space program goes.

[NeilC]

Zaeo: Please don't take my posts the wrong way, I'm not arguing or trying to shoot your idea down! I really like debating these ideas to get them fully fleshed out, is all. We all know that the numbers we're tossing around here will need lots of playtesting, and that SQUAD will have the final say.

I had only thought of the blocks doing exactly the same thing, I like your idea of having them do slightly different things. I just think that the improvements should stack towards making each type of engine a better engine of that type. To me, there's no sense making a mainsail a little bit better for an upper stage since you wouldn't want to use it that way. Same with LV-T30s. That way it's easier to manage even when you've unlocked them all, since all the improvements are in the same direction and you're really making a choice on one axis only: better engine vs more cost.

boomerdog2000:

That's a great idea! Not as realistic as having set Block designs, like NASA uses... but I'm not sure that matters at all. A slider GUI might be more clear than the GUI I had in mind, which would come up when you right-clicked an engine in the VAB and would look something like:

LV-T30  B0     BA     BB     BC     BD
WEIGHT  1      1      1.05   1.05   1.15
THRUST  200    220    220    250    250
ISP     270    270    290    290    320
COST    200    220    240    260    280
       | SEL  | SEL  | SEL  | SEL  | SEL |  

GUI is just like right-click menus now, |SEL| represents a clickable SELection button. Only the changing parameters are tabulated, all else is listed as normal.

My only concern with sliders is making things like thrust vs ISP cost-neutral - I think each "tick" you move a slider away from stock values should always cost.

Maybe we just have s thrust v ISP slider and we leave weight out of it?

Maybe we have a positive-only thrust slider, a negative-only weight slider, and a vac ISP vs sea-level ISP slider?

I really like this concept of EEP limiting slider motion, let's flesh it out!

[astropapi1]

THIS.

We really need something like this for the game.

[boomerdog2000]

Having the sliders only have cost as a downside makes sense too.

Should the sliders move backwards as well?

I.E. Your space program is strapped for cash so you're cutting corners on engine design.

[NeilC]

I'm not sure I like backwards motion. It's a neat idea, I just feel like it's too min/max-ey. I see the EEP system as something that's only good for performance, always more expensive, and something that can be safely ignored by any player who doesn't want to bother.

Being able to reduce thrust/ISP to save cost or to shift those points around makes the system much harder to balance. I makes me fear there will be a forum post titled "The BEST way to set your sliders", and anyone who hasn't read it will just have far less efficient designs than anyone setting them the Right Way. I'd prefer to keep it simpler: the best engine is the one with all the sliders all the way to the right. It's just gonna cost you.

[astropapi1]

Long time ago there was a thread on this topic. It was a much more crude idea, but it was there. The OP suggested a system for reducing the cost of a rocket for every time it was launched. Kinda like what you're talking about.

It'd be interesting to see how reusability is integrated, since it's not just grabbing a lifter and attaching it to the payload. Struttage and some changes always have to be made, so detecting a "lifter" in the .craft file may be a little hard after adapting it to the payload. See how the crew tab resets after you add/change/move a part?

Of course, it could simply check every time you select the sub-assembly and place it on the craft; the problem with this would be people exploiting it. Imagine people building rockets with decoupler "heads", attaching them to a payload, and then removing everything but the decoupler and building a completely new lifter below it. They'd still get the reduced cost and part EEP for using the same "lifter".

We really need an dev's opinion on this. Just to see what they think about it.

[astropapi1]

The other aspect of reusability, actually picking up and re-launching a craft, will also play an important role on career mode. What if I developed this really cool Skylon-like cargo ssto plane, and land it safely on the runway? I shouldn't get 50% back, I should get the entire cost of the plane back. Refurbishing and fuel are minor expences compared to building a new freaking rocket/plane every time. Again, the devs could simply add a "check for wing, gear bay, landed" status-checking system, but people would find a way to exploit it, somehow.

There's also a problem with the 2.5km rendering limit. What if ai build a first stage with a metric crap-ton of chutes that activate on stage separation? How will the game calculate if it crashed or landed safely?

Sorry for kinda derailing into the reusability aspect of this suggestion, but reusability would take a big part on this system. Not only for the science! and "EEP" it gives you for using a craft repeated times in a non-controlled environment, but for the radical decrease in production costs and obvious increase in flights due to lower mission cost.

See? I'm getting all excited. This would make KSP more complex for the ones (most of us) which want it, and new players could completely ignore it while they get the hang of the game.

Edited October 15, 2013 by astropapi1

[NeilC]

It'd be interesting to see how reusability is integrated, since it's not just grabbing a lifter and attaching it to the payload. Struttage and some changes always have to be made, so detecting a "lifter" in the .craft file may be a little hard after adapting it to the payload. See how the crew tab resets after you add/change/move a part?

Of course, it could simply check every time you select the sub-assembly and place it on the craft; the problem with this would be people exploiting it. Imagine people building rockets with decoupler "heads", attaching them to a payload, and then removing everything but the decoupler and building a completely new lifter below it. They'd still get the reduced cost and part EEP for using the same "lifter".

I'm not sure you would need to detect a lifter, per se. It could be handled when you place it from the subassembly menu, just multiplying each part's cost by the current EEP bonus.

As for changes/abuse, one thing to note is that adding struts or other parts wouldn't change anything unless you're editing the subassembly itself. Attaching stuff to it in the context of a larger craft is just fine.

Removing things would be more challenging, you're right. I can see two ways of dealing with this:

1) make subassemblies non-editable "blocks" when you inset them in other craft. You can add them or remove them, and you can add things to them. but you can't change them.

2) If the craft editor has no concept of a subassembly at all after it's placed, track the part cost that was applied when subassemblies are placed, and when removing any parts that have less-than-stock costs, spider the tree and set all parts back to stock price. That way breaking up a subassembly removes the benefit. This would break if you placed 2 different subs and then broke up one - you would lose all benefits, not just the broken sub one. To get around it you'd have to make the editor aware of subs inside the craft, I don't know enough about the implementation of the new sub system to suggest how.

[Zaeo]

I know Neil, sorry if i sounded defensive. I wrote that in haste and didn't bother to read it over for presentation.

I was just trying to explain my thought process. I understand your thought process on the specific block upgrades, but it isn't specific to Category, but to individual parts.

For the Mainsail, Mass reduction, Heat reduction, improved ISP sea, and improved thrust comes to mind. Whatever role it fills now, it fills it better in different ways. The mass reduction is probably the best for the mainsail due to the reduced total weight the engines have to lift, thus improved fuel efficiency.

A lot of design thought per part, but pays off in the long run, and once implemented, it is a LOT less work for 2-4 parts per release vs all of stock immediately.

Either which way, I don't think a standard scale of improvements would be as "useful" as situational modifications, but again, its my opinion.

Thoughts on EVA space engineering consuming EEP or Science to change a parts configuration in Flight to "upgrade" existing ships?

IE, Right click on LV-45 engine, Click Configure button, And select Block B Engine, which would consume 2-3x the normal EEP to do, but it costs no money?

[NeilC]

I'm sure we wouldn't get all of stock revamped for EEP immediately, it's probably sensible to implement the system for engines-only at first and playtest it thoroughly before adding any other parts. But when we start talking about development increments, we're way out in Squad-only-knows la-la land.

I hear your opinion on situational mods for each engine being better than a defined trend, and I get where you're coming from. I disagree, but hey that's no problem!

I also disagree on EVA modifications, from a realism perspective. An astronaut on EVA just can't change the shape of the engine bell or the size and spacing of the holes in the injector plate, and those are the parameters that matter for engine thrust/ISP/weight.

Now, I DO think that it would be neat to gain additional EEP for inspecting an already-fired engine on EVA! You could learn something from pictures and observations, even if that engine later re-enters and burns up. Maybe 1/2 of the EEP you'd get for recovering, and it doesn't stack if you then recover the same engine? I'm not convinced implementing this would be worthwhile.... but it would be cool!