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