I like games of all types and sometimes try to make them. IT Professional who likes mechanical keyboards and weird hobby electronics too much. He/Him.
I’ve never understood the “these people hate Star Trek!” take I’ve seen around the new shows. It’s clear that nobody working on these sets out to intentionally make a bad show. Some of the Easter eggs and references are deep cuts, so it seemed obvious to me that the people working on these are big fans.
To give credit where it’s due, RotS and many of the Disney-era Star Wars products have gone a long way to fitting the glamorous, shiny prequel aesthetic into the gritty, used, “lived in” aesthetic of the OT. I’m not the biggest fan of The Last Jedi, but I actually think the implicication of the shiny galaxy just being a property of the rich inner rim planets was a great move in unifying everything.
I’m going to be honest, Klingons in the TNG era always felt too goofy to me. They weren’t a proud warrior culture so much as borderline clownish space vikings who spent more time getting drunk than actually conquering anything. A redesign and change in how their culture(s) present on screen was welcome for me, and I think Discovery did a great job. I even liked the way they recontextualized the Klingon language, to make it sound more alien and more threataning than the staccato, oft-mispronounced mess that we got in the TNG era.
That said, I also think there was a missed opportunity with them. For a long time, I’ve had a head canon of the different looks of Klingons throughout all of the eras could be chalked up to these all being distinct peoples from within the Klingon Empire. It stands to reason that over a long enough time scale, an empier spanning multiple stars would start to consider people not originally from their homeworld “Klingon,” even if they might be genetically different. I always thought it would be cool if the TOS smooth forehead Klingons were actually just one species that were culturally Klingon, where the Worf-type were another, and the General Chang type was yet another. It would provide a way to smooth over the aeshetic differences with an in-universe explanation that doesn’t require any retconning except for a handful of episodes from ENT that die-hards didn’t like anyway.
But oh, well. One can dream.
Xfce might be the choice here, since most of benefits of Wayland won’t really apply to this machine (from an end user perspective) and it is relatively lightweight.
Been hearing a lot about Hyprland, will probably check it out even if I don’t end up using it on this build.
How does loading up a game through steam work with that? I’m a big fan of Sway (and i3) but I don’t use them on gaming focused systems at all, so I’m curious.
Hoping the bug with Corsair Vengeance RGB Pro is fixed so it doesn’t take up a huge amount of CPU resources to run effects. I had a really cool set of effects going that I just couldn’t use because of this.
To be fair though, that isn’t fully OpenRGB’S fault, I think the bug is actually in the effects plugin, not the main application.
You can use it on Arch too. It’s probably worth checking out the whole Power Management page on the wiki, but in short, the major desktop environments all have hooks for these options, and there are a lot of options for supplementary packages to power-profiles-daemon that you might find helpful.
Thank you ☺️
It’s been several years since I worked with Manjaro, so I don’t remember which specific apps I ran into problems with, but the general idea is this:
Manjaro holds back packages for several weeks behind vanilla Arch, so packages from the AUR are often built on versions of their dependencies that aren’t yet available to Manjaro users. This can result in apps not installing properly (or at all), or apps that were previously installed without issue suddenly breaking when they attempt to update.
This isn’t actually specific to Manjaro – other Arch-derivatives like Garuda can also run into this problem. You’ll find that any Arch-based distro that makes significant changes to Arch (like holding back packages, or distributing versions of packages different to the ones in the Arch repositories) can have issues if it’s attempting to use things from the AUR. Arch derivatives that make no changes to the base system, and just use the vanilla Arch repositories don’t have this problem. Endeavour OS is an example of this, as the only changes it makes are additive – they have their own extra packages, but don’t change any core functionality from vanilla Arch.
EposVox on youtube ran into some issues with Garuda about a year ago, and those are of the same flavor as what I experienced on Manjaro, even if they aren’t identical issues.
I do have one note of caution for anyone considering Manjaro: For most uses it’s totally fine, but if you plan to make heavy use of the AUR, tread carefully – because it updates on a different cycle from vanilla Arch, there can sometimes be unforeseen breakages in AUR packages. If it’s a gaming-only machine, this will likely not be a problem, but if you plan to also daily drive it as a general purpose workstation, this might be a deal breaker.
Endeavour is what I recommend for people who are technical but not interested in setting up Arch from scratch. It’s about as close to Vanilla Arch as you can get while having an installer and sane defaults. It’s kind of perfect for gaming, where up to date packages can be the difference between a game working flawlessly and that same game being a choppy mess.
I set my partner up with it, and they’ve had a very easy time running all their favorite games from Elden Ring to Valheim. No headaches required!
I mean it’s not a comeback, it’s just advice. I started using Linux in 2004, when trying to Google an answer basically never worked, and once I was told that the included manuals contained all the instructions for everything, I started having a much better time. It was humbling since I considered myself very proficient with Windows troubleshooting, but I had to recognize that I still needed to read the instructions now that I was in unfamiliar territory.
Anyway, since you’re not interested in that, have a nice day, and I hope your future experiences work out better for you.
If it’s a terminal command you need help with, type “man [command]” in the terminal and it will give you the literal manual page for the command. For example, to get the manual for tmux, type “man tmux”
If it’s something else, check the Arch Wiki. Yes, even if you aren’t running Arch. It’s some of the most comprehensive Linux documentation all on one site and most of it can be generalized to any distro.
But to be honest, your attitude here makes me think you will never have a good time on Linux. It does require a certain curiosity and willingness to learn – maybe even some patience while you get the experience to intuit solutions as you likely already do on Windows without thinking about it.
The manuals really do contain exact information on how to engage with pretty much everything, but if someone suggesting that you use the resources designed to help you makes them “an ass,” then I suspect you will simply fail to become familiar with the environment. I’m not trying to be a dick, I’m just telling you that when you’re new, you need a different mindset than what you’re showing with this comment.
I have an XPS 13 with the i7 1165G7 and Xe graphics are fine for light stuff like Minecraft (even with shaders) or indie titles from the last 10 years. He won’t be able to push very high framerates or resolutions, but at 1080p with low/medium graphics, it should be workable.
Ben Milton’s take on traps is, I think, the best way to handle them.
Don’t use traps as a hidden thing. Make the trap itself obvious to the players, and describe it’s positioning. The trick should be for the players to figure out how to either avoid or safely disarm the trap.
One example he uses is a pit trap with a narrow board serving as a bridge over the top of it. The smell of volatiles indicates that there may be some kind of fuel at the bottom of it. The board is on a rotating mechanism, and if anyone tries to stand on or otherwise move the board, it ignites the fuel below with flint inside the mechanism, like a lighter. Since the pit is too large to jump across, players will need to find another way across.
In my own game, I recently pointed out a section of floor filled with skeletons whose legs were partially sunken into the tiles up to the knee. Since the sections of the floor were too long to jump across, they tested what was wrong by throwing objects onto the tiles and seeing what happened. Once it was clear that only objects that had been stationary for a few seconds sank in, they sprinted through the hallway and made it to the other side fine (one character lost a boot). They had fun, nobody felt it was unfair, and I would call that a win.
Unfortunately for them, the floor on the other side of this trap was greased, so they went sliding down a chute to the fourth floor of the dungeon, and had to look for a way back up, which came in the form of a previously inactive elevator that was a shortcut back to the first floor.
Sen’s Fortress in Dark Souls 1 is a good example of how traps like these can be utilized. They’re all obvious and easy to avoid, and serve more as positioning puzzles than as gotcha mechanics.
This, at least, is not entirely true. OD&D does not have any distinction at all between male and female characters in the original 3 pamphlets.
Pretty sure that stuff came in later, post-Greyhawk. It certainly showed up in fanzines of the late 70s, though…