Live data from Hacker News

I found a 55 year old bug in the first Lunar Lander game

martincmartin.com

81–90 of 124 posts

Re: I found a 55 year old bug in the first Lunar Lander game

#81
post #17

Earlier quoted context omitted.

Automobiles are more (wear-)efficient at braking when they use the engine to brake, not the brakes, so that would probably be a better approach to automate

A long time ago, in a book whose title I don’t remember, a character said, “but engine parts are more expensive than brake parts”. That has always stuck with me, even as I glide to a stop with almost no braking.

True, however that statement sort of makes the assumption that engine braking is the same ablative system as friction braking. with the same wear characteristics.

I have to admit I don't know the exact wear characteristics of an IC engine in breaking operation but I don't think it is any different/more than it's normal running wear.

Re: I found a 55 year old bug in the first Lunar Lander game

#82

I still have a roll of punch tape, I think for a PDP11, that says "Lunar Lander" on it, and I have no idea who to give it to.

Internet Archive or Computer History Museum? Ask @textfiles for recommendations for places that might be interested.

Re: I found a 55 year old bug in the first Lunar Lander game

#83
post #80

If anyone is curious, in 2009, I discovered that Jim Storer was the author of the first Lunar Lander game and interviewed him about it (and also chronicled the history of the game beyond that). He later provided the source code, which was awesome. https://technologizer.com/2009/07/19/lunar-lander/index.html My favorite part is this: “After leaving high school I never thought about the game again,” says Storer. “Until…

That's awesome I just wanted to add, there's also mechanical lander games that pre-date lunar lander I can't find a picture. IIRC the machine was something like this https://content.invisioncic.com/r322239/monthly_10_2015/post... Except it had terrain and pits. A pit would light up and you needed to land in the pit (your ship landing would depress the button in the center of the pit). If you didn't aim well your ship…

I played the game in this picture at the pinball museum in vegas. One lever operates the rear fan and the other operates the bottom fan. It was a lot of fun for an analog arcade game.

I returned to the museum a few years ago and it was no longer working. I hope they fix it one day.

Re: I found a 55 year old bug in the first Lunar Lander game

#84

Earlier quoted context omitted.

I get what you're saying, but I don't think that contradicts the optimal strategy I outlined? Rather than a large deviation from a suicide burn at the end of the burn, a small deviation at the beginning of the burn should be a cheaper way (w/r/t fuel burn) to "search" the buggy code for a possible soft landing solution. Anyway, what a fun write-up! Thanks for posting it.

Yeah, I think we're agreeing. :) So it turns out, before discovering the bug, I actually wrote code to find the optimal sequence when your choices are restricted to integers. I thought, along the same lines as you, "maybe if you burn 165 or 170 or something in the first non-zero term, then you could burn less on the 14 turn and still land." And this is how I know it's not possible, at least with integer burn rates. :…

I think they are saying that you need to switch to 199.999... lbs/s for all the 200 lbs/s burns, not just the last one.

Just trying to clarify where you seem to be speaking past each other, though it seems that this might simply lead to a non-optimal strategy (i.e. taking more time to land than theoretically possible, however minute the difference is).

Re: I found a 55 year old bug in the first Lunar Lander game

#85
post #17

I wonder if this works for braking in automobiles to minimize brake pad wear.

Automobiles are more (wear-)efficient at braking when they use the engine to brake, not the brakes, so that would probably be a better approach to automate

Isn't that simply because the engine provides less resistance through the clutch than brakes do? Would clutch really be spent less than brake pads for the same braking power (light press on the brakes)?

FWIW, modern flywheel clutch kits are way more expensive than brake pads, so the cost is not so clear cut anyway.

Re: I found a 55 year old bug in the first Lunar Lander game

#86
post #81

Earlier quoted context omitted.

A long time ago, in a book whose title I don’t remember, a character said, “but engine parts are more expensive than brake parts”. That has always stuck with me, even as I glide to a stop with almost no braking.

True, however that statement sort of makes the assumption that engine braking is the same ablative system as friction braking. with the same wear characteristics. I have to admit I don't know the exact wear characteristics of an IC engine in breaking operation but I don't think it is any different/more than it's normal running wear.

They are certainly in any way identical, but to engine break, you usually need to switch into a lower gear (or a couple gears lower), which means that the clutch needs to reattach while the engine is rolling at a higher rpm than the gearbox can handle in that gear. Every downshift will do another "reattachment" through the clutch.

Which means that there will be some friction braking before internal engine resistance "takes over". Now, while both brake pads and clutches use "similar" material, it's not the same, and the cost is not the same (clutches are usually more expensive in modern cars).

Re: I found a 55 year old bug in the first Lunar Lander game

#87

> By 1973, it had become “by far and away the single most popular computer game.” On Lunar Lander and bugs: my first programming book had a version of this game in Basic that I never got to run correctly. 25 years later I came back to it and I was surprised at the ridiculous amount of bugs it had and the convoluted logic ("440 IF GOTO 450"). I eventually rewrote it as an adult [1] but young me stood no chance. And to…

That was an enjoyable read. I, too, when I was a child sometimes thought the same thing about my C64 “magically” being able to load some game-related images with just a few lines of code that are… just somewhere inside it? A super bizarre thought, but as a child you’re still prone to a lot of magical thinking.

> and the convoluted logic "440 IF GOTO 450“

To expand a little bit on that, while some instances in the code of your book could indeed use some cleanup (line 440 is especially egregious), the code in the book was likely written for the common BASICs of home computers of the time, which only operated on line numbers and had very limited branching statements?

The BASIC you use seems to be “structured”, which was extremely unusual for home computers of the time. I just recently saw that a C64 magazine from 1984 spent at least 3 issues of the magazine on a lengthy article series that introduced the readers to the wonders of structured programming!

The severe restrictions of the IF statement made assembly-language style conditional branches (using GOTO) extremely common and necessary.

You definitely could not nest IFs (as done in your code), so if you wanted to combine IFs together, you had to jump over the ones not taken. Commodore/C64’s BASIC (effectively Microsoft BASIC) did not even have ELSE, so usually ELSE had to be implemented with a negated condition and jumping over what would be the “ELSE” branch.

C64 BASIC did however have the interesting quirk that any other statement on the same line would belong to the THEN, e.g.

   10 IF A=1 THEN PRINT “FOO” : PRINT “BAR”
Would print FOO BAR if A=1, and nothing otherwise. This of course worked only so far as you could fit statements on a (limited) single BASIC line. Other BASIC dialects would consider the PRINT “BAR” to not belong to the ELSE anymore, which is syntactically cleaner, but could be less convenient depending on what else the dialect offered.

A lot of the convenience and rigor we take as granted today wasn’t there. C64 BASIC seemed especially “dirty” to me, having lots of bizarre quirks that are more the result of its implementation. (Another random instance: Every function had to have an argument, whether it was required or not, so you had to write something like “?FRE(123)” to print the amount of free memory, where the 123 did not matter at all.)

Re: I found a 55 year old bug in the first Lunar Lander game

#88

Earlier quoted context omitted.

I get what you're saying, but I don't think that contradicts the optimal strategy I outlined? Rather than a large deviation from a suicide burn at the end of the burn, a small deviation at the beginning of the burn should be a cheaper way (w/r/t fuel burn) to "search" the buggy code for a possible soft landing solution. Anyway, what a fun write-up! Thanks for posting it.

Yeah, I think we're agreeing. :) So it turns out, before discovering the bug, I actually wrote code to find the optimal sequence when your choices are restricted to integers. I thought, along the same lines as you, "maybe if you burn 165 or 170 or something in the first non-zero term, then you could burn less on the 14 turn and still land." And this is how I know it's not possible, at least with integer burn rates. :…

  >I thought, along the same lines as you, "maybe if you burn 165 or 170 or something in the first non-zero term, then you could burn less on the 14 turn and still land."
That's not exactly what I was thinking.

Clearly that won't work, because just by changing the least significant digit (ie adding 1e-8 lb/s) in step t=70 seconds, you "blow past" the soft landing window, in part due to the bug.

Evidently the move played at t=70 seconds is, in effect, too 'course-grained' to effectively target the (small) soft landing window. By shifting your "subtract 1e-8 lb/s" move (ie playing 199.99999999 lb/s) later and later in the burn, you effectively make it more and more fine-grained (for a minimum fuel penalty) until you can achieve that soft landing.

Thanks again. I'm not sure who's right, but it's certainly a very stimulating problem!

Re: I found a 55 year old bug in the first Lunar Lander game

#90
post #72

Earlier quoted context omitted.

> and an impressive amount of capability for a high school senior It's only impressive because very few (none?) high schools teach calculus at the level required for his implementation. High schoolers are quite capable of handling that kind of calculus, it's just that the high schools don't teach it.

The UK stopped including calculus as part of physics even! I got told off for doing an integral.

[deleted]
Post reply on HN