skittlebrau's comments

Tell me you don’t ski in New England without telling me you don’t ski in New England.

I have the same issue, seemingly, with my 2017 Outback. My battery kept dying for which I got a lot of run around from the dealer (gaslighting about keyless entry drains it if the key is too close to the car, etc.) Eventually I found a Reddit post about the DCM (Starlink) module, removed this fuse, and it hasn't died since. It sounds like it wakes up in the middle of the night to do something and thereby drains the battery, so whenever they test at the dealer for extra drain, they find nothing. Having that fuse out kills some speakers and the mic too, so it's a kind of annoying solution. I have not gone back to complain again recently though, so maybe they can do whatever it is they did for you. I saw some posts about wiring it to another circuit that's off when the car is off, but I am not confident doing that myself.

I spent three summers sorting QSL cards at the outgoing bureau (between giving tours) at the ARRL. It perhaps wasn’t so much “magical” as tedious, but it was a pretty cool job as a high school-aged ham. I even got my own ARRL staff QSL cards which was pretty sweet. I probably still have some in a box somewhere.

I too haven’t been active in a long time, but do think about getting back into it now and again as well.

Looks like that’s the max weight for any package.

Spaceteam is kind of a "Jackbox bridge simulator" if you haven't tried it. It's definitely silly and not serious, and in my experience can be enjoyed by a pretty wide audience. https://spaceteam.ca/

BonusXP | Game Developer | Allen, TX (Dallas area) | Onsite or Remote | Full-Time

BonusXP, developer of the BAFTA-nominated Stranger Things: The Game, is looking for talented developers to join our team to work on a next-gen multiplayer RPG. We hire programmers who can work in a wide variety of areas and have a passion for games. We currently have openings for a Senior Multiplayer Programmer, a Senior Programmer, and a Mid-level Programmer.

Our studio is founded by industry veterans who have learned the hard way that endless crunch is not an effective or sustainable way to develop quality games. We have an highly-iterative process where everyone is involved in the game design process, including regular playtests of our games under development.

See more details at https://bonusxp.com/#careers

“Starting October 14th, 2019 Steam will require all new macOS Applications to be 64-bit and notarized by Apple.” (https://partner.steamgames.com/doc/store/application/platfor...)

BonusXP | Game Developer | Allen, TX (Dallas area) | Onsite | Full-Time

BonusXP, developer of the BAFTA-nominated Stranger Things: The Game, is looking for a talented programmer to join our team. Shipped games, knowledge of C#, and experience with Unity are all pluses, but not requirements. We look for programmers who can work in a wide variety of areas and have a passion for games.

Our studio is founded by industry veterans who have learned the hard way that endless crunch is not an effective or sustainable way to develop quality games. We have an highly-iterative process where everyone is involved in the game design process, including regular playtests of our games under development.

https://bonusxp.com/jobs/ or email [email protected]

IMO as someone who works on games, developers will come along with high quality Linux builds when there are a significant number of users that demand it. I think anyone who's doing a Linux port now is doing it out of the goodness of their hearts and not as an economic decision. It doesn't matter if you're using an engine that already supports Linux, it's still extra work to develop and test, and it's still more support issues that (in the current market) you are very unlikely to make back in additional sales. I'm certain most Linux gamers also have Windows installs, so while they might complain about having to dual-boot, they still do it.

If Proton bridges the gap to the point where people are 1) more willing to be on Linux and 2) less willing to deal with dual-booting for the few games that don't work without it, then maybe the number of Linux-exclusive gamers will grow. That's when you'd see significant attention paid to proper Linux builds. (There are of course other impediments to people switching over to Linux full-time besides games support, so I don't think the Year of Desktop Linux is quite imminent yet.)

Beers on "nitro" are still carbonated with CO2. The nitro is used to achieve a higher serving pressure used to force it through a diffusing nozzle on the tap. N2 doesn't actually dissolve in liquid very easily compared to CO2. If you put the CO2 at higher pressure, it makes the beer more carbonated over time.

You can run your updates faster than the slowest ping. You just need more command latency. So when you, say, command a unit to move somewhere, there's an agreed-upon future time when that's going to happen. This time has to be longer than it takes for the command to get to everyone. If it's not, then you stall. If command latency is very high, the game feels very unresponsive though (and tricks of showing local/visual-only confirmation of your commands only goes so far).

You can't run updates any faster than the slowest machine can run them, though, or again you stall. This was a bigger problem on Age 1 and 2 where render rate and update rate were linked. On Age of Mythology and beyond, the render rate was decoupled from the update rate, so updates could happen more slowly while animations and so forth could still look smooth via interpolation.

We got way better at dealing with synced/deterministic simulations over time. Much better sync logging system, decoupling render rate from simulation rate, more institutional knowledge/intuition about all the surefire ways to break determinism (using unsynced random number generator, uninitialized variables, reading local machine state from sim, using local timers rather than synced ones, not resetting floating point flags after calling Direct3D, etc). The bad news was once we were generally avoiding all the common causes as a matter of course, the sync bugs that remained were non-trivial ones that took lots of time to diagnose.

We made a Stranger Things mobile game for Netflix that is free and devoid of IAP. It's just freely available on the app stores though, and does not require a Netflix subscription. https://itunes.apple.com/us/app/stranger-things-the-game/id1... and https://play.google.com/store/apps/details?id=com.bonusxp.le...

Very cool to see this (I worked on Hero Academy). When you say the randomness was removed, does that mean player's hands were a specific fixed shuffle or something else?

How does it fair against good human players? Would it do much worse with randomness added back?

I have never written anything up personally, but I'm sure there is some stuff out there to be found.

Get any two former Ensemble employees together, possibly buy them a beer, and you will almost certainly get some stories that sound apocryphal but probably actually happened :)

Strangely I am responsible for the name of this cheat code. It's an accidental-turned-intentional misnomer for a place we used to eat a lot during Age2 development called Fred's Downtown Philly.

Also, "exclusive checkout" is something that doesn't even really make much sense in git, but is important for people collaborating on non-mergeable assets (3D models, textures, etc). We end up using git for code and in-game assets but p4 for source art assets.

Cocos2d-x is another option: http://www.cocos2d-x.org/

I worked at Ensemble Studios (Age of Empires) and by the time we shipped Age of Mythology we had much better tools for dealing with sync bugs. Most of the run of the mill ones could be tracked down pretty quickly, but there were still plenty of painful ones. What made them easier to track down was a more advanced tracking/logging system for the simulation state history. The simulation was littered with tons of sync logging code that tracked the execution flow and values of things as they were calculated/updated. When the state went out of sync, all the machines would dump their last couple updates worth of logging (often several gigs) and you could diff them to see where things diverged. If you were making a synced simulation game, a nicely done version of this type of thing would be pretty useful to have, especially if you made a good diff tool to go with it.

It's not completely obvious what technology you could make that would make it easier to avoid sync bugs in the first place. You could make a good network command-passing and simulation timing library, but in my experience the majority of problems did not come from bugs with the networking itself. Most of the sync bugs were from things like uninitialized variables, memory overwrites, using user input or other local machine state directly in the simulation without going through a multiplayer command, using a non-synced random number generator in the sim, DirectX changing the FPU rounding mode on you, etc. (Using a "safer" language would help with stuff like uninitialized variables/memory overwrites of course, but at an inevitable performance cost. Static code analysis tools are pretty good at finding these type of problems now too.)

Project Settings/Editor/Asset Serialization/Force Text. I think this might be pro-only though.