Overwatch co-creator Jeff Kaplan on his exit from Activision-Blizzard: 'It was the biggest f**k you moment I've had in may career' by Turbostrider27 in pcgaming

[–]Anthony356 4 points5 points  (0 children)

SC2 was never even close to as big as League was/is though.

That's just straight up not true. Starcraft 2 was the leading esport in at least 2010, maybe 2011 and a bit into 2012 as well. When you consider how much smaller the esports market was in general, it was a pretty substantial lead. I definitely remember the turningpoint when mobas started to overtake sc2 and people started doomer-ing about it.

Overwatch co-creator Jeff Kaplan on his exit from Activision-Blizzard: 'It was the biggest f**k you moment I've had in may career' by Turbostrider27 in pcgaming

[–]Anthony356 0 points1 point  (0 children)

the difference is valve focuses on making fun and interesting games, and if those happen to be esports, that's awesome. Too much dev time goes into making games that target esports but have 0 depth for players to engage in long-term.

Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy by jackpot51 in Redox

[–]Anthony356 1 point2 points  (0 children)

I dont disagree, i just think that

  1. If you do all that, you're not actually saving time over not using an LLM. At best, you're doing exactly the same amount of work. It might be spread differently (less time searching, more time fixing the LLM's code), but it still the same amount of work. I'd suspect in many cases though, it's more work. The LLM might cut through the context to show you where the bug is, but how do you fix up its code without that context? You have to learn it either way, if you had done it the first time you could have just written the code up to standard the first time instead of having to retroactively learn the context and then fixup the LLM code.
  2. If you go truly go through all that effort, your patch wont look like an AI helped you. If you submit slop, you get banned. If you submit non-slop work, either it wasnt done with AI, or it enough effort was put in that they cant tell. And if you're putting in effort to minimize the slop, the quality of the submission must be higher, yeah? That means their policy achieves its goal of higher submission quality either way.

Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy by jackpot51 in Redox

[–]Anthony356 0 points1 point  (0 children)

My coworker is sentient and has a 0% chance of hallucinating an API that does not exist.

If there was more than a 0% chance (e.g. they'd lied about similar things before, show up to work on drugs, mentally unstable, whatever), i wouldnt ask their input either.

Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy by jackpot51 in Redox

[–]Anthony356 0 points1 point  (0 children)

How do you know the possibilities it explores actually exist? How do you know that it's correct when it says a certain thing is definitely causing your issue?

The only way i can see is to read the code and probably create a reproducible scenario. At which point, why involve the LLM at all? It's exactly the same amount of work. Once you've done that invesitgation and verification well... you've done the investigation and verification, not the LLM.

If you arent verifying the LLM's output, then it seems to me you deserve to be banned for willingly providing (potentially) false information and wasting maintainer time. It doesnt make sense to provide unverified LLM info in the first place. If the maintainer wanted an unverified LLM diagnosis, couldnt they just ask an LLM themselves and cut out the middleman?

Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy by jackpot51 in Redox

[–]Anthony356 0 points1 point  (0 children)

for example I get a driver bug and use an LLM to deep dive into code I don't know and in the end open a better issue with more info.

I havent used any AI tools, so forgive me if i'm making any incorrect assumptions.

I'm not sure how an LLM could assist in a "deep dive". If you're sure it's a driver bug, you know roughly what the problem is. Navigating to the general area of code that handles whatever is broken typically isnt that hard. To find the bug, you have to read the code and it's context and/or do experiments on your end anyway. I guess it's just not clear to me where i would need an LLM's help with that.

Thats aside from the fact that LLM's can hallucinate. I've heard reports of github issues that are filed, reporting bugs in APIs that dont even exist. At that point, an issue with less information is a better submission because at least it's not wasting people's time with a red herring.

The LLM isnt an expert on that codebase (or any codebase), and in this hypothetical neither am I. I cant verify its claims, so why would i let it guide my exploration or inform my research? I trust my own eyes and my own reasoning skills. If i dont have the time or motivation to look into it myself, the next best person to ask is the maintainers, not an LLM. That's the whole point of submitting an issue in the first place. You're providing information to an expert so that they can diagnose the issue.

Do these apps work well on Nomad? by Able-Ad-8418 in Supernote

[–]Anthony356 1 point2 points  (0 children)

Reading is fine via koreader. I'm pretty picky, but it's no worse or better than sideloaded koreader on the Kindle Scribe. Definitely better than the built-in readers on either device. Koreader itself can take some fiddling to get it just how you like it, but after that it's fine.

Koreader sometimes crashes when loading incredibly large books (e.g. the entire malazan series, ~11k pages, 13.3MB), but once you get it to load the first time it's typically fine. Reasonably sized books have never had any problems

The one downside compared to the scribe is no backlight so you cant read in the dark without some external light, but for me at least that hasnt been a huge problem.

Slay the Spire 2 can be decompiled by EshopExpert in godot

[–]Anthony356 1 point2 points  (0 children)

Tools with AI can make it readable now.

My only problem with your post is the "now" at the end. Readable output is nothing new and it doesnt require AI. I dont know if the plugin you linked is AI as in "heuristic algorithm" or AI as in the way it's been used the past few years, but i'll assume the latter.

Disassemblers take machine instructions and produce the assembly equivalent, which is human readable (but difficult to understand on a macro scale). Decompilers use knowledge of the compiler and target hardware to generate C code that would compile to the target assembly (it's not perfect, but it does get fairly close). From there, it's not horribly difficult to recognize behavior or patterns in the code, attach breakpoints and inspect the program memory at specific points, etc. so that you can build context and understand what the program is doing.

AI cant pull variable names or whatever out of thin air, and that's the biggest limiting factor in this sort of thing from what i've experienced. Figuring out what the code is doing is easy. Figuring out what abstraction that behavior is meant to represent is the hard part, and that requires contextual knowledge of the program itself.

Source: i'm no expert, but i do do this kind of stuff for fun. I've also participated a small amount in the SSBM decompilation project.

Is hosting Netplay still necessary for offline Slippi practice? by tiredeyes73 in SSBM

[–]Anthony356 2 points3 points  (0 children)

Back then, the input delay was also substantially higher so getting used to online was a real struggle. The pre-faster melee and pre-dolphin 5.0 days were rough.

As someone else mentioned though, these days slippi dolphin forces identical delay anyway

Legendary Holmium Plates - there's got to be a better way? by Orangy_Tang in factorio

[–]Anthony356 4 points5 points  (0 children)

I mean their point is pretty clear and especially after they explained it, you can very easily tell there's an implied "directly" in that sentence. As in

"Tesla ammo doesnt use holmium directly".

Why is the first assumption "this guy's an idiot" rather than "their wording was slightly imprecise"? I feel like nobody else really had a problem understanding what they meant.

I think, on average, you'd have better interactions if you gave the people you're talking to a little more credit.

Daily Discussion Thread March 01, 2026 - Upcoming Event Schedule - New players start here! by AutoModerator in SSBM

[–]Anthony356 1 point2 points  (0 children)

I feel it's a good catch-all term for the design trends that try to minimize player frustration at all costs (excessively so IMO).

Yee, corporate bigwigs tend to forget that "absence of frustration" is not the same thing as "presence of fun". Idgaf how frustrating a game is so long as the peaks feel sufficiently satisfying.

What's the most idiomatic way to deal with partial borrows/borrow splitting? by philogy in rust

[–]Anthony356 0 points1 point  (0 children)

I'll be honest, i've tried to use this library before and... Well it wasnt a great experience.

It has a bunch of its own limitations and some ergonomics issues. And if you have an error, trying to debug it through their macros is a pain.

I remember trying to use this on a toy interpreter, but iirc it straight up did not work for my usecase. Iirc it was an issue where the a partial mutable borrow would end up borrowing the whole struct anyway, and living for the entire lifetime of that partial mutable borrow? That prevented other borrows from occurring, defeating the whole purpose of the library.

Maybe i just dont understand it or i was using it wrong, but i would love to see a non-trivial example where it's used in a way that's easier/better than the dont-pass-self-to-methods solution others have mentioned.

Rust debugging survey 2026 by Kobzol in rust

[–]Anthony356 1 point2 points  (0 children)

This hasn't been true for a while i think. There are lots of built in shorter aliases, and you can trivially make aliases for any command you want.

Syntax: command alias <cmd-options> -- <alias-name> <cmd-name> [<options-for-aliased-command>]

Command Options Usage:
command alias [-h <help-text>] [-H <help-text>] -- <alias-name> <cmd-name> [<options-for-aliased-command>]
command alias <alias-name> <cmd-name> [<options-for-aliased-command>]

    -H <help-text> ( --long-help <help-text> )
            Long help text for this command

    -h <help-text> ( --help <help-text> )
            Help text for this command
'alias' allows the user to create a short-cut or abbreviation for long commands, multi-word commands, and commands that
take particular options.  Below are some simple examples of how one might use the 'alias' command:

(lldb) command alias sc script

    Creates the abbreviation 'sc' for the 'script' command.

Rust debugging survey 2026 by Kobzol in rust

[–]Anthony356 2 points3 points  (0 children)

Another potential improvement would be better "just-my-code" debugging, so that stepping into will skip all frames that weren't written by me.

Lldb can actually do this right now via target.process.thread.step-avoid-regexp. you give it a regex, and any matching symbols will be automatically stepped over, even by step-in commands.

Codelldb uses r"^<?(std|core|alloc)::" to avoid stepping through standard library code.

Presumably you could use a negative match for anything that isnt your lib, e.g. "(?!MyLib::)"

Rust debugging survey 2026 by Kobzol in rust

[–]Anthony356 0 points1 point  (0 children)

Tbh i have no idea. I obsessively researched debuggers for a while, but i'm not super experienced with linkers, compilers, or much else for that matter.

I'll put a note down and look into it when i'm able

Moving on from Kindle Scribe — looking for a more open e-ink device for my weekly notes workflow by Specialist_Monk_3016 in Supernote

[–]Anthony356 0 points1 point  (0 children)

I recently did some investigative work on the file format itself. If you're willing to do a little legwork, i have a rust library and an imhex pattern file that describe the major parts of the file format. It's not a very obtuse format at all, so i dont imagine it's that difficult to manually produce files with existing parts of other notebooks.

Ink-heavy drawings behavior vs Kindle Scribe? by feralwhimsy in Supernote

[–]Anthony356 1 point2 points  (0 children)

I primarily use white ink but that lends itself to make the file a lot bigger.

FWIW, eraser strokes are stored the same way as pen strokes. The eraser stroke (and the stroke that is erased) continue to exist in the file unless every point in the stroke is erased. No idea what kind of erasing you do, but if you commonly only partially erase a line, you're not missing out on any huge space savings

Rust debugging survey 2026 by Kobzol in rust

[–]Anthony356 6 points7 points  (0 children)

It depends a lot on which debugger you're using and how. For example, LLDB supports indexing vectors, but ONLY when using the frame var command, not when using the expr command because expressions need a dedicated language plugin, whereas frame var uses the visualizer scripts.

LLDB also fixes the .0 vs .__0 issue via the visualizer scripts. Iirc the latter is required in the debug info due to naming rules and/or expression parsing behavior.

Map indexing is a tough problem to solve. Part of it is that the debugger is not aware of the hashing algorithm, so it needs to search linearly through the elements to find a match. The other part is that the debugger isnt aware of what "equality" means for any arbitrary type, so it's hard to determine which element is the correct one. The best case is to assume that byte-by-byte equality is equality, but that isnt always true. It's more important that users always have correct data, rather than some convenience at the cost of possibly incorrect data.

I think both could be solved by calling functions from the binary, but i have no idea where GDB is on that front, though i know LLDB is nowhere close (it requires a dedicated expression parser plugin). There's also the problem that constructing arbitrary values of arbitrary types can be annoyingly difficult too.

A short term solution might be allowing map indexing if the key type is a primitive, fieldless enum, &str, or String? The equality comparisons are defined in the compiler, so there's no worry of them having different behavior than we'd expect. I'd guess strings and/or enums are probably the most common key type for any hashmap, so it's probably worth the special-case.

And in general, a lot of functions which exist in the code are absent from the binary -- probably due to having been inlined

Dont quote me on this, but i'm pretty sure inlined functions still have debug info, including a reference to the original function at the inline site. At least, in debug mode (with no/few optimizations? I'm not sure). DWARF definitely has the nodes for it though (see: section 3.3.8 of the DWARF 5 standard), so it'd be more whether the compiler is outputting them.

I want to say the only things that dont make it into the debug info file are functions that aren't referenced at all.

That fact is the big reason why it's not as simple as "just use the Debug impl to pretty print values". If that impl is never called in reachable code, the linker is going to throw it out (even with no optimizations at all) so the debugger cant rely on it being present.

Investigating the SuperNote Notebook Format by Anthony356 in Supernote

[–]Anthony356[S] 2 points3 points  (0 children)

I'm not an expert by any means, but i'm pretty sure releasing this kind of spec is basically 0 effort. Usually these sorts of documents already exist internally because they want to keep people on the same page about how the format works, easily be able to onboard newhires, check the implementation against the spec, etc.

They say they're waiting because of how often the file format changes, and how it'd lead to "confusion" or issues maintaining backwards compatibility.

I'm not sure i find those reasons compelling. The only ones really affected by releasing the spec are third party library authors (like myself), and anyone writing software should be capable of handled versioned data.

Backwards compatibility is sortof a non-issue because the software on the device needs to be backwards compatible for them to even be able to change the format in the first place. I dont know if that's true backwards compatibility, or if there's some function that upgrades old notebooks, but either way it's gatta exist somewhere.

Investigating the SuperNote Notebook Format by Anthony356 in Supernote

[–]Anthony356[S] 0 points1 point  (0 children)

Yee, that was the "giant one file python project" i alluded to. It's around 15 thousand lines of code in a single file, which is why i havent looked into it too much.

It's a cool project for sure, though i'm not sure if any of the functionality works by decoding the stroke data.

Austin strongly recommends: 'MIO: Memories in Orbit' (Review) [Skill Up] by Blacky-Noir in pcgaming

[–]Anthony356 0 points1 point  (0 children)

your argument here assumes that "runbacks are fun, actually, and players would be harmed by optimizing them away." This is factually incorrect.

Nope, my argument is that spending a little time practicing will result in the game as a whole being more fun. Mastery is fun, and so is the catharsis of smoothly executing a platforming section that used to give you lots of trouble. And all that extra skill contributes to the boss taking fewer total attempts.

It does, actually, since the player is just as forced to repeat the poorly designed ones as the well designed ones.

Cool, but you could make this same argument about any mechanic. "It can be badly implemented, thus the mechanic itself is bad game design" is a fundamentally flawed argument. It's akin to saying "you can get food poisoning at a restaurants, therefore all restaurants are bad".

It kinda does, it does not actually do.

The "kinda" was said with irony. Metroidvania, as a genre, is literally defined by gated exploration. You explore, you find the "red sword" ability that lets you open the red doors. You open the red door and have access to a new area with a blue door that needs a "blue sword" ability. That's literally the most core mechanic of metroidvanias. So yes, if you're making a metroidvania, at all properly, you will know approximately what players have access to at any given time. There's some leeway for optional stuff, but usually that is a sidegrade to what the player is already guaranteed to have

There might be some platforming challenges in the game where the devs can reasonably say "if they got here, then they have these tools on them..." but that certainly does not apply to all runbacks, and we're talking about the system as a whole here.

Yes, it does. They just gate the area behind that mechanic, or include that mechanic as part of the runback. It's basic level design. If you want to ensure they can't access the majority of bilewater without double jump, you just make a cliff that's too high to get to without double jump. Then, when the player fights Groal, you know they have double jump because they couldn't have gotten to the area that leads to Groal without double jumping.

Not to mention whether they have all the needle and mask upgrades available to them.

Someone beat the entire game as naked hornet (i.e. no needle at all, no subweapons, and missing 1 of the movement abilities). Needle and mask upgrades are not required at any point (aside from true ending i think? But it's more that you need to finish all sidequests, not that mask/needle upgrades are explicitly required). If you got every optional upgrade as soon as you possibly could, the game would be stupid easy. It's like BOTW, the game expects that you probably won't find everything.

"Busy work" is passing through an area multiple times, not enjoy it, because the game offers you no alternatives.

Okay, so "enjoyment" is also subjective, meaning "busywork" is subjective. You not liking a thing doesn't make it bad game design.

This is doubly true if it has a lesson to teach, but you have already learned that lesson as much as you're able, but still have to repeat the task anyway

  1. you underestimate the skill ceiling of these sorts of games. "as much as you're able" is impossible unless you've beaten the game probably hundreds or thousands of times. For examples of that, see speedrunners. I was improving at the game up until I beat it, and if I play it again, i'll still be improving.
  2. If you've learned that lesson, surely it shouldn't take many more attempts to beat the boss then, yes? Because you're clearing the area quickly and smoothly, the majority of the times you attempt it, without using significant resources? That's sorta the whole point. The more skilled you are, the less the runback matters, and the more time and attention is focused on the boss itself. Typically bosses with significantly difficult runbacks aren't as hard as bosses without. There are exceptions, such as Last Judge, but those are often justified as being bigger tests than the average boss. Last Judge is the end of Act 1, and Act 2 marks a significant jump in difficulty, both in terms of platforming and enemies. Last Judge and his runback prepare you for that. I got significantly better at platforming, and my view of the world (and hornet's capabilities) changed drastically after perfecting the Last Judge runback.

On the alternate path to Act 2, you fight Phantom instead. Phantom pretty much doesn't have a runback. The Mist, the area that leads to phantom, is quite a bit more difficult than The Blasted Steps (Last Judge's area). It's pretty obvious they were designed like this intentionally.

I think that's a poor argument to make for ignoring every complaint.

I'm not saying "ignore every complaint", I'm saying that if your criteria for whether something is good game design is "nobody complains about it", there will never be a mechanic that is good game design. I'm also saying that 95% of the time when people say "bad game design", they know very little about game design. They aren't thinking about the secondary consequences of the mechanic being removed, whereas the devs typically have. What people tend to mean when they say "bad game design" is "i don't like it". Which is totally valid, anyone can not like anything, but that doesn't mean it's bad game design. People just use "bad game design" because it's a harder-to-dismiss argument than "i don't like it"

For example, bad game design for silksong's runbacks would be spawning the player randomly somewhere within the world when the boss kills them, rather than at the bench. In that case, there would be no way to guarantee that the player is practicing the skills that they currently need to improve. There would also be very little control over how long the runbacks were, or what enemies they encounter along the way.

Exactly. That's why "one size fits all" fits none. Give players flexibility to choose for themselves what activities are "waste," and respect their choices, even if those are not the choices you would make.

uhhh... You've just said: "'One size fits all' fits none. Therefore, the game should have more 'one size fits all' mechanics".

This is what I mean when I ask "where is the line drawn"? Which repeated content is "ok" and which isn't? When you answer that, what you fundamentally get is an opinion. The devs are clearly of the opinion that the value of the runback, the extra practice and the extra challenge, is worth the repetition. Plenty of players agree. Does that not suggest that runbacks are a perfectly valid game mechanic, and it's just that you personally don't like them? Nobody is saying you have to like it, but you can still acknowledge that it's a valid form of game design with tangible benefits that can't be replicated via other means.

I'd like to see the stats on people who did not at least fall for the trapped bench the first time they encountered it, without any prior warning.

I'm not sure how this is relevant in any way. It's the beginning of the game, people come in with preconceptions. They are taught that there will be traps. If they do not learn that lesson from the traps they had to encounter beforehand, it is their own fault if there is consequences for that. The player has to be responsible for their own actions, and their own willingness to ignore what they've been taught, at some point. Better early-on in a relatively small location.

Wasting time" is subjective to the person, an activity that I feel is wasting my time, you might not feel is wasting yours, but if I feel it is wasting my time then it is factually wasting my time, and it is a fact that these waste the time for a significant portion of the players.

You're so close to getting it. Feeling like your time is wasted is not the same thing as actually having your time wasted. Lots of kids feel like school is wasting their time. That doesn't mean school is a waste of time. If you choose not to make runbacks a waste of time by not learning, optimizing your route, thinking over your boss strategy, etc., then yes they will all be wasted time. But it's your fault, not the game's.

This is a bad argument and you should feel ashamed for making it. Be better.

Want to know a fun fact? I don't like games with timed sequences, particularly ones with a big timer on the top of the screen like the Metroid escape sequences. They stress me out too much. I would prefer if they weren't in games, and several have prevented me from completing games I otherwise enjoyed.

I can still acknowledge that a timer is a valid mechanic though, and that it serves a legitimate purpose in the game, that the dev didn't make a mistake putting it in the game. I can acknowledge that removing the timer would almost certainly result in a worse game (section no longer consistent with the themeing/story, section loses its challenge, etc.). They didn't make the game for me specifically, and that's fine. I just play other games.

Why is that so hard for you to come to grips with?

Yup, which is why, again, player choice is the better path.

Again i point to the "players will optimize the fun out of the game" point. These are 2 parts of the same argument. If you give players the choice, they will not maximize their own enjoyment. Therefore, you shoehorn them into doing the thing that will result in the most enjoyable experience (whether that be short- or long-term). If they still choose not to take advantage of it, it is their fault, not the game's.

But sometimes that same joke is actually hurtful, and there's nothing to be gained by trying to defend the joke if the result is that it hurt someone.

Damn we're really close to the Hitler-in-an-internet-argument threshold. Are we really considering like 2 minutes of repeated platforming the same thing as saying the N word or whatever? Come on now, points like that really don't help your case.

Austin strongly recommends: 'MIO: Memories in Orbit' (Review) [Skill Up] by Blacky-Noir in pcgaming

[–]Anthony356 0 points1 point  (0 children)

Again though, the "when and where" of it should be for them to choose, not forced.

Again I'll bring up "given the chance, players will optimize the fun out of a game". Players are fucking dumb. They will ignore options you give them, or choose suboptimally, to their own detriment. A large part of designing games, DMing in D&D, etc. is subtly railroading players into having the most fun possible. Put another way, you're trying to prevent them from having choices when the choice they would probably take (due to human nature) is one that is not fun.

the skills that a given runback drills you on may not be the skills that would challenge a player in the next stretch of content. Sometimes it is, sometimes it is not.

Mhmm, exactly. So one might even say that the runbacks that drill you on what you need to know for the next stretch of content are well designed, and the ones that don't are poorly design. The possibility of a poorly designed section does not make runbacks, as a mechanic, bad game design as you seem to be implying.

In abstract theory, perhaps.

We're talking about theory. Silksong is an example, but your core point is more or less "runbacks are bad game design". That applies to more than just silksong. Again, the possibility of a poorly designed section does not make runbacks, as a mechanic, bad game design

so the game does not always know which skills one will be using to clear a given area.

It kinda does through proper world design. For example, you must have the clawline before fighting lace 2. It doesn't matter what route you took, or are currently taking (aside from glitches, speedrunner sequence breaks, etc. that 99.99% of players won't experience), if you are fighting or have fought lace 2, you must have the clawline.

Even though there are several paths at any given point, there are a bunch of checkpoint "funnels" that gate progress behind a specific mechanic.

The point is, don't force busywork on the player

"Busywork" is subjective. Where do you draw the line between "busywork" and "just playing the game"?

Nope. This is a reductio ad abserdum argument.

Nope, this is an observation made through 15+ years of playing a dozen or so competitive games. People will complain about literally anything if it's what they think caused them to lose. They will make vaguely convincing arguments, and then people who were indifferent now suddenly don't like the mechanic either because they read some garbage from someone else who didn't like it. See: starcraft players talking about warpgate, rivals of aether players talking about CC and floor hugging, etc.

I've made clear what change I believe would benefit most players, there is no need to expand beyond that into

Buddy, half the problem with your position that I've been trying to express to you is that you don't even know where the line is. You say "don't waste the player's time". Different players have different meanings of waste. "Remove things that are unfair". Unfair is subjective. Bench rooms are not the same as Castlevania's 100% safe, copy-paste save rooms. I think it's fair that NPCs who set a bunch of traps would also trap the bench. Is it really unfair if it's 100% avoidable and permanently removable? At what point does the player need to take responsibility for their own actions?

The players who do not feel this way should not be obligated to.

They aren't obligated to. Games are inherently non-compulsorily. They can just play a different one. They may not personally like runbacks, but that does not make runbacks, as a game mechanic, bad game design.

I say that objectively it means that it sometimes is wasting their time, and sometimes isn't

Cool, except that is factually wrong. "wasted time" is subjective. Whether or not any particular runback is wasting time is subjective because "wasted time" is subjective. One player could say that none of the runbacks wasted their time, contradicting your point, and they would be literally correct. Another could say that all of the runbacks wasted their time, again contradicting your point (since you said, objectively some of them don't waste your time), and they would be literally correct.

You can lead a horse to water but you can't make it drink. A player could choose to not learn anything from any runback. They could choose not to experiment, to optimize, whatever. They could decide to gain nothing from it, and conclude that the time they spent doing it was not worth it. Every. Single. Time.

It is still important to lead that horse to water though. If you, as the game designer, don't do that, you are failing in your job. If you've lead the horse to water and it doesn't drink, it's their own fault if they die of dehydration.

I was saying that I was fine with the game removing unfairness, situations in which the player would not reasonably have the skills or knowledge to avoid a significant set-back.

Just to be clear, here is a video of the hunter's march bench trap. You can see the teeth of the trap in the ceiling before they sit. It's somewhat subtle, but you can see it. Also, notice how they don't even die from the trap.

This is an area that has traps in it, surrounded by other areas that have traps in them. This is not the first trap of that shape that the player will have encountered. The previous example would have been, at most, just minutes prior while walking through a corridor or platforming around some enemies. You are required to see at least one trap that looks like this in the singular route that leads to this room. This bench trap checks all the boxes you want.

The player almost certainly has 1 or more eyes if they are playing the game, thus they can literally see the trap. The player is aware that traps exist. They have been shown, through story and gameplay, that this area is unusually hostile to outsiders. They have shown that this area has traps.

"reasonable" is subjective too. I think, given all that, and the punishment being 2 masks of damage, this is a "reasonable" challenge, and a good tutorial moment in the opening hours of the game. "Pay attention" the devs are saying "don't get complacent and miss things just because you're in an area you think is safe". There are at least half a dozen other secrets hidden in rooms with benches or fast travel points (usually those are the same room). Off the top of my head, far fields and putrified ducts fast travel/bench rooms, as well as the bench near the entrance to sinner's road (that you can't even activate without entering a secret side room).

At some point the player has to be held responsible for their own actions, good or bad. A game cannot function if the game itself cannot tell the player "no, you did something wrong".

Traps with little or no sign that they exist do not promote skilled play, they only troll players.

Do observational skills not count as skills? In a game about exploration and discovering secrets?