As discussed in the gnome mages thread, it'd be nice to have some alternative implementations of the nexus stat swap effect. This thread can discuss implementations. Arguments about what game impact nexus should have can continue going in the original thread; this is more for code details.
The current effect is "memoryless", i.e. the game just swaps the values of two of your stats, and that's the "new normal". Any effect that allows for later reversion (as a temporary status effect, or reversion at levelup, is going to require the game to keep track of what the stats ought to be when the effect expires, so they can be restored later.
I haven't had a chance to take a close look at the 4.0 codebase yet, but a quick look indicates that there's still a player struct that includes an array of current stat values (stat_cur). I assume this is the "internal" stat value before race/class/equipment modifiers are applied.
The way I'd propose tracking nexus stat swaps, then, would be to add a "lookup table" that maps stat indices to stat indices. Normally this would be an array that looks like this: {0, 1, 2, 3, 4}. That is, each stat index maps to itself. When a nexus stat swap occurs, we a) swap the stat values in stat_cur (as we do now), and b) update the mapping array. For example, if STR and INT are swapped, then the array becomes {1, 0, 2, 3, 4}. If STR then further gets swapped with CON, it becomes {4, 0, 2, 3, 1}.
When the time comes to revert the swap, we can use the mapping array as a guide, and then restore that array to its "identity" state.
This does result in the interesting behavior that e.g. if you get swapped, then any stat boosts / drains applied during the swap will "transfer" when the swap reverts. Which sounds reasonable enough to me.
Presumably it'd also be desirable to add a "Nexus" or "Scrambled" text to the status line to indicate to the player that their character is in a temporarily-unusual state. Though this could result in semi-annoying UI if (in Nick's proposal where the stat swap only goes away on levelup) the character hits level 50 with maxed stats across the board and can't get rid of that little status line. One reason to prefer the temporary status effect approach I proposed.
The current effect is "memoryless", i.e. the game just swaps the values of two of your stats, and that's the "new normal". Any effect that allows for later reversion (as a temporary status effect, or reversion at levelup, is going to require the game to keep track of what the stats ought to be when the effect expires, so they can be restored later.
I haven't had a chance to take a close look at the 4.0 codebase yet, but a quick look indicates that there's still a player struct that includes an array of current stat values (stat_cur). I assume this is the "internal" stat value before race/class/equipment modifiers are applied.
The way I'd propose tracking nexus stat swaps, then, would be to add a "lookup table" that maps stat indices to stat indices. Normally this would be an array that looks like this: {0, 1, 2, 3, 4}. That is, each stat index maps to itself. When a nexus stat swap occurs, we a) swap the stat values in stat_cur (as we do now), and b) update the mapping array. For example, if STR and INT are swapped, then the array becomes {1, 0, 2, 3, 4}. If STR then further gets swapped with CON, it becomes {4, 0, 2, 3, 1}.
When the time comes to revert the swap, we can use the mapping array as a guide, and then restore that array to its "identity" state.
This does result in the interesting behavior that e.g. if you get swapped, then any stat boosts / drains applied during the swap will "transfer" when the swap reverts. Which sounds reasonable enough to me.
Presumably it'd also be desirable to add a "Nexus" or "Scrambled" text to the status line to indicate to the player that their character is in a temporarily-unusual state. Though this could result in semi-annoying UI if (in Nick's proposal where the stat swap only goes away on levelup) the character hits level 50 with maxed stats across the board and can't get rid of that little status line. One reason to prefer the temporary status effect approach I proposed.
Comment