There's FTL travel of course, but you can navigate at 'normal' speeds as well. The normal speeds really show how there's no way to get to any other object even at full throttle (without FTL). It's just for asteroid belts, space stations and so on. the way they did it gives a really nice intuition of the enormous size of space. It's a fantastic game!
This was already present in Frontier: Elite II released in 1993. You could travel at sub-light speeds as far as you wanted, visiting gas giants within the same star system and scooping fuel. But to get anywhere else, hyperspace was the only practical option.
The crazy part is that this 3D game was programmed in 68k assembly, ran smoothly on Amiga and Atari ST home computers, and fit on a single 1.44MB floppy. The massive universe with realistic solar systems was almost entirely procedural.
Jupiter is between 4 and 6 AU from Earth. So at the speed of light it would still take over half an hour to get there. It’d be a dull game flying anywhere at sub-light speeds.
It’s been over thirty years since I played Frontier, but I think you could accelerate the in-game time. So you didn’t have to sit still for hours to get to Jupiter. For your character, that time did pass.
Yup that’s how it worked - there were several time advance multiplier buttons. Anytime an enemy ship engaged you it forced you back to 1x time, annoyingly
You certainly could simulate time dilation, I'd be surprised if that isn't already an element of some game out there.
If you go close enough to the speed of light, what you actually see is that space appears to shrink (in the direction of travel) and the trip seems to take less time than light would, because you've apparently covered less distance. Of course what those on the planets would see is that time has been moving oh so slowly on your otherwise speedy ship. There are equations you incorporate into a simulation that would account for this. If the game mechanics were such that you could could see what day/month/year it is in local time, vs your ships time, it would quickly become apparent that bashing through the void is no way to get anywhere.
Sure you could. Each local area (such as a planet) is a single timezone, and everyone there experiences time at the same rate. Someone leaving that timezone would experience time dilation... But in game it would just appear as a communications lag, just as it is for people on different planets. Then, once you've arrived at your destination, there's no longer any lag with your new timezone, and your lag with the original time zone is now fully synched with everyone else on your new planet.
Player A remains on planet A. Player B remains on planet B. Player C commutes between planets A and B, accelerating hard enough for measurable time dilation.
Yeah but by the time player C reaches the other player A thousands of real years have to pass so neither player A or player B can meaningfully interact with player C or each other .
Time dilation is just shortcut to say you are no longer sharing the same frame of reference. If everyone has their own frame of reference there is no difference between single player game and multi player one
Agree. I've mentioned to a few friends how that feeling of emptiness and scale is quite awe inspiring and was a first for me. Theory can't replicate how small and isolated you physically feel when you are between systems. At least not for me.
I'd love to build this. I have access to a 3d printer, use Python, and have some electronics experience. I live in a northern climate and have been eyeing ERV systems for a while. Basically, I'm the perfect target for this.
However, reading the docs, they seem written more to discourage any kind of DIY attempt by saying things A, B or C are difficult, than actually explaining how to do them correctly. I'd love to contribute to the project, but it feels like it's not set-up to foster community contribution.
If I'm mistaken, I'd love to donate some of my time on this!
Unfortunately the recovery core, which is the interesting part of an ERV, is not included in the 3d stl's.
IMO, this feels like a more marketing project than anything open. ERVs are already very simple (a recovery core + blowers/fans). Commercial units last an extremely long time (some with 10 year warranties) and have comprehensive parts availability.
Also a long term window install is a bit janky and is likely to lose out on efficiency due to glass being a poor insulator.
In the photos it seems to be a bunch of nested single-perimeter cylinders that are joined at a few points to maintain spacing. Easy enough to model, but I agree the documentation is horrible and there's no way to contribute.
Commercial units are not comparable because they're way more expensive despite being so simple
Prusaslicer opens it, and it is the right size and shape to be the core, but there's no internal geometry in that STL, at least not how Prusaslicer renders it.
I'd be interested in seeing a diagram of how the air flows through it, if such a thing is available.
Edited to add: There are instructions in the WM12 manual to use your infill settings to make the old version of the core. Page 15 of the manual states there is a python script in the source files to generate the new core, but it only works for their particular printer. I wasn't able to find the script.
Thanks for mentioning that. It seems the PDF and the google docs "manual" have diverged a bit. (at least in page numbers).
I was curious about materials for the core. I know that they're supposed to exchange humidity as well as heat. I know PLA will absorb and release water but I would guess it wouldn't transfer enough to be very efficient. Though I would be happy to be wrong.
I assume the Core in my Panasonic whisper comfort was made out of something more permeable than "simply" extruded plastic. (would love to know more if someone has details).
The MPLA (not pla) does not absorb the water vapor, but it condenses on the plastic and then evaporates. There is also the option of sorbent, which grabs the water vapor and then releases it with each cycle, before condensation occurs, getting higher efficiency.
The material in the whispercomfort is IIRC a fiberglass paper. It can only transfer liquid water, not solid water, and not vapor, effectively. The water condenses, whets the paper, then evaporates out the other side. It's a reasonable approach but does not work well in very low temperatures, and also the condensation process implies certain limits to efficiency, same as a non sorbent coated regenerative heat exchanger. The water doesn't start to condense until 100% RH, so it is 100% when it leaves the exchanger, while the air coming in is lower than that, usually. Thus water is lost.
Very interesting! Do you have a method of adding sorbent to a 3d print?
I wonder if it'd be worth having three TW4 modules with sorbent on only one of them. That way you can control humidity better by choosing 2 of the 3 to use at a time. Eg after a long shower you might wanna discard water vapor for an hour
What's the significance of the model numbers 4 and 12?
Yeah that would probably work, it's just a matter of cost. A lot of people balk at $700 CAD, the eventual price is supposed to be $1300 for a pair, you do that and you are looking at a lot of $ for the flow and energy recovered.
The numbers are the number of versions before it stabilized, so 12 tries for the window mount, 4 for the through wall. It took a while.
My price is for a pair, remember, not one. And those pioneer things don't work very well, poor flow and efficiency unfortunately. They claim high efficiency but it's only at the lowest flow rates and not the average for the cycle, only at the beginning of the cycle. There is one company that keeps emailing me trying to sell me units wholesale, I keep telling them to send me actual test data and then I might buy some (for testing), and they never do.
There is the tw4, which is made to be put in a wall, and there is the WM12, which goes in the window. The main focus is the TW4. There are instructions in the manual for making an ERV core. It is not trivial.
I understand that the addition of desiccant material is the core aspect of what makes this an ERV. I don't actually see any clear explanation of how the desiccant material is added to the printed part. While the creator (open_erv2) mentions that sorbent/desiccant can be used to handle moisture ("If you have sorbent, it gets grabbed out of the air before it can condense"), they don't specify how it's incorporated into the design.
Is it added mid-print? After printing? Is it difficult to add?
I invented a process using some environmentally friendly solvents, grinding the sorbent and so on. It is not diy friendly unfortunately so there is little point in sharing the recipe.
The latest and greatest heat exchanger is produced directly with python script generated gcode specific to the printer I use and cannot be practically produced diy, unfortunately. However the old model can be, and the STL is included for that, in the source repository. To do this, simply use Cura, load th STL in, put it in the center of the build plate, and set it to do “lines” infill with about 2.5 mm on center (between centers of the lines) spacing and 0.45 mm width, no top layer and no bottom layer (set them to zero). Check the preview and it should show you a structure which is much like grid infill, parallel channels which are square in cross section, with the outer wall. Tape can be applied over the nubs on the side to fit in an oversized pipe, or they can be sanded if the pipe is too small. You could also use grid infill, but the roads tend to have problems where they intersect. When the nozzle goes over one road, it wipes the plastic off, and not enough is deposited on the lee side. I don’t know how to solve this in Cura without using lines infill. If you could make it so the nozzle went in alternate directions each layer that would probably solve it well enough.
I expected a community open source project from the title, but reading the docs led me to the same conclusion: The website is about convincing you to buy one while discouraging you from attempting to build one.
It looks like a fun project. I don’t want to discount what has been designed and built. It is confusing to start reading about the project and discover that it’s more of a business than a community project while simultaneously being unavailable for purchase. The person who built it commented on HN that they’re focused on a 3rd different fan project right now, which brings the future of this project into question.
It would be great if a community effort could fork this project and work on making it easier to DIY so the community could push it forward.
EDIT: After exploring the files I’m not sure I’d even call this open source. I either can’t find some key files or they’re deliberately excluded. True open source projects would also include the CAD source, not only .STLs so others could adapt and modify the source. I think the open angle on this project is more marketing than substance.
The step files are also there, which is the best common denominator for CAD files. Again, it's open source for the purpose of maintenance and repair, not cloning, and frankly earlier on I did make it more community oriented and nobody ever contributed even a little bit, so I just gave up on that idea.
The most likely scenario for longer term is that people may submit minor patches or suggestions, which I roll into the hardware or firmware. In reality, hardware is not like software. You can't make changes easily. Some wizards may take it upon themselves to spruce up the firmware with fancy features and release something, which anyone is free to do. There would then be multiple compatible versions of the firmware, one which I curate for reliability with minimal features, and others which others can provide. Same as for 3d printer firmware.
The firmware is Micropython, which is extremely easy to understand and modify.
I played this for an embarassingly long time. My high score that might entertain some engineers:
defective adhesive -> pipe repair patch -> fluid leak -> hydraulic press -> drill -> bucket -> water -> fire -> a giant pile of crisp hundred dollar bills -> budget cuts -> reliable engineering -> leaky lithium batteries -> uninterruptible power supply -> power outage -> electrochemical rust removal -> rust -> scissors -> paper -> rock
I had more creative ones (unsuccessfully tried stopping a supervolcano with an asteroid sized cork bottle cap), but it seems surprisingly grounded in 'reality', if we can say that!
wow that is a great run. i love a giant pile of crisp hundred dollar bills. yes it's quite grounded in 'reality.' will play along / stretch a bit and does well with fictional characters too.
I work specifically with small and medium businesses too, and can echo that sentiment! I'd love to know more about what you do. Love working with SMBs but don't know a lot of other people in that space.
Its nice. It's certainly not high faluting as a lot of HN jobs but I make good money for where I live, our clients are mostly regional but a lot of the 50 states have customers over the years. Mostly we work on implementing and servicing ERP systems. Our differentiator is our skillet in integrations and holistic problem solving. Since the ERP sits in the middle of almost every IT venn diagram, we run into new tech on a weekly basis.
Besides the ERP consulting bit we sell niche solutions in our product space. Mostly comms(EDI, ecommerce,etc) or payroll/bookkeeping addons.
The header image on the website shows slashed zeroes, but the font preview doesn't, which is unexpected. In fact when previewing in Google Fonts there's barely any visual distinction between uppercase letter O and zero. There's only a very slight difference in width which you actually have to look for. Punctuation isn't centered in their box and leaves so much tailing space the test text `5240N 15:01 .84 8,9` reads like `5240N 15: 01 . 84 8, 9`
These problems don't exist as much in the variable width font, where there is no tailing space in the punctuation and the uppercase Os are rounder.
There's also some weird pinching in the corners of N. 1, l and I are perfectly distinguishable though, so at least it's got that going for it.
The hollow zero vs slashed or dotted zero thing is often done in fonts with an extra variant; basically the font can contain both and will display what the application requests. So you should assume that the font really does have the slashed zero, but the font viewer you looked at it with didn't ask for it.
That's a good point. I added that rule (font-variant-numeric: slashed-zero;) to the font preview using the browser's devtools, and I saw no difference.
