Sorry, old habits die hard. Replace hxxp by http. I'm not too fond of having my personal stuff ending up indexed and I don't trust robots.txt to be foolproof either. =)
This will require a special bigmap that uses a unique symbol for each sector type to be compatible with other clients. I tried doing the same thing in the past, and I found that zMUD has a pretty awful bug when using #sub on colored patterns.
http://forums.zuggsoft.com/forums/viewtopic.php?t=28582
Er, why does it need that? I just thought that if you had the "blue water" symbol you would replace that with something more "water-like".
As for the bug report, I do it differently, as I use style runs, and you don't search for ANSI codes in the first place.
Anyway, that bug seems related to the other one you reported.
It is possible the change I made here will correct that as a side-effect, and possibly not. I think it gets confused about the clipping region, and the update region.
If it is not corrected, I could probably make every screen draw draw the whole window, now that the flicker is gone. Let me know how 4.30 works for you.
Safari can’t open the specified address.
Safari can’t open “hxxp://qs.merseine.nu/images/mush_bug_drawing.png” because Mac OS X doesn’t recognize Internet addresses starting with “hxxp:”.
On the topic of fixing drawing glitches... (maybe I should make a new topic but hey >_>)
When you have relatively length scripts that do relatively much, you get a drawing glitch like in hxxp://qs.merseine.nu/images/mush_bug_drawing.png
The left image is while my plugin is loading, the right is as it is after loading. While this script shows the bug very exaggeratedly, I also get it in other cases. For example, when in a busy fight, my prompt occasionally looks 'double' like the date line in those screenshots. It can get pretty distracting. I found I can minimize it by making sure nothing is swapped out and having lots of RAM, but imo, it could still use some tweaking.
If 'fixing' it means a bigger penalty to speed, you could additionally make a 'fast draw' setting or some such to deal with that issue.
> A simple map of the standard characters to the improved ones would fix the translation, that part would be easy.
This will require a special bigmap that uses a unique symbol for each sector type to be compatible with other clients. I tried doing the same thing in the past, and I found that zMUD has a pretty awful bug when using #sub on colored patterns.
http://forums.zuggsoft.com/forums/viewtopic.php?t=28582
If the map does unique symbols and the font is customized anyway, then there's really no reason to do any processing in the client. I think it'd be better to use a font that already has the symbols in the right places.
Now if you wanted to get *really* fancy you would find a nice font that had trees, water, er ... caves, mountains and so on, so the map looks more realistic.
A simple map of the standard characters to the improved ones would fix the translation, that part would be easy.
Yes, well the plugin started out as a test of the flicker, but seems to have grown into something almost useable in its own right.
The latest version caches each continent in memory, and uses the "save state" functionality of plugins to remember that for next time.
Now it will only need to do "bigmap" the first time you ever visit a continent. We still need to get rid of that star that appears when you first do it, but I think a server change will achieve that.
A bit more tweaking, to allow for changes to continents (eg. some alias), and perhaps resizing the window to exactly hold the map, and it is about done. :-)
Yeah, I have a habit of finalizing notes before I'm actually done with them. I wish there were a way to go back and edit. Anyway, what I mean is...
The part that looks like:
if old_continent ~= continent then
Send "bigmap" -- grab map
old_continent = continent
end -- need big map
Needs to not do that. Instead it needs to pull the map from internal storage. The stored maps should get updated with "bigmap" only when a special update routine is used, and that update routine would only need to be used when a continent actually changes like when a new area goes in. There's no good reason to use "bigmap" if the continent doesn't look any different than the last time you were there, and there are a few good reasons to not do it.
In my version I just store each map as a text file in the mud directory.
Oh, by the way. The map data needs to be stored to the local computer and then accessed from there, so that bigmap is only required when the continent actually changes appearance.
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.