If you were to do it without "frames" you would need calculus i think.

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!

One more thing: I would use a polar system and split everything into r and theta compnents.

I wrote a small program to simulate an object in orbit. The window size should be set xMin=0 xMax=96 yMin=0 yMax=64. Ignore lines starting with "//" they are comments. (Thurst not modeled)

Code:

It's not perfect; there's no collision so if you get near the center of the planet the /(r^2) causes the projectile to shoot off into infinity. Nor is it precise; for some reason or another the orbit significantly drifts.

Wow, Thanks for all of your help everyone! The more I get into this, the more I realize how much I need to learn.

prgmTrouble: Thanks for those formulas, definitely going to be useful!
c4ooo: That's probably going to be really helpful! I think I will be able to add collision detection to it. However, I only have a rudimentary understanding of Basic, I'm not sure how to fix the drifting orbit (yet)

Actually, i think the problem with accuracy is happening becouse the timesteps are to big. Replacing L₁+L₂→L₁ with L₁+L₂/25→L₁ and L2+L3→L2 with L2+L3/25→L2 should lower the problem. (This paragraph was edited)

Also, as an optimization, L3 should be acceleration, not force. That way L₂+(L₃/M)→L₂ gets replaced by L₂+L₃→L₂. (Just remember to divide the thrust in newtons by mass before adding it to L3)

As I was looking through this thread again I noticed that I somehow missed mr womp womps code optimization. However, when I put it in, it now keeps giving me an 'invalid dimension' error.

my original code:

Code:


mr womp womps code:

Code:

Anyone know what's wrong? (I don't know enough Basic to fix it alone)

EDIT: Ans+sub(" ▫Ŝ^/",L₁(X+7Y),1 ##error takes me here

Presumably L₁(X+7Y) is less than 1, greater than the length of the string, or not an integer. I'd recommend Disping the contents of L1 and X + 7Y directly before that line, see what's going on, and then trying to trace back to where the incorrect element of L1 came from.

Ok, so I put in code that would continually show me the lists and all my various rockets got an error on
x=5, y=3
my first rocket with
L1={1,1,1,1,1,1,1,2,1,1,1,1,3,1,1,1,5,3,6,1,1,1,4,1,1}
L2={1,1,2,1,1}
L3={1,1,3,1,1}
L4={1,5,3,6,1}
L5={1,1,4,1,1}

All of the lists L2 to L5 make sense, It maps out the rocket perfectly. I don't understand why it's erring out at the last 1 of L3, maybe it's trying to go to the 6th number? It works perfectly fine with the other lists.
Here's a video if that would help

Yes duh, dim(L1)=25 while 5+3*7=26

The fix:


Code:


Thanks PT_ for your help!

This is looking really good! I hope the best of this project. Also, I will happily be a beta tester for this (when it's ready).

Thanks! Glad to see you're still supporting it!

This is to the 3 people who didn't want a KSP for the CE
*Why didn't you want a 2D KSP?
*Is there any way I could maybe improve it?

This is for me mostly:
0 received replies
possibly Mateo voted no as a troll?

Mateo wrote:

‎5‎:‎15‎:‎51‎ ‎PM [MateoConLechuga] Maybe I said no to troll

So it's been quite a while since my last update, and I'm sad to say that progress has about as slow as Doors 9, without as good of a reason though. (I'm no CEO)
Mainly for these reasons: End of school eating up my time (hoping for more time over summer), my lack of knowledge of physics (yes Cemetech has been a huge help, but it's just not enough. I need to actually learn physics with a teacher. However, I am taking AP physics next year so I should get all the knowledge and help I need at school.), my last reason is my overall limited experience with Basic, I just don't know enough tricks to get Basic to do what I want. (I'm sure you guys don't want to be just optimizing my code all the time )

Anyways, what I have done is figure out that, (duh) overclocking this program makes it run much smoother So now I have added settings! You can now choose to overclock your calculator when you start the program! (EDIT: You can also choose to disable the overclocking too. The default option right now is 'off') I've added several other things too, I jut don't remember them right now...

So if anything need clearing up I 'll try to clear it up here, I have not dropped this program, I will always continue to add more on to it. It'll just take a little while longer than anticipated. :\

I knew that this was an ambitious project when I started it, I (per usual with me and projects) didn't expect rocket science to be so frustrating.

Could there be an option to declock it back to its normal speed after you've finished running the program?



It is rocket science, after all. Keep going though; I know you can do it!

Do you mean reducing wait states... which is not technically overclocking, even though it has similar effects. If you do, I think you should just not talk about it at all, just reduce it in the background and set it back at the end, if the user exits the program in a bad way (like an error) then his/her calculator will remain faster until he/she turns it off, which isn't really a bad thing anyway.

You're right, I'm just reducing the wait states using this program. I don't know how to set the wait states back though, nor do I really need to. The reason why I have it as an option is because not everyone has prgmFASTEST and because it makes your calculator slightly unstable.

Not really unstable, I have never experiences a crash with 6...
and to set it back to normal, do

Code:

Should i use that in my game to make it faster?
(and hi mr womp womp )

Since your game is in ICE, using this won't make much of a difference, reducing wait states essentially increases the speed at which you can access memory, something that ICE code doesn't do very much. however, I'm sure you will get a marginal speed increase, just don't expect the 25%ish increase you could expect from running basic code with reduced wait states.