On Wednesday, October 15, 1997 2:54 PM, Jeremy Elson
[SMTP:jelson@CIRCLEMUD.ORG] wrote:
> George writes:
> >On Wed, 15 Oct 1997, Jeremy Elson wrote:
> >
<snip>
> >Is not the realism of don't drop things while over the water better than
> >things such as anvils floating around?
>
> In my opinion, no. There are already many examples of concessions we
> make to realism for the purpose of making the game more playable
> (e.g. "gossip"); I wouldn't want to deal with the first 10 players to
> lose their Amazing Sword of Destruction after dropping it while on a
> boat.
This is one concession that a few function calls inserted into the correct
places would provide a new layer of behavior that players would quickly
become accustomed to, and then wonder why every mud wasn't this way.
Boats are only checked a few places in the code, mainly to determine
if a person has one or not. Why not junk the entire boat concept, add a
is_waterproof flag to objects, and then start checking to see if a player
has a container on them that is waterproof and can contain them and their
eq. Issues of boat type could be added in the container values.
(example lookup snippet for a boat... mailercode)
int found_one=0;
for (obj=ch->carrying;obj;obj=obj->next_content)
if ( (GET_ITEM_TYPE(obj) == ITEM_CONTAINER) &&
(IS_SET(OBJ_FLAGS(obj), ITEM_WATERPROOF)))
if ( GET_ALL_WEIGHT(ch) < GET_OBJ_VAL(obj, 1))
/* we're floating */
else
/* we're sinking */
Then modify drop to check for a water room. If found, call the perform_put
routine with the proper arguments, instead of dropping them. Give an
override "DROP SWORD &" or something.. to really drop it. Same with
GETs that don't find anything. Have them look in your boat if appropriate.
Not that messy really. Players would never know the difference, unless
they happened upon a 50 gallon drum, stripped off all their eq and tried
to float down a river.. not impossible.. but not likely either.
Things to add: flotation ability, streamlined ratio, engine
>
> The container idea is nice, but I don't think it can really be
> implemented elegantly unless and until C++-Circle comes out :-) (where
> instead of a "type field" on objects, they are all derived types of a
> common superclass) -- then all the special cases would be very neatly
> taken care of by way of virtual functions.
>
C++ would be a nice way to go. But if we're going to do that it seems a
waste to leave out an event model, multiple threads and a message
passing interface for external modules (Mob AI, economy processing, etc)
--Mallory
Neither sweat, nor blood, nor frustration, nor lousy manuals
nor missing parts, nor wrong parts shall keep me from my task.
--Christopher Hicks
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST