CF: Prot/chaos, Efficiency, and Portals (was Re: ideas for next experiments)

[David Andrew Michael Noelle <>]

Mark Wedel wrote:
> [...chaos weapons...]
>  But that makes me think that adding protections to chaos is even a worse idea.
> If that general purpose weapon no longer works because people are now protected
> and you instead have to go to a specific attack weapon, the usefulness of the
> general purpose weapon is greatly reduced.

    Agreed.  I was testing immunity/protection from chaos, since it was
trivial to add, but I'll abandon that one.  Making chaos weapons is easier
without it anyway.


>  You still need to have an index to these types to be useful.  And you can't
> really sort when going on a map - a top down approach is used - you drop
> something on the map, and it is the top object.  A pile of objects is not going
> to re-arrange itself so all the swords are together.

    Well, I was overlooking that technicality on purpose, since objects do
rearrange themselves now.  Only when they merge, though.
    Speaking of order of objects, could someone more familiar with the
client tell me just how hard it would be to sort inventories by object type
and archetype and then name?  It bugs me that my key ring thinks it's a
ring, despite the fact that I listed key ring specifically in the item types
file.  Also, any unusual weapons with non-standard names that might be lying
around on whatever map, have to be added to that file unless you're willing
to keep normal weapons at the top of your inventory and weird weapons at the
bottom.  Even standard spellbooks won't sort correctly.  Any spellbook of
any bolt spell sorts itself in with your arrows and crossbow bolts.  But
wait, it gets worse!  Cabbage gets sorted as a bag!


>  But from the other mail message, it seems that CPU issue on the constant
> searching should not be a big deal.  Traversing the list itself is pretty quick
> (going to the next pointer and whatever).   If anything, the big cost issue
> would be the comparisons, so if searching for an item, using a method other than
> string comparison would be hte big gain (do these point to the same thing, or
> are these integer values the same, etc.)  Comparing a couple 20 character
> strings is probably as costly as traversing 100 objects.

    When I read the other message, I started imagining all kinds of strange,
complex schemes to make searching, addition, and deletion faster, without
increasing memory usage significantly.  I don't know what the rest of you
are running on, but with only 40 Mb ram (and no excess cash to expand it)
and wasting most of it on Emacs and Netscape, I start noticing lag on my own
machine after only a couple hours of playing with a single character.  The
lag is particularly noticable every time I pick up an object, and the larger
my inventory and the pile of objects on that space, the worse the lag is. 
Apparently that is a further result of the client sorting objects by name.
    If nobody else is having these problems, I'll just leave the data
structures alone (for now.)  I will keep an eye out for searches that can be
streamlined without changing anything else.  Maybe a single inventory_search
function that could efficiently step through a linked list and return all
objects of a given type, would help somewhat.  It would make the code a
little neater anyway, since there are currently a ridiculous number of
identical search loops scattered throughout.


>  I would prefer not to have this state in the maps.  Maps then need to know
> there is a portal on them, and where they point (which means that at that time,
> the map has to examine all of its objects and when it finds a portal, do the
> right thing, assuming the character is still in the game as hasn't left and
> saved off to disk).

    It doesn't have to be done the hard way.  One pointer in the MAP object
could be used to keep a seperate inventory of portal objects.  Stepping
through that list and removing them, and their matching objects in the
player's inventory, would then be trivial.  And there wouldn't be any
portals for characters who have left the game, since portal markers wouldn't
save.  They'd delete themselves and the matching object in the map instead. 
But the point is moot.  I'd rather not have the map actively do anything to
the portals.


>  My preferred method would be all that info be in the portal object itself.
> Thus, you only need to validate the destination is OK when the player tries to
> use it - if the player creates a portal but never tries to use it, you don't
> need to worry at all where it may point to.

    Actually, that's the method I prefer, too.


>  Note that portals to apartments needs to be thought.  Suppose merlin has an
> apartment, creates one end in that, and goes on an adventure with his friends.
> He creates another portal to go home.  Can his friends use it in that case?  And
> if they can, where to they end up?  IF they end up in merlins apartment, that is
> now a place they were never able to get before.  IF they end up in their
> apartment, that is a little strange since a portal was never created there
> (although the fact that as many people can have a unique apartment off the same
> map isn't the most realistic)

    The way I have it now, they would all end up in Merlin's apartment.  I
don't see a problem with that.  I think there /should/ be a way to
specifically allow the rest of your party into your apartment.  The problem
would be anyone else sneaking in while the portal is still open.  Maybe that
would just be a risk you'd have to take, opening a portal to your apartment,
but I don't want to do that.
    The portal could test whether the target map is unique and set its own
unique flag.  Then, the owner would be able to use it, and for anyone else,
it would first make sure they're part of the owner's party.  If not, it
could collapse or just not let them in.

    I'm not sure which way to go with this one.  Another option would be to
only allow the caster, and not the rest of the party, to use a portal to an
apartment map.  The caster could then exit the apartment, set a portal
marker in town, return through the private portal, and open a second one for
everyone else.  I think I'm leaning toward that solution at the moment, but
I'm open to suggestions.

-- 
            -Dave Noelle,                 
            -the Villa Straylight,  http://www.straylight.org
Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com

Disclaimer:#include <std_disclaim.sig>

Quote of the Day:
"Twas brillig, and the slithy toves
   Did gyre and gimble in the wabe.
 All mimsy were the borogoves,
   And the mome raths outgrabe."  - Lewis Caroll
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]