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

Nik wrote:
Thrust should already be given from the engine's specifications and the throttle.

Interestingly, I've run into a very similar problem earlier - actually for Kerbal Space Program, I was writing a trajectory calculation tool for extremely low TWR spacecraft, which couldn't be approximated with point burns. What I ended up doing was to set a time step ("frame"), calculate the total applied acceleration in this frame, approximate the long burn as a set of tiny ones, one every frame, after every burn I calculated the new orbit and advanced by one frame by advancing the vessel's true anomaly by the given amount.

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.67410^(−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:

//Position
2→dim(L₁
//Velocity
2→dim(L₂
//Will use this to calculate force
2→dim(L₃
//mass of ship
1→M
//gravitational constant*mass of planet
400→G
//starting position of object.
{0,10}→L₁
//starting velocity
{7,0}→L₂
ClrDraw
Circle(48,32,5
Repeat getKey
//draw position
Pxl-On(64-round(L₁(2)+32,0),round(L₁(1)+48,0))
//find distance to center of gravity
√(L₁(1)+L₁(2))→θ
//Normalized and negate position vector, this gives a unit vector pointing to center of planet. Multiply it by G (gravitational constant*mass of planet) and divide by the distance squared. This is our gravitational force on the object.
-{L₁(1)/θ,L₁(2)/θ}*G/(θ)→L₃
//f/m=a. L₃/M is acceleration; acceleration is added to velocity.
L₂+(L₃/M)→L₂
//Velocity is added to position.
L₁+L₂→L₁
End

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. Very Happy

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) Sad
TheLastMillennial wrote:
Wow, Thanks for all of your help everyone! The more I get into this, the more I realize how much I need to learn. Very Happy

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) Sad

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:
"?
For(X,1,dim(L₁
Ans+sub(" ▫Ŝ^/\",L₁(X),1
End
sub(Ans,2,length(Ans)-1→Str1
"?
For(X,1,dim(L₂
Ans+sub(" ▫Ŝ^/\",L₂(X),1
End
sub(Ans,2,length(Ans)-1→Str2
"?
For(X,1,dim(L₃
Ans+sub(" ▫Ŝ^/\",L₃(X),1
End
sub(Ans,2,length(Ans)-1→Str3
"?
For(X,1,dim(L₄
Ans+sub(" ▫Ŝ^/\",L₄(X),1
End
sub(Ans,2,length(Ans)-1→Str4
"?
For(X,1,dim(L₅
Ans+sub(" ▫Ŝ^/\",L₅(X),1
End
sub(Ans,2,length(Ans)-1→Str5


mr womp womps code:

Code:
augment(L₁,augment(L₂,augment(L₃,augment(L₄,L₅→L₁
For(Y,0,4
"?
For(X,1,7
Ans+sub(" ▫Ŝ^/\",L₁(X+7Y),1 ##error takes me here
End
sub(Ans,2,length(Ans)-1
If not(Y
Ans→Str1
If Y=1
Ans→Str2
If Y=2
Ans→Str3
If Y=3
Ans→Str4
If Y=4
Ans→Str5
End
7→dim(L₁

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 Wink
The fix:


Code:
augment(L₁,augment(L₂,augment(L₃,augment(L₄,L₅→L₁
For(Y,0,4
"?
" ## I just have this here so this code isn't all green, it's not in my program
For(X,1,5 ##changed 1,7 to 1,5
Ans+sub(" ▫Ŝ^/\",L₁(X+5Y),1 ##changed 7Y to 5Y End
" ## I just have this here so this code isn't all green, it's not in my program
sub(Ans,2,length(Ans)-1
If not(Y
Ans→Str1
If Y=1
Ans→Str2
If Y=2
Ans→Str3
If Y=3
Ans→Str4
If Y=4
Ans→Str5
End
7→dim(L₁


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).
Caleb_J wrote:
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! Very Happy

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
Question possibly Mateo voted no as a troll?
Mateo wrote:
‎5‎:‎15‎:‎51‎ ‎PM [MateoConLechuga] Maybe I said no to troll Razz
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) Laughing
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. Sad 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 Smile )

Anyways, what I have done is figure out that, (duh) overclocking this program makes it run much smoother Rolling Eyes 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. Smile
TheLastMillennial wrote:

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


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

Quote:

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. Smile


It is rocket science, after all. Keep going though; I know you can do it! Smile Good Idea
Caleb_J wrote:
TheLastMillennial wrote:

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


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

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

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


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

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

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


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

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:
Asm84CEPrgm210500E03604C9
Should i use that in my game to make it faster?
(and hi mr womp womp Smile )
Pieman7373 wrote:
Should i use that in my game to make it faster?
(and hi mr womp womp Smile )

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.
  
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.

» Go to Registration page
Page 3 of 5
» 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

 

Advertisement