Thanks for a note.
Freefall does the trick 
I have a problemā¦ I solved level 1 and only got 2 achievements because I didnāt see about economic achievement (finish with > 300l), so I did solve it again, managing to end with 320l, but I didnāt get the achievement, what am i missing ? Am i meant to get it when i run the test or validate ?
4 Likes
Itās because the REAL test isnāt at the same height as the normal test.
That imply one thing: you succeed the test by putting and arbitrary condition like:
if Y < 2000
And that condition doesnāt work with the real test. Try to work something with the Vertical Speed and Y to make a more global code.
1 Like
Solved it considering that there are three steps during a landing :
1Ā°) Choose the right angle to go to the middle of the platform
2Ā°) Reset smoothly horizontal speed to 0 near the end
3Ā°) Throttle to stay put with vertical speed
I had three booleans therefore : step1, step2, step3.
All the tests succeed.
Good luck.
3 Likes
You donāt need to submit solutions if people didnāt ask for it.
Moreover, we donāt know which mars lander puzzle you are speaking about, but i guess itās more like a general advice.
But thatās ok, just donāt provide full code and weāll be friends 
Alright, I wonāt try to publish my walkthrough, you can count on me.
My solution has a bug. I did level one using a physical solution: each frame determine: if we applied full power starting one second from now would we fail to slow to 20m/s in the remaining time? If so donāt wait one second - apply full power starting now. By my reasoning this should put us on the pad at more or less 20m/s.
I use that classic āone-half-ay-tee-squaredā formula to turn speed/acceleration/time into distance.
But it doesnāt work. I wondering if anyone can see what Iāve messed up here. For some reason I need to pad the time by ten seconds before determining how far we will go in that time with full thrust applied.
Hereās some code - hopefully this isnāt too much code to put in this forum: CxyFox let me know if so and Iāll move it to a google doc or something.
int d = Y - LAND_Y[X]; // distance remaining
int t = (20-VS)/4; // time to reach Vf with thrust of A: (Vf-Vi)/A
t += 4-P; // add time it takes to build up thrust
t += 1; // add one more second so we sim hitting 20m/s above the ground and not below it
t += 10; // add ten more seconds - I don't know why
int s = abs(VS)*t + 2*t*t; // distance travelled = Vi*T + 0.5AT^2
if (s > d) // if distance is greater than we have available hit it
cout << "0 4" << endl; // R P. R is the desired rotation angle. P is the desired thrust power.
else
cout << "0 0" << endl;
Very fun and interesting puzzle to solve. With matematical approach Iāve managed to land for achievement on level 2 with 550l fuel remaining and on level 3 with slightly more than 600l. There should be also a fourth level at āInsaneā difficulty with few caves, a stopover with refueling in the middle and maybe some tunnels? 
5 Likes
I didnāt want to be the bad guy
Your code try the mathematical approach, i donāt see a problem with that, since it may be the best way to do it. What bothers me more is when people pull full 100% code.
Some may argue that it may be close to 100% code, but since itās not perfect and since we are talking about mars lander 1, you can go on
For your code itself, well ask @kijanek6 who seemed to have mastered the math ^^
Good job! I didnāt do the mars lander 3 yet but Iāve seen the test and i agree that maybe a fourth level might be cool in the future.
@CvxFous haha, Iām weak at math itself, but Iām very good at combining various concepts. My solution isnāt perfect, I think the ideal solution would save few percents more fuel, but as I passed it for 100% I moved to other puzzles (and got stuck there, hah!).
@agraham there are really many possible ways to solve it and Iām not sure if I understand your approach correctly (though I like the t+=10; part a lot - Iāve also got some various unexplainable hacks - see, we have something in common! :D).
If I understand correctly your problem is to estimate turns/distance needed to slow down from (actual) vertical velocity V1 to desired velocity V2 (less than 40 to land).
Itās relatively easy if you donāt need to adjust horizontal velocity at the same time (so no need to manipulate lander angle). Ok, so to the merits:
Gravity force is approximately -3.7 m/s2. At 0 angle engine generates upward acceleration of 4.0 m/s2. So, at each turn you can lower your velocity only by approx. 0.3 m/s2. Given that, time needed to decelerate from V1 to V2 is equal to difference between them divided by 0.3.
Knowing T and V1 you can now calculate distance that will be traveled in that T. If your actual V is for example -50 and you have applied thrust=4 you will travel -49.7 m. At next round you will travel -49.4 m, at next -49.1 and so on. It now should look familiar to you if you werenāt sleeping at maths in school (hint: arithmetic progression).
Special case occurs if your initial thrust is not 3-4 or actual angle is greater than 20 (so it takes few turns to manoeuvre to correct state), but I think you should figure it out by yourself. 
There could be also small inaccuracy due to rounding of floats to integers when passing ins and outs, but I didnāt notice it as a significant issue.
4 Likes
@kijanek6 One issue I see with your solution is that you are integrating your acceleration once per second, but the lander is giving you updates about once every 100ms IIRC so your calculation will probably be off by a bit - perhaps thatās why you had to add some padding?
In my case Iām simulating the future in one calculation: essentially doing continuous integration.
I think the way the lander works is every update it takes the accelerations (thrust and gravity) acting on the lander and adds that to the landerās velocity and then adds that to the landerās position. This means that the speed is applied over the whole previous 100ms when the landerās speed was actually changing over that 100ms (integrating with 100ms step size). Thatās the way games are typically done and thereās no problem with that but it does mean the lander doesnāt move like a real object: when itās accelerating it wonāt move as far as a real object would and when itās decelerating it will go further (or maybe thatās backwards - my thinking is a little muddy here).
Iām going to try changing to doing the simulation in steps like you and see if that works.
In this case I donāt recall any paddings - dirty hacks are in collision detection.
100ms time is timeout limit, not turn duration! One turn equals to 1 game world second, but you have 100ms to execute your calculations. You can easily verify that if your lander will move with constant velocity and you observe position changes. Next turn X equals to X+(vertical velocity+vertical acceleration). Thrust and angle changes are applied immediately in the same turn (before calculation of next position), of course in bounds of per turn manoeuvre limits. Itās the method of jumping frog. In preview window you see lander moving smoothly because positions there are linearly interpolated between frame Z and Z+1, but simulation itself isnāt linear.
Ah yes you are right. I changed it to use a one second step size and it worked perfectly on the first try.
I would submit that this question is not really as good as it could be because it asks you to imagine you are coding the controller for a real lander, not coding the controller for an unrealistic simulation of a lander.
Behind the scenes it should be using 0.5at^2 to get the next secondās position instead of just adding over this very large step size that leads to very large error.
3 Likes
Seems like the order of input for Java is wrong, X and Y coordinates are swapped and thrust P seems to be read first in the while-loop.
1 Like
1st level of this puzzle is extremely easy. I donāt know why it have biggest prize among other 1st-level-tasks.
Seems valid. I used the same formula, although I handled the thruster in a slightly different way.
So the idea is to start fueling when
mgh <= .5 mv^2
Where:
m = irrelevant
g = 4 - 3.711 (assuming thruster is at full speed)
h = Y - safe_platform_y
v = abs(VS) - 40 (speed difference)
Then I read the instructions again and noticed that the thruster needs to be set in 4 steps (0.4 sec), so I decided to replace these variables by estimates of their values in 0.4 seconds if no thruster output would be given.
h = Y - safe_platform_y + 0.4 * (VS + 0.4 * -3.711)
v = abs(VS + 0.4 * -3.711) - 40
Note that VS is negative when falling down
This resulted in my rocket fuelling at a heigh of 1777m and crashing with a speed of -73 m/sā¦
I am trying to use physics to understand the logic to solving this but I am getting confused with what the parameters R and P are trying to achieve. This is something that we set right??? but why is it given as input?? Could someone help me understand the logic for mars lander 2?
We should read current values of R and P and calculate new.
Could you please explain a little more? I am unable to comprehend the logic behind this
Okay, Iāll try.
Our Lander has many parameters (such as speed, fuel, rotation power, etc) which are calculated on server based on physics and magic. Every second your program reads this current (or ārealā) values from stdin and it should answer with one simple command.
E.g., program read current speed (VS = -40) and calculate:
if (VS < -30) // Oh no! Lander falling too fast!
power = 4; // We need to speedup.
// This is the command:
print(angle + power); // "Hey, Lander! Increase your thrust up to 4!"
Nice, Lander rises. But in the next second speed wonāt be ā-40+4ā, it will be smaller and itās exact value will be calculated on server based onā¦ Oh, dejavu.
2 Likes