[crossfire] Items that evolve all the time

[tchize at myrealbox.com]

Le Mercredi 27 Avril 2005 07:19, Mark Wedel a écrit :
>
     
        A few notes:
     
     >
     
     
     >
     
        Storing tick counts is not reliable.  If the server resets, tick count
     
     >
     
      restarts at zero I believe, so that value won't do any good.
     
     
Did not speak of storing tick count but measuring tick counts from the time 
since last map swap out or last time the overlay map saved.

>
     
     
     >
     
        The last_ values, are I believe, used only when the object is in memory. 
     
     >
     
      This is used to refine things like regeneration times (eg, you don't want a
     
     >
     
      character to get a hp back every tick they go, so last_heal is decremented
     
     >
     
      each time the player gets an action, and if zero, player gets a hp, and
     
     >
     
      last_heal is set to the regen rate).
     
     
They all are restored at reaload. Whas i was suggesting is to modify those 
value like if n server ticks did happens, n being calculed from the last map 
save. I already used to prefill such fields in a map so to desynchonize all 
animations (i gave this way to items a random number of moves to do at load 
time and so the animation of various items did get a random desync with 
neighbors items. Was used for a lava like ground).

>
     
     
     >
     
        Similar oddness is used for monster regeneration.  However, monsters
     
     >
     
      don't get HP back when the map is swapped out.  This has long been a known
     
     >
     
      fact, and often used by experienced player (if the time it takes you to
     
     >
     
      heal is greater than map swapout time, then it doesn't matter how long it
     
     >
     
      takes you to heal).
     
     >
     
     
     >
     
        The only way I can see for the object to survive map resets is to either
     
     >
     
      store it on the overlay map, like weather, or make it unique, so it gets
     
     >
     
      stored on the unique object maps.
     
     
I opt for a general overlay system, as the unique object is, well, some kind 
of unique system. This way you can easily process with such pseudo alogrithm:

load:
- if no overlay-map exist, load the map from share/
- else
      - load map from share but drop any persistent thingie (add a 
is_persistent tag to object?)
     - load the overlay-thingie
save:
simply save non persistent thiniges in swap and persistent ones in overlay

>
     
     
     >
     
        So the next step is know how long since last activated - the best way is
     
     >
     
      to store the results of time() into the object.  If the object is in
     
     >
     
      memory, let the normal speed processing do its logic.  Add some flag so
     
     >
     
      that when it is saved, the time() value is automatically stored into some
     
     >
     
      field.  Then at load time, you can at least know how long the object has
     
     >
     
      been inactive.  Probably need to add something in ready_map_map() that
     
     >
     
      processes these object (fix_auto_apply is only called when a map is reset,
     
     >
     
      not when swapped back in.)
     
     
Objects don't need to get the time. The time is the same for whole map being 
loaded, that's why this informations should be map related.

>
     
     
     >
     
        In terms of processing, it'd make the processing more smart.  Eg, if hte
     
     >
     
      object has been out of memory for 5000 seconds, instead of calling process
     
     >
     
      object that many times for that object, make it more clever - figure out
     
     >
     
      what it would have done in that time (eg, produced 30 apples, died off,
     
     >
     
      whatever).  That will make processing then not very costly at load time.
     
     >
     
     
     
i don't think processing would be that costy. If you assume something like 
'30' apple, the problem is , well, if someone picked up all apple before last 
swap out, all tree would have same number of apple. But  we can do something 
like move(object,missedturns) be smart and do a general probability, like 
saying ok, produce between 20 and 40 apples.


>
     
        If that isn't possible (because object may go through bunches of states),
     
     >
     
      then doing it more like weather code probably makes sense.
     
     >
     
     
     
That mean do the move of object on idle times, objects which perhaps will 
never be used again because of map reset.

Please note i'd like to dissociate problem of object needing to get turns 
while not in memory and proble of objects needing to survive map resets;
Sure growables will have both caracteristics. But There could be non growables 
needing turns when out of memory like there could be non growables needing to 
stay persistent, while we don't want the map it is in to be permanent. 
Perhaps if such a generic overlay make his way in code, it must be used by 
weather too.

>
     
      _______________________________________________
     
     >
     
      crossfire mailing list
     
     >
     
     
      crossfire at metalforge.org
      
      
     >
     
     
      http://mailman.metalforge.org/mailman/listinfo/crossfire
      
      
     
-- 
David Delbecq
Royal Meteorological Institute of Belgium