Wikipedia says the virtual memory cards are compatible between them. But I’ve never done anything with the Memcard Pro. I have messed around with PS2 memory cards and PCSX2 and generally the raw bytes are compatible between the two. I would imagine the M.Pro is the same.

To answer my own question, based on all the responses, thank you everyone, here’s what I’m thinking.

Get a number of different colored d20s, one for each race team. At each leg of the race roll them all on the table for the players to see. Any 1s are automatically knocked out of the race, they had some catastrophic failure. Any 20s get a marker to indicate some great success or inherent skill that will grant them a bonus later.

Then in the final portion of the race I’ll take the three teams with the most markers and put them in scene in direct competition with the Players. I’m thinking this will allow my Player’s to go hunt teams that are doing well to take then out before the final leg if they want and let them see how dangerous their competition is.

I took a listen and it doesn’t address the issue of a large number of racers.

I think you’re right about making events or tables to make the scene feel alive and dynamic. We should focus on just the players and have story events announced to them as needed.

I think this is the answer, we only care about the players and what’s happening around them.

I’m not sure what a long action is, but the players won’t be confined to just race mechanics. They’ll be able to cheat if they want. Or come up with novel uses of resources to leverage advantage.

I looked at the sample on DriveThru which had just the first page of chase rules. Seems to be based on a series of events through the race. It seems like a fun way to randomize a race, but does address the problem of a large number of racers.

The limiting factor in 1e, discouraging long resting in the dungeon and using spells to recover hp was random encounters. The Tomb unusually does not have random encounters, but you’re not supposed to tell your players that.

From what I understand, players were scored individually. So those players who convinced the others to take on the dangerous parts fared better.

I scanned through the 1e DMG and PHB, but I didn’t see anything about a base chance a trap does not trigger. These two traps, the needle and the pits, have their specifics listed in the module.

The needle trap is always found if the box is searched, and always triggers if precautions aren’t taken. It harkens back to skill play, where the player is meant to find alternate means instead of rolling dice. It’s like how the west false entrance specifically says there’s no saving throw.

The pit trap does have a percentage chance not to fall in, but it still triggers. Being as the pits are 10’ square I do enjoy the idea of catching multiple PCs at once. And that was possible back in the day with how turns were organized, which I’ll cover in my next post.

I definitely agree about the the HP and other resource management. I’ll be covering some of that in my next post.

Those late 80s, early 90s network sci-fi shows are a special kind of train wreck that I love.

One of the later seasons of Earth Final Conflict. They built up the female support role to be this tough brilliant independent woman who didn’t need no man. Then when the male lead left the show and she took the lead roll they immediately had her fall into a romance with some no name character that wrecked her confidence.

On the reverse, Sliders, the male lead and female support had this will they won’t they for a bit, but then in an awkward scene later between the two support roles she relates that off camera they had “the talk” and said they weren’t an item with no real feeling about it.

This is a great read. I’ve worked on software my whole career that wasn’t designed to kill someone, but could quite literally kill someone if it wasn’t correct. There’s a weight that comes with that kind of responsibility.

We were all cheated my friend. We were all cheated.

It was a good read, but holy fuck did vice’s website crash 20 times trying to read the last two pages.

How should a contributor gauge whether to make big changes to “do it right” or to do it a little hacky just to get the job done?

When you work in enough diverse codebases, with enough diverse contributors, you begin to understand there isn’t one objectively right way. There are many objectively wrong ways to do something. Picking a way to do a certain task is about picking from tradeoffs. A disturbingly common tradeoff is picking rapid development over long term maintainability, but that isn’t not the right way to do it in a competitive space.

Needs change over time and certain tradoffs may no longer apply. You’re likely to see better success making lots of little hacky fixes until it’s not a hack anymore because you’ve morphed it slowly over time.

Version control, git et al, allows you to make multiple commits in a single PR, so you could break the changes up to be more reviewable.

Hear, hear! I would add that it multiplies again, again when other people are actually using the product. Engineers famously build tools for engineers which can leave something to be desired for the layman.

My experience, ymmv, the most work went into configuring everything you need or want the first time. The right drivers for your graphics card, for your webcam, wifi, acpi multimedia keys, etc. Though I don’t use a gnome/kde/DE, so some of that may automagically work for you. After that though, updates don’t tend to break the things you’ve already fixed.

One time in 5 years the names of some acpi keys changed, and I had to update the script, and that wasn’t really arch’s fault. Also Google did a funny thing with their monospaced font that xft couldn’t handle, again not an arch specific thing.

And here’s a hot take for you, I only update about every 18 months. That’s usually how long it takes Discord to become binarily incompatible with installed libraries. Update the keyring first and never a problem.

I too have had idle thoughts about what lessons to pass on and what was lacking in my own formal education.

My elevator pitch is to have a semester long project broken down by feature. You get a couple weeks to develop, but after each one is complete you have to trade code bases with someone else in the class. It’d teach both how to work in an established code base, and how to be kind to some future maintainer (who might be yourself).