What do YOU want to see in 0.24?

[Captain Sierra]

Manipulable asteroids, like we heard about today with the NASA collaboration.

Also, RESOURCES.

Unlikely. Squad seems focused on a single scenario mission pack and there's about a 50/50 chance that the development of that will actually lay the groundwork for a good, off-rails asteroid belt like so many of us demand. I wouldn't get your hopes up on this, but maybe Squad will pull through and give Sandbox something great out of it.

Mining, i want to see, mining, even though they said no

They never said no, they just backburnered it and if they are not wanting to do it, then they are trying to make it quietly go away by ignoring it. Though I doubt it. The community demands it too regularly for it not to be done.

[pizzaoverhead]

3. Procedural generated terrain.. Well, I actually means is: use procedurally generated terrain as model, so don't generates them everytime player creates a new profile..

That can fix the consistency between each player's copy while keep away the tough modeling work from DEVs..

4. Procedurally generated asteroid?

The terrain is already procedurally generated. See here for details.

[Dunbaratu]

The terrain is already procedurally generated. See here for details.

While true, it's not in a way that's meaningful to the player since it generates the same exact terrain every time.

A bit like a world in which everyone playing Minecraft had to use the exact same world seed and could never change it. The fact that the terrain is procedurally generated doesn't matter if it's identical each time.

[pizzaoverhead]

While true, it's not in a way that's meaningful to the player since it generates the same exact terrain every time.

A bit like a world in which everyone playing Minecraft had to use the exact same world seed and could never change it. The fact that the terrain is procedurally generated doesn't matter if it's identical each time.

Random terrain is not the same as procedural terrain. Minecraft popularised both, leading to confusion in the terms. 8749236 specifically mentioned procedural generation being used to provide a deterministic output for every player in order to reduce developer workload. Having the same planets is very meaningful to the player as they can share their experiences on similar terms. It also matters in that the planets have their current level of detail without needing gigabytes of HDD space. This is why procedural terrain is often used in games that require huge terrain areas.

[Dunbaratu]

Add the "weathervane effect" to areodynamics already. It doesn't need to be the full blown accurate areodynamics model - just that one thing would help get rid of the biggest annoyance - unrealistic flipovers and spinouts. The main reason I don't do much spaceplane stuff in KSP is that I get frustrated with the fact that the chief challenge I face when doing so is a challenge based entirely on a buggy artifact of the simulation.

What I mean by the "weathervane effect" is the way that by virtue of the flat panel on its tail, a weather vane always tends to point into the wind. It happens because the wind pushes on the tail when the tail shows its side to the wind, and it has the least resistance when it's aligned with the wind.

The reason it's not happening is that drag is being applied to the craft as a summary global whole, rather than being applied to each part and calculating how those forces pull on the craft. If it was applied to each part, the fact that facing the tail into the wind drags the tail more would cause the tail to try to decelerate relative to the rest of the craft's parts, and thus tend to rotate the craft back into a position where the tail is in back. The groundwork for this is all already there, since when the craft is in space the rotations the craft experiences because of applying a force to individual parts is being calculated.

[Dunbaratu]

Random terrain is not the same as procedural terrain.

In a Venn Diagram, "random terrain" is contained entirely inside "procedural terrain". There is no such thing as non-procedural random terrain. And when you fix the seed in a random procedural algorithm and never allow it to change like I was describing, it stops really being correct to call it random either. It becomes a deterministic procedural algorithm.

Minecraft popularised both, leading to confusion in the terms. 8749236 specifically mentioned procedural generation being used to provide a deterministic output for every player in order to reduce developer workload. Having the same planets is very meaningful to the player as they can share their experiences on similar terms. It also matters in that the planets have their current level of detail without needing gigabytes of HDD space. This is why procedural terrain is often used in games that require huge terrain areas.

I'm aware of all that. It's also irrelevant to my comment. You chose to reply as if I was comparing random procedural generation to deterministic procedural generation, which I wasn't. I was pointing out that as long as the outcome is deterministic, regardless of how it got that way, the difference doesn't matter to the player.

The only way procedural generation would matter at all to the player is if it IS random or at least allows there to exist alternates or tweaks to cause changes. If you can't, as is the case with the dev's belief that its more fun for there to only ever exist one solar system configuration ever (1), then it's a pointless thing to ask for as a game feature. It's an underlying implementation detail, not an end-user game feature.

(1) Which I don't agree with. I think there is an easy compromise between "no shared experience possible because everyone's got their own different universe" and "no variation allowed ever so everyone has the same universe." and that is a moddable solar system generator. That gives more than one possible universe, but still only a few countable ones, as other solar systems would be mods.)

If the devs allowed that, THEN the fact that the terrain follows a deterministic procedural algorithm would start to matter to the user community.

[tetryds]

I was pointing out that as long as the outcome is deterministic, regardless of how it got that way, the difference doesn't matter to the player.

Yes it matters.

You probably know this, but forgot that, as pizzaoverhead mentioned, it saves a lot of HDD memory.

It also increases significantly the level of detail on the terrain mesh.

And it allows the terrain to be worked on a lot easier, the devs just adjust parameters until they get the wanted result, don't have to do it all by hand, at least not the details.

Allowing us to change those seeds, or settings could lead to weird behaviours, buggy meshes and weird texturing, so I don't think its a good idea unless you add an entire planet+mesh+texture+autofix to a planet generation, which devs stated they wouldn't like to do (somewhere on kerbalkon).

[Capt Snuggler]

I would like to see the Space plane parts redone. models and textures but mainly textures.

Wings, intakes, control surfaces. with the addition of air-breaks, larger landing gear, cargo bay.

The current parts are looking very dated and not in-keeping with the overall graphical quality of the game.

That would be tons of work for DEV...

of all the requests on here, you think re-texturing, a little remodeling and a few new space plane parts is "tones of work"? wahh? you crazy man, I like you, but your crazy.

[Wahgineer]

of all the requests on here, you think re-texturing, a little remodeling and a few new space plane parts is "tones of work"? wahh? you crazy man, I like you, but your crazy.

Agreed. Ever since the space centers' facelift, the spaceplane parts have become the oldest original elements in the game. It is about time they got up to date.

[tetryds]

Yeah, the spaceplane parts hasnt been touched for so long that I expect them to dedicate one update just for that.

And that will probably happen when they change the atmospheric drag and lift behaviour.

So, its no big deal to touch that before atmosphere gets redone since it will be forced to be changed when that happens.

But i don't think it get to be as complicated as FAR.

Few tweakables settings would be enough, we get the results at the flight.

The atmospheric changes will also require aircraft building tutorials, so thats one big update package.

[Majorjim!]

of all the requests on here, you think re-texturing, a little remodeling and a few new space plane parts is "tones of work"? wahh? you crazy man, I like you, but your crazy.

LOL! Love that movie!

Anyway..

I agree with you Snuggly one. Have you seen that Squad recently posted a job advert for a modeler and texture artist?

Looks like they are gearing up for some new parts!!

It would take a talented texture artist a only a few days to retexture EVERY stock part. Seriously, its not that hard to do.

MJ

Edited January 29, 2014 by Majorjim

[Capt Snuggler]

LOL! Love that movie! Hank the tank! Hank the tank!

Anyway..

I agree with you Snuggly one. Have you seen that Squad recently posted a job advert for a modeler and texture artist?

Looks like they are gearing up for some new parts!!

It would take a talented texture artist a only a few days to retexture EVERY stock part. Seriously, its not that hard to do.

MJ

Right! the parts current already have textures and the UV mapping is already done. unless you fundamentally change the mesh but even then it aint that bad. just redo/sharpen the texture.

MK2 and MK3 fuselage should be converted be cargo bays. air breaks are just big-ol flaps the pop out like a landing gear.

didn't Bac9 (the author of B9 aerospace) redo the KSC for squad? (YES) seems to be a no-brainer to me...

Edited January 29, 2014 by Capt Snuggler

[Majorjim!]

Right! the parts current already have textures and the UV mapping is already done. unless you fundamentally change the mesh but even then it aint that bad.

MK2 and MK3 fuselage should be converted be cargo bays.

didn't Bac9 (the author of B9 aerospace) redo the KSC for squad? seems to be a no-brainer to me...

Also, agreed.

If Bac9 is making the new spaceplane parts they wont be anything like the mod. They will ask him to completely redesign them. That may take time.

MJ

[rkman]

While true, it's not in a way that's meaningful to the player since it generates the same exact terrain every time.

While random terrain is possible with procedurally generated terrain, the primary point of procedural is to save a ton of time on content creation.

[Capt Snuggler]

Also, agreed.

If Bac9 is making the new spaceplane parts they wont be anything like the mod. They will ask him to completely redesign them. That may take time.

MJ

yeah, but even still, a lot of the work is already done. stock models, concepts etc. the functionality of the cargo doors them selves have been proven by that mod (and others).

any revamp would need to loosely fit the current collision mesh for the stock parts to maintain compatibility. but it seems obvious to me that the MK2 and MK3 fuselages, by their shape and weight, were designed with this in mind. it just seems to have been forgotten.

[Skyrunner27]

LOL! Love that movie!

Anyway..

I agree with you Snuggly one. Have you seen that Squad recently posted a job advert for a modeler and texture artist?

Looks like they are gearing up for some new parts!!

It would take a talented texture artist a only a few days to retexture EVERY stock part. Seriously, its not that hard to do.

MJ

of all the requests on here, you think re-texturing, a little remodeling and a few new space plane parts is "tones of work"? wahh? you crazy man, I like you, but your crazy.

.18 was this plus docking and you hear it was the last great update from multiple people on the forums. The simple fact is nothing is simple.

[Giggleplex777]

A data collecting instrument for the sensors (i.e. Graphoton).

[Captain Sierra]

How about an off-rails asteroid belt, like I think they should be focusing on instead of a mission pack for a sandbox game (does anyone else see the irony and possibly misdirection in that?).

[Ketsa]

(does anyone else see the irony and possibly misdirection in that?).

I'm afraid of the DLC.

[EnigmaRaptor]

Definitely adding more to the science tree. It seems short now and I feel like I am just getting started by the time everything is researched. I guess that might mean more parts or more "computer" functionality like Kerbal Engineer or Mechjeb? I absolutely think the concepts from remote tech should be added eventually, but with a less strict requirements to make it work. remote tech is too cumbersome to be any fun for me the way it is now.

And finally, but certainly not leastly... Imaging sensors for science! It's one of the basic ways we actually DO science, but it's not in the game!?

[aeTIos]

I'm afraid of the DLC.

I'm not. But that's because I will get all DLC for free. Huzzah, early adopters! :evillaugh:

[Dunbaratu]

While random terrain is possible with procedurally generated terrain, the primary point of procedural is to save a ton of time on content creation.

But my point is that this is a thread about features the user sees in the game, not features the developers see. It make little sense for a player to request a feature that's not relevant to the player experience. The only way the difference between procedural or manual terrain generation is relevant to the player is if the procedural terrain is NOT determinisitcally giving the same answer every time. As long as there is one and only one universe that ever exists in KSP anywhere and it's the same for every player, then the difference between procedural versus manual terrain is relevant only to the game developers, not to the players.

In other words, procedural terrain generation isn't really a user-visible game feature unless the devs drop their insistence that everyone must play in an identical universe.

Edited January 30, 2014 by Steven Mading

[Dunbaratu]

Yes it matters.

You probably know this, but forgot that, as pizzaoverhead mentioned, it saves a lot of HDD memory.

It also increases significantly the level of detail on the terrain mesh.

I didn't forget. I just recognize that the title of the thread is "what do YOU want to see in 0.24" and the "you" in that refers to the players not the developers. Developer tools don't belong in that topic. And as long as players are only allowed to ever see one and only one universe, the means by which that terrain is created is purely a developer-side issue. It belongs in the same category as what revision control system they're using, or their decision to use Unity, or their decision to use C#. These are not game features. They're implementation details.

[Superfluous J]

I didn't forget. I just recognize that the title of the thread is "what do YOU want to see in 0.24" and the "you" in that refers to the players not the developers. Developer tools don't belong in that topic. And as long as players are only allowed to ever see one and only one universe, the means by which that terrain is created is purely a developer-side issue. It belongs in the same category as what revision control system they're using, or their decision to use Unity, or their decision to use C#. These are not game features. They're implementation details.

If the stock game used up less memory, you could add more mods. Also, the planets' terrains granularity could be - in theory - reduced so that you could have features on the meter-level (or less) instead of the kilometer-lever. Also, you could have an infinite universe but I personally don't care about that. These are practical, player-desired benefits of procedurally-generated terrain.

Not every (or even many) players may know it, but if a player DOES know it that player should be able to request it. Especially because if they request "Detail down to the meter-level or less on every square meter of every surface of every planet" and people would chastize them that it's impossible because all the planets' surfaces are image files.

[frizzank]

I would like collision on scatter objects...