Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Nightmare IVa combat.c

0 views
Skip to first unread message

jtmiii

unread,
Dec 3, 1995, 3:00:00 AM12/3/95
to

Ok, not sure I can describe this sufficiently, but here goes...*wishes
the mudlib arch was posting this, not the law arch*

Beek paid a visit to Paradox II not too long ago, and pointed out that
our combat was a bit funny, in that the damage messages came _after_ the
hp report. E.g.,

hp: 13/200 sp: 100/120 mp:100/100
Monster destroys you utterly in the left foot with his magic.

We'd never really thought about it before, but we agreed, and our mudlib
arch implemented the necessary changes.

This created an additional unforseen problem. The function do_damage(),
which previously had automatically given a hp report, ceased from doing
so. Combat worked fine, i.e., the messages were in the proper order, as
Beek had suggested. However, certain skills which relied on do_damage()
(we have several which allow non-spellcasters to do damage beyond regular
combat) stopped giving hp reports.

Why is this a problem?

Because a player who is fighting a monster who uses these do_damage()
skills doesn't get told s/he is about to die. Yes, a message comes
through (Kahn Draxen crushes you with an all-out smashing motion), but
without the hp: 13/200 sp: 100/120 mp:100/100 , a player doesn't know
how close s/he is to death without typing <status> in mid-combat.

Our mudlib arch suggested 3 options:

Alter every skill which uses do_damage() to include an additonal 2 lines:
TP->check_on_limb();
TP->hp_report();

(the latter he created just for this purpose)

---OR

Make do_damage() contain a couple more parameters--this would also
require an edit of every skill which uses do_damage().

--OR

Put it back to the way it was before Beek made his astute observation.
-----


For the time being, we've chosen the last option, only because the law
arch and qc arch are really tired of editing every single damned skill to
make them compatible with new innovations in the mudlib.

whew...hope that all made sense....any ideas? questions?

thanx for any replies.

--john@rl
--mag...@paradox.ii

-------------------------------------------------------------------------------
"To be truthful means using the customary metaphors-- in moral terms: the
obligation to lie according to a fixed convention, to lie herd-like in a
style obligatory for all...." Nietzsche, 1873.


George Reese

unread,
Dec 4, 1995, 3:00:00 AM12/4/95
to
One thing that makes this difficult is that you guys are the only ones
on Earth using this alpha release :)

jtmiii (du...@selway.umt.edu) wrote:


: Our mudlib arch suggested 3 options:

: Alter every skill which uses do_damage() to include an additonal 2 lines:
: TP->check_on_limb();
: TP->hp_report();

: (the latter he created just for this purpose)

: ---OR

: Make do_damage() contain a couple more parameters--this would also
: require an edit of every skill which uses do_damage().

: --OR

: Put it back to the way it was before Beek made his astute observation.
: -----

I am not exactly sure from this post where do_damage() fit into the
scheme before the change. At any rate, I think what you need to do to
get help is....

#1 post the requirements you have
You are trying to do what? I am guessing you need to dole out skill
advancement and show the victim damage it took?

#2 post the current behaviour
I gather, the current, new behaviour is damage hgappens, but no one
gets skill points or sees the hp message?

If I am right baout my guesses, then you simply need something in
there after you see the messages that performs these things. It need
not be the do_damage() thingy.

--
George Reese (bo...@imaginary.com) | "What the world needs now is
http://www.imaginary.com/~borg/ | some true words of wisdom,
phone/fax: (612) 829-5495 | like la la la la la..."
| -Cracker

George Reese

unread,
Dec 19, 1995, 3:00:00 AM12/19/95
to
Ok, I understand the problem now. The text was quoted below for
others who wish to read the problem.

jtmiii (du...@selway.umt.edu) wrote:

: Ok, not sure I can describe this sufficiently, but here goes...*wishes

: the mudlib arch was posting this, not the law arch*

: Beek paid a visit to Paradox II not too long ago, and pointed out that
: our combat was a bit funny, in that the damage messages came _after_ the
: hp report. E.g.,

: hp: 13/200 sp: 100/120 mp:100/100
: Monster destroys you utterly in the left foot with his magic.

: We'd never really thought about it before, but we agreed, and our mudlib
: arch implemented the necessary changes.

The problem is...
combat does damage
combat dispolays messages base don damage done

AND
combat does damage implies show how much damage is done

Thus displaying status ends up showing before the hit shows.

: This created an additional unforseen problem. The function do_damage(),

: which previously had automatically given a hp report, ceased from doing
: so. Combat worked fine, i.e., the messages were in the proper order, as
: Beek had suggested. However, certain skills which relied on do_damage()
: (we have several which allow non-spellcasters to do damage beyond regular
: combat) stopped giving hp reports.

: Why is this a problem?

: Because a player who is fighting a monster who uses these do_damage()
: skills doesn't get told s/he is about to die. Yes, a message comes
: through (Kahn Draxen crushes you with an all-out smashing motion), but
: without the hp: 13/200 sp: 100/120 mp:100/100 , a player doesn't know
: how close s/he is to death without typing <status> in mid-combat.

: Our mudlib arch suggested 3 options:

: Alter every skill which uses do_damage() to include an additonal 2 lines:
: TP->check_on_limb();
: TP->hp_report();

You end up with the same problem done differently.

: (the latter he created just for this purpose)

: ---OR

: Make do_damage() contain a couple more parameters--this would also
: require an edit of every skill which uses do_damage().

Same problem

: --OR

: Put it back to the way it was before Beek made his astute observation.

Beek is right.

I cannot think of a way under the old NM lib to do it nicely. One way
you might consider doing it is doing the messages through a 0 second
call out. This is roughly the same as posting an event.

In other words, call the hp report from do_damage(), but make that hp
report done through a call out so they occur after the messages are shown.

Michael J. Tanenhaus

unread,
Dec 20, 1995, 3:00:00 AM12/20/95
to
George Reese (bo...@winternet.com) wrote:
: Ok, I understand the problem now. The text was quoted below for

: others who wish to read the problem.

: you might consider doing it is doing the messages through a 0 second


: call out. This is roughly the same as posting an event.

: In other words, call the hp report from do_damage(), but make that hp
: report done through a call out so they occur after the messages are shown.


I dont begin to understand the NM lib, old or new, but why not just havea
player_ob flag or no flag is this is to be displayeed all the time

Which does status update in heart_beat, if they are in combat?

--
---
---
mta...@seas.gwu.edu "One Never Knows what Will Happen, Could Happen,
or Should Happen, But they try to Change it Anyway"
Michael J. Tanenhaus
Computer Science

George Reese

unread,
Dec 21, 1995, 3:00:00 AM12/21/95
to
Michael J. Tanenhaus (mta...@seas.gwu.edu) wrote:

: George Reese (bo...@winternet.com) wrote:
: : Ok, I understand the problem now. The text was quoted below for
: : others who wish to read the problem.

: : you might consider doing it is doing the messages through a 0 second
: : call out. This is roughly the same as posting an event.

: : In other words, call the hp report from do_damage(), but make that hp
: : report done through a call out so they occur after the messages are shown.


: I dont begin to understand the NM lib, old or new, but why not just havea
: player_ob flag or no flag is this is to be displayeed all the time

: Which does status update in heart_beat, if they are in combat?

Damage does not always occur in combat, and the next heart beat may
prove too late to avoid death.

0 new messages