Devnote Tuesday: Fairing well

[NoMrBond]

Please no. Stock Tweakscale would be much more flexible.

Yeah, but node snapping is kinda might happen plausible, while TweakScale integration with stock is way out in the far reaches of super unlikely territory

I wouldn't complain, and they could always restrict it to structural/wings/parachutes etc for Career, I just wouldn't hold my breath (I'd cross my fingers though)

[kofeyh]

Yeah, but node snapping is kinda might happen plausible, while TweakScale integration with stock is way out in the far reaches of super unlikely territory

Tweakable code needs some work so it's less inclined to haemorrhage memory. Tweakscale has it's own set of issues; engines provide hysterical figures once scaled, for example.

There's actually far more flexibility in the existing code to add a more 'dynamic' nature to a number of existing parts. At this point however it's less about capability, and more about development choice.

This game has a distinct 'lego' feel due to fixed parts. This isn't likely to change much, even though from a longevity point of few, it probably has to.

As I mentioned above, there is actually a middle ground of having parts that are far more dynamic, with simple fixed restrictions used in Career and Science game modes to set boundaries for parts, at various levels. As you progress, more options/ less restriction (eg a single probe part that gains features as you progress) is more efficient than simply unlocking more of them with different features.

[GusTurbo]

I'm really excited about stock fairings because they could save my Saturn V at least 100 parts, taking it from 377 to 277, which would be game-changing.

Hopefully each fairing type will be reproducible within the new system. I'm pleased with everything Harvester has said in this thread.

Edited February 26, 2015 by GusTurbo

[Bill Phil]

You seem to be conflating "procedural fairings" (non-predefined-shape fairings) with Procedural Fairings (the mod). In Procedural Fairings you just place a fairing base and a fairing panel, and it automagically reshapes itself to fit the payload- am I right that you feel that this is "cheating"/"too easy" since it requires no effort from the player to ensure that the payload fits in the fairing? The actual description of how the fairings work by HarvesteR seems to imply that this is not the case for their implementation.

I see nothing in there about automatic fairing shaping, and several things about manual fairing shaping. If your desire is for fairings that are manually shaped by the player, you seem to be getting your wish.

I would rather have pre-set sizes. But a fairing built by the player is fine. And it technically isn't procedural. Well, it's a mix of procedural and something else.

[kofeyh]

I would rather have pre-set sizes. But a fairing built by the player is fine. And it technically isn't procedural. Well, it's a mix of procedural and something else.

If I have a fairing that is constrained in height by career limitation, and constrained in width based on career progression, how is that not a facsimile of a fixed fairing that is also constrained by build height, and fixed width - it leads to a fundamental outcome that is the same?

The only difference is that the former can be programmed to change during progression to allow for additional sizes. The later forcibly requires more parts.

In sandbox, this makes the fixed parts almost pointless; as the point of restricting payload has no intrinsic value. Apart from "fixed good, procedural bad", I'm not sure what you're actually trying to say.

I guess my point is, it's healthy to consider each part both in career and in sandbox. Procedural allows for both 'limited' as well as dynamic usage. Fixed is, well, fixed and is why we have quite a high part count as is, of which only a subsection may be used at any given time.

Having said that, HarvesteR seems to be using a hybrid model - dynamic, if you will - where I expect tweekables and the editor can be used to 'shape' fairings, based on a set of minimum and maximum values.

Edited February 26, 2015 by kofeyh
clarity

[Bill Phil]

In other words, it's procedural. The player procedurally-generates the part.

The beauty of KSP is that, even if I use entirely stock parts, my rockets will be, and can be, entirely different than yours.

KSP is many things to many people and allowing the parts to change shape or providing critical information (such as delta-V) does not, in any way, ruin the troubleshooting or puzzle aspect of the game (if developing a hybrid Buran/STS-style orbiter for RSS has taught me anything). Parts than can change their size or shape just give the player more options to design their craft without blasting their machine with additional memory-reducing parts.

That's not quite procedural. A player can make any shape. Then, a way for the computer to define that shape can be made. But that method wasn't the original way the shape was put together.

How can you say, for sure, that my rockets aren't similar to yours? I might build very similar to you. Sure it's unlikely. But it is possible. Most stock rockets start to look very similar to each other. MOST. Not all of them. But the majority are similar to each other.

KSP is about putting parts together. It's a basic mechanic. And if a changeable shape fuel tank is introduced, then that building mechanic will change. You might as well make the game all about building a payload, and then when you click "Launch" it asks you what kind of rocket you want. Parts that can change shape are not like a delta-V readout, which doesn't do much in the long run other than let you know a rocket's capabilities. Variable shape parts would heavily change the puzzle aspect, because then I don't need to do much thinking anymore if they're in the game. It would be something like letting me change the block shapes in Tetris. It changes the gameplay in a large way, making the game very different, perhaps not even fundamentally the same. Although this topic should be in the dedicated thread...

The problem isn't "ruining" per se... But changing it to the point of not being all that similar.

Memory can be reduced by making the textures more efficient, making the 3d models take less space (it's not that dependent on # polygons), and load on demand. Changeable Parts aren't the ONLY option...

If the game started with changeable shape parts, then that would be fine. But it didn't start with them, resulting in the game we have now.

[regex]

That's not quite procedural.

It is. Like other procedural processes in other games, the player can set the initial parameters upon which the feature is procedurally built.

How can you say, for sure, that my rockets aren't similar to yours?

I can't, but given the wildly varying nature of craft of the What Did You Do In KSP Today thread, I can say for certainty that not everyone builds rockets the way I do.

I'm skipping the middle part because it boils down to personal preference (in which case I always default to.more options rather than less).

Memory can be reduced by making the textures more efficient, making the 3d models take less space (it's not that dependent on # polygons), and load on demand. Changeable Parts aren't the ONLY option...

No, but they are one of the most immediate way to prune parts. Also, memory restrictions aren't the only reason to reduce the bewildering array of parts. I literally spend at least 1/4 of my build time trying to find the part I want to use. At least on the aerodynamic and fuel tank tabs I can easily grab a part and reshape it as needed.

If the game started with changeable shape parts, then that would be fine. But it didn't start with them, resulting in the game we have now.

The game hasn't come out of beta yet. Also, that's like saying that the 48-7S or the NASA parts shouldn't be balanced because they started that way. Edited February 26, 2015 by regex

[kofeyh]

How can you say, for sure, that my rockets aren't similar to yours? I might build very similar to you. Sure it's unlikely. But it is possible. Most stock rockets start to look very similar to each other. MOST. Not all of them. But the majority are similar to each other.

Yes and no, conflating two different causes for similar rockets doesn't really answer the question. Also of the various people I've watched play KSP (and I have watched quite a few) almost none look "similar to each other". Give 15 people a lego set with 20 pieces, and ask them to go away, build "a car" and bring it back. You won't get 15 identical cars. Some won't even be similar. Some may not even BE a car, from a traditional design point.

Initially, people build similar rockets (tall, thin or pointy and with fins because of what they see and hear) because most know what a rocket looks like. Then when KSP teaches you that that doesn't work, people eventually (though the lego mechanic) figure out a pancake will fly much better and will achieve orbit.

So you have an entire generation of people who started KSP building pancakes. Until they figured out the 'soup' and were able to make something that looks more like a traditional launch vehicle Does that mean every rocket should look like a pancake? or just that they are similar because of game limitations?

Standardised parts will not, automatically, mean standardised designs. It does not work like that. People and technology do not function this way. KSP started with a block-build concept, this is true, but it's not to force or create a fixed progression (that came later to a degree, thanks to career) - it was to give people a set of tools to go to space.

Edited February 26, 2015 by kofeyh

[kofeyh]

Also, memory restrictions aren't the only reason to reduce the bewildering array of parts. I literally spend at least 1/4 of my build time trying to find the part I want to use. At least on the aerodynamic and fuel tank tabs I can easily grab a part and reshape it as needed.

Part of the frustration in building in KSP at this point is both the bewildering array of parts, and the shear redundancy that such a large part catalogue creates.

Adding more parts to address perceived needs (rather than using a single part that has broader function to address actual need) adds to a) the numbers of parts chewing up valuable memory and spending the requisite 20 minutes hunting for it. I can't count the number of times I have looked at tanks, given up, and grabbed a procedural tank.

Often it ends up actually being close to an existing stock tank. Just because I can make it any size and shape, doesn't mean I will. But the flexibility exists to do either.

Related: I almost never use the various options available to filter parts; because the interface is interruptive to the build process. So I end up cycling through various tabs looking. Always looking.

Edited February 26, 2015 by kofeyh

[Bill Phil]

Yes and no, conflating two different causes for similar rockets doesn't really answer the question. Also of the various people I've watched play KSP (and I have watched quite a few) almost none look "similar to each other". Give 15 people a lego set with 20 pieces, and ask them to go away, build "a car" and bring it back. You won't get 15 identical cars. Some won't even be similar. Some may not even BE a car, from a traditional design point.

Initially, people build similar rockets (tall, thin or pointy and with fins because of what they see and hear) because most know what a rocket looks like. Then when KSP teaches you that that doesn't work, people eventually (though the lego mechanic) figure out a pancake will fly much better and will achieve orbit.

So you have an entire generation of people who started KSP building pancakes. Until they figured out the 'soup' and were able to make something that looks more like a traditional launch vehicle Does that mean every rocket should look like a pancake? or just that they are similar because of game limitations?

Standardised parts will not, automatically, mean standardised designs. It does not work like that. People and technology do not function this way. KSP started with a block-build concept, this is true, but it's not to force or create a fixed progression (that came later to a degree, thanks to career) - it was to give people a set of tools to go to space.

I never said they were ALL the same. I said that MOST were similar.

And watching people play KSP introduces a selection bias. :|

I didn't say that standardised parts results in standardised designs. I said most designs are similar. This is because of the "Average Joes" of the KSP community. (I'm pretty much one of them)They don't have very different play styles. However, as they get better and better they start to have their own designs, which start to drift more and more in difference. Even at their farthest, they're still similar. Similar =/= the same. All rockets have fuel tanks. And the majority of design styles are only different in how and where parts are placed.

- - - Updated - - -

It is. Like other procedural processes in other games, the player can set the initial parameters upon which the feature is procedurally built.

Would you call drawing a box on a sheet of paper procedural generation? Most wouldn't. Would you call sculpting a 3d model on a computer procedural? That's taking an input and drawing the result of the input. But that's not exactly procedural. Procedural would be giving it a set of instructions that gives you a different result and then letting it do that. In this case it's just showing you what has been done.

I can't, but given the wildly varying nature of craft of the What Did You Do In KSP Today thread, I can say for certainty that not everyone builds rockets the way I do.

There is more than likely a fair amount of selection bias in the What Did You Do in KSP Today thread.

I'm skipping the middle part because it boils down to personal preference (in which case I always default to.more options rather than less).

Changing gameplay would interrupt many players build styles. That was what I was getting at.

No, but they are one of the most immediate way to prune parts. Also, memory restrictions aren't the only reason to reduce the bewildering array of parts. I literally spend at least 1/4 of my build time trying to find the part I want to use. At least on the aerodynamic and fuel tank tabs I can easily grab a part and reshape it as needed.

?

I generally spend a few seconds looking for a part. The biggest delay for me is that the engines and the fuel tanks have been separated and I constantly click on the wrong one.

I mostly use certain parts more than others. I guess I instinctively know where they are.

The game hasn't come out of beta yet. Also, that's like saying that the 48-7S or the NASA parts shouldn't be balanced because they started

that way.

There's a difference between ironing out a game, and changing the gameplay severly. The latter is more extreme than the former.

[kofeyh]

And watching people play KSP introduces a selection bias. :|

KSP isn't a clean-room, or a science experiment that requires people to not know what it is or to build in a specific function. This game does not feature a "singularly correct" outcome to any given situation. This community willingly and freely shares ideas.

Many people who start this game, stop. They stop because of the daunting part count. They stop because they can't figure out how to make a rocket. They stop because the game has less of a learning curve, and more of a precipitous cliff. Adding dozens of new parts doesn't address any of this. It just adds more parts, for the sake of it.

This has been the response to any number of existing part balance issues. Just add a new one that's better. Because this is simpler than making an existing part more useful.

I didn't say that standardised parts results in standardised designs. I said most designs are similar.

The variable nature of each individuals understanding (or lack) of physics, engineering and the degree of lateral thinking will automatically ensure no such outcome. This is bounded by the games construction, structure and restrictions, yes. But that is not a simplistic cause and effect result.

Understand what you are saying but that is a considerable over-simplification of a far more complex situation.

This is because of the "Average Joes" of the KSP community.

I think we can have a sensible discussion without referring to people using such nomenclature.

All rockets have fuel tanks.

This is an oversimplification, and not a terrible accurate one, I am afraid.

[regex]

IWould you call drawing a box on a sheet of paper procedural generation?

No, that's not procedural. Procedural is telling the computer to build a part 3.75m wide by 10m tall with four sections each consisting of ten subdivisions.

Procedural would be giving it a set of instructions that gives you a different result and then letting it do that.

No, that's random generation. Procedural generation produces the same results from the same seed (in this case, the same player input).

There is more than likely a fair amount of selection bias in the What Did You Do in KSP Today thread.

So what? It proves the fact that many people design rockets differently than I do.

Changing gameplay would interrupt many players build styles. That was what I was getting at.

Interesting. How about a new stock aerodynamic system? Re-entry heat? How about thrust being calculated correctly? How will that affect your build style? How did career mode affect your build style? KSP is still an unfinished product and the gameplay has continually changed since it has come out. It will be balanced again for 1.0 and many of the parts you know and love may not work the same.

There's a difference between ironing out a game, and changing the gameplay severly. The latter is more extreme than the former.

I think you're over-inflating the issue and that you have never used procedural parts. There are many changes coming in 1.0 that will affect gameplay severely, I hardly think introducing some procedural parts (most especially, tanks would be incredible!) will be as drastic a change as you think they will be. Edited February 26, 2015 by regex

[Bill Phil]

KSP isn't a clean-room, or a science experiment that requires people to not know what it is or to build in a specific function. This game does not feature a "singularly correct" outcome to any given situation. This community willingly and freely shares ideas.

Many people who start this game, stop. They stop because of the daunting part count. They stop because they can't figure out how to make a rocket. They stop because the game has less of a learning curve, and more of a precipitous cliff. Adding dozens of new parts doesn't address any of this. It just adds more parts, for the sake of it.

How does this address what I said? I was saying that when you watch people playing KSP you have introduced a selection bias, skewing the results.

This has been the response to any number of existing part balance issues. Just add a new one that's better. Because this is simpler than making an existing part more useful.

?

The variable nature of each individuals understanding (or lack) of physics, engineering and the degree of lateral thinking will automatically ensure no such outcome. This is bounded by the games construction, structure and restrictions, yes. But that is not a simplistic cause and effect result.

Understand what you are saying but that is a considerable over-simplification of a far more complex situation.

Everybody falls somewhere on a curve, when you're measuring understanding of something. So, you can fairly accurately predict what they will build. You get even more accurate the more you know about the person. And there is a finite number of different types of people. People of the same type have subtle differences, but they think in very similar ways. Differences are inevitable. But most people are very similar. The rest are only a little bit less similar. People are surprisingly alike. It's weird.

I think we can have a sensible discussion without referring to people using such nomenclature.

Do you have a problem with using terms like that? Because I think we CAN have a sensible discussion using such terms. You are simply choosing not to. (And also wasting bits)

This is an oversimplification, and not a terrible accurate one, I am afraid.

Let me rephrase: All KSP rockets have fuel tanks.

[NovaSilisko]

What the hell are we actually arguing about, again?

[kofeyh]

What the hell are we actually arguing about, again?

Which way is 'up'? Who knows.

[Bill Phil]

No, that's not procedural. Procedural is telling the computer to build a part 3.75m wide by 10m tall with four sections each consisting of ten subdivisions.

In a text box, I presume?

That isn't exactly procedural either. You're telling it what to be, not giving it a seed. It wouldn't really have to use procedural generation for that. You could, in some other way, specify each thing on the object (the four sections, ten subdivisions thing). You're describing variable geometry fuel tanks/wings/fairings/whatever else.

No, that's random generation. Procedural generation produces the same results from the same seed (in this case, the same player input).

Different result as in it's not the same as another result for a different seed.

So what? It proves the fact that many people design rockets differently than I do.

Sort of. It proves that those people don't build like you.

Interesting. How about a new stock aerodynamic system? Re-entry heat? How about thrust being calculated correctly? How will that affect your build style? How did career mode affect your build style? KSP is still an unfinished product and the gameplay has continually changed since it has come out. It will be balanced again for 1.0 and many of the parts you know and love may not work the same.

That will hardly change my style of play. I already account for all those things. Heck, it'll be fun re-learning the atmospheric physics of KSP.

I think you're over-inflating the issue and that you have never used procedural parts. There are many changes coming in 1.0 that will affect gameplay severely, I hardly think introducing some procedural parts (most especially, tanks would be incredible!) will be as drastic a change as you think they will be.

I never used PROCEDURAL parts because they don't really exist. They're not actually procedural.

There is quite a large difference between changing the atmospheric conditions or adding re-entry heat and "procedural" parts. One affects flight, the other construction. A construction change would be harder to navigate around, so to say.

[federicoaa]

What the hell are we actually arguing about, again?

apparently, about the definition of a concept

[regex]

That isn't exactly procedural either. You're telling it what to be, not giving it a seed. It wouldn't really have to use procedural generation for that. You could, in some other way, specify each thing on the object (the four sections, ten subdivisions thing). You're describing variable geometry fuel tanks/wings/fairings/whatever else.

That's still procedural content. It may be built via player input, but the artwork and statistics in-game is are produced via an algorithm (from the player's seed input) rather than, say, a hand-edited text file.

There is quite a large difference between changing the atmospheric conditions or adding re-entry heat and "procedural" parts. One affects flight, the other construction. A construction change would be harder to navigate around, so to say.

Wait, atmospheric conditions or re-entry heat won't affect construction? Oh man, there are going to be a ton of happy players when 1.0 rolls around!

[White Owl]

What the hell are we actually arguing about, again?

One guy said procedural fairings are very bad.

Other people said they don't think they're bad, and wondered why the first guy thought they were bad.

Shortly after that point, control was lost and .... got weird. The crazy spiral commenced. Some people hung on for the ride, others ejected safely.

[CaptainKipard]

Two questions.

1. What is the patcher?
   
2. What is the problem with Rsync?
   

[AlexinTokyo]

1. What is the patcher?
   

A companion application to the launcher; it's intended to download any updates to the game that have been made available. My understanding is that it has never worked properly, and that, therefore, noone actually uses it.

[Pigbear]

In a text box, I presume?

That isn't exactly procedural either. You're telling it what to be, not giving it a seed. It wouldn't really have to use procedural generation for that. You could, in some other way, specify each thing on the object (the four sections, ten subdivisions thing). You're describing variable geometry fuel tanks/wings/fairings/whatever else.

Different result as in it's not the same as another result for a different seed.

Sort of. It proves that those people don't build like you.

That will hardly change my style of play. I already account for all those things. Heck, it'll be fun re-learning the atmospheric physics of KSP.

I never used PROCEDURAL parts because they don't really exist. They're not actually procedural.

There is quite a large difference between changing the atmospheric conditions or adding re-entry heat and "procedural" parts. One affects flight, the other construction. A construction change would be harder to navigate around, so to say.

I'm pretty sure you have no idea what you are talking about.

[cpast]

In a text box, I presume?

That isn't exactly procedural either. You're telling it what to be, not giving it a seed. It wouldn't really have to use procedural generation for that. You could, in some other way, specify each thing on the object (the four sections, ten subdivisions thing). You're describing variable geometry fuel tanks/wings/fairings/whatever else.

"Procedural" doesn't really have a solid definition, but given that apparently tanks in the Procedural Parts mod work like "set diameter and length and texture, and the tank adjusts to fit that," and no one in the community has a problem calling those tanks "procedural," I think it's a bit pointless to try to maintain that "telling it the appropriate diameter and height" isn't procedural. As far as I can tell, the term "procedural" in the community basically means "the part doesn't have a fixed size and shape, but rather dynamically generates the model and textures based on parameters that can be changed fairly easily" -- that is, the model (and textures) is procedural, and isn't limited to what someone made in Blender or other external software. Basically, the part model used ingame is dynamically generated by a subroutine (or "procedure") at runtime, rather than set beforehand in 3D modeling software and just loaded straight into the game. And by that standard, "sculpt this fairing that is then processed as one part and only shows as one part in the VAB menu" is certainly procedural. I think you're getting too hung up on Procedural Fairings and the way that does things, but even then you can tweak the shape of a PF fairing within certain parameters, and don't have to accept the automagically generated one.

I admit the definition is sorta fuzzy; from the dev's point of view, something can be procedural and yet hardcoded, if it's easy to change (e.g. if one number controls terrain on Kerbin, it's procedural from their point of view but not from ours, because we can't change that number).

Different result as in it's not the same as another result for a different seed.

I'm really confused what you mean here. If you supply different input to a PP or PF part, they produce different models. If you stick a different payload in a PF fairing, it defaults to a different model (yes, "thing contained in this part" is absolutely an input in the same way that "thing set by tweakables" is one; PF adjusts to both, proc tanks to the latter, these fairing seem to do input slightly differently, but all of them have some sort of input on the basis of which they create a model). "Seed" is not a concept that has anything to do with procedures; a procedure has parameters or arguments or inputs, but "seed" is a term only applicable to a PRNG (or, I suppose, a plant). From that point of view, "procedural" would be like "procedural level generation" in other games, in which it's a shorthand for "pseudorandom levels instead of handmade ones." But that's not the only use of the term; PF and PP don't have "seeds," because the point isn't to be pseudorandom. I accept that you didn't introduce the term here AFAIK, but it's still not a term one would typically use. Incidentally, the real term used to describe a function that produces different output when given different input is "not constant."

Sort of. It proves that those people don't build like you.

...which was kinda his point? There are many people who post on the "What have you done" thread. The fact that they don't tend to build like him establishes that his way of building is not the only way. I'd wager that many build *very* differently from him, since he plays RSS+FAR+RealFuels+other realism stuff AFAIK, and so his rockets are presumably mostly less ridiculous-looking than what stock players can easily do. I don't see how this in any way goes against "different people do stuff differently."

That will hardly change my style of play. I already account for all those things. Heck, it'll be fun re-learning the atmospheric physics of KSP.

But there are plenty of people whose style it *will* change. So is the rule "when Bill Phil already accounts for it you can add it, but otherwise no"? You account for those things, but players who don't know how real rockets work likely have not a clue that engine thrust is lower at sea level than in orbit (they didn't think fuel consumption changed either, but since KSP so far changes fuel consumption they assume that's how it works), or that reentering in a steep orbit from Minmus is going to be fatal for their astronauts. Columbia probably helped public awareness of this, but how many regular players do you think act like you have to stick heat shields on everything when the 3-person capsule doesn't even *have* something that works like a heat shield? Given that currently the obvious way to recover, say, a Goo canister from orbit is no better than "slap it on the side of a rocket and have it exposed to the full force on the atmosphere on reentry," and there's no issue with doing that in stock, do you think that adding reentry heat will not change people's style of play? I mean, that makes the whole concept of recovering experiments very, very different, with a lot more consideration to the cross-section of the rocket.

I never used PROCEDURAL parts because they don't really exist. They're not actually procedural.

And here's the confusion. When everyone else on the entire forum uses the term "procedural" one way, and you use it another way, then discussions are actually pretty much pointless -- you aren't even talking about the same thing as everyone else. You're hung up on "procedural" meaning "procedural generation based on pseudorandom seed," but that's not what the term means at all: all it means is that something is algorithmically generated based on input. Randomness is utterly irrelevant, and insisting on a definition of "procedural" that no one else uses means you should probably reconsider if you want to discuss things.

There is quite a large difference between changing the atmospheric conditions or adding re-entry heat and "procedural" parts. One affects flight, the other construction. A construction change would be harder to navigate around, so to say.

How do you figure? We've already had major changes in construction -- tweakables and gizmos (or do you think "you can offset a part in any direction, including to clip it inside something else" isn't a major change?) And it doesn't seem like this is even going to be too far a departure from current building -- you still control the shape of the fairing, just without having to use tons of individual parts and the standard generic VAB interface (you get a more optimized for the task one).

[NathanKell]

If the mesh is loaded by the game, it's not procedural. If the mesh is created by the game, it's procedural. It's really simple...

[TheMoonRover]

Finally, someone who knows what they're talking about.

I was starting to lose track of what people were arguing about.