> Because the common interaction people have with their insurers is "We are denying this because of <REASON>"
Of the multiple times my insurance has declined to cover one thing or another, not once have I ever gotten a reason. The claim is just billed to the patient, directly. I'm then left wondering things like "Hey, your plan documentation says 'preventative care is 100% covered'. This was preventative care. Why is it being declined?"
If I want to know, it's an hour of my time, at least, going back & forth with insurance to learn "Oh, '100% covered' … except in these cases."
I've never seen the point of HSAs, either. The only benefit is the tax difference. There are (usually unknown, unstated upfront) plan fees that eat into that, and coupled with the higher deductibles and worse plan coverage, you're going to pay more out of pocket. It's never been clear to me if (higher OOP + plan fees) < (tax savings) is true, like they want you to believe.
An employer sponsored HSA is the single most tax advantaged account in the US, and Fidelity HSA have no fees. No FICA tax, no income tax going in, on investment returns, and coming out. Worth tens of thousands of dollars over 20, 30, 40+ years.
If your employer is shitty and doesn’t offer Fidelity HSA, you can also easily rollover the HSA funds to Fidelity every year to avoid the fees.
The coverage for HDHP plans is the same, since it’s the same insurer. The only change is deductible/copay/oop max, which is offset by lower premiums and higher cash flow for younger/healthier/higher earners shouldn’t matter.
128 ticks per second servers. (And lo, suddenly the article's thesis is inherently clear.)
A "tick", or an update, is a single step forward in the game's state. UPS (as I'll call it from here) or tick rate is the frequency of those. So, 128 ticks/s == 128 updates per sec.
That's a high number. For comparison, Factorio is 60 UPS, and Minecraft is 20 UPS.
At first I imagined an FPS's state would be considerably smaller, which should support a higher tick rate. But I also forgot about fog of war & visibility (Factorio for example just trusts the clients), and needing to animate for hitbox detection. (Though I was curious if they're always animating players? I assume there'd be a big single rectangular bounding box or sphere, and only once a projectile is in that range, then animations occur. I assume they've thought of this & it just isn't in there. But then there was the note about not animating the "buy" portion, too…)
When Battlefield 4 launched it had terrible network performance. Battlefield 3 wasn't great but somehow BF4 was way worse. Turned out while clients sent updates to the server at 30 Hz, the server sent updates back only at 10 Hz[1].
This was the same as BF3, but there were also some issues with server load making things worse and high-ping compensation not working great.
After much pushback from players, including some great analysis by Battle(non)sense[2] that really got traction, the devs got the green light on improving the network code and worked a long time on that. In the end they got high-tickrate servers[3][4], up to 144Hz though I mostly played on 120Hz servers, along with a lot of other improvements.
The difference between a 120Hz server and a 30Hz was night and day for anyone who could tell the difference between the mouse and the keyboard. Problem was that by then the game was half-dead... but it was great for the 15 of us or so still playing it at that time.
Also for comparison, the Runescapes (both RS3 and Oldschool Runescape) have a 0.6 tick/second system (100 ticks/minute). It works rather well for these games, which I guess highlights that some games either a) can get away with high latencies depending on their gameplay mechanics, or b) will evolve gameplay mechanics based on the inherent limitations of their engines/these latencies. RS3 initially leaned into the 0.6s tick system (which is a remnant of its transitions from DeviousMUD to Runescape Classic to RS2) and eventually developed an ability-based combat system on top of what was previously a purely point-and-click combat system, whereas OSRS has evolved new mechanics that play into this 0.6s tick system and integrate seamlessly into the point-and-click combat system.
Having played both of these games for years (literally, years of logged-in in-game time), most FPS games with faster tick systems generally feel pretty fluid to me, to the point where I don't think I've ever noticed the tick system acting strange in an FPS beyond extreme network issues. The technical challenges that go into making this so are incredible, as outlined in TFA.
OSRS exists in a pretty fascinating place, mechanically.
High level PVP play is basically a turn-based-tactics game, with some moves (attacks or spells) taking more "ticks" than others, meaning there's a lot of bluffing and mind games in anticipating what your opponent will do next.
If you're really fast, you can even equip tank gear for your opponent's attack, then swap back to mage gear for your own. Very strong if you can pull it off consistently due to how paper thin mage robes are. Not sure how many other games are that...slow?
And yeah, a lot of people are quite predictable and easy to read. In fairness there are only a handful of things you could possibly do in a fight :-)
They're right, when they said 0.6s tick they mean there's a tick every 0.6 seconds.
It's important to some players because you can get some odd behaviour out of the game by starting multiple actions on the same tick or on the tick after you started a different action. It's ridiculous click intensive but you can get weird benefits like cutting the time to take an action short or get xp in 2 skills at once.
For those unfamiliar, the act of absuing the tick system to "stack" actions like this is called "tick manipulation". It's a relatively common practice among high-efficiency players and PKers (player killers, players who engage in PvP). Many players eventually come to use this mechanic in PvE regarding "hard food", "soft food", and potions. Typically, your character is limited to one action per tick, but due to engine limitations and quirks, multiple actions can be performed in the same tick that would, out of "correct" order, take multiple ticks. A great example of this is eating a piece of hard food, eating a piece of soft food, and drinking a dose of a potion in the same tick. Out of order, this isn't possible and your character is limited to healing once per tick. Done in the correct order, your character may heal three times in a single tick.
RS3 has almost seemingly leaned into this quirk of the engine, causing many high level activities to top out around 250-300 actions per minute (2.5-3x the tick rate of the game itself, as measured by keypresses in some streamers' software setup; this doesnt include mouse interactions). These extra actions include swapping weapons, casting spells, swapping gear, using items, eating food and consuming potions, changing prayers (character effects/buffs), and movement. Gameplay becomes incredibly complex due to the nuances of the engines interpretation of actions, despite the limited temporal fidelity of actions. These actions become so rhythmic in fact, that many players will play 100 or 200 BPM music as they play to subconsciously sync their actions to the game engine.
Client update was measured to be 73, not quite matching the 128 server tick and update rate. Maybe it changed in the last 5 years. CSGO private servers also ran with 128 tick rate.
> I assume there'd be a big single rectangular bounding box or sphere, and only once a projectile is in that range, then animations occur.
Now that's a fun one to think about. Hitscan attacks are just vectors right? So would there be some perf benefit to doing that initial intersection check with a less-detailed hitbox, then running the higher res animated check if the initial one reports back as "Yeah, this one could potentially intersect"? Or is the check itself expensive enough that it's faster to just run it once at full resolution?
This is the basis for basically every physics engine in some form of another. Collision is divided into the "broad phase" pruning step that typically uses the bounding box of an object and a "narrow phase" collision detection step that uses the more detailed collision primitives
CS2 is mostly 64 tick from what I understand. The "sub-tick" stuff is timestamping actions that happen on a local frame before the next tick. So in theory the client feels perfectly responsive and the server can adjust for the delta between your frame and the tick.
In practice it seems to have been an implementation nightmare because they've regularly shipped both bugs and fixes for the "sub-tick" system.
The netcode in CS2 is generally much worse than CSGO or other source games. The game transmits way more data for each tick and they disabled snapshot buffering by default. Meaning that way more players are experiencing jank when their network inevitably drops packets.
That's very interesting. The CS2 netcode always felt a little brittle and janky to me, but I could never pin point exactly what was causing the issues. Especially since other games mostly run fine for me.
I also remember reading a few posts about their new subtick system but never put two and two together. Hopefully they keep refining it.
Worth noting that part of the packet size appears to be due to animation data, which they’ve begun the process of transitioning to a more efficient system. [0]
With that being said: totally agree on the netcode.
It's actually incredible how CSGO was such a great game and it's been replaced (not deprecated, replaced!) by CS2 which is still inferior over 2 years after the launch.
CS2 is 64 tick under the hood, with interpolation between the ticks. In the beta, server operators could modify the tick rate by patching the server binary, but when that revealed inconsistencies (which was meant to be avoided with the "subtick" system), they hard coded the client side tick rate to 64 [0].
Nowadays it's more like 20 players and 80 bots, so a lot less networking stuff going on, and the bot AI is so basic that I doubt it has a significant impact on server performance unless it's very badly implemented.
Also assumes that the bots coexist on the server. My first thought would just be to connect them like any other client, with compute of their own so the server doesn't even know it's a bot.
In my experience you can do reasonable bots cheaper than sending network updates to a regular player. Thats just straight up, but you can also tick their logic way less than every update if you want. Even more way-less if nobody is near them or spectating them.
Also some stuff you might want to calculate for them to use to make decisions can be shared among all bots.
As I aluded to in my post, how expensive the AI is depends entirely on how complex and optimized is. Remember that the process of encoding and sending packets to a client and receiving/decoding/processing the client's packets in turn is completely skipped for bots.
Fortnite bots are very barebones and are only capable of performing a handful of simple tasks in repetitive ways. It's entirely plausible that the code responsible for governing their actions is fast enough to be less expensive than networking a real player.
An advantage to bots is that the server can trust them. It doesn't need to do any verification of input since it can trust that they aren't cheating (except they probably are...).
I think for FPSes, the server relies on the client for many of the computationally intensive things, like fog of war, collision detection, line of sight and so on. This is why cheating like wall hacks are even possible in the first place: The client has the total game state locally, and knowing where to look for and extract this game state allows the cheater to know the location of every player on the map.
If the server did not reveal the location of other players to the client until the server determined that the client and opponents are within line of sight, then many types of cheating would basically be impossible.
Both CS2 and Valorant use fog of war, and so does LoL and Dota 2. It works because they have simple geometry in their maps, mostly straight corridors, 90 degree turns so it has blocking walls in all directions. They still have to start sending player information before they get to the corner to avoid pop in effects, so they'll use the map geometry and then adjust the fog of war mesh.
Open world games or if you have complex geometry like buildings with windows and such it's not really worth the effort to implement its useless in most areas of the map.
Sending all to all clients is the simplest and easiest implementation, all other options are much harder to implement and adds a lot of load on the server, especially if you have more players than 10.
Fallout 76, for example, lets you see where other players are facing/looking at, or where are they pointing their guns even if they don't fire. The models are animated according to the input of their users.
I don't think its ticks per second are great, because the game is known for significant lag when more than a dozen of players are in the same place shooting at things.
SF has dedicated commercial loading zones, for large deliveries. (Or, for some of the larger buildings, they just have an underground or partially underground loading dock.) For things like Uber, yes, one would need to find a parking spot, not park in an active lane of traffic¹. If either are insufficient, people are free to lobby for more, where they are needed.
(¹and as bike lanes are not wide enough to accommodate a vehicle, you're partially blocking a car lane, too.)
Your last point is one of the most frustrating things with unprotected bike lanes - drivers will endanger bicyclists for no real gain when they park in the bike lane because the car lane is also still blocked! Somehow they prefer to block 2 active travel lanes instead of just one.
Autonomous cars are not the solution to traffic issues. At best, the may make some driving situations slightly safer because humans are terrible drivers.
What we need is trains. Trains everywhere. We had this once in fact; we had passenger rail to every corner of europe and north america. Turning that back on would massively improve traffic.
I disagree. Building trains in America is next to impossible in the modern day. Obtaining the property for the railways would be extraordinarily difficult, because America has such strong property rights and is such a legalistic society. It's a recipe for way over-budget and behind schedule projects. Just look at the California project. There's also very little expertise in the rail industry in America due to underinvestment in recent decades. Furthermore, the built environment is so spread out because it was built for cars, so you don't get the clustering effects of density around train stations. Rail isn't that helpful if you have to walk another 30 minutes from the station to actually get to your destination.
Also, I think your assertion that autonomous cars don't solve traffic is partially wrong. If entire fleets of cars can "think" as a whole, you can avoid some traffic problems, such as traffic waves, that occur due to individual decision-makers.
Even with traffic waves, the capacity of a road is not infinite and trains beat it hand over fist, simply because of physics. Imagine a crowded highway with invisible cars: people would be sitting 30 feet x 15 feet apart. That is why there is traffic more than anything, the limits of that capacity with that really loose packing that cars enable.
Walking 30 mins from the station is no issue. Try walking through a far flung terminal at DEN or ATL or the new TBIT at LAX, you will walk 30+ mins from the gate before you hit your rideshare point I expect. Also, rail stations do not exist in a vacuum. They often interface with bus lines that go parallel or perpendicular to the rail routing, so that 30 min walk could just be a 2 min ride.
We also do have railbuilding experience in this country. LA metro has built out their entire network of over 100 rail stations within the last 35 years. This is the fastest rate of railbuilding on the entire continent, not just in the U.S., in a high land value land labor cost area to boot. As we speak multiple concurrent rail projects are being planned or actively built. Much of the build out is paid by a 1 cent sales tax measure that local voters approved with 71% in favor.
I agree that rail still wins on the capacity front by far. I was just pointing out that self driving cars should offer some improvements over the current state of traffic.
I don't think that walking for 30 minutes is "no issue". Of course at airports you have to walk 30 minutes because those are a special case, and you have no other option. Also, trips to/from the airport do not make up a large portion of the average person's trips.
A better and more common example would be going to a friend's house or grocery store. Compare:
Home>self driving car>destination
Home>bus>train>bus>destination (with likely higher amounts of walking between each)
Admittedly the car performs much worse our traffic score, but cars are essentially point-to-point which I think is a huge advantage. Additional advantages include privacy and cargo space.
Like it or not, our built environment has been made for cars. Metros still offer value for high density areas, but for the huge number of Americans that live in suburbs/exurbs, self-driving cars are the answer.
I am not arguing the car isn't supremely convenient. Even in Tokyo, drop two arbitrary point A or B about 5 miles as the crow flies apart and the car will win 9/10. That is beside the point. I am arguing against the idea that transit usage is impossible. Virtually everywhere that people take transit en masse, the car is faster. Seemingly there is some culturally learned impatience surrounding transit that is deep rooted in north american culture, to the point where the idea of taking a little extra time is an outright impossibility to most people. This is a highly individual culture where tragedy of the commons externalities are handwaved away in favor of a supremely convenient individual experience, as the climate of the earth is more damned by the year.
Tokyo (and a lot of other cities) has basically priced parking so that it is a luxury. You save a lot of money by taking public transport even if you own a car.
I don't believe that anyway. The USA has a very robust rail network, it's just all dedicated to freight. Building and maintaining railroads is not some forgotten capability; it's very high tech with robots/automation doing a lot of the work now.
The USA has proven to be... incapable of completing any public transport infrastructure anywhere near on budget or on time. This is a deeply rooted problem. Until this gets solved autonomous electric vehicles could theoretically just leapfrog the problem altogether. Point to point transportation also mostly solves the last mile problem.
Point to point transportation is not sustainable with a vehicle as large as a car. The physics are simply quite poor and there are too many people to move, at least in cities with real traffic like LA or NYC vs small edge case backups.
At least with my CU, mobile check deposit is the only function I need a mobile phone for; everything else is equally available on the web interface. (I could go to a physical branch, in lieu of mobile, I suppose.)
Not necessarily: I gain the ability to switch insurances (imagine, for example, a "free market" where insurance has to compete…), job losses or changes don't affect my insurance, etc. Actual competitive pressure and lower switching costs should, in theory, drive the price down.
Also, IIRC, insurance premiums paid with post-tax dollars are deductible, so they're not really post-tax. However, that deduction is part of the itemized deduction — while currently most people are not itemizing (as they do not have enough itemized deductions to hit the "it is worth it" threshold), my napkin math says that throwing HC premiums in there — since HC is so damn expensive — tips the scale / breaks the threshold for basically any normal income level.
But this is also an "imagine if" thread. Imagine if we made healthcare premiums outright deductible to alleviate the problem you've identified?
I also was buying out of pocket while employed for awhile. Unless you have a qualifying event you can only switch insurance at the beginning of the year, at least from the insurance options I was able to find that fit my family.
I honestly didn't even realize the thing about the standard deductible until I had already done it. I was shocked to find I couldn't deduct it because I'd have to use the itemized deduction which would have been lower. I just assumed my insurance could have been deducted like it was when I bought it through my employer... how wrong I was.
But yes I would absolutely prefer the "imagine if" scenario.
> Is it so bad to just click to increment the emoji regardless of the color/tone choice made by the first reaction?
This is sort of what I feel like the parent was implying without outright saying it, too. But: that's not how Slack works. If the only reaction is an emoji of skin tone A (let's say its a dark skin toned thumbs up), and I click that dark skin toned thumbs up to also react, Slack adds a thumbs up with the skin tone configured in the user's settings (which I believe defaults to no skin tone), not the skin tone of the initial reaction.
Certainly the younger generations are not hung up on the skin tone of an emoji.
Some people customize them to more closely represent themselves. Some people use the defaults. Who … cares? … it's just an emoji.
Heck, for a while some emoji were only available in specific genders. (Those are much rarer, now.) Nobody where I work ever got hung up on the gender of an emoji not matching the user.
> Heck, for a while some emoji were only available in specific genders. (Those are much rarer, now.) Nobody where I work ever got hung up on the gender of an emoji not matching the user.
You mean those emojis were originally gender neutral but have now been reinterpreted. Another unnecessary division that we really don't need.
My experience is the opposite. I've seen 20-somethings getting hung up on these sorts of issues. My teen daughter is unhealthily concerned about such things. Us old farts dgaf.
Of the multiple times my insurance has declined to cover one thing or another, not once have I ever gotten a reason. The claim is just billed to the patient, directly. I'm then left wondering things like "Hey, your plan documentation says 'preventative care is 100% covered'. This was preventative care. Why is it being declined?"
If I want to know, it's an hour of my time, at least, going back & forth with insurance to learn "Oh, '100% covered' … except in these cases."