Orc captain attacking just after game load

[LostTemplar]

Most monsters are sleeping anyway, so this will only make hounds more dangerous, but they are already bad enough.

[buzzkill]

You'll have to be more specific about what you mean.

If you start the player at 50 energy and a double-speed monster at 15 energy, the monster will still go first. That's true of an entire pack of time hounds if the player is at speed+5 even if some of the hounds are 20% less energetic than average.

I'm not exactly sure what the inner workings of Angband are so I don't even know if this is possible, but I was thinking that each individual monster, as well as the player, would receive a (unique) random amount of energy. Thus, if the player were to descend into a pack of equal speed enemies, he would likely take his turn somewhere in the middle of the first round of combat. As Hariolor said, faster monsters being more likely to move first is only fair, and anything with double speed would always go first (as it should be). I guess players would adopt the tactic of hasting themselves before descending if second-move survival was questionable, and even that wouldn't guarantee anything. It's definitely a big move toward making the game harder (and more realistic).... and yet another happy stair-scumming deterrent.

[PowerDiver]

If the player is normal speed, and the monster is double-speed, it doesn't seem unfair that the monster goes first, does it?

Fair? To be fair, the player should be at the same disadvantage when summoned to a level compared to monsters on the level, as symmetrically summonees are made to be in comparison to the player when summoning happens during battle. Fair has nothing to do with it. Ain't gonna happen unless a meanie like me is put in control.

The goal is to stop the player from being insta-killed when he lands on a new level in a room with a pack of time hounds. That's what the buggy line of code that caused the OP to die was trying to accomplish.

The ticket about avoiding unavoidable deaths has been around long enough for Takkaria to squash it if he opposed it, so presumably he is on board with the general idea. I believe the policy is set, and it's now a question of implementation details.

[Hariolor]

You'll have to be more specific about what you mean.

If you start the player at 50 energy and a double-speed monster at 15 energy, the monster will still go first. That's true of an entire pack of time hounds if the player is at speed+5 even if some of the hounds are 20% less energetic than average.

If the player is normal speed, and the monster is double-speed, it doesn't seem unfair that the monster goes first, does it?

[PowerDiver]

Couldn't we start both monsters and player with a random amount of energy, not guaranteeing the player the first move, but (probably) not being left to move last either.

You'll have to be more specific about what you mean.

If you start the player at 50 energy and a double-speed monster at 15 energy, the monster will still go first. That's true of an entire pack of time hounds if the player is at speed+5 even if some of the hounds are 20% less energetic than average.

[buzzkill]

Personally, I think the player should start at 0 and the monsters at 100. They should get the move on you when you appear from a recall, not vice versa. I know I'm in a minority here.

Couldn't we start both monsters and player with a random amount of energy, not guaranteeing the player the first move, but (probably) not being left to move last either.

[PowerDiver]

I closed the duplicate ticket (#1147) - Takk had already reported this as #1058. Most of the discussion is on #572. IMO it would suffice to ensure that the player always get the first move on a new level, however he arrives there, and also after accidental summoning (undetected trap or unIDd scroll or staff, but not known/IDd).

They seem like separate issues. The right way to fix summonees and waking monsters is to start them with -100 energy. We continue to pay the price for the initial choice to make so many things bytes that should have been ints. We should change all bytes and shorts to ints and break the savefiles once rather than dealing with this stupid issue over and over.

No one seems to care much about energy on new levels. I think it's a little unfair to start the player at 100 and the monsters at around 10. Probably everyone should start at 100. Then the player gets the first move from the tiebreaker, but the monsters aren't penalized.

Personally, I think the player should start at 0 and the monsters at 100. They should get the move on you when you appear from a recall, not vice versa. I know I'm in a minority here.

Doing things properly in terms of setting energy_usage seems like too much effort, so a quick fix seems appropriate. I've been playtesting with debugging printfs and changing to

        /* Give player minimum energy to start a new level, but do not reduce higher value from savefile for level in progress */
        if (p_ptr->energy < INITIAL_DUNGEON_ENERGY)
                p_ptr->energy = INITIAL_DUNGEON_ENERGY;

seems to work as intended.

[Magnate]

It seems that the line is working as described by the comment except on game load.

The question is whether you think the player should always get the first move, even if he falls through a trap door and lands next to much faster monsters. If so, then the change I suggested earlier is correct. If not, a fair amount of work needs to be done.

I closed the duplicate ticket (#1147) - Takk had already reported this as #1058. Most of the discussion is on #572. IMO it would suffice to ensure that the player always get the first move on a new level, however he arrives there, and also after accidental summoning (undetected trap or unIDd scroll or staff, but not known/IDd).

[PowerDiver]

It seems that the line is working as described by the comment except on game load.

The question is whether you think the player should always get the first move, even if he falls through a trap door and lands next to much faster monsters. If so, then the change I suggested earlier is correct. If not, a fair amount of work needs to be done.

[will_asher]

It would be kind of starkly amusing to start up a new gnome mage who just happened to appear in town right next to a mercenary.

The Mean-looking mercenary wakes up. -more-
The Mean-looking mercenary hits you. -more-
You die.

Hey, just one more place to add an instadeath to the game, right?

It would have to be a half-troll mage to wake up the mercenary that fast..

[Derakon]

It would be kind of starkly amusing to start up a new gnome mage who just happened to appear in town right next to a mercenary.

The Mean-looking mercenary wakes up. -more-
The Mean-looking mercenary hits you. -more-
You die.

Hey, just one more place to add an instadeath to the game, right?

[PowerDiver]

It sounds like some ancient cheat to make it possible to gain a free turn after a forced save.

That would be sneaky and clever.

However, I usually assume carelessness over cleverness until proven otherwise. I just looked, and energy is not set in birth.c except from wiping the player structure. I wonder if that line was just intended to make a player start a new game with 100 energy.

[Pete Mack]

It sounds like some ancient cheat to make it possible to gain a free turn after a forced save.

It is (or was) possible to force quit (and save) with SIG_TERM (kill -15) on Unix. This would give you a free turn if you were getting pummeled by a mob of Cloud Giants or something.

[PowerDiver]

Basically I'm trying to figure out why manipulating energy on load would ever be necessary.

It isn't. Someone trying to solve some other problem did something wrong, with the side effect that on load energy is reduced.

[Derakon]

Shouldn't all creature energy be saved when the game is saved? And the game can't be saved when it isn't the player's turn, right? Therefore, all creature energy should be restored properly on load, meaning it should always be the player's turn when a save is loaded.

Basically I'm trying to figure out why manipulating energy on load would ever be necessary.