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

[David Andrew Michael Noelle <>]

Mark Wedel wrote:
[...client-side inventory sorting...]
>  To do it by type, then arch, then name requires a change in the protocol that
> the client and server use to communicate with each other.
> 
>  The current implementation, which is probably the right way to go, is the
> client determines type by name.  It would not be hard to change the name
> matching so it only matches start of string, but then you don't catch things
> like +1 sword properly.  It probably would be good, however, to at least change
> it to be word match and not substring (so 'key ring' would still get matched by
> name, but the cabbage/bag would not get confused.

    When the client guesses the object type, it uses an array constructed
from the contents of the itemtypes file, right?  It seems to be matching
against that array in the order of the type values assigned, and not in the
order they're listed in the text file.  What if that array was ordered as
listed in the text file, and the type value to assign was stored as an
additional field with each list of equivalent names?
    That would allow "key ring" to be sorted correctly, as long as it's
listed before either "key" or "ring", and "grimoire of firebolt" to be
sorted correctly as long as "grimoire" is listed before "bolt".  It would
also allow more common items to be listed first, and therefore matched
first, so less comparisons are needed.
    How complicated would that be to change?


>  I think a 40 mb ram machine (and anything slower than say a pentium 90) is
> below the officially supported goal.  Granted, it might be nice for it to still
> run on a sun 3 nicely, but I don't want to go through a lot of hoops to make
> that happen.

    The processor's an AMD K6-2 300, but expanding the memory at this point
would require retiring all my 60ns SIMMs and replacing them with PC-100
DIMMs, which I can't afford.  The reason I suddenly have so much time for
Crossfire is that I'm currently "between projects." (Read: unemployed.) 
Anybody know any gaming companies that need a programmer?


>  Removing portals may not be that easy.
[...]
>  This may not seem like a big deal - to me, it is more a style/programming
> cleanliness issue.  IF an object needs to do something, lets try to store all
> that information in the object itself, and not add pointers to maps or other
> areas to track that.  This will generally result in cleaner code and is also
> easier for other people to maintain.  The other benefit is that if the other
> areas (in this case, the map object) changes, those changes are more localized
> if they are not holding state for half a dozen different things.

    Agreed.  The solution I'm proposing is this:

1) When either Word of Recall or a first Portal are cast, they create two
matching invisible markers, with the player's name in their title field, and
drop one.

2) When Word of Return or a second Portal are cast, they get the map path
from the marker in the player's inventory.

3) If the map is an apartment belonging to that player, which is easily
determined from the path, it's okay.

4) If the map is in either memory or swap, then it's also okay.

5) If the map is okay, the space specified by the marker is searched for the
matching marker that was dropped.  If it's not there, the map must have been
reset and loaded back into memory, in which case the spell fails.

6) If the spell succeeds, 

 6a) For Word of Return, the marker in the player's inventory becomes a Word
of Recall object and starts counting down to teleport.  The other marker is
discarded.

 6b) For Portal, both markers are discarded and Enchantment objects are
created in their place, with an animation showing the portal opening, and an
exit in their inventory, so it's not functional until the enchantment is
complete.  If necessary, each map's timeout is incremented to at least the
tick after the portal closes and disappears, to keep the portals from
getting swapped out and then still being there when the map is swapped back
in.

    Does anyone see any problems with that? 

>  I agree that apartments should not be as super private as they are now.  The
> old apartment building did not have that problem, but had the other problem that
> all the apartments could get 'rented', leaving nothing for anyone else.  Also,
> apparantly with the huge amount of objects people were storing, it became a huge
> map to load, and would actually slow down the server to load that many objects.
[...]
> 
>  So maybe we should not worry about that issue as much, since the private map
> aspect is probably something that should also go away, just from a realism
> standpoint.

    Sounds like a good plan to me.

   One other factor I was wondering about is portals in allowing portals to
towns, even if the town map has reset.  I don't think there's any way to
cheat by teleporting to a town.  The only problem is, how do you tell from a
map's path whether or not it's a town?  I suppose there could be a short,
static list of the paths to towns.  That would also allow certain safe
places, like taverns and inns, to be put on the "teleport safe" list.  Would
that cause any problems or complications?

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

Disclaimer: SUNY Buffalo still won't officially admit to sharing my
opinions.
            Neither will U.C.L.A.  Imagine that.

Quote of the Day:
It does not do to leave a live dragon out of your calculations.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]