By creating a spot of lava, filling up the whole level, and creating
a lurker above, I managed to trigger the impossible "Dismount: can't
place former steed on map" that was added earlier today. I also was
told that my god was displeased even though the engulfer's attack was
responsible. This addresses both situations. I can't trigger that
impossible any more, and only voluntary dismount blames the hero if
it's killed because there's nowhere to place it. Hero is still blamed
for any dismount that kills the steed while flying or levitating over
dangerous terrain--hero took steed into jeopardy.
Still not quite there yet though.
Focusing on tty (maybe curses) right now.
The gui has had significant code deviation from
prior gcc builds for windows and will take more
work.
Noticed whlie testing the steed-in-pit fix. The EXTRA_SANITY_CHECKS
for remove_monster() are being tripped if riding hero has steed killed
out from under him because the steed is not on the map. This started
out simple but got a bit complicated. It seems to be sufficient but
I'm not very confident about it.
Being engulfed while mounted gave "placing monster over another?" due
to a change made along with EXTRA_SANITY_CHECKS but not conditional on
it. (The change was to issue a warning about an actual problem which
was previously undiagnosed.) I think bumping the engulfer off the map
in favor of the former steed only worked because some u.uswallow code
eventually used the hero's location to put the engulfer back. I didn't
pursue that to try to figure what really happened, just prevent it.
The DISMOUNT_BONES handling was being executed even if the steed was
dead. DISMOUNT_BONES only happens if the hero is dead. Since I don't
know whether it's possible for dead hero and dead steed to happen at
the same time, move it inside the steed-not-dead block just in case.
Fixes#164
No message was shown when riding a steed into a pit or spiked pit.
Setup for the message was done, but post-3.4.3 insertion of else-if
into the previous if/else/endif cut off its delivery.
Applying a non-wielded cursed pick-axe first wielded it, then dug,
but it didn't report "pick-axe is welded to your hand". (Attempting
to drop it or wield something else did report that, after the fact.)
The same thing happened if you used a pole-arm rather than pick-axe.
The Windows graphical version in NetHackW.exe is meant to lock
itself to its own windowtype and ignore the OPTIONS=windowtype
setting in the config file, but the code to perform the lock
only did so if (argc > 1).
Stinking cloud placed near water or poison gas breathed across it
would affect and potentially kill underwater monsters. Most swimmers
are on the surface and should be affected, but eels and other fish
shouldn't be.
This also changes minliquid() to not treat flying and levitating as
ways to survive water when on the Plane of Water.
I think goodpos() needs to be taught about that Plane (where many ways
of existing at a water location don't apply). This doesn't do that.
There was a spurious seli-colon after an if's test, making a boundary
check be ineffective. When looking at that, I noticed that the 'O'
command's display of the current value for mouse_support ("0=off" and
so forth) was relying on implicit concatenation of adjacent string
literals, which would break K&R compilation. Do that concatenation
the old fashioned way....
While testing (after temporarily adding WC_MOUSE_SUPPORT to tty's
window_procs), I also noticed that wording used by config_error_add
looked strange when it was in response to giving a bad value via 'O'
command. Suppress its "config_error_add: " prefix is that situation.
On Windows only:
0 = turn off mouse_support
1 = turn on mouse_support and turn off QuickEdit mode
2 = turn on mouse_support and leave QuickEdit mode untouched
More generally, but not implemented anywhere:
0 = turn off mouse_support
1 = turn on mouse_support and make supporting O/S adjustments
(O/S adjustments not implented beyond Windows as yet)
2 = turn on mouse_support and do not make OS adjustments
(unimplemented as yet so behaves as 1)
Fix lev_comp's variable argument usage by changing it to make
add_opvars() expect an int rather than a long when given the "i"
indicator, and add "l" for really passing a long. The ints are
conveted to longs when setting up the interpreter. I think I changed
just about all the integer opvars to int, although there is one use
of "l" in lev_main.c just to make sure it works. There could be
arguments that really do need to be 'long'; if so, the add_opvars()
calls for them will have to have its indicator string updated and
possibly add or remove some casts.
There's a lot of reformatting included but it's not consistent about
tab replacement. Some of the changes are due to renaming long-named
'variable_definitions' to 'vardefs' to shorten a bunch of lines.
Updated sys/share/*_yacc.c will be checked in separately. The ones
currently in the repository won't work with patched lev_main.c due to
that renamed variable.
Fixes#163Fixes#153
Encumbrance calculations for taking things out of a bag of holding
where subject to rounding issues due to integer division. This may
improve things, although I think taking out a partial stack might not
be much better than before.
I simplified the contributed code, then decided that it wasn't an
improvement. In the process of switching back and forth I may have
introduced bugs which weren't present originally.
Under some circumstances, when all the marauding orcs belonging to the
horde operating within the gnomish mines had been provided with their
spoils and placed appropriately, there could still be some pillaged stuff
left-over on the migrating obj chain. Orcs created by regular monster
generation elsewhere would then be susceptable to receiving that stuff
until it was used up. That part is fine, except that the orcs were then
being named as part of the same horde operating within the mines. Now
they will no longer be named as part of the Gnomish Mines horde.
Mythos: There's a good chance that these particular orcs received the
stolen goods from the Gnomish Mines horde.
On Windows, if you build without STATUS_HILITES defined,
you'll be greeted by the following barrage of errors when
you start the game.
On Windows, use makedefs to detect that STATUS_HILITES
isn't defined, and comment out the offending lines in
the sample config file.
Errors received before this change:
OPTIONS=statushilites
* Line 197: 'statushilites' is not supported.
OPTIONS=hilite_status:hitpoints/100%/gray&normal
* Line 200: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<100%/green&normal
* Line 201: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<66%/yellow&normal
* Line 202: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<50%/orange&normal
* Line 203: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<33%/red&bold
* Line 204: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<15%/red&inverse
* Line 205: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/100%/gray&normal
* Line 208: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<100%/green&normal
* Line 209: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<66%/yellow&normal
* Line 210: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<50%/orange&normal
* Line 211: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<33%/red&bold
* Line 212: 'hilite_status' is not supported.
OPTIONS=hilite_status:cap/burdened/yellow/stressed/orange/strained/red&bold/ove
rtaxed/red&inverse/overloaded/red&inverse&blink
* Line 215: 'hilite_status' is not supported.
OPTIONS=hilite_status:hunger/satiated/yellow/hungry/orange/weak/red&bold/fainti
ng/red&inverse/fainted/red&inverse&blink
* Line 218: 'hilite_status' is not supported.
Hit <Enter> to continue.
Fixes#161
Report states that scattering objects might leave a 'pile' glyph when
no longer appropriate. I didn't try to reproduce that, just took it
on faith. The fix tried to be too efficient and might have missed
fixing the display if breaks() or ohitmon() destroyed the objects
being scattered and left 'total' at 0.
During level change, when a monster from mydogs (monsters accompaying
hero, usually pets) couldn't be placed because the level was full, it
was set to migrate to that level (in order to get another chance to
arrive if hero left and returned). The code sequence
mon_arrive()-> mnexto()-> m_into_limbo()-> migrate_to_level()-> relmon()
tried to remove the monster from the map, but it wasn't necessarily on
the map (depending upon whether it couldn't arrive at all, or arrived
at the hero's spot and couldn't be moved out of the hero's way). The
EXTRA_SANITY_CHECKS for remove_monster() issued impossible "no monster
to remove". relmon() now checks whether monster is already off the map.
While investigating that, I discovered that pets set to re-migrate
to the same level to try again on hero's next visit didn't work at all.
migrating_mons gets processed after mydogs so moving something from
the latter to the former after arrival failure just resulted in
immediate second failure when the more general list was handled during
the hero's current arrival. And failure to arrive from migrating_mons
would kill the monster instead of scheduling another attempt.
The sanest fix for that turned out to be to have all monsters who
can't arrive be put back on the migrating_mons list to try again upon
hero's next visit. Pets still fail twice but are no longer discarded
during the second time, and now do arrive when hero leaves and comes
back provided he or she has opened up some space before leaving. If
there's still no space on the next visit, monsters who can't arrive
then are scheduled to try again on the visit after that.
Recent fix for invalid corpses becomes moot. Monsters aren't killed
during arrival failure so there are no resulting corpses to deal with.
