ApolloHoax.net
Apollo Discussions => The Reality of Apollo => Topic started by: tikkitakki on April 29, 2017, 08:13:55 PM
-
https://ideas.lego.com/blogs/1-blog/post/137 (https://ideas.lego.com/blogs/1-blog/post/137)
Introducing LEGO® Ideas 21309 NASA Apollo Saturn V
The wait is over! After a year in development we're incredibly proud to unveil and present the first official images of the LEGO Ideas 21309 NASA Apollo Saturn V designed by LEGO Ideas members Felix Stiessen (saabfan (https://ideas.lego.com/profile/saabfan/profile)) and Valérie Roche (whatsuptoday (https://ideas.lego.com/profile/whatsuptoday/profile))
You'll be able to find the 1 meter high (approximately 1:110 scale) icon of space exploration in stores from the 1st of June, 2017 for a recommended retail price of just USD 119.99 / EURO 119.99 / GBP 109.99. With 1969 LEGO elements the 21309 NASA Apollo Saturn V rockets its way into LEGO Ideas history as the tallest LEGO Ideas set, as well as the one containing most elements.
(https://dp1eoqdp1qht7.cloudfront.net/community/blogs/1/2957888-o_1bepvhbvt186fv6mtpdfthvn1d.jpg) (https://dp1eoqdp1qht7.cloudfront.net/community/blogs/1/2958017-o_1beq8iod0cc61vv0ej510sim70a.jpg)
-
1969 pieces. That can't be a coincidence! :)
-
1969 pieces. That can't be a coincidence! :)
They should have used the Unix time code for the launch time.
-
1969 pieces. That can't be a coincidence! :)
They should have used the Unix time code for the launch time.
That would be an ... interesting ... number of pieces. (0, in Unix internal timestamps, is Jan 1, 1970, 00:00 UTC).
-
Twos complement I presume.
-
Indeed. The ANSI C `time_t` type, which can contain a Unix timestamp (and will on Linux and Unix), is usually a signed integer. Whether it's 32-bit or 64-bit depends on your compiler; older ones will have it 32-bit (which leads to the 2038 problem (https://en.wikipedia.org/wiki/Year_2038_problem)).
-
Some details:
http://www.collectspace.com/news/news-042817a-lego-nasa-apollo-saturn-v.html
One of the reviews - see comments at the bottom:
https://brickset.com/article/27956/review-21309-nasa-apollo-saturn-v
And sorry to other Kiwis, it will knock us back the rather stupid price of NZ$199.99 instead of a more sensible $200.00, and can be ordered direct from Lego (NZ):
https://shop.lego.com/en-NZ/LEGO-NASA-Apollo-Saturn-V-21309
It's hard to figure why it's so much dearer than US$120 in the States - our exchange rate should make it around NZ$175.
-
1969 pieces. That can't be a coincidence! :)
It isn't.
-
Thanks for the tip Tikkitakki, just ordered mine :)
Lurky
-
I got mine. There's a Lego store nearby. I also got a Yellow Submarine set.
Fred
-
That would be an ... interesting ... number of pieces. (0, in Unix internal timestamps, is Jan 1, 1970, 00:00 UTC).
It was January 1, 1970 at 00:00:00 UTC. The epoch moves every time a leap second is added to the UTC time scale.
Using UTC instead of TAI (GPS didn't yet exist) was a major mistake. Don't get me started...
-
Oh dear I went and bought one for my Grandson, build project for us both.
-
That would be an ... interesting ... number of pieces. (0, in Unix internal timestamps, is Jan 1, 1970, 00:00 UTC).
It was January 1, 1970 at 00:00:00 UTC. The epoch moves every time a leap second is added to the UTC time scale.
Using UTC instead of TAI (GPS didn't yet exist) was a major mistake. Don't get me started...
Never thought of that; but of course it would.
Time/date manipulation, on computers, is harder than most people - including all too many developers - realize, especially as as soon as time changes enter the picture (you aren't even safe in a single time zone, if that zone has daylight savings - or ever changed in the past).
-
-
Delightful video, thanks for sharing :)
Lurky
-
I'm looking forward to getting one. Somebody must have anticipated this and came up with his own lego crawler:
-
Delightful video, thanks for sharing :)
Lurky
If you play KSP, you must know Scott Manley.
-
Delightful video, thanks for sharing :)
Lurky
If you play KSP, you must know Scott Manley.
Indeed.
-
That would be an ... interesting ... number of pieces. (0, in Unix internal timestamps, is Jan 1, 1970, 00:00 UTC).
It was January 1, 1970 at 00:00:00 UTC. The epoch moves every time a leap second is added to the UTC time scale.
Using UTC instead of TAI (GPS didn't yet exist) was a major mistake. Don't get me started...
Never thought of that; but of course it would.
Time/date manipulation, on computers, is harder than most people - including all too many developers - realize, especially as as soon as time changes enter the picture (you aren't even safe in a single time zone, if that zone has daylight savings - or ever changed in the past).
Here's one of the Computerphile guys having a bit of a humorous rant about coding for time zones.
-
Maybe this would be a better idea than my decade old Apollo spacecraft, which has lost three LM footpads, the APS bell, the LM low gain antenna and the SM high gain antenna.
-
That's a wonderful rant, BazBear. But he still hasn't covered the full madness that is UTC, without even time zones, daylight saving time and international date times. Because UTC can have 61-second (or theoretically 59-second) minutes, it is fundamentally impossible to represent UTC as a single integer count of seconds. You just can't do it. You have to keep it as years, months, days, hours, minutes and seconds, the latter of which can reach 60.
And then you have UTC in the 1960s, before the present leap second system was adopted (in 1972, I think). To keep it in synch with earth rotation time the length of the UTC second was continuously varied relative to the atomic second!
I got into this because I was interested in simulating historical space trajectories, such as those from the Apollo program...I don't know that I ever got past the time conversions.
-
That would be an ... interesting ... number of pieces. (0, in Unix internal timestamps, is Jan 1, 1970, 00:00 UTC).
It was January 1, 1970 at 00:00:00 UTC. The epoch moves every time a leap second is added to the UTC time scale.
Using UTC instead of TAI (GPS didn't yet exist) was a major mistake. Don't get me started...
Never thought of that; but of course it would.
Time/date manipulation, on computers, is harder than most people - including all too many developers - realize, especially as as soon as time changes enter the picture (you aren't even safe in a single time zone, if that zone has daylight savings - or ever changed in the past).
The few times I've had to do it have been painful and left a bit of scar tissue. Not something I'd choose to work on again if I could help it.
-
And they're all self-inflicted scars, too. I can accept that handling relativistic effects is complex, but relativity is a law of nature that cannot be ignored so you gotta do it. But using UTC as it's been (re)defined for the past 5 or so decades created a totally artificial and unnecessary problem.
-
Adam Savage Builds the LEGO NASA Apollo Saturn V!
-
Had to share this quote from my 3 year old grandson Finley, he is 4 in July and have bought this for him as a project with Granddad as I have already said.
Finley to his mum "I want to go to the Moon!"
"How do you get to the Moon, Finley?"
"In a big rocket!"
"But where can you get a big rocket?"
"From the big rocket shop, silly!"
-
Toys r uskosmos?
-
One of the 1969 pieces is a flag that can be accurately placed for the LM Ascent stage lift-off:
(https://c1.staticflickr.com/5/4235/35495181436_a6e289d567_k.jpg) (https://flic.kr/p/W5A5NQ)Apollo_20170625_077 (https://flic.kr/p/W5A5NQ) by AlJ1964 (https://www.flickr.com/photos/41437046@N05/), on Flickr