Mudlet Mapper, help marking visited rooms
Mudlet Mapper, help marking visited rooms
For personal purposes, I'd like to mark rooms I've already visited by changing the colour of the blocks, but I can't figure out how to make it happen. Any ideas?
Re: Mudlet Mapper, help marking visited rooms
To change the colour of the block would mean to change its environment. If that's okay with you, see functions at http://wiki.mudlet.org/w/Manual:Mapper_Functions that mention the environment - in particular, http://wiki.mudlet.org/w/Manual:Mapper_ ... setRoomEnv changes it.
Re: Mudlet Mapper, help marking visited rooms
Actually, I found the solution in highlighting the rooms, which worked, at least temporarily.
For a return isPrompt() trigger, I just put in
For a return isPrompt() trigger, I just put in
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Mudlet Mapper, help marking visited rooms
Do yourself a favour and keep track of the rooms that you have highlighted (say in a table) - it is much faster to unhighlight them if you have a list rather than having to go through each room and turn it off in all of them (there is not a way to recall that a room is highlighted after using setting it IIRC.
I have a doSpeedWalk() (it has to be called that!) function in my test profile that gets called when a speed walk is initiated from the mapper - this calls another script to grab the contents of the speedWalkPath,speedWalkDir and recently coded speedWalkWeight table and (after deleting an old path) shows the path selected and displays the weight for each step - but as those tables get updated when a new path is found it is much better to keep track of this... For the record I was using this to investigate the behaviour of the route finding code - and there are some oddities there! The A* code we use stops when it finds a route but, particularly if the map coordinates used in the map do not accurately represent the positions to each other and to the goal this throws off the h(n), heuristic function so that this is not necessarily the optimum route, just the first it finds...!
I have a doSpeedWalk() (it has to be called that!) function in my test profile that gets called when a speed walk is initiated from the mapper - this calls another script to grab the contents of the speedWalkPath,speedWalkDir and recently coded speedWalkWeight table and (after deleting an old path) shows the path selected and displays the weight for each step - but as those tables get updated when a new path is found it is much better to keep track of this... For the record I was using this to investigate the behaviour of the route finding code - and there are some oddities there! The A* code we use stops when it finds a route but, particularly if the map coordinates used in the map do not accurately represent the positions to each other and to the goal this throws off the h(n), heuristic function so that this is not necessarily the optimum route, just the first it finds...!