[CF-Devel] Suggestion: map flag for town portal

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Sun Feb 22 18:57:39 CST 2004


tchize wrote:

>
     
     
     >
     
      I think you misunderstood problem. Already work that way (using the 2 way exit 
     
     >
     
      subtype)
     
     
  Thanks for the explanation.  snipping most of it.


>
     
      Players using town portal to get access again and again to treasures rooms use 
     
     >
     
      the following trick.
     
     >
     
     
     >
     
       1 access the map in a 'classical way'
     
     >
     
       2 make the first step of portal casting (the step memorizing location)
     
     >
     
       3 get back to town by any mean (eg word of recall) when treasure room is 
     
     >
     
      emptied
     
     >
     
       4 wait for map reset
     
     >
     
       5 cast second part of portal
     
     >
     
       6 access treasure room using portal
     
     >
     
       7 in treasure room , cast first part of portal
     
     >
     
       8 get back to town with treasures and wait reset
     
     >
     
       9 cast second part of portal to regains access to treasures
     
     >
     
       - and so on.
     
     >
     
     
     >
     
      So, as i see from discussions, ways to prevent this trickery may be one of the 
     
     >
     
      followings (between brackets are the steps of trickery blocked) 
     
     >
     
       - flag treasure map to prevent town portals spell(bad imo) [2,7]
     
     >
     
       - flag treasure map to prevent portals pair creation if map has been reset  
     
     >
     
      (better, but lots of work to identify and flag all those maps)[5,9]
     
     
  Flagging maps is always difficult - just as you say, because it can be 
difficult to identify all those maps.

  In addition, that may not always solve the problem - a player may still be 
able to save themselves a lot of the work by doing the town portal on the map 
right before the treasure/final map.

>
     
       - in any map, prevent portals pair creation if map has been reset (best imo)
     
     >
     
      [5,9]
     
     
  This is probably best.  But does have some issues.

  IT is easy enough to add some code to portal creation to know if the map is 
being loaded into memory for the first time (Effectively, a reset) or if it has 
been swapped out.

  But do we care about the case of player is on treasure map, casts one side of 
the town portal, returns to town via other means (word of recall).  Map then 
resets, but it is reloaded for some other reason (some other player visiting the 
map for example) - player could then town portal in.

  This could be very nasty if that person doing the town portal is just waiting 
for that event (watching the 'maps command for example).  The town portal player 
could basically screw over another play by portaling in, and stealing the 
treasure before the other player gets a chance to do so.

  There are some thoughts to maybe prevent this - the most notably putting a 
real time limit on how long you can remember your previous portal location.

  One could express this simply in ticks (eg, the spell last 50,000 ticks, or 
roughly 1.5 hours, before it goes away).  However, that doesn't help out the 
case where the player logs in, portals to the treasure, returns home, and logs 
out, and repeats the next day.

  So the better solution is then to actually store that in terms of real time 
(time() call) - this would actually be relatively simple - when player casts the 
first side of the spell, store in some value of the force field the current time 
+ the reset time from the map.  Then when the player casts again, compare that 
value against the current time - if that value is in the past, tell the player 
that they forgot the other location.

  That is foolproof and relatively simple.  Now there could be cases where the 
map does not reset as soon as expected (if people keep visiting hte map, it 
might never reset), but that's a different matter.



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list