No, there is going to be a huge setback because I actually need to learn ASM first. And that takes at least one month to learn. I also am busy with school right now. This is going to take a while...

This is my shackle for not doing everything that i want to in C... I need to actually learn it first!! ;P

so, uhh, when you mean 2d ksp, you mean like this?.

Probably something similar to that, I'll draw some ideas from it and rearrange the building process and the launch so it's more calc friendly. I'm not sure if I'll include rovers since the calculator probably couldn't handle it.

I went through the learn to code in assembly in 28 days over the summer, and learned how to code in assembly ( although I haven't really written a fully functional program yet). Can I help with the programming?

A good idea would be to plan out the entire program before officially beginning the coding process. it will not only give you time to learn ASM (or C), but it will also create a solid foundation for the project and prevent confusion with respect to what exactly needs to be coded.

So I've decided no assembly for now, instead I'm making a Basic version of this. I've got the ship builder finished and now I just need formulas, LOTS of formulas. I have looked at several websites for the physics and astrodynamics equations. However, as you can probably guess it's rocket science, it's complicated. So my question is, does anyone know astrodynamics? or any physics equations that would be useful for this program? or maybe a website that could explain the formulas in laymans terms?

It shouldn't be to hard, all you really need is trigonometry and algebra. After all, it's only rocket science
Edit: if you write this in C or asm i will be willing to do a physics engine for it.

If I were to simplify a lot, you only need two equations:

F = ma, or perhaps rearranged to a = F/m. Given a known thrust (easily simplified to be constant or at least a simple fraction of maximum thrust) your acceleration is the thrust divided by craft mass.

Assuming some kind of known time step (easily implemented as a fixed frame step), mass of the craft changes at a rate roughly proportional to thrust (as a proxy for fuel flow).

Meanwhile, gravitational acceleration g = Gm/r², where G is an arbitrary constant, m is the mass of the parent body (simplifying such that your craft has no gravity of its own since it's a very small mass) and r is the distance from the center of the parent body.

Then it's just a matter of doing vector addition, where a little trigonometry comes in handy (since it's easy to treat all bodies as spherical and you want some arbitrary common coordinate system). Acceleration due to thrust is a vector of magnitude a opposite the direction of thrust, and acceleration due to gravity is a vector of magnitude g towards the center of the parent body.

Actually, in KSP, the celestial bodies are "on rails", which means they literally cannot be moved (since this could cause them to fall into unstable orbits and maybe someday crash into each other). Therefore, it would be staying true to the original game if you ignored the gravity induced by the mass of your ship. Besides, the mass of a celestial body would be several orders of magnitude greater so any change in trajectory would probably be rounded out by the numbering system used.

Thanks Tari and mr womp womp! This was a huge help. I'll go work on implementing the formulas now.
c4ooo, That's a really nice offer. Of course it'll be a while before I can get started on an ASM version of this, but I'll keep your offer in mind.

I would recommend doing this in C if I were you; but that's just me Best of luck!

So I've gotten the game to a fairly playable version now. However I'm running into some a strange bug. For some reason the program (ZLAUNCH) is spawning my rocket at y=8 instead of the y=5 (I set it at the beginning of the program.)
here's the link to the 3 programs needed to use this. (prgmCSP is the main program) I also put as much commenting as I could so it will be easier for you guys to figure out my code.

Link removed

If any of you could point out my (hopefully just a simple, stupid) mistake, that would be amazing! Also any optimizations would be greatly appreciated.

Forgot a ReadMe!
Use [enter] and the top 5 buttons to navigate most of the program. I think that's it for now.

EDIT: Hey I found and fixed the bug! (forgot I used a For( loop with the var Y in it)

So I'm going to ask for suggestion
Also, I'm still not sure how to do the physics of this. (I'm taking physics and calculus next year)

Or download the programs link removed

Outdated code
prgmCSP

Code:


prgmZPARTS

Code:


prgmZLAUNCH

Code:

Sorry about the double posting, I thought my post would look cleaner if I just made a new one.
Anyways, any suggestions would be nice, I feel like I'm at a good spot to make major changes to the code without messing everything up.

Here comes PT_ the bytekiller!

First of all, please use SourceCoder to write these programs, SC allow comments with "// <comment>", instead of putting strings everywhere, which can be useful, although it's slow. When you replace this comments why "// <comment>", I'm sure you could increase the speed to like 130% .

Next, I see some For-loops, which have step size 1. You can omit the 1, which should save 2 bytes.


Code:

can be

Code:

It is... faster and smaller


Code:

can be

Code:

This code is more complicated, especially the sum(DeltaList( part. Ans={24,26} returns a list which is {1,0} if getKey=24, {0,1} if getKey=26, and {0,0} if none of the keys was pressed. DeltaList calculates the Xth argument of this list minus the (X-1)th argument of this list, so if getKey=24, DeltaList returns {0-1}, and if getKey=26, it returns {1-0}. Take the sum of this list, you get either -1, 0 or 1, which is what we need. Since both N and S are bounded by [1,5], I used a max( and min( as well.

Next, you have a bunch of lowercase letters, which is fine, but they are 2 bytes each. You can change this to uppercase letters, which are 1 byte tokens, but that's up to you.

Also, I see somewhere a
Code:

which doesn't make sense at all. You can just remove the "Else"


Code:

can be

Code:


Disp "<string>":Pause can be Pause "<string>"

If K=11 or K=12 can be If max(K={11,12

My last tip is that you can omit parenthesis at the end of a line, so If [B](Y,X)=3 can be If 3=[B](Y,X

I'm sure there are a bunch of more optimizations, but with these you should be able to speed it up. Good luck with it!

One little thing, you can use the equation variables for things that recur a lot, it won't slow you down, but it will chop off some bytes. For example:

Code:

could be:

Code:

EDIT: lets do better...

Code:

Also, the SetUpEditor command can take multiple arguments, so this:
Code:
could be
Code:

However, I don't know why you are using SOOOO many different lists
Same goes for the default lists, except that by default, SetUpEditor already does those, so
Code:
could be
Code:

Thanks guys! I'll start working on that!

PT_: I will take your advice and try to use SourceCoder. However I'm having some trouble getting a ROM image off my CE so I can use jusTIfied.

mr womp womp: the reason I have so many lists is for my save/ load function. because I'm limited on matrices (they could get overwritten by another program) I decided to use something that wouldn't interfere with another program. If there is a better way to do this I'm open to ideas, but for now I don't know a better way.

EDIT: wait, jusTIfied can emulate a CE right?

EDIT 2: Dang, I just got put on POTM! (Thanks guys!) So I'm really going to have to kick myself in gear to figure out this rocket science. Should be fun!

Nope, jsTIfied can't emulate the CE yet, we are working on that although progress go slowly
You can download the programs though with SC and  transfer it to CEMUor a real calc

Also, in the declarations, something like

Code:


Can be

Code:

^This
Every tick, add the vector of each force, then divide the resulting vector by mass of the craft, and that is your acceleration vector. Add acceleration to velocity and then velocity to position.

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.
All in all, it was a big mess and I never succeeded, but I believe this is the way to go. I.e. use Keplerian coordinates, not Cartesian, when dealing with orbits. Really, the other way round it's even more pain.

EDIT:
Up until now, everyone seems to assume that the thrust vector goes through the center of mass, which is not at all necessary. This makes things more complicated, requiring to take rotation into account.