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

[Mark Wedel <mwedel@scruznet.com>]

David Andrew Michael Noelle wrote:
> 

>     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!

 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 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.

 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.

 Likely there will be some streamlining done in the future - objects will be
stored on a map basis, and not global linked lists like they are now - that
makes loading, saving, and processing maps faster.

 Insertions in player inventory, on the server side, should be constant speed,
since all new items get put at the head of the inventory, so only a few pointers
need to get updated.  It is very possible the client is not as optimized as
efficiently.


>     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.

 Removing portals may not be that easy.

 Suppose you have this case:
 1) Player creates portal on some map he is on.
 2) Player leaves that map.  That map is inactive, so is swapped out to disk (As
a temp map)
 3) Player leaves the game.

 IF we don't save the portals out in step #2, then portals are only good for as
long as the map remains in memory, which may not be long (a couple minutes).  If
we do save it is #2, then when the player leaves the game, we need to reload
that map so we can then remove the portal.  You could arguable store the portal
information in the area that contains that the map is swapped out (which is then
lost if the server crashes/is restarted), but I don't like that solution.

 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.



>     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 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.

 I think that later (old apartment style) is the more realistic method to go. 
IT has an interesting affect that if you do play with permadeath and you find a
players body, you could get his key and access his aparatment.  Right now, the
apartments are truly private, so in no way can another gain access.

 There are ways this could be done - instead of the apartment contents actually
being on the common map, just have exits that lead to private rooms - in that
way, each map would be small and quick to load.  You could also create a map
with 100 of these exits (or more - like a 5 story block with 100 each or
something), which would probably provide enough apartements.

 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.

Doug wilder wrote:

> I suggest this; (i don't know if its possible with coding) that the lower
> level dungeons reset at higher rates than the higher level ones. i believe
> right now that when the game resets it resets everything at once.

 This is more or less possible right now.

 Maps get reset as determined by their reset value - this can be set uniquely on
all maps, or you can use the default in config.h (if not set on the map or the
like).  There is also some other control on this - the default behaviour is that
a map can not have been accessed in that time period (usually 2 hours) for it to
reset - if another player wanders accross it, the reset time is put off for 2
more hours, and so on.

 There is an alternative, which is used for the shops, that says the map resets
after some time period after its initial loading, no matter when it was last
accessed.  This creates a worse case scenario in that a player could leave a
shop, it hits its reset time, and the player wanders back in a couple minutes
later, and it is all reset.

 Anyways, the point is that the above feature can be done right now.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]