Re: CF: Dup'ing items

["Mark Wedel" <mark@icp.siemens.com>]

>
> Not really --- most maps aren't that big, and most maps allow players
> to go back to the previous map (so players can do intermediate saves).

 True.  But there are some fairly big maps out there in which you could easily
spend a lot of time on one map.  And I don't really like the idea of having to
think about heading to some certainly place (or exiting hte map or whatever
else) to make sure I am saved.



> A character sitting in some treasure room, waiting for the map to
> reset again and again will never be a reasonably good character.
>
> Crashing the server works better, and hurts other players as well; so
> that's the prime thing to work at instead of trying to make things
> more annoying for players.

 Agree on both counts.  I was just pointing out one of the shortfalls of the
current save method - in theory you could get repeat treasure.  Whether it is
really worth it is hard to say.


> Indeed. However, the autosave could be improved by one little detail
> --- don't save if the player is standing on "unholy ground", try again
> after he has moved (or in 10 seconds, or whatever).

 Thats not a bad idea and easy to do.  I'll see about adding it in.

>
> Another improvement would be to somehow enable players to "peek" into
> the map they will arrive in --- so they know whether the map has reset
> at the crash and whether the location is safe. Sometimes I'm asked to
> clean out a map because somebody might arrive inside there, but the
> character then arrives in a safe place. Or people log in, find that
> they are in big trouble, disconnect and ask for help. Or die :-(

 Adding a peak gets a bit more complicated, as that puts the player in 'limbo',
which I don't know how well supported that would be (the map draw routines
might not be happy with a player not having a map).  This may be more possiblei
n the future if the moving between maps get cleaned up some (so we can put the
player into limbo while loading the new map for example).

>
> Maybe do it like this: if the current location is at a bed to reality,
> log in. If it isn't, and the save file was created because of a disconnect
> (-> add a flag to the savefile) log in. If the savefile is an autosave
> file it means the server has crashed: show the map as if the player was
> logged in (i.e. not the dm visibility we have right now), mark the
> spot, and ask whether he wants to log in. If he doesn't then return
> him to the city.
>
> Sure, that's quite different from the weird ideas discussed here, but
> that's one of the improvements I have been missing for quite some time.

 In reality, the autosaves and disconnects should probably be treated fairly
similarly (however that might be.)  for example, if it is bad for a
disconnected player to rejoin the game in the middle of a room full of
monsters, it is also bad for an autosave character to rejoin the game there.
 Right now I believe there is an option to do backup save at home, which sort
of fixes that problem.  But a similar strategy for both autosave and disconnect
could be done (if map has been reset/reload since player left, put them back at
some safe location, otherwise let them go forward.)

 I have also thought about sort of doing a backing store for the temp maps -
that is, the only time the temp map gets deleted is when it resets or is
resaved, otherwise when the temp map is loaded, we still keep the copy on the
disk.  So if you do return, the old temp map is still there.

 The problem here is that this opens up item duplication again - but in this
case, only if you can crash the server (ie, you drop some items, exit map,
swaps out to disk, you go in, grab items, crash server.  When you log back in,
it pulls up the temp map again that also has your items saved to disk.)

 However, I suppose keepign the temp maps as above is only useful because the
server does crash, so if it is put in, the only real purpose would be to
duplicate items.


-- 

-- Mark Wedel
mark@pyramid.com
-
[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]