I recently added in overland maps to my FotE based mud (thanks Samson for the snippet ). As usual I was using AFKmud (v1.8) as a reference (thanks again Samson et all ). Anyways, after I got most of the kinks worked out I decided to use AFK's style resets, since my mud uses the newer reset system anyways. So, I changed all the necessary stuffs but noticed something odd once I was done. If you are on a map, and you instaroom, only the resets for the coords you are at stayed. I don't know if it's really a bug or just a workaround for people who didn't want that to be the case. At any rate, I realized it was because when you instaroom, before the resets are added the code calls wipe_resets. Well when on a map, that isn't a good idea since you really are just in the same room. I checked 2.03 and couldn't find anything since I know 1.8 isn't being developed. I kinda threw togother a "fix" for 2.03.

Looks like a perfectly reasonable function. Generally speaking you might want to consider using algorithms rather than writing explicit loops, because it's less error prone, often more efficient and can make the code look clear and straight forward (and simply because I like them ). I'll first write a suggested version, then offer some brief explanation of what's going on.

The list.remove_if member function calls the predicate function in its argument for each element in the list (or operator() in the case of function objects). In this case we pass the conditions (map, x and y) to the constructor. If we didn't need to store these variables then we could have used a function instead of a function object.

We inherit from the std::unary_function template, because it creates some typedefS and such that are needed when using it with some STL algorithms, so it's generally a good habit to do it. You'll usually need to include the <functional> header for this.

My choice of name (CoordResetDeleter) is probably not the best. Try finding something that makes the line resets.remove_if( condition_is_fullfilled ) crystal clear to a human reader.

You can often reuse such predicate function classes in many different contexts, so it's definitely worth your time looking into it.

Oh, and a standard disclaimer, I've not tested the above code, may contain typos, etc etc.

Edit: of course with this solution you don't actually need the room_index::wipe_coord_resets member function, you can just call room->resets.remove_if directly in the client code. Unless the resets list is private, that is.