[Gaming] The Kerbal Space Program - Version 0.20.x

[krashkart]

Cool beans! I had a feeling about that the other day when I looked at it.

Really looking forward to seeing the final product.

[Pyromaniac605]

One question about the R&D.

Will it be similar to Total War and a lot of other games with research where there is a large tree and you need certain things researched or developed to research and develop other things?

I think a really in depth R&D system like that would work great in a game like this.

[Ripley]

Quote:

Originally Posted by HarvesteR

 ...hire less stupid crew...

I don't know why, but you made me think about him.

[jedimaster1214]

I have another question.

1.)Did you put random failures into this?
I tried to separate my final stage after Entry Interface, but won't seperate no matter how many times i press {SPACE}. (A bug?)

2) How is the planet's geography compared to Earth's? is it totally made up, or slightly different, etc. (cause i swear i flew over the united kingdom... )

[diogom]

1. Did you put a decoupler? Happened to me yesterday, only to realize I had no decoupler.

[HarvesteR]

I haven't yet given much though to how R&D will function, but it'll probably be something like a tech tree I imagine. You can't discover the top-notch solid booster if you've only studied parachutes now, can you?

Also, the plan is to include tech tree info in the cfg for each part, so mod makers can make parts that must be researched. This way mod parts can be integrated with the gameplay, and not just add volume to the content. I think Total Annihilation was a game that did this. Modders could make new units, and decide in which construction facility that unit would be built, essentially integrating it with the game's tech tree (there was no research in TA).

Anyhow, about how things are going today, I've managed to add pages to the parts list this morning. So now whenever a category has more parts than the list can hold, buttons to flip through pages pop up. The limit is set at 18 parts per page ( 6 rows ), so it's unlikely this feature will be used right now, since we only have 11 parts so far

But since people are already making mods, I thought it'd be a good idea to put this in now, before the amount of user-made parts can overflow the list.

Now, I'm about to start on the fuel tank code... I plan to restructure it all, to make it simpler to keep coding, and also make them stackable.

Also, If there's time, I'd like to create a module for an Oxidizer tank... You may have realized that those engines will burn without oxygen now... with the oxy tank, you'll need them too if you expect to reach space.

After that, comes more bug fixes, like getting the Undo/Redo actions back in the game (it used to exist, but there was a bug with them and I disabled it because there was o time to fix it), fixing the part-poke-through problem in the VAB, and finishing up the indicators on the parts...

Hopefully all this can be done before the end of this week, so we can start working on the bonus features, which I'm itching to get to

Cheers

EDIT: double 'd!

I haven't put in any random failures yet... It seemed flying was already chaotic enough to have to deal with parts all of a sudden deciding they want to not work anymore or just explode ...I think your problem might be that your decoupler isn't actually a decoupler (the tricoupler is an adaptor, it won't separate the craft), or the ship might be crumbling under it's own weight (or g-forces), and the control linkage is severed.

Hmm, this is a good point... I should make the parts indicate if they become disconnected from the control feed for any reason.

The ship works like this: The command pod is the only part that receives input from the Input gathering systems in the game. It then sends a control update to every part that's connected, and they do the same, and so on recursively.
So if a part becomes disconnected from the ship (by decoupling or by, erm, accident ), it will be cutoff from the control feed and becomes stuck at the last control setting it received. (that's why SRBs and engines will keep burning if you don't throttle down before separation)
But yeah, there's no visual indication that a part is connected or not to the control feed... Maybe the icons should change color to indicate that.

About the planet, yeah, it's totally made up. Although there are many parts of it that resemble earthly geographic features (I guess that's a good thing )

Cheers

[jedimaster1214]

Quote:

Originally Posted by diogom

 1. Did you put a decoupler? Happened to me yesterday, only to realize I had no decoupler.

Yes, i did. at MECO had:

^ <---Parachutes
/ \ < ---- Command Module
{ }<----Decoupler
[ ]<----SAS Module
| | \
| | \
| | <-----Solid-Fuel Stage
| | /
\ / /
^ /
/ \

I pressed [SPACEBAR] maybe....50 times. All i'd hear is a click, then nothing.

EDIT: 'd
Then i have no idea why it didn't separate.

[HarvesteR]

Ok, new quick update here!

I've started reworking the fuel tank and liquid engine logic (which were a mess), and they're much better now.

Also, I've added the ability for fuel tanks to stack onto each other. So a single engine can drain as many tanks as you can pile on top of it.

The tanks now also update their mass as they are emptied. Through the cfg you can define the wet mass of the tank (standard 'mass' parameter), and it's dry mass as well.

Now, I have a question for you guys... about draining order... which is more realistic? to drain the stacked tanks top-down, or bottom-up? Think of how the CoM will shift as the tanks empty...

Cheers

[Fabri91]

I guess the top of the tank would empy first, since due to the acceleration the fuel flows to the bottom and is pumped from there to the engine(s).

[iamwearingpants]

I'd say top down, AFAIK the acceleration and gravity would force the liquid down unto the lower parts of the tank. Assuming it's not compressed.


EDIT: Yay, 200!

[HarvesteR]

That's the thing, stacking fuel tanks doesn't make them into a big one... they're still separate compartments...

So it's a decision the Kerbal engineers would have made

But yeah, top-down does seem better.

Cheers

EDIT:

top-down it is then!

I'm also recoding the engines now, trying to clean up that mess... I went through the trouble of creating a huge class interface for all modules that extend the generic part class... and it seems I went out of my way to not use it later

Now it looks better, and I've realized something... it seems the SRBs aren't losing mass as they burn... I'm about to add that now, and I was wondering if anyone knows how much mass usually is fuel in a solid booster?

Cheers

[Fabri91]

Ah, now I understand!

We can make-pretend that a tank has plumbing on top and on the bottom to receive-transer fuel from/to another tank. This way fuel would still continue to "flow" down like it were a big tank.
The top tank feeds the bottom tank which feeds the engine and so on...

[jedimaster1214]

I think it should burn just like the real SRB's do.

which is bottoms up, right?

[DaveS]

Quote:

Originally Posted by jedimaster1214

 I think it should burn just like the real SRB's do.

which is bottoms up, right?

SRBs burn from the inside out.

[Urwumpe]

There are many different grain geometries for solid rocket motors, with different burn profile, grain mixtures and different thrust profiles.

Most common though is the simple inside out, followed by a star shape. For short high thrust burns, you use a grain with many long channels drilled into it.