» Goto page Previous  1, 2, 3, 4, 5  Next

Would you like to see a KSP for the CE?
Yes   69%  [ 47 ]
No   4%  [ 3 ]
Only if it was really good   26%  [ 18 ]

prgmTrouble wrote:
Gravity is directly proportional to distance and mass: Just assume the spacecraft mass is one, and then you only have to mod the mass of the planet and the distance. G = 6.674×10^(−11) N · (m/kg)^2
Forces: Since we are assuming mass of the spacecraft is one, we have a direct proportion which states force = acceleration. Then factor in a direction using trigonometry where needed and subtract all relevant force vectors (thrust, gravity, and air resistance) to get a net force. Then divide by one and you have acceleration.
Kinematics: With acceleration already sorted out, anything else you need is found with the kinematic equations. Just remember that acceleration changes direction constantly if you move around the center rather than just away.

Hope this helps!

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!
deuteriumoxide wrote:
prgmTrouble wrote:
Gravity is directly proportional to distance and mass: Just assume the spacecraft mass is one, and then you only have to mod the mass of the planet and the distance. G = 6.674×10^(−11) N · (m/kg)^2
Forces: Since we are assuming mass of the spacecraft is one, we have a direct proportion which states force = acceleration. Then factor in a direction using trigonometry where needed and subtract all relevant force vectors (thrust, gravity, and air resistance) to get a net force. Then divide by one and you have acceleration.
Kinematics: With acceleration already sorted out, anything else you need is found with the kinematic equations. Just remember that acceleration changes direction constantly if you move around the center rather than just away.

Hope this helps!

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 mr womp womp wrote:

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.

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!)
deuteriumoxide wrote:
...if you have more time...

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.

Oldmud0 wrote:
(if anyone finishes KSP-CE, please be sure to add a hidden particle effect for money for the rocket exhaust!)

Hmm... That's a good ide-wait, hold up.
Oldmud0 wrote:
if anyone finishes KSP-CE

⁰—⁰

***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:
`(1) q''(t) = gravity_acceleration(q(t)) + engine_acceleration(q(t), t)`

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:
`(2) Y' = f(t, Y)`

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:
`(3) Y_n+1 = Y_n + f(t_n, Y_n) * Δt`

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:
`(4) Y_n+1 = Y_n + Δt * sum(b_i * k_i) | i = 1 to s`

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:
```c_1 | c_2 | a_21 c_3 | a_31  a_32 ... | ...   ...   ... c_s | a_s1  a_s2  a_s3  ... ----+----------------------------     | b_1   b_2   b_3   ...   b_s```

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:
```  0 | 1/2 | 1/2 1/2 |   0  1/2   1 |   0    0    1 ----+-------------------     | 1/6  1/3  1/3  1/6```

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:
```k_1 = f(t_0, Y_0) k_2 = f(t_0 + c_2 * Δt, Y_0 + a_21 * k_1 * Δt) k_3 = f(t_0 + c_3 * Δt, Y_0 + (a_31 * k_1 + a_32 * k_2) * Δt) k_4 = f(t_0 + c_4 * Δt, Y_0 + (a_41 * k_1 + a_42 * k_2 + a_43 * k_3) * Δt```

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.)
deuteriumoxide wrote:
F=ma assumes that mass is held constant; however, in a rocket mass is constantly decreasing because the burning propellant is constantly being expelled.
Good Luck!

Thats why you calculate all the forces / speeds every time step Again, Thanks Nik! I'll finish reading that in about 5 years. _iPhoenix_ wrote:
Has any tangible and visible progress been made, besides math?
(I have nothing against math, but eye candy is a thing I like.)

Nope, just math. Besides the Map view all my graphics and eye candy is pretty much done. (I hope)
TheLastMillennial wrote:
Again, Thanks Nik! I'll finish reading that in about 5 years. _iPhoenix_ wrote:
Has any tangible and visible progress been made, besides math?
(I have nothing against math, but eye candy is a thing I like.)

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! TheLastMillennial wrote:
it can still only be a mono-colored rocket 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.
_iPhoenix_ wrote:
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

Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

»
» Goto page Previous  1, 2, 3, 4, 5  Next
» All times are UTC - 5 Hours

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum