time's recent activity
-
Comment on Elite Dangerous discussion in ~games
-
Comment on Elite Dangerous discussion in ~games
time Link ParentLike most of my projects it ended up taking much longer than expected, and I had bought my first VKB stick while I was still working on it. The hall effect sensor actually ended up working fairly...Like most of my projects it ended up taking much longer than expected, and I had bought my first VKB stick while I was still working on it. The hall effect sensor actually ended up working fairly well for a bit, and it was a direct replacement for the old twist potentiometer, but I had it and the magnet hot glued into the stick of the X16000 joystick, and it kept coming loose while I was testing it.
I had aspirations of making a new 3D printed case that would hold things better, but the VKB was working so well I never went back to it and instead worked on several of my other projects with my free time instead.
-
Comment on Elite Dangerous discussion in ~games
time Link ParentI wasn't there for the first one, but the second one was basically a community organized, FDev supported several months long expedition out into the black. They had waypoints along the journey...I wasn't there for the first one, but the second one was basically a community organized, FDev supported several months long expedition out into the black. They had waypoints along the journey where we would meet up in cool systems, have SRV races, and such out in the black. They made the journey possible for someone playing fairly casually to keep up without too much trouble. There were no fleet carriers back then, so we all just made our way along with the expedition and did fun things together in the black. FDev worked with the organizers to have us build the Explorer's Anchorage station as a community event during the expedition, and I can't remember if the whole expedition went, but I ended up out at beagle point before heading back to the bubble. They also gave out ship decals for all the participants that went along, which I usually put on my exploration ship livery even now.
They've already started some pre events for DW3, using colonization to build systems out as a launch point for the next expedition, and when you sign up you agree not to bring your own fleet carrier, so it'll feel a bit closer to the previous journeys. There are a few official carriers that will be making the journey along with the fleet this time. I've signed up with my Mandalay, Cobra Mk V, and a Corsair outfitted for mining so I can help refill the fleet carriers while we're out in the black. They have their own private group if you're worried about gankers in open while you're along for the journey. I haven't been following along too much myself, but they have a roleplay backstory for the whole thing going on as well. It was fun in the past, and gave me a reason to play the game other than the solo content I usually play, so I figured I'd give it another go this time as well.
-
Comment on Elite Dangerous discussion in ~games
time Link ParentI will say that if you're looking for a Hotas, anything currently available that is cheaper than VKB is going to not be worth it in the long run. I've tried the X52 (both the old pre-Logitech...I will say that if you're looking for a Hotas, anything currently available that is cheaper than VKB is going to not be worth it in the long run. I've tried the X52 (both the old pre-Logitech version and the current model), as well as the Thrustmaster T.X16000m setup, and they all started breaking down with ghost inputs from the buttons and pots wearing out within a couple months, especially on the twist axes.
After being frustrated with the cheaper options and even trying to upgrade one with a hall effect sensor myself, I splurged for the VKB Gladiator NXT stick and omni-throttle a few years back, and haven't had a single input problem since. They cost a third of what the high-end HOTAS setups from somewhere like Vrrpl would be, but for the price, the quality you get is excellent. Their config software is a bit janky, and I had to watch some youtube videos to figure out how to work with it, but the config is stored on the device itself, so once I had it set up how I liked it, I haven't had to worry about it again, even after a couple OS upgrades/reinstalls.
-
Comment on Elite Dangerous discussion in ~games
time (edited )LinkI used to play a ton, then I took a break for a few years, but I did get back into it a couple months ago. I've always been big on exploration, and through the power of Exobiology I made more than...I used to play a ton, then I took a break for a few years, but I did get back into it a couple months ago. I've always been big on exploration, and through the power of Exobiology I made more than enough money to buy a fleet carrier to use as a base out in the deep. It takes away the fear of smashing into a planet and losing months of data/money, which is kind of a double edged sword for me. I really enjoyed exploration before fleet carriers, as it felt like a real accomplishment to make it so Beagle Point all on your own just to say you did. The risk is much lower now. I don't usually even bother with AFMUs on my exploration ships anymore, as there's always a carrier somewhere nearby you can repair at these days, so it feels a lot different.
In terms of the new ships, the Type 8 and Corsair were alright, but I haven't settled on an equipment layout I'm happy with for those yet. I really liked the Cobra Mk V, as well as the Mandalay are both great for exploration (and can also be outfitted for other things as well). You can fit lots of handy things like shields, torpedos, limpets, and multiple SRVs, they run cool enough to scoop without throttling down for all but the hottest of stars, and they still have 40-50+ LY of jump range. They also have reasonably small landing footprints, which is very handy for Exobiology.
I did claim a system and build a few stations/settlements in it, but it was early on and I decided to hold off on further development until someone else figured out how to control the economy of the stations so I could make some of my orbital slots be actually useful. Haven't gone back to colonization as I'm out in the black a few thousand light years, but I'ma need to make my way back to the bubble soon to join up with the Distant Worlds fleet by the end of the year-ish.
I'd also like to give a Caspian a try, though I don't know if I want to buy/engineer one before the Distant Worlds 3 take off, as I already have a Mandalay and a Cobra Mk V ready to go. DW3 is exciting for me as someone who was on the previous expedition. Even in the face of the new fleet carrier reality for exploration, I think that the new expedition will be fun to participate in.
Anyways, here's my Inara fleet page if anyone is interested in my ship builds. Hope I'll run into some of you out in the black one of these days.
Edit/Post Script:
I also want to add that if you're new to Elite and have the opportunity to play in VR, DO IT! Flat-screen vs VR is the difference between playing a spaceship simulator game, and actually flying a spaceship. The VR experience is next-level, especially with the game's awesome sound design. Elite is probably my second favorite VR experience after Half Life Alyx, even in spite of the space legs not being full VR. The quality of the experience inside the ships more than makes up for it. VR makes combat so much more fun, as you can literally look up at the guy who just flew past you and follow them visually as you spin around. I mean, sure you can do it in 2D with headlook keybindings, but it's just so natural and intuitive in VR that it feels like a major unfair advantage in dogfights. -
Comment on What games have you been playing, and what's your opinion on them? in ~games
time Link ParentI've also been playing Space Age since it released, and I found Gleba to be quite enjoyable once I figured out how to start up a nutrient/bioflux feedback loop. The rest of the game encourages...I've also been playing Space Age since it released, and I found Gleba to be quite enjoyable once I figured out how to start up a nutrient/bioflux feedback loop. The rest of the game encourages making a bunch of resources and stockpiling them for whatever you are building next, so Gleba was a pleasant change of pace for me. The general design philosophy for the planet is that if you harvest/create a resource you either need to use it as soon as possible, or have a plan for dealing with spoilage if you don't need it.
I've written up a description of how I ended up setting up my Gleba base below, focusing mostly on my general design principles of how to keep things from backing up and stopping production. Hopefully you will find the below helpful to you when you set out to attempt your second Gleba base.
My Gleba Design Philosophy (spoilers for a way to solve Gleba production)
I started with a mostly logistics bot layout, and I actually found it was much easier for me when I used belts for things, as you can just add splitters that send all your spoilage to a waste belt that leads to an incinerator. You also get to see everywhere that things are spoiling so it's easier to track down bottlenecks visually than it is to figure out where the 10k of spoilage in your logistic storage came from.
The main change for me on Gleba is that instead of trying to make one giant system that does everything like my Nauvis main base, I instead made a bunch of small specialized production loops that can be duplicated as needed to output a specific product. Fruits go in, seeds and useful items come out, and everything I don't need immediately for that loop gets burned at the end of the line. There will always be more fruit coming in as long as you're processing it and shipping seeds back to the farms, so burning the excess items is totally free and it keeps things from getting backed up. If you find you're running out of fruit, you just go find a new soil patch and plant more trees.
The back end of each of my production loops changes depending on what I'm making, but they all start with the same basic system in the front. I will take tree fruits as an input and use it to make bioflux. I then use the bioflux to make nutrients. I do need to manually feed nutrients into the biolabs to start the loop up, but once it gets going, as long as I'm processing all the fruit that gets picked and sending the seeds back to the tree farms, it will run indefinitely and I'll never run out of nutrients/bioflux again.
Once I have the biolabs producing nutrients from bioflux, I then use that basic setup setup of fruits to bioflux to nutrients to sustain a constantly running loop of nutrients and bioflux that supplies all the machines in the production loop for whatever else I'm producing, be it iron/copper bacteria, science, petroleum products, etc. As long as both fruits keep coming in to make more bioflux, and the line doesn't get backed up, it will run forever. I will add a couple more Mash or Jelly labs depending on what the things I'm building down the line will need, but everything starts with the sustainable fruits to nutrient/bioflux loop.
To keep things from backing up and stopping production, my bioflux/nutrient loop always has a splitter or two that filters out any spoilage and sends it down a waste belt back to an incinerator. If any belt I'm using isn't looping, I just add a filtered output (like a splitter or inserter) at the last belt tile that will remove any spoilage as it collects at the end of the belt and feed it to the waste belt system.
The same is true for machines with anything spoilable in them. If a biolab gets backed up for a bit, the nutrients fueling it turn into spoilage even if nothing else in the machine can spoil, so I make sure every machine has a filtered inserter that will remove spoilage and add it to the waste belt/incinerator system. The spoilage is never high volume, so long inserters can handle offloading spoilage without hurting throughput. As long as waste disposal is handled at every machine and at the end of belt lines (or via splitters in looping belts), things will run forever.
One potential non-spoilage blockage that got me was seeds. If you're belting seeds back to your tree farms, you'll eventually end up filling up the seed belt since you get more seeds back than you need, so it's a good idea to check if the belt is backed up and burn the excess seeds before they reach your production loops. If the seed output on a biolab is full, that can halt your bioflux production and stop processing fruit.
-
Comment on Tom Cardy and Brian David Gilbert - Beautiful Mind (2023) in ~music
time Link ParentI don't know if this is the case for this particular song since it's a collaboration, but Brian David Gilbert gives out the stems to his other original songs on his Patreon. At least that was the...I don't know if this is the case for this particular song since it's a collaboration, but Brian David Gilbert gives out the stems to his other original songs on his Patreon. At least that was the arrangement when I was donating to him last year.
-
Comment on “Going shopping” is dead: How stores sucked the fun out of an American pastime in ~finance
time Link ParentAs someone who worked at a Target during the Christmas season circa 2004-2005, I can assure you that my store definitely had music playing back then. This may be a regional thing, or you just got...As someone who worked at a Target during the Christmas season circa 2004-2005, I can assure you that my store definitely had music playing back then. This may be a regional thing, or you just got lucky and had a quiet store.
-
Comment on Guild Wars 2 announced it's first mini expansion, 'Secrets of the obscure' in ~games
time Link ParentI'm a current GW2 player, and this expansion is a new thing ANet is trying. It's supposed bigger than a living world season, but smaller than the previous 3 expansions. They are also doing a slow...I'm a current GW2 player, and this expansion is a new thing ANet is trying. It's supposed bigger than a living world season, but smaller than the previous 3 expansions. They are also doing a slow release of content, so initially there will be two new maps and some story content, and over the next while there will be more story chapters released and a third new map.
In general, I am tentatively excited for the new changes, including new weapons for existing classes, new PVE legendary armor that's not locked behind raids, and new story content. While I have unlocked legendary armor from raiding with my guild, having a way to get it without needing to grind raids every week for currency is appealing for acquiring my second two sets. I'm also excited about the changes to the skyscale mount, making it easier to get and upgrading existing flying mounts to work with leyline gliding and updrafts.
-
Comment on Rust takes a major step forward as Linux's second official language in ~tech
time (edited )Link ParentThere's been some significant progress on a gcc backend being added to rust. You can find out the current state of things in this blog and this repo. They've been making quite a bit of progress to...it would require a GCC backend
There's been some significant progress on a gcc backend being added to rust. You can find out the current state of things in this blog and this repo. They've been making quite a bit of progress to being able to use gcc as an alternate backend over the last year, though they do still have a ways to go.
-
Comment on The coming firmware revolution in ~comp
time Link ParentThere's a very good chance that the compiler is smart enough to remove some checks, but I haven't really looked into it very thoroughly. It's been a while since I was working on something where...for the C implementation if you're setting those pins at compile time anyways are you sure the compiler isn't just doing away with those runtime checks? Or does your HAL interface require you to set everything up at runtime?
There's a very good chance that the compiler is smart enough to remove some checks, but I haven't really looked into it very thoroughly. It's been a while since I was working on something where the timing of digital pin switching mattered, so my memory is a bit fuzzy. The last time I remember running quantifiable tests, I think it was on an Teensy 3.1 or 3.2 board (can't remember which), and using a library with
set_high(pin_number)orset_low(pin_number)functions in some platformio library, it came out to be about 5 times slower than just manually setting the register bit. It has been a while, so I may be recalling things a bit off, but that was the gist of it.The main takeaway, for me at least, is that while it is possible to make things work the same way in C/C++, it's nice that the default way in rust's embedded-hal is also the way with the least overhead.
-
Comment on The coming firmware revolution in ~comp
time Link ParentBased on the embedded developers I know and interact with, I can definitely agree that it's going to be an uphill battle to get them to change how they do just about anything. Using C++ features...One area that I can see being hard for Rust to break into is replacing embedded C.
Based on the embedded developers I know and interact with, I can definitely agree that it's going to be an uphill battle to get them to change how they do just about anything. Using C++ features in embedded development is still frowned upon by most of the embedded developers I know despite widespread support, and almost no downsides provided you use an appropriate subset of C++ that is embedded-friendly (i.e., no major standard libraries, nothing that heavily makes use of the heap, etc.). While I personally love rust for embedded development, trying to convince the embedded world at large to move away from C is going to take a great deal of effort.
The subset of C they're working in -- no heap allocations and linted to the MISRA C standard -- already eliminates large classes of bugs rust addresses. I don't know if the large jump in language complexity and features is going to be an added benefit for them.
I've actually been getting very into embedded rust programming of late, and I find that while things like avoiding the heap are indeed helpful in avoiding bugs, the greatest benefit of embedded rust is to practically guarantee that race conditions and other memory issues are not possible at compile time, with no run-time overhead. In my past embedded C/C++ projects, debugging race conditions has been extremely difficult and time consuming, due to their intermittent, ephemeral nature. I'll gladly trade a bit of language complexity to avoid the possibility of these types of bugs being possible in the first place.
I also feel, as someone coming from a programming background of mostly embedded C/C++ and getting into rust, that people with the embedded C mindset are uniquely suited to understanding the memory safety features of rust such as the borrow checker. Embedded C programmers are already intimately familiar with having to manage memory at a low level, and the rust compiler just enforces an explicit, rigid framework to allow this to happen. I work with a local hackerspace to teach people programming, and the ones who already know C have been most receptive to learning rust concepts, as opposed to those who are more familiar with languages like javascript and python, that abstract away low level memory management to a much greater extent.
Another reason that I feel rust is well suited to embedded development is that one of its big selling points is its zero-cost abstraction model. This allows for syntax used in higher level, more abstracted languages, but it doesn't cost anything in terms of processing time or memory.
A good example of this being an advantage for embedded programming is setting a pin as an output, and toggling it. In a typical embedded C hal, there would usually be a function that has to check if a pin is configured as an output before setting it at runtime. This costs a small bit of time every time the pin is toggled.
With embedded rust's model, each pin exists as a single entity in a peripheral struct, so due to the borrow-checker and compiler guarantees, there can only ever be one reference to that pin in use at any given time. When you want to configure a generic pin as an output, the pin is returned as a new type that has implemented a trait with functions to allow you to toggle the pin on and off. Since the pin is a singleton, and it's been transformed into an output pin type, it is impossible for it to be configured as an input now, and therefore you no longer need to check if it's valid to toggle the pin at runtime.
While it is possible to explicitly configure embedded C to work in the same manner, it would require you to explicitly code your own compile-time types and checks, instead of using the standard tools provided by a typical manufacturer's HAL libraries. With embedded rust, there's a generally an agreed upon standard way of doing things as outlined in the embedded rust book, so changing architectures is also made simpler, and still results in the same zero-cost abstraction model working on every architecture.
I will readily admit that the embedded rust ecosystem is still a long way from being a ready replacement for C, especially on less-popular architectures. Rust's default use of LLVM instead of gcc for compiling binaries immediately precludes many architectures not supported by LLVM. A rust gcc backend which will allow support for every architecture gcc supports is in the works but it's still a fair ways off. Even once the gcc backend is implemented, it will still be a while before embedded-hal libraries can be implemented for architectures not currently supported by LLVM.
As part of my current project linked above, I found that the rust hal for the chip I am using is far from complete, and I've been working alongside my project to help implement the hal as I go. Many other embedded ecosystems are in a similar state of not-yet-complete-or-stable. This is definitely a valid reason that commercial embedded shops would want to avoid rust at this time.
Overall, I feel that rust offers significant advantages in the embedded space, as the memory safety problems rust is fundamentally trying to solve as a language are the same problems that embedded C developers have had to manually address up to this point. The embedded rust ecosystem is still in its infancy, but it is growing rapidly, and I feel that eventually it will be a popular alternative to embedded C development.
Disclaimer: I haven't had time to watch the video yet, so this is all only in response to the comments. Sorry if the video already covers these ideas.
-
Comment on Take a look inside Steam Deck in ~tech
time Link ParentWell, I guess I missed that video when it was released, but good on Sony for the same reasons as Valve. The trend of making it possible for end users to repair and maintain their hardware is one I...Well, I guess I missed that video when it was released, but good on Sony for the same reasons as Valve. The trend of making it possible for end users to repair and maintain their hardware is one I am very much in favor of, so any progress towards that end is good in my book.
-
Comment on Take a look inside Steam Deck in ~tech
time LinkWhen I clicked on this video, I expected some developer that got a demo version of the steam deck breaking their NDA and doing a tear-down anyways. I was pleasantly surprised to find out that the...When I clicked on this video, I expected some developer that got a demo version of the steam deck breaking their NDA and doing a tear-down anyways. I was pleasantly surprised to find out that the video came directly from Valve. This just makes me even more excited about this product, as I saw nothing but normal fillips head screws, and nothing unnecessarily glued down inside the device.
Sure, it's not the easiest thing to perform maintenance on, but it's at least possible. not only that, the company making it had produced the video going over potential pitfalls and issues that may occur when taking one apart. That's practically unheard of for almost any other gaming devices that have existed in my lifetime. Props to Valve for backing up their 'it's yours, you can do anything you want with it' statements.
-
Comment on Advice on colorful programmable LED lights in ~tech
time Link ParentI believe that when I was making my decision on which bulbs to buy, I was highly influenced by this review video. I haven't ever used Hue bulbs myself, so I don't know about their shortcomings /...To that end; would you recommend the sengled zigbee rgb bulbs you mentioned over hue bulbs?
I believe that when I was making my decision on which bulbs to buy, I was highly influenced by this review video. I haven't ever used Hue bulbs myself, so I don't know about their shortcomings / advantages outside of other people's reviews on the internet. I initially bought a couple of the sengled bulbs to test, and I was happy with the results, so I've stuck with them for my whole house. If you've already bought some hue bulbs and a hub, you can integrate the bulbs you already have into Home Assistant, and then either get more hue bulbs or another brand, and control them all together from one interface.
-
Comment on Advice on colorful programmable LED lights in ~tech
time Link ParentI've gone down the Home Assistant path for RGB lighting throughout my house. I've got Home Assistant OS Installed on a Raspberry Pi 4 with an SSD. I use a HUSBZB-1 dongle which allows...Or if you want complete control, you can invest some time and get Home Assistant up and running. You can completely customize it, but it is a lot of up front time investment.
I've gone down the Home Assistant path for RGB lighting throughout my house. I've got Home Assistant OS Installed on a Raspberry Pi 4 with an SSD. I use a HUSBZB-1 dongle which allows communication with Z-Wave and Zigbee devices. All the bulbs in my house are Sengled Zigbee RGB Bulbs (make sure not to get the bluetooth only ones that only work with Alexa devices, you need the more expensive zigbee bulbs), and I've had no issues with responsiveness or disconnecting bulbs. On the same Zigbee network I've got some Ikea Fyrtur roller shades, and on Z-Wave I have several Inovelli smart switches as well, all running off the one HUSBZB-1 dongle. All in all I've currently got about 16 Z-Wave devices and 45 zigbee devices.
With HomeAssistant you can do lots of neat things like set up scenes and toggle them with switches from a web interface or phone app. One scene I particularly like is 'theater mode' for my living room, which will close the curtains and dim the all the lights in the room at the flip of a switch. I've also got scenes set up to turn all the lights off completely when I'm leaving the house or going to bed, or to turn them all on at full brightness when I'm cleaning.
As @JXM mentioned, it can be pretty technically complex to get everything set up the way you want. I've got a fair bit of networking, system administration, and general programming experience so it definitely made sense for me to go with this route, as I highly value the flexibility, ability to combine different technologies, and complete local control over my devices.
If you feel you're up to the technical challenge of setting up a Home Assistant server, I highly recommend it. It won't be the fastest or easiest way to control light bulbs, but it'd definitely among the most versatile and customizable.
-
Comment on What games have you been playing, and what's your opinion on them? in ~games
time LinkI picked up the Halo Master Chief Collection on steamrecently, and I have now played the Halo Reach campaign for the first time, and I'm making my way through Halo CE this week. Reach was a pretty...I picked up the Halo Master Chief Collection on steamrecently, and I have now played the Halo Reach campaign for the first time, and I'm making my way through Halo CE this week.
Reach was a pretty solid game in terms of gameplay, especially since prior to playing reach, I had only played the original Halo back on the xbox. The story wasn't the most engaging for me, and it felt like they were referring to a bunch people and things I didn't know about with little to no explanation. Hopefully the other games in the series will fill in the gaps in my knowledge and may make me like the story more in hindsight.
The original Halo has been fun and somewhat nostalgic for me, but as I play through the later missions for the first time in over15 years, I'm finding the game much more repetitive and uninteresting than I remember. It feels like every room and hallway is the same as the previous one, and the only way to tell I'm still moving forward is if new enemies are spawning when I enter the same room full of the same few enemies for the 15th time this level. I've honestly forgotten how the game ends, so I don't know how much longer the backtracking and repetitiveness will continue, but hopefully the end game will at least take me to somewhere new.
All things considered, I'm glad I am able to play reach and the original game again on a PC with updated graphics, and I look forward to seeing what happens in the future entries in the series as they are released.
-
Comment on LDS Church suspends all worship services worldwide due to coronavirus in ~humanities
time LinkThis honestly seems like a good move. Hopefully other churches will follow suit and help to slow down the spread of COVID-19.This honestly seems like a good move. Hopefully other churches will follow suit and help to slow down the spread of COVID-19.
-
Comment on No Man's Sky - Beyond update patch notes in ~games
time Link ParentYou might want to wait a bit before pulling the trigger on VR. Looks like lots of people are having trouble with frame rate and stuttering unless the settings are really low. Probably worth at...You might want to wait a bit before pulling the trigger on VR. Looks like lots of people are having trouble with frame rate and stuttering unless the settings are really low.
Probably worth at least waiting until they know if it's a bug, or if it's a a problem with the game itself.
-
Comment on Teensy 4.0 Released. in ~comp
time LinkI love the Teensy platform, and I've used many in my personal projects over the years. This new one seems like a massive improvement in terms of hardware functionality. Looks like a great step,...I love the Teensy platform, and I've used many in my personal projects over the years. This new one seems like a massive improvement in terms of hardware functionality. Looks like a great step, and I look forward to seeing how people use it. Now I just need to come up with a project that would be able to use these features...
I found an email from digikey that had a hall effect sensor in it, and it matches the rough timeframe of when I was working on it as well. The part is listed as:
I didn't get far enough along on the project to have a writeup on my blog, so unfortunately the details from 5-6 years ago are a bit fuzzy. I also can't find the bin where I put all the pieces of the joystick at the moment, but from what I remember the hall sensor itself is hot glued into the top of the metal stick, and I glued the magnet into the plastic case that sat on the stick and rotated around it after carving out a place for it.