Strangely enough, I haven’t really used regular expressions until recently. They’re incredibly powerful. In fact, here’s one that replaces about 40 lines of C++ code with a single line of C#.NET code:
text = Regex.Replace(text, @”\e\[\d*;?\d+m”, “”);
It’s not absolutely perfect, but it does the trick for removing all of the ANSI color codes from a block of text.
I completed the last of the code for the command processing engine today. Not much detail to report — it’s done and seems to work well enough.
Command processing in the old Basternae was pretty klunky. The command interpreter would just pass on any text that was entered and each command function would have to do a lot of parsing to split up the command strings and figure out what the user actually intended. About half of each command would be devoted just to breaking up strings in some cases.
Luckily with .Net we have all these nice string functions — Split, Join, Substring, IndexOf, Remove, and many more.
With the new command processing engine I’ve just written the command functions are a lot easier to read, maintain, and create more of.
Of course, I’ve had to redo every command in the process and that’s only 80% done so far, but it’s a far better system overall.
And, of course, I still have to finish the replacement spell system.
When writing a zone, it can be tough to know where to end your lines of text.
While a standard terminal has 80 characters, some telnet programs start to look weird with any line that is more than 77 characters, and some terminals have 130 or more characters per line (usually depends on screen resolution).
With different zone writers writing descriptions with varying line lengths it can make the MUD look pretty inconsistent from zone to zone.
That’s why I wrote an auto-wrapping function that takes care of all of that. It will take a description and insert line breaks as necessary. Right now it just defaults to a 78-character terminal width, but it will be user-configurable when I’m done with it.
This means that zone writers don’t have to worry about line breaks anymore. They can just type out their descriptions and it’ll be handled by the MUD.
Word wrapping still isn’t perfect, so I’ll need to work on that a little, but it’s pretty neat to have autowrapping in place now.
The text visualizer in Visual Studio 2005 isn’t very good. When you’re looking at a string in the debugger, you won’t see what you’re looking for if there are any null characters in the string. As far as I can tell this is a holdover from the bad old days when null-terminated C strings were the norm.
This is a pain in the butt if you are dealing with data stored in a System.String. I regularly work with data that needs to be viewed in hexadecimal format. That’s why I created the hex string visualizer, thanks to THIS POST by 4 Guys From Rolla, which is a mighty fine tutorial on creating visualizer plugins.
Here’s what the not-so-informative text visualizer looks like:
Here’s what my hex string visualizer looks like:
I’ll leave it as an exercise to the reader to figure out which one gives better debugging info.
This is more useful in my day job as a home automation programmer, but it will also come in handy when it comes to debugging low-level communications in the MUD.
It’s available HERE if you want a copy. Just drop it in your My Documents\Visual Studio 2005\Visualizers directory and it’ll be available in the list of string visualizers next time you run Visual Studio 2005.
I’m still working on converting char * strings to std::string strings. Here’s the recent progress:
|
Reference |
5-27-07 |
5-29-07 |
6-1-07 |
6-4-07 |
6-10-07 |
6-15-07 |
|
strncat |
772 |
723 |
641 |
605 |
606 |
581 |
|
snprintf |
1199 |
1166 |
1096 |
1079 |
1064 |
1032 |
|
const char * |
343 |
287 |
317 |
330 |
341 |
330 |
|
MAX_STRING_LENGTH |
2404 |
2313 |
2062 |
2011 |
2000 |
1955 |
|
MAX_INPUT_LENGTH |
471 |
446 |
153 |
153 |
142 |
108 |
Since 5/27 we’ve gone from about 5200 references down to 4000. There’s still PLENTY to do.
Because of the way strings are handled, the number of references “to const char *” will fluctuate during the conversion and probably not decrease much until we’re nearly complete.
I’ve been using Visual Studio .Net 2003 for a long time. I’ve finally upgraded to 2005, and some of the changes are interesting.
One of the things I’ve been doing is converting a lot of the c-string functions to STL std::string. It turns out that the old string functions I’m gradually eliminating have been deprecated:
_snprintf: “This function or variable may be unsafe. Consider using _snprintf_s instead.”
strncat: “This function or variable may be unsafe. Consider using strncat_s instead.”
stricmp: “The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _stricmp”
fopen: “This function or variable may be unsafe. Consider using fopen_s instead.”
strncpy: “This function or variable may be unsafe. Considre using strncpy_s instead.”
I will gladly avoid using those functions. I hate them.
I’ve written new string functions based on std::string. They’re the typical case insensitive compare, check prefix, compare with list of names, get first argument, get last argument, and other string manipulation functions you’d normally see used with a MUD. The difference is: They’re not very prone to buffer overflows and pointer errors because they’re using std::string and it’s safer.
Not everything uses std::string natively yet – there’s still too much char * for my comfort.
Next tasks:
– Testing the string functions to see whether they work as I’d expect.
– Running the whole thing through valgrind to see whether I can catch any memory (stack-smashing) errors.
This new incarnation won’t be crashproof (software never is), but the goal is to have it never crash “randomly” like Basternae 2 did. I have a lot of good command tracing and error logging code and have written quite a bit more over the past few weeks, so if something explodes it should tell me exactly what and where.
Shared string management has been completely removed from the code. Gone. Done for.
The result: greater stability at the cost of higher memory requirements and a slight reduction in processor power requirements (which aren’t even a concern). The removal automagically fixed a few bugs due to the less-than-perfect shared string management.
Next task: Getting Thendar’s zones attached and loading. Some load code modifications will probably be needed.