24 Nov, 2008, Tyche wrote in the 2nd comment:
Well I use this in Murk++, feel free to steal it or whatever else you need from it.
Of course the above is not a lexical correct version of stricmp|strcasecmp, which doesn't seem to matter for either Merc or ROM as it's not used for sorting in either codebase to my knowledge.
This would be a lexically correct replacement.
// Case insensitive compare
bool str_cmp(const std::string & s1, const std::string & s2)
{
if (s1.size() != s2.size())
return true;
std::string::const_iterator p1 = s1.begin(), p2 = s2.begin();
while(p1 != s1.end() && p2 != s2.end()) {
if(tolower(*p1) != tolower(*p2))
return true;
p1++;
p2++;
}
return false;
}
Of course the above is not a lexical correct version of stricmp|strcasecmp, which doesn't seem to matter for either Merc or ROM as it's not used for sorting in either codebase to my knowledge.
This would be a lexically correct replacement.
// Case insensitive compare
int str_cmp(const std::string & s1, const std::string & s2)
{
std::string::const_iterator p1 = s1.begin(), p2 = s2.begin();
while(p1 != s1.end() && p2 != s2.end()) {
if(tolower(*p1) != tolower(*p2))
return (tolower(*p1) < tolower(*p2)) ? -1 : 1;
p1++;
p2++;
}
if (s1.size() == s2.size())
return 0;
return (s1.size() < s2.size()) ? -1 : 1;
}
24 Nov, 2008, David Haley wrote in the 3rd comment:
Could the function pleasepleaseplease be called "stricmp" or "strcasecmp" or really about anything other than "str_cmp"? The name "str_cmp" is confusing and misleading, since it depends on your noticing the underscore to realize that something other than normal "strcmp" is happening, and the underscore is really not a very intuitive way of saying "case insensitive"…
25 Nov, 2008, kaervos wrote in the 4th comment:
I have just stumbled onto what you guys are doing, and I'm all about it. I've been hacking through a variety of mud codebases in the past week, and nothing makes me feel at home like ROM. That being said, ROM does need much done, as you are aware.
I'm a veteran programmer, have run a few muds… I don't think I need much more background aside from saying that I can be a resource for this project, and would love to see progress made. This is the only active ROM development happening anywhere in the world as far as I can tell.
Anyway, I'll be at your next meeting.
Cheers.
I'm a veteran programmer, have run a few muds… I don't think I need much more background aside from saying that I can be a resource for this project, and would love to see progress made. This is the only active ROM development happening anywhere in the world as far as I can tell.
Anyway, I'll be at your next meeting.
Cheers.
26 Nov, 2008, kaervos wrote in the 5th comment:
Hey guys, I checked out the Ice and Fire projects from your SVN repository. I really like everything I see so far. The logs are much more readable.
I happened to notice you changed 'detect invis' in the skill table to 'detect invisibility', and it was causing problems with some areas. Is a semantic change like that worth breaking areas? If so, you can:
sed "s/'detect invis'/'detect invisibility'/g"
For all your area files. I wouldn't think this worth it though. Not preaching, just suggesting. ;)
I'm excited about Fire. When we meet this Sunday, I'll be eager to plan the next attack to help move ROM to C++.
Just felt like chiming in.
I happened to notice you changed 'detect invis' in the skill table to 'detect invisibility', and it was causing problems with some areas. Is a semantic change like that worth breaking areas? If so, you can:
sed "s/'detect invis'/'detect invisibility'/g"
For all your area files. I wouldn't think this worth it though. Not preaching, just suggesting. ;)
I'm excited about Fire. When we meet this Sunday, I'll be eager to plan the next attack to help move ROM to C++.
Just felt like chiming in.
29 Nov, 2008, quixadhal wrote in the 6th comment:
Welcome aboard Kaervos!
At the moment, it's mostly me puttering around with this. Last week was unhappy-computer week, and this week has been holiday-running-around week, so I haven't gotten NEARLY as much done as I'd hoped. But, I started thinking about how I wanted the data structures to evolve, and in C++ that's half the battle.
Yes, I expect there are a bunch of typo-style bugs like the detect invis one. Personally, I can't stand the idea of using an abbreviated form of a name as the defined name, so I changed things like that wherever I could find them. If you *really* want to abbreviate, the search code can always use a prefix match (although it doesn't now because I don't like the way it ignores conflicts).
For area files…. well, we'll need to identify "stock" area kludges and silently change them on load (as well as in OLC when we get there). The entire area format will probably be a bit different once things settle down, but legacy support is always doable.
Mainly, you'll see the code has had a fair amount of face-lifting done to it. We decided we really wanted to make something people could pick up and modify without needing to spend 3 years trying to figure out what kind of black magic C trickery was used to make something work. I intend to continue that trend in the C++ version.
I'm hoping to get a few hours to sit down and finish my overview before the meeting, as I'd like to toss it around and see if people think it's a good way to plan things, and figure out a plan of attack. :)
At the moment, it's mostly me puttering around with this. Last week was unhappy-computer week, and this week has been holiday-running-around week, so I haven't gotten NEARLY as much done as I'd hoped. But, I started thinking about how I wanted the data structures to evolve, and in C++ that's half the battle.
Yes, I expect there are a bunch of typo-style bugs like the detect invis one. Personally, I can't stand the idea of using an abbreviated form of a name as the defined name, so I changed things like that wherever I could find them. If you *really* want to abbreviate, the search code can always use a prefix match (although it doesn't now because I don't like the way it ignores conflicts).
For area files…. well, we'll need to identify "stock" area kludges and silently change them on load (as well as in OLC when we get there). The entire area format will probably be a bit different once things settle down, but legacy support is always doable.
Mainly, you'll see the code has had a fair amount of face-lifting done to it. We decided we really wanted to make something people could pick up and modify without needing to spend 3 years trying to figure out what kind of black magic C trickery was used to make something work. I intend to continue that trend in the C++ version.
I'm hoping to get a few hours to sit down and finish my overview before the meeting, as I'd like to toss it around and see if people think it's a good way to plan things, and figure out a plan of attack. :)
I will endeavor to be more alert, have something useful for show and tell, and NOT have my hardware blow up so that next week's meeting will be somewhat more productive and/or entertaining!
to make Fire a true C++ game driver.
1 Replace all char *'s with std::string or a similar
shared string class. Initially std::string is
probably our best bet, since most shared string
classes will be drop-in replacements, more or less.
The sticking point is that we need a case INsensitive
compare function. Obviously, it's not hard to code
a version of strcasecmp() to take strings instead of
char *'s. It's ugly though. It would be nice to
have it an operator, but I don't see that being
possible since you won't ALWAYS want it to be
case insensitive.
2 Replace the room array with a std::map of either
int to room *, or maybe just int to room. The idea
is that we should be able to simply access the rooms
by vnum directly, not futz around with lookups.
Since rooms only have one instance of each vnum, a
map should work fine. Virtual rooms can be implemented
either in a seperate map, or perhaps a dyanmic counting
trick, like INT_MAX - vnum. Not a big deal, since they
aren't widely used in ROM.
3 Replace the mob and object arrays with std::map for the
prototypes, and std::multimap for the instances. There
should only be one prototype of each mob or object, but
there may be many instances. Changing an instance should
not affect the prototype. Changing a prototype might or
might not change the instances, I'm leaning towards not
since they will be changed on a reboot anyways.
4 Many of the list structures in ROM are cobbled up so the
pointers are embedded IN the objects. Bad practice. We
should instead allow the objects to be stored in multiple
containers (via pointers).
Just to show that I was online, although mostly AFK, here's a LOG!
18:51:47 # [200 Human IMP] Davion irrelivent.
18:51:47 #
18:51:47 # Players found: 2
19:00:04 #
19:00:04 # Asylumius has reconnected.
19:00:11 #
19:00:11 # Asylumius yawns.
19:14:56 # Quixadhal stretches and blinks.
19:24:04 # Quixadhal dozes off again.
19:46:51 # Quixadhal blinks and looks around.
19:46:54 # [200 Human IMP] Asylumius is AFK
19:46:54 # [200 Dwarf IMP] Quixadhal is taking a nice nap.
19:46:54 # [200 Human IMP] Davion irrelivent.
19:46:54 #
19:46:54 # Players found: 3
19:49:59 # You chuckle politely.
19:50:15 # You say 'Well, I figured it would be extra-quiet this week. :)'
19:50:50 # You say 'I will post my TODO list to the forums so folks can comment on how foolish or right I am, and offer ideas to make it work better!'
20:27:39 #
20:27:39 # Asylumius says 'I'm kinda here.'
20:27:42 #
20:27:42 # Asylumius says 'Unpacking from hunting.'
20:29:13 #
20:29:13 # Darva has entered the game.
20:32:27 #
20:46:27 # The sun slowly disappears in the west.
20:46:49 #
20:46:49 # Darva says 'someone needs to mark this room as indoors.'
20:47:00 #
20:47:00 # Darva grumbles and growls. You wonder what's wrong…
20:47:28 #
20:47:28 # The night has begun.
20:49:27 #
20:49:27 # Darva has left the game.
20:50:03 #
20:50:03 # Asylumius chuckles politely.
20:56:27 #
20:59:27 # The rain stopped.
21:01:43 #
21:01:43 # Asylumius sighs.
21:01:44 #
21:01:44 # Asylumius has left the game.
21:10:27 #