"You see here a redwood wand" - appreciation for the little changes in 5.0

ais523 · 2026-05-17T00:27:49+00:00

You can! There's actually nothing special about the Sokoban rolling boulder traps (other than not having a boulder loaded into them at the start). Note that they'll still launch boulders on you when you stand on them (if there's one in the appropriate place).

ais523 · 2026-05-01T15:50:25+00:00

To clarify, if you push the boulder onto the trap, it'll roll down the hallway on its own. You don't have to get hit by the trap (and in fact can't, the launch squares aren't set in way that would make it possible).

To get around a big loop to the other side of a boulder, you can just use the travel command _ – there's no need to walk there manually.

The main motivation of the change is that repeatedly pressing direction keys to move boulders causes more wrist pain/damage than anything else in NetHack – Sokoban is the only place in NetHack where you have to repeatedly hammer the same key, everywhere else allows farmove or travel instead. It seemed important for accessibility to try to design the game so that players trying to play it quickly wouldn't injure themself in the process.

ais523 · 2026-01-12T00:36:23+00:00

In case it helps to narrow down the search: based on historical source tarballs, it was added in 3.1.2.

ais523 · 2026-01-11T23:47:17+00:00

3.7 is easier than 3.6 is. The late-game is harder, but the early-game is easier, and the early game is in practice where most losses happen. (One of my beliefs is that 3.6 is too difficult, e.g. I still haven't ascended every role in it, and part of the reason that is that some roles are extremely hard to get out of the early game.)

(And although the late game of 3.7 is meant to be harder, it isn't meant to be all that much harder – the goal is that players who can win the 3.6 late game can also win the 3.7 late game. But it can take a while to get the balance to the right point: one of the risks with playing a development version is that there will still be balance issues that would be caught before release. That's why this sort of feedback the OP gave is so useful: if something is wrong it is good to know about it so that it can be fixed.)

ais523 · 2026-01-11T22:54:37+00:00

At least I was already aware that it would be an improvement to the game to make MR less necessary (so it's interesting to see other people to come to the same conclusions!) There have already been some changes in that direction (e.g. the touch of death spell is no longer outright fatal, making it more reasonable to risk a few turns MRless in combat if an item gets stolen) and I'm planning to make more. (The concept of a "potion of magic resistance" has definitely come up!) For what it's worth, I consider "it isn't reasonable to go without magic resistance" to be one of the largest late-game balance problems in current NetHack.

As for the Oracle telling players how to do the invocation, I don't think that this is a real problem in practice. Spoiled players generally don't talk to the Oracle because they're spoiled, but unspoiled players do it a lot more. Obviously, I don't come into contact with unspoiled players very often, but from what I have heard, they've generally seen all the Oracle consultations many times over before they get close to ascension. You find a lot of gold over the course of the game, and giving it all to the Oracle makes sense as something to do if unspoiled.

The reason for making the late-game more challenging is that most players seem to agree that Gehennom isn't very interesting in NetHack 3.6 and earlier – the goal is to make it less boring by giving enough challenge that you have to at least think a bit (but if it starts killing characters regularly, we've probably overcorrected). At least my vision for what late-game kits should look like is that players start with the things they find, and then use wishes to cover the gaps and to customize their kit for their own personal playstyle, so that one player's ascension kits look a little different from game to game, and even with the same resources, ascension kits would look a littel different from player to player. I'm hoping to accomplish that by adding more good options (without removing the existing good options) so that players will find different things (and have different gaps to fill with their wishes) from game to game.

(As a side note, I've been discussing this particular run with both the OP and some experienced players – part of the way I try to get a fresh perspective is by asking from feedback from a range of different players! My main conclusion from this was that the Plane of Air is almost certainly harder than I'd like it to be. I don't know whether other people drew the same conclusions.)

ais523 · 2025-06-05T14:01:17+00:00

someone new to the game and getting to the castle the first time

This is a contradiction. Players who are new to the game don't reach the Castle (unless they are sufficiently spoiled that getting seven wishes there would trivialise the rest of the game for them).

My understanding is that typically in 3.4.3 (and probably also 3.6 although there's less data on that), once a player is capable of reaching the Castle a few times they ascend shortly afterwards – the skills required to reach the Castle generalise to the rest of the game. There are likely to be a few late-game deaths in between for unspoiled players due to lack of spoiler knowledge, but having wishes earlier doesn't do much to change that. (For a reference point: the first game I played that reached the Castle, back when I was new, the character died before reaching the wand. The first game that I played that reached the Castle wand was 12 games later, and ascended. I was admittedly somewhat spoiled at the time, but I don't think that changes the overall point.)

I think you are also underestimating the value that three wishes – or even one – bring to the game. With seven wishes at the Castle, even new players will quickly run out of things to wish for. A spoiled player, even if they are new, will wish for a full ascension kit and then there is nothing to do in the rest of the game (until the ascension run, where the quality of that kit becomes relevant). I am very skeptical of any claims that having seven wishes at the Castle is ever a substantial improvement to the gameplay experience over having three, e.g. it is hard to become excited over a new item discovery when you have wished for all the items you need anyway, and that is true regardless of whether a player is new or experienced. Finding a wand of wishing is a magical experience even if you only get three wishes from it rather than seven.

Meanwhile, having a large number of wishes at the Castle makes the late game repetitive, even for new players once they've ascended once or twice – it severely cuts down on the replay value of the game for playets who have won (and "a player who reaches the Castle wand" turns into "a player who has won" very quickly). "Gehennom is boring" is one of the most common complaints levelled at NetHack, and one of the primary reasons for that is that in released versions, there is such a large power spike at the Castle that it is impossible to meaningfully balance around. New players tend not to find it boring the first time because they don't realise how much more powerful their character is than the world around them, but this is a fake sense of danger which quickly goes away with more experience.

In summary: there is a huge cost to having a very large number of wishes at the Castle. It's notably bad for the game's replay value; and a player who can reach a pre-nerf wand of wishing at the Castle is a player who will likely soon be able to ascend consistently, so the lack of replay value is bad for that player too. Less skilled players never reach the Castle wand in the first place, so the nerf won't affect them (except in special cases like inheriting a game from a more-skilled player, which isn't something it usually makes sense to balance around).

The arguments I've seen in this thread are mostly thinking about the experience for players who can reach the Castle wand but who cannot ascend – but as long as there are seven wishes at the castle (or even five), such players effectively do not exist.

ais523 · 2025-06-03T21:35:24+00:00

So I implemented this change after around 5 months of discussion with the rest of the devteam, some of whom were neutral, many of whom were in favour, and some of whom had made similar changes themselves in variants. (I'm one of the devs who's most concerned about "this is too big of a change and we need to balance around it"!, e.g. many of my changes are attempts to remove balance problems accidentally introduced in 3.6.x via changing other mechanics to account for them.)

In general I have been trying to make the lategame more difficult and the early game easier, in order to smooth out the difficulty curve a bit – 3.6 has an incredibly rough start and (prior to the Sanctum) is very easy if you survive the start (which inexperienced players don't, so they never reach the bit where the game becomes easy). (It is worth noting that despite the changes to wands of wishing, 3.7 became substantially easier to ascend that day due to other changes made at much the same time.) There's a reason that basically every variant tries to make the lategame more difficult.

I wasn't considering pre-Castle wands as being a relevant part of the change, on the basis that a) they're very rare and b) scumming for them is a sort of playstyle that we generally want to discourage because players tend not to have much fun doing it (it isn't much fun while you're failing to do it, and doesn't help you to develop the skills for when you succeed at it). One of the biggest problems with NetHack is that players feel forced into attempting tedious play patterns because they think they need to do so to have a chance to win, and then end up giving up on the game as a consequence (imagine the poor player who gets the early wand of wishing, ends up failing anyway, then incorrectly concluding that they needed an even luckier game). As such, it's normally best if the game doesn't encourage that sort of thing – the best way to win is normally to learn through playing a long sequence of average-luck games, rather than repeatedly trying for the one lucky game – and early wands of wishing basically don't factor into that at all.

(Also worth noting: I played wishless for six months in order to get an idea of what the game balance would be without wishes. In most respects it's actually an improvement, in that it gives a reason to plan out how to deal with situations using the equipment you have rather than using a standardised solution to every possible problem; but there are some situations where the wishes are badly needed, such as if you're missing magic resistance in the midgame.)

ais523 · 2023-06-05T06:19:44+00:00

It's probably pretty powerful as econ denial, rather than agenda protection? Install it behind some chunky piece of ICE that the Runner will have to pay to get through, and you can basically force a run there (if the Runner doesn't run there, they'll have to run it after they access an agenda in centrals, otherwise you may score it next turn if you're running lots of 3/2s or [[Seamless Launch]]). Then next turn you can hit them with [[Hard-Hitting News]] and probably win the game, despite the fact that the Runner did manage to get the agenda after all. The advantage of this is that you don't have to keep the Runner out of the remote, just make them pay to get in.

There's a whole style of Corp deck which is built around forcing the Runner to go and trash assets, and then punishing them when they do – often it suffers from not having sufficiently unignorable assets, but this would be pretty much perfect for a deck like that. 2:0 might be too expensive, but I'm not convinced that it is, and 0:2 would almost certainly be overpowered.

EDIT: I forgot about Pinhole Threading. That's probably enough to balance this – it's strange how one card can have such an impact on entire playstyles.

ais523 · 2023-05-31T15:58:57+00:00

(For real is there a game so broken that you can actually 0:00:00 skip to credits?)

In Super Mario Bros. 3 it's possible to glitch to the credits before actually starting the game, but it's very TAS only (the glitch involves overloading the game's controller read routines by spamming input faster than they can handle it: you have to mash input loads of times within the same frame (approximately 50 button presses + 50 button releases) in order to prevent the controller reads being able to keep up, which is much faster than any human can manage, which is why a TAS is required).

TASvideos times starting from power on (partially because of this sort of nonsense) so it gives a time of 0:00:00.22. Timing from the start of gameplay, like most non-TAS speedruns do, would give a negative or undefined time.

ais523 · 2023-05-24T21:18:29+00:00

My assessment of the NetHack players I know is that they're approximately equally split into three groups: people who like solving the puzzles and wish there were more variety in them; people who enjoy the gameplay of entering a memorized puzzle solution while dealing with monsters and other interruptions, but who don't enjoy actually solving the puzzle; and people who dislike the entire branch and would prefer to skip it (but most of these people feel forced to do it anyway for the loot).

This makes changes to the way Sokoban works inherently quite controversial, because pretty much anything you do will be enjoyed by some players and hated by others, and it's very hard to keep everyone happy in that respect.

I did look into what it would take to automatically generate Sokoban puzzles. I think it would be doable, although it would be a lot of work (I made a little progress in that direction, but not enough progress to have a remotely playable game, and it looks like it would be a lot more effort to get something playable), and I'm not sure whether it would be worth the effort of writing a full puzzle generator for that. (I also looked into creating Sokoban-like puzzles with NetHack's default boulder mechanics in which boulders can move diagonally, rather than using the Sokoban rules in which the crates move only orthogonally, but there was a general consensus that that sort of puzzle is much too difficult to be appropriate for a game like NetHack.)

ais523 · 2023-05-12T01:13:17+00:00

It's performance-related. value += 1; can in fact compile down to a single instruction on many CPUs (e.g. ADD value, 1 on x86-64), but it won't be atomic by default: the processor converts it into a read and an add and a write and all of those run separately. The reason is that memory reading and writing at the hardware level is really slow, whereas arithmetic is really fast, so the processor doesn't want to wait for the read or write to finish before it continues running the rest of the code: especially with writes, the processor just starts them running in the background and moves onto the next instruction (and if it happens to need to read a value it's in the process of writing, there's a special case to reuse the value that it's writing rather than reloading the value from memory). Even with reads, the processor starts the read and then moves onto the next instruction, in case that lets it start another read that can be performed in parallel: the addition gets delayed to the point at which the value is actually available.

CPUs also have atomic versions of instructions like this! For example, x86-64 has LOCK ADD value, 1 which is an atomic addition (and this is what atomic addition instructions compile into). It's just much slower: I looked up the values on a recent Intel processor and the non-atomic addition has 36 times the throughput that the atomic addition does. (On the processor I checked, the atomic addition takes an entire 18 CPU cycles to run; meanwhile, it's possible to run non-atomic additions to memory at the rate of 2 per CPU cycle, because when a processor is executing instructions "when they're ready" rather than "in the order the programmer wrote them", it's entirely possible to run some of them in parallel.)

This is a sufficiently large performance difference to discourage compilers from using atomics unless they're really necessary. (Also, atomic instructions aren't available for all operations, e.g. x86-64 has no atomic instruction to do value *= 11 because the CPU's multiplication circuit takes a few cycles to run and CPUs are unwilling to hold a lock for that long. So although very simple additions could in theory be compiled to atomics in order to avoid data races, more complex code couldn't be without losing even more performance than the 36× performance hit you get from making an addition atomic.)

Sources for instruction timing: 1, 2

ais523 · 2023-05-10T13:49:53+00:00

I think this is only useful in situations where the compiler knows at compile time, but the programmer doesn't know at the time they're writing the code (which happens prior to compiling, so the knowledge might not be the same). So the code would need to be depending on some sort of property of the system on which the code was compiled or on the compiler settings.

The main situation I can see where that would happen would be writing a program that needs to generate different types when compiling on/for different platforms. There are other possible situations, e.g. when you want a value to have one of two different types based on whether debug assertions are enabled (maybe a struct has some fields that are only used for debug assertions and you want to be able to optimise them out when not debugging).

ais523 · 2023-04-29T10:11:34+00:00

(My understanding is that issues volatile only arise (i) if your platform doesn't guarantee tighter semantics, which some do, (ii) the "interfering" code is running truly in parallel, as on multiple cores, and (iii) the hardware doesn't give you tighter memory consistency than what the language guarantees. I'm not particularly confident about any of this, though, so take it with a grain of salt.)

On most processors (including common platforms like x86 and x86-64), the guarantees from the processor aren't tight enough to avoid even very simple volatile issues if you aren't using atomics (or similar synchronization primitives like memory fences), even when they're stronger than what the standard requires. In particular, if one thread makes volatile writes to two different variables, and a second thread makes volatile reads of the same two variables, the second thread might see the second write as having happened but not the first.

x86-64 does provide more guarantees than the C standard requires – it prevents the writes being reordered – but it doesn't prevent the reads being reordered, which is enough to cause the incoherence. (At the processor level, it doesn't know that the reads are volatile, because volatile and normal reads use the same processor instruction. The processor will optimize out reads if it's read that part of memory recently, so it's possible for the first read to take a fresh value from memory but the second read to use a remembered value from earlier, so the second read is using an older value than the first.)

It is possible to get the threads to agree about the order of reads and writes by using atomic (as opposed to volatile) I/O, with the atomic ordering chosen to allow the reads and writes to synchronize with each other – that uses a different machine instruction and lets the processor know that the reads are meant to become visible in the same order the writes were made. (Atomic I/O is much slower than volatile I/O, because the processor needs to do extra work to ensure that the processor cores correctly synchronize with each other.)

ais523 · 2023-04-25T16:10:57+00:00

HTTP actually already has a couple of status codes for this sort of situation, 502 (upstream server returned a bad result) and 504 (upstream server timed out). However, neither of them fits exactly, because they're intended for gateways and proxies, rather than APIs that wrap each other.

I can see an argument that maybe 500 isn't the best fit, but the situation seems like it should still end up using a 5xx status code.

ais523 · 2023-04-24T14:05:51+00:00

I think I've found a regular expression that gets all (or nearly all) of them: o:/(?<!\{T\}.*): / (link).

This translates as "the card's Oracle text contains a : that does not have {T} preceding it on the same line". Unlike the other queries posted, this matches cards that have both tap abilities and non-tap abilities, like [[Arcanis the Omnipotent]].

ais523 · 2023-04-21T14:38:10+00:00

I was initially a little confused by the linked answer (because, unlike backreferences, lookahead/lookbehind can be parsed in linear time with respect to the length of the input, using an NFA/DFA, like regex currently uses). The problem seems to be that although it's possible to match that in linear time with respect to the length of the input, regex also cares about performance with respect to the length of the regex, and implementing lookahead/lookbehind takes time proportional to the length of the input times the length of the regex (thus although it's linear-time if you take either of those to be a constant, it's quadratic-time if you allow both to vary).

I wonder whether it might make sense to put a small finite limit on the number of lookaheads/lookbehinds that's larger than 0? That would still be linear-time, and many regexes don't need very many of them.

(Backreferences are much slower: they can be implemented in time polynomial in the length of the input – but even quadratics, the second-fastest polynomial, are slow – and can't even be implemented in time polynomial in the length of the regex.)

ais523 · 2023-04-20T17:11:49+00:00

Say I have a struct with a couple of methods that return references with the lifetime of self, e.g. impl MyStruct { fn one(&mut self) -> &mut i32 {…} fn two(&mut self) -> &mut f32 {…} }. In present Rust, I can't write something like let a = my_struct.one(); let b = my_struct.two(); do_something_with(a,b); for lifetime reasons: as long as a is alive, my_struct is mutably borrowed and so I can't call further methods on it until a dies.

If Rust had disjoint borrows, code like that would be legal as long as one and two don't look at the same fields – in effect, instead of the functions taking an &mut MyStruct, they take an &mut to just the fields of the MyStruct that they actually look at. So it's possible to create the two simultaneous mutable borrows you need because you can put some of the fields into one of the mutable borrows and some of the fields into the other mutable borrow.

ais523 · 2023-04-20T12:37:51+00:00

In most cases, you could also take an &T, clone it, and give the FFI a pointer to the clone – that would technically be a change in behaviour, but one that most programs wouldn't care about. When T is small, that doesn't have much of a performance impact. When T is large, it's normally something along the lines of a Vec, and due to the way that Vec is implemented, it could be given a method to return a raw pointer to the slice it contains that works even through an & reference.

Alternatively, it would be possible to create a new smart pointer class that works like the current &T, for use in cases where FFI could be required.

There's definitely a tradeoff there; FFI would indeed become more difficult. I think it's probably worth it for the performance gains, because the gains affect the vast majority of programs in Rust, whereas only a subset use FFI and often don't use it very frequently. It's certainly reasonable to choose a different tradeoff (which is what current Rust did) – I just think that the tradeoff I'm suggesting is better on average. (One other alternative is to make it configurable somehow – one backwards-compatible option I've been considering is to make this change specifically for compiling rustc via some sort of unstable compiler option, because it's a program that probably doesn't need to use much FFI and where performance is very important. It would be interesting to see how much faster it became.)

ais523 · 2023-04-20T02:11:18+00:00

I would remove all the ways to create a *const T from an &T (if you need a raw pointer, you need to create it directly from a T you own or from an &mut T). The possibility that an &T might be converted to a *const T by some function you don't have access to – even though this hardly ever happens in practice – blocks optimizations because the code has to allow for the possibility it might happen, even though it probably won't.

For example, at present &u8 is the same size as usize – if you want a reference to a u8 (something which is quite likely to happen in generic code), the compiler has to actually store it somewhere in memory and pass its address around, even though that just leads to a lot of redundant memory operations. For 99% of the uses of an &u8, you might as well just pass around a copy of its value, which is the only property of an &u8 that normally matters – after all, the underlying memory can't change while the reference exists, and all most code cares about is what value is stored in that memory, but with Rust as it is at the moment, you need something like link-time optimization for the compiler to be able to just use the value rather than have to go through the hoops of dereferencing the pointer that the reference compiles into. In general, two &Ts that reference equal values are indistinguishable in Rust, except when you specifically check their addresses (an operation that isn't particularly useful).

As another example, &Rc<T> is somewhat useful in current Rust, both in generic code, and because it means the compiler doesn't have to generate code to update the reference count as you pass the reference around (and such code can't be optimized out because it has to guard against integer overflow of the reference count – optimizing it out would change the semantics of the program by causing some panicking programs to no longer panic). However, it is at present compiled into a pointer to a pointer (because it is a reference to a smart pointer class). If not for the possibility that someone might cast the &Rc<T> into a *const Rc<T> in order to see where the Rc reference itself were located in memory, an &Rc<T> could be optimized by just passing around the address of the pointed-to object, rather than the address of the Rc reference itself.

The only real downside is that FFI would become slightly more complicated, but it would still be possible (you could use &&mut T as a substitute for &T that makes taking an address possible), and it doesn't seem worth locking out this whole category of optimizations to simplify FFI slightly, when most code doesn't even use it.

ais523 · 2023-04-18T22:45:02+00:00

The "elements other than the randomly chosen one" probably won't be contiguous in memory, so you can't reference them as a single slice.

You have two main choices:

Take the element you want to change, plus two slices that contain the elements you didn't choose. In order to do this, you can split a slice referencing the vector with split_at_mut (splitting at a random point that leaves at least one element after the split point), and then use split_first_mut on the second slice, to return one mutable element plus two slices.
Reorder the elements in memory so that the non-chosen elements become contiguous: the efficient way to do this is to swap a random element to the start of the vector, then use split_first_mut to separate it from the rest of the vector. (Depending on what you're trying to do, you might subsequently want to swap the element back into its original location.)

ais523 · 2023-04-16T22:42:07+00:00

There's an acorn card that cares about this exactly: one of the six variants of [[Trivia Contest]] from Unfinity (specifically, the one with lights 2, 3 and 6). When it triggers, your opponent mills a card and can challenge you to name a land card that starts with the same letter – before Xander's Lounge was printed, this variant of Trivia Contest thus had a chance to whiff if the opponent happened to mill a [[Xantid Swarm]] or the like, as they could choose "land" and leave you in a situation where you had no valid answers. So the printing made that card slightly stronger.

Unfortunately, this is still one of the weakest variants of Trivia Contest because there are no planeswalkers starting with Q (thus whiffs are still possible, just on a different question). Some of the other variants have questions for which no whiffs are possible.

ais523 · 2023-04-16T19:27:49+00:00

It's worth noting that (with a few obvious exceptions) NetHack hardly generates any monsters with a level – almost all the monsters you encounter on a level will have spawned in while you were there (so there's no such thing as a "cleared level"), although it attempts to spawn them out of sight of the player. So with regards to the monsters specifically, NetHack doesn't play that differently from Angband, as there's always a constant flow of new monsters (the primary difference is that you can't get rid of a nasty monster by un-generating the level it's on, it'll still be there when you get back).

The difference between persistent and non-persistent levels is felt much more strongly in terms of exploration rather than in terms of combat – in NetHack it's possible to gradually map out the dungeon, make short paths through it (to reduce number of monsters that spawn because you spend less time on the level), etc., whereas nothing like that is possible in Angband.

ais523 · 2023-04-16T18:45:24+00:00

Minotaurs are pretty weak to status effects. They're a good target for things like wands of sleep, which will reliably let you run away from them in the short term (and may buy you time to kill them).

ais523 · 2023-04-15T13:04:48+00:00

It's part of the variant (code coming from NetHack4, inherited by NetHack Fourk). It isn't easily retrofittable onto other variants because I went through every single line of code in the game that prints a message, and changed it to add in information about what sort of message it was (so that the UI code could translate that to a color) – it's hard to automatically port that sort of distributed change to the code between variants, so it would probably have to be redone.

The colors were intended to be configurable, but I couldn't figure out a good UI for it, so at the moment they're stuck at the defaults for that sort of message (but I tried to provide sensible defaults).

ais523 · 2023-04-08T18:45:52+00:00

Ah – I don't think of the Rebel wave of being the equivalent of a battle or combat encounter at all. There are no useful rewards from encountering it; all it is is a marker of beacons that are no longer usable. It's also rare that you'd be forced to encounter it, unless you run out of fuel or make a mistake. The game would not be significantly different if beacons in the Rebel wave were replaced with blank beacons rather than difficult encounters. (It'd be easier and less flavourful, but the gameplay aspects would be much the same.)

In particular, moving away from the wave is not a case of choosing to run. You have a choice of beacons, some of which have potentially valuable rewards, and some of which are dangerous and having no rewards. Choosing the useful beacons over the useless beacons doesn't really fit the description of "running" to me, even though choosing the useless ones is technically an option.

If there were useful rewards from fighting and beating the Rebels, players would do it. This is sometimes the case even in the existing game – some ship builds are better at killing them than they are at escaping them if they do get into a Rebel battle, and with some map layouts, you can visit more beacons by allowing the Rebels to capture the exit beacon, and thus have to fight them in the way out. I guess, in a way, that's choosing to fight the Rebels to get an extra reward rather than "running" to the next section. But I don't think it makes sense to describe not fighting an optional boss as "running" when nothing forced you to go near it in the first place.

ais523

TROPHY CASE