4.0.2 Bugs

[Nick]

In my current game, Mushrooms of Emergency are not causing hallucinations, just all the other effects. I think in my last game they worked fine, which is a little odd.

You don't have RChaos, do you? That protects from hallucination effects.

[Egavactip]

You don't have RChaos, do you? That protects from hallucination effects.

Oh, I guess I do. I can't believe I have never once had RChaos before while eating a Mushroom of Emergency!

[Nick]

Sometimes the number of enemies in messages gets more than the actual number when you hit multiple targets. In my particular case, it shows "5 Dracoliches shrug off the attack" when there are only 2 of them.

I was using meteors but I think I have probably seen this before for other ball attacks. I'm not sure about beam attacks, though.

OK, this is great. This bug only occurs with multiple meteors hitting multiple monsters of the same type (and for the record, one Dracolich was counted once, and the second one four times). I'm currently working out a fix that doesn't involve a major rewrite of the monster message code

[PowerWyrm]

Two or five dracoliches don't matter anyway... the next message you get is a big tombstone

[Werbaer]

Morgoth double move bug

Priest at 38 base speed. Morgoth got double moves against me at 3 times. At least twice i am sure i was hasted, so even a hasted Morgoth shouldn't be able to double move me.

The i saved before each of my moves. With the attached save file, after i take my turn (casting an orb), Morgoth gets a double move.

[Nick]

Morgoth double move bug

Priest at 38 base speed. Morgoth got double moves against me at 3 times. At least twice i am sure i was hasted, so even a hasted Morgoth shouldn't be able to double move me.

The i saved before each of my moves. With the attached save file, after i take my turn (casting an orb), Morgoth gets a double move.

I can confirm the double move - I'll look into how that's possible.

[PowerWyrm]

Found a bug with the equipment counter, while playtesting my variant. This happens when an equipped item gets excised (gear_excise_object):

	/* Make sure it isn't still equipped */
	for (i = 0; i < player->body.count; i++) {
		if (slot_object(player, i) == obj)
			player->body.slots[i].obj = NULL;
	}

In this code, equip_cnt should be decreased.

	/* Make sure it isn't still equipped */
	for (i = 0; i < player->body.count; i++) {
		if (slot_object(player, i) == obj) {
			player->body.slots[i].obj = NULL;
                        player->upkeep->equip_cnt--;
               }
	}

Looking at the latest code, this (gear_excise_object called on an equipped item) can only happen in a specific case: when an equipped torch runs out of fuel.

[PowerWyrm]

Morgoth double move bug

Priest at 38 base speed. Morgoth got double moves against me at 3 times. At least twice i am sure i was hasted, so even a hasted Morgoth shouldn't be able to double move me.

The i saved before each of my moves. With the attached save file, after i take my turn (casting an orb), Morgoth gets a double move.

This is clearly a problem of not clearing energy on specific turns, because moving away from Morgoth or pressing '5' repeatedly still makes Morgoth do nothing on specific turns, showing clearly that Morgoth is at base +30 speed and that the speed delta is is favor of the character.

[Werbaer]

Morgoth double move bug

This bug was introduced when the speed system was changed in 2.7.3, and got fixed in 2.9.1.. At some point since then, it has been reintroduced by code changes.

Before the fix, the player was always processed before the monsters in each game turn. Assume Morgoth at speed +30 (38 energy/turn) and the player at speed +38 (41 energy per turn). If the player currently has 61 energy, and the monster 98, the player still acted first, and has 2 energy left. Then the monster acts, and has 36 energy left, and will act again 2 game turns later, before the player reaches 100 energy.

The fix was: Each turn, player and monsters get their energy. Then the monsters with more energy as the player act first, then the player, then the remaining monsters.

There have been some major code rewrites since then. Which lead to that bug creeping up again.

In the current code, the player gets his energy first, but the monsters get theirs while they are processed. Example above: Morgoth has 98 energy. Player has 61. Player gains 41 energy, resulting in 102. Player turn triggers. Monsters with more energy than him get to act first; but since Morgoth didn't get his energy yet, he's still on 98, and the player acts first (2 energy left). After him, Morgoth acts (36 enery left). And acts again 2 turns later, resulting in a double move.

[Nick]

Looking at the latest code, this (gear_excise_object called on an equipped item) can only happen in a specific case: when an equipped torch runs out of fuel.

Excellent, that should explain the crash on a torch running out upthread.

[Nick]

The fix was: Each turn, player and monsters get their energy. Then the monsters with more energy as the player act first, then the player, then the remaining monsters.

There have been some major code rewrites since then. Which lead to that bug creeping up again.

Yeah, the mistake was putting monster moves between monsters getting energy and the player getting energy.

The surprising thing really is that the bug is as subtle and minor as it is, given that the whole main game loop was turned inside out in the course of doing the core-UI split

[Nick]

Looking at the latest code, this (gear_excise_object called on an equipped item) can only happen in a specific case: when an equipped torch runs out of fuel.

Could also happen when selling an equipped item, in fact, and possibly other uses of gear_object_for_use(). No need to check, though as your fix covers it all.

[PowerWyrm]

OK, this is great. This bug only occurs with multiple meteors hitting multiple monsters of the same type (and for the record, one Dracolich was counted once, and the second one four times). I'm currently working out a fix that doesn't involve a major rewrite of the monster message code

And the hack is unneccessary, since the bug is obvious: monster is not recorded in the temporary message history list when the message is already stored. Fix should be trivial:

	/* Query if the message is already stored */
	for (i = 0; i < size_mon_msg; i++) {
		/* We found the race and the message code */
		if ((mon_msg[i].race == mon->race) &&
			(mon_msg[i].mon_flags == mon_flags) &&
			(mon_msg[i].msg_code == msg_code)) {
			/* Can we increment the counter? */
			if (mon_msg[i].mon_count < MAX_UCHAR) {
				/* Stack the message */
				++(mon_msg[i].mon_count);
			}

	[B]/* record which monster had this message stored */
	if (size_mon_hist >= MAX_STORED_MON_CODES) return (TRUE);
	mon_message_hist[size_mon_hist].mon = mon;
	mon_message_hist[size_mon_hist].message_code = msg_code;
	size_mon_hist++;[/B]
   
			/* Success */
			return (TRUE);
		}
	}

[Nick]

And the hack is unneccessary, since the bug is obvious: monster is not recorded in the temporary message history list when the message is already stored.

Not obvious to me, apparently

Fix implemented.

[PowerWyrm]

Finding Ingwe: "You see a Pendant <+3,+4>." Inspecting it gives info about stats and activation. This doesn't happen with other arts like Arkenstone. Why is jewelry treated differently?