Just an idea, if you have more time and want to make the physics of the game more accurate (and more complex) you have to use the Tsiolkovsky rocket equation. F=ma assumes that mass is held constant; however, in a rocket mass is constantly decreasing because the burning propellant is constantly being expelled. The Tsiolkovsky rocket equation is as follows:

ΔV = Vex × ln (mi / mf)

ΔV: Change in velocity
Vex: Velocity of the Propellant
mi: initial mass (the rocket body + the total propellant)
mf: final mass (basically the rocket's mass after all the propellant has been burned and expelled)

The change in velocity is equal to the exhaust velocity of the propellant times the natural log of the inital mass divided by the final mass.

The equation can also be rearranged to give this:

mi/mf = exp(ΔV/Vex)


An example:

In order to keep an object in Low Earth Orbit(LEO) an object should be traveling at around 9000 m/s (this is the change in velocity or ΔV).
We assume our rocket is a chemical rocket that can expel its propellant at 4000 m/sec (this is the exhaust velocity or Vex).
Thus
mi/mf = exp(-9000 / 4000) =
mi/mf = exp(-2.25)=
mi/mf = 0.105 = 10.5%

The ratio between the initial mass and the final mass is 11%. This means that 89% of the rocket's inital mass has to be gone by the time all of the propellant is burned away. Basically 89% of the rocket's total mass has to be propellant and so only 11% can be devoted to the rocket body, payload, life support, etc. If you've ever wondered why its expensive to get a kilogram to orbit this is why.

Note: I am not a rocket scientist or engineer so I if there are real rocket scientists or engineers or more knowledgeable people here feel free to correct me.

Here's a basic aerospace engineering course if you want to learn more:
https://www.edx.org/course/introduction-aerospace-engineering-mitx-16-00x-0


Good Luck!

Yes, the delta v equation can be derived from newton's equations, they are essentially the same formulas written differently.
As for the 89%, although that figure sounds like a plausible and sensible answer, it is not why it is so expensive to put things in space.
According to these sources, tho total cost of hydrogen and oxidizer for the space shuttle's main tank is about $1,380,000. You can buy APCP on amazon by the pound for $13 per pound, of which there were about 1,000,000 in each SRB on the shuttles. This makes a very high estimate of $26M for the SRB propellant, and a total of $27,380,000 of fuel in a shuttle.
However, according to NASA, "Recent NASA estimates peg the shuttle program's cost through the end of last year at $209 billion (in 2010 dollars), yielding a per-flight cost of nearly $1.6 billion."(URL). So the fuel cost about 1.7% of a shuttle launch, even though it represented the vast majority of the wet mass.
The fact of the matter is that the costs of spaceflight are mostly related to R&D, administrative stuff, the more expensive parts such as engines, and in the case of NASA, random intermediate hoops that it has to jump trough because it is a government organization. Contrary to popular belief, the raw materials (generally a hunk of aluminium, a few fancy alloys, and some fuel) aren't really the expensive part at all. Elon Musk once stated that the fuel on a Falcon 9 only costs about 200k, which is pretty insignificant as far as spaceflight goes, even for non-government funded institutions like space-X.

Likewise, I am not a rocket scientist, nor do I claim to be a knowledgeable person on the subject, I'm simply an enthusiast

Er, I'm pretty sure he was talking about mass, not cost. Too bad $1 bills do not make great combustibles...
(if anyone finishes KSP-CE, please be sure to add a hidden particle effect for money for the rocket exhaust!)

Ha! free time... umm, what's that again?

I'm kidding of course
Thanks for reposting those equations and explaining (very nicely) the ones you added! I'll be sure to add those in! I'm having a little trouble with navigation on edx.org, I've gotten enrolled in the class, but things happened and... well, I'll just have to mess around with it.

Also, thanks everyone on the pricing ratios, I'll add those in the ASM (or C) version.


Hmm... That's a good ide-wait, hold up.

⁰—⁰

***TheLastMillennial trudges off the stage

As mentioned in SAX, I am now posting a cool bit of maths I got from a KSP channel...

My problem was to simulate extremely low TWR burns, ones you could not simply approximate as a point burn, or many point burns, for that matter, but which represent something continuously changing. Pretty much exactly what your problem of defining an orbit is.

So the guys in that channel suggested I set up an equation. Consider your position is q and the time is t, so q(t) yields your position at any given time. Now consider this:

Code:

Now, here comes the, in my opinion, most beautiful realization of the whole thing: If your position is q, the derivative of q, q', is the change in position, or the velocity! Equally, q'' is the change in velocity which is the acceleration. Now it should be easier to understand equation 1.

Next consider this:

Code:

This is an ODE, an ordinary differential equation. Sounds scary. It is, actually. But well, we live in a scary world, so let's just deal with it:
We know how to solve an ODE, or rather we will know in just a bit of time, so we need to transform our equation 1 to the form of equation 2.

You may express your position, velocity and acceleration as a vector of three components each in a regular 3D space (or two components in 2D). Now, our equation 1 has a second derivative and the equation 2 does not, so let's fix that. We now introduce a new vector Y which has six components (or four in 2D): position x, y[, z], velocity x, y[, z], or rephrase that as position x, y[, z], position' x, y[, z]. We also introduce a new function f(t, Y) which outputs the derivative of this vector given an input t (time) and Y (the vector itself). This function basically does what the right hand part of equation 1 did - it combines engine and gravity acceleration.

And look what we've got! We now reached Y' = f(t, Y)!

Now on to solving this. As mentioned earlier, this is an ODE, and there is a variety of methods solving ODEs. Some of them perform better, some worse. One you may have heard of is Euler's method. Basically what you do is, consider you have a point on the function's graph, and you want to take the next point. So you get the current derivative and assume it just stays constant until the next point, so you basically draw a straight line to get the next point. This is obviously not a good approximation at all, so you should not use it. However, here's the maths anyway, for the record:

Code:

Where Y_n is your current point, Y_n+1 is the next point, t_n is your current time and Δt is the change in time between now and the next point. The smaller Δt is the better the approximation, but Δt has to be really small for the solution to be exact over a longer period of time.

Now there exist better approximations. For example start with Euler's method, take the derivative of your current point, but instead of using that for the next point, calculate the average between that and the derivative of the next point, and use that to determine the next point. This sounds better, doesn't it? It makes a guesstimate of the overall average derivative, anyway. This is called the midpoint method. I won't show the maths here, it is a bit complex.

Anyway, you can continue averaging those derivatives up until infinity, but it gets computationally intensive really fast, so you usually only do it four times. This chain of methods is called "Runge-Kutta Integrators" and the particular fourth order method is usually referred to as "the" Runge-Kutta Method. And, brace yourselves, the maths is indeed mind blowing and impossible to fully understand, at least for me. But you don't need to understand it to use it.


Code:


Where b_i are order specific constants (our order is 4, remember), k_i are constants computed each step and s is the order (4!).

Now, how to compute k_i and what b_i is... You have a table, which is fixed for a method and basically those constants define the method:

Code:

This is the Butcher Tableau and you don't mess with it. The numbers are just ther and you just use them.
For our fourth order Runge-Kutta Method, this Buther tableau looks as follows:

Code:


The constants k_i have general formula, too, but let's just skip it and leave it as an exercise to the reader, for we are looking at a particular fourth order method and thus we may keep only four fixed equations. (And, to be honest, I am tired of typing this post by now...)


Code:


And finally, where I have most of this from: https://raw.githubusercontent.com/mockingbirdnest/Principia/master/documentation/ODEs%20and%20Runge-Kutta%20integrators.pdf. Really, you should have a look. It's complicated, but what I am explaining is based almost entirely on how I understood this. No guarantees and no liability and things, you know...

Has any tangible and visible progress been made, besides math?

(I have nothing against math, but eye candy is a thing I like.)

Thats why you calculate all the forces / speeds every time step

Again, Thanks Nik! I'll finish reading that in about 5 years.


Nope, just math. Besides the Map view all my graphics and eye candy is pretty much done. (I hope)

Never mind, I've decided that while I'm learning and implementing the formulas, I'm going to try and move CSP from the home screen to the graph screen.
1. It'll look a lot nicer
2. With build mode I'll be able to let people build rockets larger than just 25 pieces
3. I can make custom looking parts!
4. When launching your rocket it'll be able to rotate (along with a possible NavBall)
4.5. Unfortunately the only way to easily make the craft rotate is with plot sprites and although the sprite will be more flexible, it can still only be a mono-colored rocket
5. I can add a simple fire animation under the rocket engines (just altering between V and v )

Some downside though.
1. I've never made a full program/ game with the graph screen before. (Although I have since the last post done some small tests with plot sprites and such so I'm fairly comfortable with that.)
2. If I add custom parts (like a better looking pod instead of just a ▫ ) then my compiler that takes the parts from the build screen and adds all the attributes to them, is also going to have to build custom rocket pieces out of ASCII pieces. This'll make it take much longer to finish.
(I may add more points later)

I would say that this shouldn't be too hard, but nothing is ever easy.
Here I go!

Awesome! I love the idea of plotsprites. This should be difficult, but nothing that you can't overcome. I can't wait for screenshots! Good luck Millennial!

Guess what? I'm wrong!
I just found out that I can have multiple (up to 3) plot sprites on the screen at once! So if I can figure out how to get the NavBall into just its own list, then I can make the rocket up to three different colors! Just for fun I'm allowing you to change those colors in the settings.

I wanted to get a GIF in here, but unfortunately CEmu refused to work correctly for me. Nope, it was my fault not CEmu



Please note that this model is an early beta model an will probably be changed. I just wanted to show that I got the rotation and colors working.

Hey I just want to give a small update about events that are going on. Tomorrow I'll be going out of state for a few days. I'm also going to take a small break from this program (just for a few days) since I've stressed myself out too much over it and I've actually had nightmares about crashing space ships since physics weren't there.

While I'm taking a break I'll be working on a different program, one that'll make hardcoding sprites much easier. With it I'll also be able to (hopefully) create more complicated and interesting sprites.

Lastly I'd like to give a big thanks to everyone who has helped me so far. I never would have even made it this far without your guy's help.

This will be amazing.

I really badly want to see this finished.
I would gladly help, whether it be designing sprites, optimizing, or anything else.

If you see this during your "break", get back to your break!

The framerate could really benefit from some asm or c :/

You know what, if a project is complicated enough, I don't really care about framerate if the code is optimized.

But yes, C or ASM could be a better language.

Small update,

I've been back at this for a little while, I just forgot to post it here.
I've never worked with the graph screen before so this is a new learning curve, but it's nothing too complicated. Unfortunately, this is requiring me to rewrite all the graphics, but oh well, C'est la vie, it gives me something to do when I'm not befuddled.

EDIT: oh, yes. I'm hoping to rewrite this in C at some point.

It's better to redo a blueprint than to redo a skyscraper, so I recommend switching to C ASAP.

ya-know, you're right. Now where are those C tutorials...

Im going to be honest, you can theoretically get any combination of ti-basic colour with plotsprites; merely save your three objects and display them, then save them to a picture. Then render the next 3 color areas. Recall the picture on top of the new render, and save it again.

Sure, its slow and maybe rapes your memory, but it works. Just remember that in this method, your picture goes on top of the plotsprites, so IF you choose to do this you design your end-goal sprite with this in mind.

Good luck, iphoenix TheLastMillennial! At least the graphics will get a huge improvement. I can't wait for screenshots!

sorry for the typo