02 Dec, 2008, quixadhal wrote in the 2nd comment:
02 Dec, 2008, quixadhal wrote in the 3rd comment:
And, HERE is a link to Lope's 2.0 color code.
I apologize if these files are already in MudBytes somewhere, but the common names they go by are "Ivan's OLC" and "Lope's Color", which don't show up via search, so unless I already had them once, I couldn't guess the filenames.
I apologize if these files are already in MudBytes somewhere, but the common names they go by are "Ivan's OLC" and "Lope's Color", which don't show up via search, so unless I already had them once, I couldn't guess the filenames.
03 Dec, 2008, kaervos wrote in the 4th comment:
Alright, so this week I will get a vanilla Rom 2.4b6 distribution patched up with Ivan's OLC 1.81 and Lope's Color, along with the basic fixes to get it to compile (incomplete types, etc). Are there any other stock ROM mods that we may want to implement? I got the feeling from reading the forums here that the board code snippet isn't splendid… but better than stock. Should we get this in as well? Any snippets we think should be RaM "stock" should get in sooner rather than later.
Anything else that might not be in the form of snippets floating about the internet, but is a definite improvement and would be rather simple to implement (small scale and wouldn't benefit from object orientation)?
Once that is done and we have something comparable to QuickMUD as a base (sans licenses and bugs), we'll get the previous ROM->RaM changes implemented. I'm happy to get involved there as well, I love 'diff'. Once we have all that done, we can consider adding new editors for the OLC and/or dive into the C++ redesign.
I'll keep it in mind this week, and see if maybe I get some time to sketch up some design ideas for various parts of ROM. Although we didn't come to a definite conclusion in the meeting, I think if we are going to move into C++, we should do it *right*… meaning a redesign of applicable ROM systems. The urge to search, replace, and make immediate progress is great… but having a well laid out object oriented version of ROM would be just too fantastic not to strive for.
Let me know what you think, especially regarding the stock mods.
Anything else that might not be in the form of snippets floating about the internet, but is a definite improvement and would be rather simple to implement (small scale and wouldn't benefit from object orientation)?
Once that is done and we have something comparable to QuickMUD as a base (sans licenses and bugs), we'll get the previous ROM->RaM changes implemented. I'm happy to get involved there as well, I love 'diff'. Once we have all that done, we can consider adding new editors for the OLC and/or dive into the C++ redesign.
I'll keep it in mind this week, and see if maybe I get some time to sketch up some design ideas for various parts of ROM. Although we didn't come to a definite conclusion in the meeting, I think if we are going to move into C++, we should do it *right*… meaning a redesign of applicable ROM systems. The urge to search, replace, and make immediate progress is great… but having a well laid out object oriented version of ROM would be just too fantastic not to strive for.
Let me know what you think, especially regarding the stock mods.
03 Dec, 2008, kaervos wrote in the 5th comment:
Alright, the OLC 1.81 patch works like butter. Lope's color patch on the other hand… I don't think would EVER work flawlessly on any ROM version. There was stuff in there that was blatantly wrong.
Anyway, I manually edited the patch (fun, fun!) so it will work flawlessly against Rom2.4b6 after applying Ivan's OLC 1.81 patch. I would like to include it here for others, but I don't see any options for attaching files.
I somewhat disagree with the escape character Lope chose (left brace) as it interferes with TinTin++'s command interpreter. There must be a better choice, such as ^ or `.
So we have a vanilla Rom2.4b6 with Ivan's OLC 1.81 and Lope's Color 2.0…
Anyway, I manually edited the patch (fun, fun!) so it will work flawlessly against Rom2.4b6 after applying Ivan's OLC 1.81 patch. I would like to include it here for others, but I don't see any options for attaching files.
I somewhat disagree with the escape character Lope chose (left brace) as it interferes with TinTin++'s command interpreter. There must be a better choice, such as ^ or `.
So we have a vanilla Rom2.4b6 with Ivan's OLC 1.81 and Lope's Color 2.0…
03 Dec, 2008, quixadhal wrote in the 6th comment:
Personally, I prefer the SMAUG color codes, but as the logs of our first meeting show, no matter what kind of system you dream up, SOMEONE will have a problem with it. :)
As this *IS* a ROM project, we need to stick to the ROM de-facto standards as much as possible, unless there's a good reason to change them.
I hope you enjoy playing with diff… re-applying many of my changes won't be simple, as there are a HUGE number of changes to syntax and formatting, let alone my moving files around and fixing bugs as I went.
If I get some more time, I might try the reverse, of patching IN OLC and color, although that won't be a happy fun time either. Ve zhall zee!
As this *IS* a ROM project, we need to stick to the ROM de-facto standards as much as possible, unless there's a good reason to change them.
I hope you enjoy playing with diff… re-applying many of my changes won't be simple, as there are a HUGE number of changes to syntax and formatting, let alone my moving files around and fixing bugs as I went.
If I get some more time, I might try the reverse, of patching IN OLC and color, although that won't be a happy fun time either. Ve zhall zee!
04 Dec, 2008, kaervos wrote in the 7th comment:
Haha, I generated a patch between RaM Fire and stock Rom2.4b6 with "diff -Nau"… the patch file is 81650 lines long! I would say I slightly underestimated the volume of changes made. =P
Looking at this, I think it may be easier to try to patch RaM with OLC and ColoUr…
I'll play around a bit and see how obscene of a task it would be to make this patch work with the vanilla Rom I have. I'm not going to hold my breath.
Looking at this, I think it may be easier to try to patch RaM with OLC and ColoUr…
I'll play around a bit and see how obscene of a task it would be to make this patch work with the vanilla Rom I have. I'm not going to hold my breath.
04 Dec, 2008, kaervos wrote in the 8th comment:
Definitely stuck between a rock and a hard place here. The OLC patch is pretty beastly, although it is no match for the 2.4 MB Fire patch of doom.
Instead of milling about, I'll work on manually editing the OLC patch to work with RaM Fire. It will be a few days. The ColoUr patch will seem like a cakewalk after that. I'll let you know how things progress….
Instead of milling about, I'll work on manually editing the OLC patch to work with RaM Fire. It will be a few days. The ColoUr patch will seem like a cakewalk after that. I'll let you know how things progress….
04 Dec, 2008, quixadhal wrote in the 9th comment:
Hehehe… if you *really* wanted to try using diff, I'd suggest doing diffs of each version of RaM and baby-stepping them. Yes, there were a LOT of changes *grin*
svn log and svn diff (using -rX:Y for revisions) would be useful there. I should also note that the repository online doesn't go ALL the way back to ROM standard. It starts about 12 revisions up (I was doing this on my own repository originally, until we got the public one working, and that started from the first "cleaned up" version).
svn log and svn diff (using -rX:Y for revisions) would be useful there. I should also note that the repository online doesn't go ALL the way back to ROM standard. It starts about 12 revisions up (I was doing this on my own repository originally, until we got the public one working, and that started from the first "cleaned up" version).
04 Dec, 2008, David Haley wrote in the 10th comment:
What would happen if you checked out the initial version, applied the patches, and then merged in the rest of the repository? Obviously there'd be conflicts wherever you had to edit and Quix did something, but at least you'd get the changes in.
04 Dec, 2008, quixadhal wrote in the 11th comment:
There's no silver bullet for branch merging, I'm afraid.
At some point, the grunt work has to be done. If you applied the diffs to an versioned checkout and then tried to commit, you'd find one of two things happening…. (a) you'd screw up the flags and end up replacing the "current" version with what you have – thus not merging at all, or (b), the svn system would force you to edit every file with conflicts before accepting it. For this code, that would be every file. :)
The typical way you use branches is that you decide you want to try something, so you make a branch via the copy command, then you start working on your branch…. and you constantly do svn updates to merge in changes from the main trunk to your working copy, thus making sure the change set stays small.
If you branch and stay in your own world for a month, and then try to merge back in, you'll typically so many conflicts to resolve that it's almost not worth it.
Of course, after development settles down a bit, there are usually not such broad, sweeping, changes to the entire codebase. In this case, you'd be fighting against a massive change for indent, another massive change to reogranize where code lives, and a third massive change for the const char fixes, and probably a fourth one where I swept through and initialized all the variables. Those ALL touched a majority of the files, and thus would conflict with almost anything.
That's one reason distributing snippets as diffs is evil. They only apply cleanly to "stock" games, and who out there runs a stock game that only uses 1 or 2 snippets?
At some point, the grunt work has to be done. If you applied the diffs to an versioned checkout and then tried to commit, you'd find one of two things happening…. (a) you'd screw up the flags and end up replacing the "current" version with what you have – thus not merging at all, or (b), the svn system would force you to edit every file with conflicts before accepting it. For this code, that would be every file. :)
The typical way you use branches is that you decide you want to try something, so you make a branch via the copy command, then you start working on your branch…. and you constantly do svn updates to merge in changes from the main trunk to your working copy, thus making sure the change set stays small.
If you branch and stay in your own world for a month, and then try to merge back in, you'll typically so many conflicts to resolve that it's almost not worth it.
Of course, after development settles down a bit, there are usually not such broad, sweeping, changes to the entire codebase. In this case, you'd be fighting against a massive change for indent, another massive change to reogranize where code lives, and a third massive change for the const char fixes, and probably a fourth one where I swept through and initialized all the variables. Those ALL touched a majority of the files, and thus would conflict with almost anything.
That's one reason distributing snippets as diffs is evil. They only apply cleanly to "stock" games, and who out there runs a stock game that only uses 1 or 2 snippets?
04 Dec, 2008, Littlehorn wrote in the 12th comment:
Not to sure what you guys are doing so forgive the text if it seems ignorance to your project.
I saw from the log that you were looking at QuickMUD and C++ bases. QuickMUD is good and it's very stable. I always use it for the stock base on all my projects. But I wanted to speak on RogueMUD here being the newer builds have been converted to C++. Here are some of it's features:
// -Credits for misc patches and addons.
1) OLC ver1.7 Added (Credit goes to Ivan Toledo).
2) Lope's Colour ver1.2 Added, Modified Slightly.
3) HEdit for OLC by Kermit (rom.are, olc.hlp, group.are put into help.are)
4) Copyover by Erwin S. Andreasen, thank you for the ROM patch ;)
5) AUTODAMAGE by Sean Cohmer, I had to modify it however (buggy).
6) Drunken Speach - Maniac
7) AutoMap taken from Ack! codebase - ACK! Consortium.
8) Pload/Punload - ??
9) SEdit added (social editor) by Erwin S. Andreasen
10) Boards 2 by Erwin S. Andreasen (~feh)
5) GEdit (Clan Edit), lets you edit clans online!
178) Converted code to C++ and debugged all but alloc_mem/free_mem.
(ANSI C++ forbids using 'void *' pointer type in arithmetic)
186) Added mountable vehicles and driveable vehicles and added to OLC.
213) Created a "pedit" for editing pmusic songs online (no more static struct)
220) MCCP, MXP and MSP for zMUD 6.0+ working now (MXP also for MUSHClient)
222) Fixed *THE* major memory leak found in OLC 1.7 new_reset_data
228) Added in new D&D 3rd Edition style classes (might want to remove)
240) Added new 3rd Ed tables for starting ages, weights, and heights. (might want to remove)
Features I like is the automapper, skill edit, social edit, ability group edits, stability, C++, have only 4 areas, lots of backend enhancements for mud growth, very little systems to rip out (I ripped most of the D&D 3rd edition systems and converted the spaceship system into horse mounts).
Anyways, assuming you're doing another directive on your own and I think Rogue is free to use for that if you're looking for a good base to start from!
I saw from the log that you were looking at QuickMUD and C++ bases. QuickMUD is good and it's very stable. I always use it for the stock base on all my projects. But I wanted to speak on RogueMUD here being the newer builds have been converted to C++. Here are some of it's features:
// -Credits for misc patches and addons.
1) OLC ver1.7 Added (Credit goes to Ivan Toledo).
2) Lope's Colour ver1.2 Added, Modified Slightly.
3) HEdit for OLC by Kermit (rom.are, olc.hlp, group.are put into help.are)
4) Copyover by Erwin S. Andreasen, thank you for the ROM patch ;)
5) AUTODAMAGE by Sean Cohmer, I had to modify it however (buggy).
6) Drunken Speach - Maniac
7) AutoMap taken from Ack! codebase - ACK! Consortium.
8) Pload/Punload - ??
9) SEdit added (social editor) by Erwin S. Andreasen
10) Boards 2 by Erwin S. Andreasen (~feh)
5) GEdit (Clan Edit), lets you edit clans online!
178) Converted code to C++ and debugged all but alloc_mem/free_mem.
(ANSI C++ forbids using 'void *' pointer type in arithmetic)
186) Added mountable vehicles and driveable vehicles and added to OLC.
213) Created a "pedit" for editing pmusic songs online (no more static struct)
220) MCCP, MXP and MSP for zMUD 6.0+ working now (MXP also for MUSHClient)
222) Fixed *THE* major memory leak found in OLC 1.7 new_reset_data
228) Added in new D&D 3rd Edition style classes (might want to remove)
240) Added new 3rd Ed tables for starting ages, weights, and heights. (might want to remove)
Features I like is the automapper, skill edit, social edit, ability group edits, stability, C++, have only 4 areas, lots of backend enhancements for mud growth, very little systems to rip out (I ripped most of the D&D 3rd edition systems and converted the spaceship system into horse mounts).
Anyways, assuming you're doing another directive on your own and I think Rogue is free to use for that if you're looking for a good base to start from!
05 Dec, 2008, quixadhal wrote in the 13th comment:
Hi Littlehorn!
Despite all the evidence to the contrary in the logs, we are actually a revival project. For whatever reasons, we want to shake the dust off the original ROM codebase and propel it into the modern era, while retaining the same look and feel that people who loved ROM really enjoy. With that in mind, we are only looking for improvements to the codebase that address problems (bugs, inefficiency, poor coding practices), add features that builders/admins can use to create their world (OLC, player/character management, etc), and so forth.
We were considering using QuickMUD because it appeared to be simply ROM with several popular addons already in place. In actuality, it also adds several races/classes and probably extends gameplay in a few other ways that aren't useful to someone who already has their own vision of a game, and wants a clean driver to start from.
In a nutshell, if you liked the feel of ROM, we want you to use our driver to create your own game – not to throw up on a port and run. Ideally, I'd like to ship with the standard 4 classes (fighter/mage/cleric/thief) and the 3 common fantasy races (human/elf/dwarf) and area files that serve as examples of an admin/immortal area, one or two variations on the "mud school" concept, and a tiny starting village, and nothing else. Again, the idea is to encourage people to make their own game, not throw up a cookie-cutter MUD.
Of course, at the same time, I realize many people like the ROM areas, and so we want to maintain compatibility to import them, and make it easy to add them back in. If you liked the smurf village, hey… who am I to take away your firing range? :)
I might well take a look at RogueMUD, as like Murk++, they've probably done some things with C++ I wouldn't have thought of. I am really a C++ n00b, as I'm old and learned to code with the dinosaurs of C, Pascal, and yes, even Assembly. I'm also curious how much of D&D 3rd edition is there… my dream is to make combat modular enough to easily replace it with your own mechanics. Of course, nobody has pulled that off yet…
Thanks for the input!
Despite all the evidence to the contrary in the logs, we are actually a revival project. For whatever reasons, we want to shake the dust off the original ROM codebase and propel it into the modern era, while retaining the same look and feel that people who loved ROM really enjoy. With that in mind, we are only looking for improvements to the codebase that address problems (bugs, inefficiency, poor coding practices), add features that builders/admins can use to create their world (OLC, player/character management, etc), and so forth.
We were considering using QuickMUD because it appeared to be simply ROM with several popular addons already in place. In actuality, it also adds several races/classes and probably extends gameplay in a few other ways that aren't useful to someone who already has their own vision of a game, and wants a clean driver to start from.
In a nutshell, if you liked the feel of ROM, we want you to use our driver to create your own game – not to throw up on a port and run. Ideally, I'd like to ship with the standard 4 classes (fighter/mage/cleric/thief) and the 3 common fantasy races (human/elf/dwarf) and area files that serve as examples of an admin/immortal area, one or two variations on the "mud school" concept, and a tiny starting village, and nothing else. Again, the idea is to encourage people to make their own game, not throw up a cookie-cutter MUD.
Of course, at the same time, I realize many people like the ROM areas, and so we want to maintain compatibility to import them, and make it easy to add them back in. If you liked the smurf village, hey… who am I to take away your firing range? :)
I might well take a look at RogueMUD, as like Murk++, they've probably done some things with C++ I wouldn't have thought of. I am really a C++ n00b, as I'm old and learned to code with the dinosaurs of C, Pascal, and yes, even Assembly. I'm also curious how much of D&D 3rd edition is there… my dream is to make combat modular enough to easily replace it with your own mechanics. Of course, nobody has pulled that off yet…
Thanks for the input!
05 Dec, 2008, quixadhal wrote in the 14th comment:
I started taking a look at Lope's colour patch, and I think the correct thing to do here is NOT mess around with trying to apply such a thing, but instead rewrite the routines so they work as filters.
Namely, we don't want separate versions of send_to_char, ch_printf, colour_send_to_char, ch_printf_colour, etc… nor do we want the same identical code cut and pasted into ch_printf, act_printf, page_printf, and whatever else I'm forgetting. We instead would like to have the thing called colourconv() actually work as a filter which the others can invoke.
I did a bunch of that in SmaugFUSS (actually in AFKMUD) a while back, and Lope's is also missing a few things that will become needed such as a proper colour-aware strlen (for use in formatting).
So, I think it boils down to making a few routines that do the job, which I will try to get to this weekend, and then adding the bits needed to the player load/save code so customized colours can be kept, and then going back and adding the colour codes to the various parts of the screen display where they'll be used.
I don't think we need or want EVERYTHING to be colourized… no rainbows!
This goes hand-in-hand with my desire to change the channel system a bit so that ALL game output of any kind is routed through a channel interface, which would give the users the ability to enable/disable any type of output at will, and allow all output to be MXP tagged for proper client identification later on. Of course the default channel does nothing but pass the text along, so it's transparent.
More later. :)
Namely, we don't want separate versions of send_to_char, ch_printf, colour_send_to_char, ch_printf_colour, etc… nor do we want the same identical code cut and pasted into ch_printf, act_printf, page_printf, and whatever else I'm forgetting. We instead would like to have the thing called colourconv() actually work as a filter which the others can invoke.
I did a bunch of that in SmaugFUSS (actually in AFKMUD) a while back, and Lope's is also missing a few things that will become needed such as a proper colour-aware strlen (for use in formatting).
So, I think it boils down to making a few routines that do the job, which I will try to get to this weekend, and then adding the bits needed to the player load/save code so customized colours can be kept, and then going back and adding the colour codes to the various parts of the screen display where they'll be used.
I don't think we need or want EVERYTHING to be colourized… no rainbows!
This goes hand-in-hand with my desire to change the channel system a bit so that ALL game output of any kind is routed through a channel interface, which would give the users the ability to enable/disable any type of output at will, and allow all output to be MXP tagged for proper client identification later on. Of course the default channel does nothing but pass the text along, so it's transparent.
More later. :)
05 Dec, 2008, kaervos wrote in the 15th comment:
I agree on the Lope color code stuff. Looking at it in depth as was required to rewrite the patch, I realized it wasn't all that spectacular nor difficult to implement. It just somehow gained mainstream acceptance (probably one of the first ROM color patches available).
I didn't get a chance to start on rewriting the OLC patch until today. I got a bit stuck when I got to comm.c (which is really nice, btw). Could you comment on the following hunks? It seems Ivan pulled the read(…) and write(…) commands. I can't locate many of these…
I didn't get a chance to start on rewriting the OLC patch until today. I got a bit stuck when I got to comm.c (which is really nice, btw). Could you comment on the following hunks? It seems Ivan pulled the read(…) and write(…) commands. I can't locate many of these…
— old/comm.c Mon Sep 14 17:46:16 1998
+++ new/comm.c Mon Sep 14 17:46:53 1998
@@ -56,6 +56,8 @@
#include <string.h>
#include <stdlib.h>
#include <time.h>
+#include <unistd.h> /* OLC – for close read write etc */
+#include <stdarg.h> /* printf_to_char */
#include "merc.h"
#include "interp.h"
@@ -173,11 +175,11 @@
int close args( ( int fd ) );
int gettimeofday args( ( struct timeval *tp, struct timezone *tzp ) );
-int read args( ( int fd, char *buf, int nbyte ) );
+/* int read args( ( int fd, char *buf, int nbyte ) ); */
int select args( ( int width, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout ) );
int socket args( ( int domain, int type, int protocol ) );
-int write args( ( int fd, char *buf, int nbyte ) );
+/* int write args( ( int fd, char *buf, int nbyte ) ); */ /* read,write in unistd.h */
#endif
#if defined(macintosh)
@@ -305,7 +307,7 @@
bool newlock; /* Game is newlocked */
char str_boot_time[MAX_INPUT_LENGTH];
time_t current_time; /* time of this pulse */
-
+bool MOBtrigger = TRUE; /* act() switch */
/*
@@ -516,6 +518,9 @@
dcon.next = descriptor_list;
dcon.showstr_head = NULL;
dcon.showstr_point = NULL;
+ dcon.pEdit = NULL; /* OLC */
+ dcon.pString = NULL; /* OLC */
+ dcon.editor = 0; /* OLC */
descriptor_list = &dcon;
/*
@@ -573,10 +578,23 @@
d->fcommand = TRUE;
stop_idling( d->character );
- if ( d->connected == CON_PLAYING )
- substitute_alias( d, d->incomm );
- else
- nanny( d, d->incomm );
+ /* OLC */
+ if ( d->showstr_point )
+ show_string( d, d->incomm );
+ else
+ if ( d->pString )
+ string_add( d->character, d->incomm );
+ else
+ switch ( d->connected )
+ {
+ case CON_PLAYING:
+ if ( !run_olc_editor( d ) )
+ substitute_alias( d, d->incomm );
+ break;
+ default:
+ nanny( d, d->incomm );
+ break;
+ }
d->incomm[0] = '\0';
}
@@ -762,12 +780,23 @@
d->fcommand = TRUE;
stop_idling( d->character );
- if (d->showstr_point)
- show_string(d,d->incomm);
- else if ( d->connected == CON_PLAYING )
- substitute_alias( d, d->incomm );
- else
+ /* OLC */
+ if ( d->showstr_point )
+ show_string( d, d->incomm );
+ else
+ if ( d->pString )
+ string_add( d->character, d->incomm );
+ else
+ switch ( d->connected )
+ {
+ case CON_PLAYING:
+ if ( !run_olc_editor( d ) )
+ substitute_alias( d, d->incomm );
+ break;
+ default:
nanny( d, d->incomm );
+ break;
+ }
d->incomm[0] = '\0';
}
@@ -892,6 +921,9 @@
dnew->showstr_head = NULL;
dnew->showstr_point = NULL;
dnew->outsize = 2000;
+ dnew->pEdit = NULL; /* OLC */
+ dnew->pString = NULL; /* OLC */
+ dnew->editor = 0; /* OLC */
dnew->outbuf = alloc_mem( dnew->outsize );
size = sizeof(sock);
@@ -1221,11 +1253,14 @@
/*
* Bust a prompt.
*/
- if (!merc_down && d->showstr_point)
- write_to_buffer(d,"[Hit Return to continue]\n\r",0);
- else if (fPrompt && !merc_down && d->connected == CON_PLAYING)
- {
- CHAR_DATA *ch;
+ if ( !merc_down )
+ if ( d->showstr_point )
+ write_to_buffer( d, "[Hit Return to continue]\n\r", 0 );
+ else if ( fPrompt && d->pString && d->connected == CON_PLAYING )
+ write_to_buffer( d, "> ", 2 );
+ else if ( fPrompt && d->connected == CON_PLAYING )
+ {
+ CHAR_DATA *ch;
CHAR_DATA *victim;
ch = d->character;
@@ -1440,6 +1475,12 @@
case '%' :
sprintf( buf2, "%%" );
i = buf2; break;
+ case 'o' :
+ sprintf( buf2, "%s", olc_ed_name(ch) );
+ i = buf2; break;
+ case 'O' :
+ sprintf( buf2, "%s", olc_ed_vnum(ch) );
+ i = buf2; break;
}
++str;
while( (*point = *i) != '\0' )
@@ -2146,7 +2187,7 @@
* Reserved words.
*/
if (is_exact_name(name,
- "all auto immortal self someone something the you loner"))
+ "all auto immortal self someone something the you loner none"))
{
return FALSE;
}
@@ -2472,7 +2513,9 @@
for ( ; to != NULL; to = to->next_in_room )
{
- if ( to->desc == NULL || to->position < min_pos )
+ if ( (!IS_NPC(to) && to->desc == NULL )
+ || ( IS_NPC(to) && !HAS_TRIGGER(to, TRIG_ACT) )
+ || to->position < min_pos )
continue;
if ( (type == TO_CHAR) && to != ch )
@@ -2551,10 +2594,14 @@
*point++ = '\n';
*point++ = '\r';
+ *point = '\0';
buf[0] = UPPER(buf[0]);
+ if ( to->desc != NULL )
write_to_buffer( to->desc, buf, point - buf );
+ else
+ if ( MOBtrigger )
+ mp_act_trigger( buf, to, ch, arg1, arg2, TRIG_ACT );
}
-
return;
}
@@ -2570,3 +2617,27 @@
tp->tv_usec = 0;
}
#endif
+
+/* source: EOD, by John Booth <???> */
+
+void printf_to_char (CHAR_DATA *ch, char *fmt, …)
+{
+ char buf [MAX_STRING_LENGTH];
+ va_list args;
+ va_start (args, fmt);
+ vsprintf (buf, fmt, args);
+ va_end (args);
+
+ send_to_char (buf, ch);
+}
+
+void bugf (char * fmt, …)
+{
+ char buf [2*MSL];
+ va_list args;
+ va_start (args, fmt);
+ vsprintf (buf, fmt, args);
+ va_end (args);
+
+ bug (buf, 0);
+}
05 Dec, 2008, Littlehorn wrote in the 16th comment:
I see, I see. Well then I think QuickMUD would be a good start too but then again I don't use stock ROM anymore because there is QuickMUD. I think that's something to consider there too. At least my impression on QuickMUD is the same impression I feel you guys want to do as well. However, QuickMUD is no longer in development I think so there is always a upside to this project too.
If you're looking to offer something like that but on a more C++ scale then that would be good as well. I would use it and I know many others would use it too. RogueMUD on the otherhand might not be good for that but again if you're going the C++ route then it will be good reference. RogueMUD has also stopped in development as I stopped working on the update and the original programmer is I believe MIA. Last I heard from him he was homeless. :tongue:
If you're looking to offer something like that but on a more C++ scale then that would be good as well. I would use it and I know many others would use it too. RogueMUD on the otherhand might not be good for that but again if you're going the C++ route then it will be good reference. RogueMUD has also stopped in development as I stopped working on the update and the original programmer is I believe MIA. Last I heard from him he was homeless. :tongue:
05 Dec, 2008, quixadhal wrote in the 17th comment:
kaervos said:
I agree on the Lope color code stuff. Looking at it in depth as was required to rewrite the patch, I realized it wasn't all that spectacular nor difficult to implement. It just somehow gained mainstream acceptance (probably one of the first ROM color patches available).
I didn't get a chance to start on rewriting the OLC patch until today. I got a bit stuck when I got to comm.c (which is really nice, btw). Could you comment on the following hunks? It seems Ivan pulled the read(…) and write(…) commands. I can't locate many of these…
I didn't get a chance to start on rewriting the OLC patch until today. I got a bit stuck when I got to comm.c (which is really nice, btw). Could you comment on the following hunks? It seems Ivan pulled the read(…) and write(…) commands. I can't locate many of these…
read() and write() are system calls. One of the many bad programming practices (TM) that Diku has fostered over the years is defining function prototypes for system calls or standard library routines in the source files of the MUD, rather than including the appropriate system header files that will get it right.
If you've looked at the code I have, you'll see that I went through and removed ALL of those, including the appropriate headers for linux systems (what 99% of us use). I also removed ALL the #ifdef garbage for old systems that we don't want to support…. like macintosh (which is pre-OSX), vms, apollo, msdos, etc….
You can also ditch that printf_to_char() thing towards the bottom… I already re-re-re-implemented ch_printf() and friends. :)
As a side note for the future, I'd like to eventually replace all the BLAH_DATA things with proper classes, at which point we can have things like ch->printf(), room[vnum]->printf(), area->printf(), etc….
07 Dec, 2008, kaervos wrote in the 18th comment:
Hey Littlehorn,
I hadn't heard of RogueMUD before you mentioned it, so I went and checked it out. Indeed it does have a nice assortment of additions to the ROM base, and there definitely was a ton of work put into making it C++. What I saw actually looked pretty damn nice. They redid the logs very similar to Quix's modifications.
Problem is, when I ran up RogueMUD2.5b3, it crashes within a minute due to a double free or corruption. =(
What version of RogueMUD was last considered stable? Let me know, I'd like to check it out more in depth.
Quix, when I get a chance I'll go through all those comm.c hunks again, and adjust what I can. I kinda bailed before I got too far because of the vast differences. I'm sure I can get most of them fixed up.
EDIT: Oh, and I noticed the ch_printf(…) and have been using that in the patch fixes.
I hadn't heard of RogueMUD before you mentioned it, so I went and checked it out. Indeed it does have a nice assortment of additions to the ROM base, and there definitely was a ton of work put into making it C++. What I saw actually looked pretty damn nice. They redid the logs very similar to Quix's modifications.
Problem is, when I ran up RogueMUD2.5b3, it crashes within a minute due to a double free or corruption. =(
What version of RogueMUD was last considered stable? Let me know, I'd like to check it out more in depth.
Quix, when I get a chance I'll go through all those comm.c hunks again, and adjust what I can. I kinda bailed before I got too far because of the vast differences. I'm sure I can get most of them fixed up.
EDIT: Oh, and I noticed the ch_printf(…) and have been using that in the patch fixes.
07 Dec, 2008, Littlehorn wrote in the 19th comment:
It should work or check out the other small fix snippets. It's possible it was corruption from the Mudmagic to Mudbytes transfer.
07 Dec, 2008, quixadhal wrote in the 20th comment:
It should be noted that if it hasn't been updated to work with newer version of gcc and glibc, it will probably suffer from that kind of crash. Back when these things were being written, the OS didn't do much in the way of data protection or checking, because the CPU overhead was just too great. Now, the default is to DO such checking (in glibc itself, as memory is allocated or freed), and so sloppy coding practices now come back to bite you.
In short, the GNU people have decided that it's time people start coding correctly or write their own compilers. :)
In short, the GNU people have decided that it's time people start coding correctly or write their own compilers. :)
But, without further ado, here's the log:
Hehehe, forgot to start logging once I got the stupid mud fixed!
We started around 8pm, and to be fair Kaervos DID show up on time (or
pretty close!), but the game kept crashing when he was logging in.
It should be noted that Giver and Jewel are not part of the meeting, they are
actual players who played on WileyMUD II about 15 years ago and managed to find
the place AND they really did just happen to log in while we were there.
Unbelievable. :)
#10 - Shylar [#3001]> who
*** Welcome to WileyMUD III, Quixadhal's Version 0.916w3-alpha (08.11.30) ***
playing Jewel the Elven Scholar/Novice - Griffin's Tale [#3001]
playing Giver the Elven Tracker - Griffin's Tale [#3001]
playing Kaervos the Dwarven Swordpupil - Griffin's Tale [#3001]
playing Dread Quixadhal is the Dark Lord of VI - Griffin's Tale [#3001]
Total visible players on WileyMUD: 4
Wiley start time was: Sun Nov 30 20:00:09 2008
Quixadhal's time is: Sun Nov 30 20:23:01 2008
Kaervos asks 'can I ask why you didn't patch the original Rom2.4 with the 1.81
OLC prior to making changes?'
Kaervos asks 'Just going to bring it in manually later?'
You say 'sure'
You say 'we were actually debating weather to start from QuickMUD or Rom.'
Kaervos says 'I'm not familliar with QuickMUD.'
You say 'I think we decided to start with Rom to minimize the number of
pre-existing bugs, which might have been a poor choice in hindsight.'
Kaervos says 'Hmm'
Kaervos says 'Looking at the QuickMUD base now'
You say 'but we also were planning to keep the C version alive a bit longer
(the C purists seem to have wandered off)'
Kaervos nods solemnly.
You say 'and figured that we'd have to add infinite bits, string sharing
(proper) and other things that would make OLC not patch clean ayways'
Kaervos says 'hmm'
You say 'and so we figured it would be less re-writing if all that base got
done first'
Kaervos says 'QuickMUD does seem like a good place to start'
You say 'especially since converting to C++ would give us STL and friends.'
Kaervos says 'everything added seems rather integral'
Kaervos says 'Copy over, color, olc'
You say 'yes, although their OLC still has some nasty bugs in it.'
You say 'especialy the help editor :('
Kaervos asks 'Ivan's 1.81 was buggy itself?'
You say 'yes'
Kaervos asks 'Or QuickMUD's implementation of it?'
Kaervos nods solemnly.
You say 'both actually.'
Kaervos chuckles politely.
You say 'QuickMUD added a few editors that Ivan's didn't have I think.'
Kaervos says 'ohh'
Kaervos says 'I didn't think Ivan's 1.81 had a help editor'
You fall down laughing.
You say 'My cat is chewing on the brim of my hat'
Kaervos says 'I noticed Ivan's went all the way to version 2 beta. It get sorta
mucked up after 1.81? Thats the feeling I got, but never verified myself.'
Kaervos chuckles politely.
Kaervos asks 'hard to ignore that, eh?'
You say 'I think that's the idea. :)'
Kaervos nods solemnly.
You say 'Yes, the version 2 beta was supposed to add and clean up alot, but of
course never got done and thus is very buggy.'
Kaervos frowns.
Kaervos shrugs helplessly.
You say 'To be honest, I'm not even a big ROM person. This place pre-dates
ROM, and Merc itself.'
Kaervos asks 'Think the editors added by QuickMUD are good additions to the OLC
though?'
Kaervos says 'Strange you got in on this project then'
You say 'Oh yes, I'm a fan of OLC for anything that can be modified at runtime.'
Kaervos chuckles politely.
You say 'this game has no OLC at all… I spent a LOT of time editing
tinyworld.wld in vi.'
Kaervos says 'just thinking it may be worth putting the effort in to fix the
OLC in QuickMUD'
Kaervos says 'heh'
Kaervos says 'When we finally got OLC implemented, I was beside myself with joy'
You ask 'it might be. that's part of the decision to make this week…. how
much do we do as a hack conversion, and how much to rewrite?'
Kaervos says 'I like making areas, but not editing area files.'
You say 'I got rid of tons of temp variables and buffers with the cleanup work
I did on Rom, with the idea being it would make converting from char *'s to
std::string easier.'
Kaervos asks 'Hmm… the changes so far well documented?'
You say 'I could redo that effort on QuickMUD, which would get us to the same
place but with color/OLC and such in place.'
Kaervos nods solemnly.
You say 'and another set of license files to carry along :)'
Kaervos frowns.
Kaervos chuckles politely.
Kaervos shrugs helplessly.
You say 'In either case, once there…. we could try to mass convert leaving as
much in place as possible.'
Kaervos says 'Just sounds like QuickMUD has the bits added we want anyway'
Kaervos says 'seems to make sense to modify that'
Kaervos says 'or…'
You say 'that is, really just replace char foo[MAX] with std::string wherever
possible.'
You say 'and the same for all the linked lists and friends.'
Kaervos nods solemnly.
You say 'orrrr…. :)'
Kaervos says 'Hmmm'
You say 'door number 3 is to write a new codebase that pulls all the combat
logic/spell logic/etc'
You say 'it would still be bound by the same licenses, since I'm not going to
rewrite all that.'
You say 'but it would have a new comm.c and friends that was designed to be C++'
You say 'one way is more search and replacing with rewrites as you go'
You say 'the other is more design and then cut-and-pasting to plug the holes.'
You say 'I'm honestly not sure which is MORE work. :)'
At this point, I remembered to turn on logging!
20:40:00 # Kaervos says 'Hmmm'
20:40:04 # Kaervos says 'Nor I…'
20:40:19 # Kaervos says 'someonetimes search/replace/rewrite as you go…'
20:40:37 # Kaervos says 'you end up feeling stupid you didn't redesign at the start'
20:40:42 # Kaervos says 'know what I mean'
20:40:42 # You nod solemnly.
20:40:44 # Kaervos nods solemnly.
20:41:15 # You say 'the thing is, much like the const char * fix, once you start converting to std::string, you have to do 99% of them before it compiles again.'
20:41:28 # Kaervos nods solemnly.
20:41:38 # You say 'so either way, you won't know you got it right for a while.'
20:43:34 # Kaervos says 'I should be able to recreate your changes from the hack log in SVN'
20:43:49 # Kaervos says 'In QuickMUD I mean'
20:44:41 # Kaervos looks at Giver.
20:44:41 #
20:44:42 # Giver the Elven Tracker is 17 years old.
20:44:42 # +————————-Abilities———————–+
20:44:42 # | STR: 16/ 0 DEX: 15 CON: 13 INT: 13 WIS: 15 |
20:44:42 # | AC: 8 To-Hit: +0 Damage: +1 |
20:44:42 # +———————————————————+
20:44:42 # You have 64/64 Hit Points, 30/112 Mana, and 115/115 Movement.
20:44:42 # You are hungry.
20:44:42 # You're resting so you can KILL MORE CRITTERS!
20:44:42 # You carry 189 Gold Soverigns and have 0 in the bank.
20:44:42 # Your home is set to: Griffins' Inn
20:44:42 # +——————————+——————————*
20:44:42 # ^
20:44:42 # Evil Neutral Good
20:44:42 # You have scored 25932 Experience Points in 0 days and 6 hours!
20:44:42 # As a 5th level ranger, you need 4068 xp and 96 gold to become a Guide.
20:44:57 # You say 'At level 5, yeah… I think the full orcs are 8'
20:45:11 # You say 'It's been a while… the hills are dangerous.'
20:45:23 # Kaervos looks around for things to desecrate.
20:45:23 # You say 'actually, most things are dangerous.'
20:45:23 #
20:45:33 # Doing Event [#1] rats - Rats invade whatever zone you are standing in. [1+]
20:45:33 #
20:45:33 # In a puff of acrid smoke, you see Quixadhal snap his fingers!
20:45:33 # You hear odd scurrying sounds all around you…
20:45:33 #
20:45:33 # You just added 87 rats to Shylar [#10].
20:45:33 #
20:45:39 # Giver says 'yeah…again, makes it interesting.'
20:45:39 #
20:45:40 # You say 'there, have some rats.'
20:45:40 #
20:45:49 # Asylumius has entered the game.
20:46:03 # You exclaim 'wow, it's a convention!'
20:46:05 #
20:46:05 # *** Welcome to WileyMUD III, Quixadhal's Version 0.916w3-alpha (08.11.30) ***
20:46:05 #
20:46:05 # playing Asylumius the Human Swordpupil - Griffin's Tale [#3001]
20:46:05 # playing Jewel the Elven Scholar/Novice - Travelers road [#3000]
20:46:05 # playing Giver the Elven Tracker - Travelers road [#3000]
20:46:05 # playing Kaervos the Dwarven Swordpupil - Griffin's Tale [#3001]
20:46:05 # playing Dread Quixadhal is the Dark Lord of VI - Griffin's Tale [#3001]
20:46:05 #
20:46:05 # Total visible players on WileyMUD: 5
20:46:05 # Wiley start time was: Sun Nov 30 20:00:09 2008
20:46:05 # Quixadhal's time is: Sun Nov 30 20:46:05 2008
20:46:05 #
20:46:08 # Kaervos tries to dance breakdance, but nearly breaks his neck!
20:46:08 #
20:46:09 # #10 - Shylar [#3001]>
20:46:09 # Your blood freezes as you hear someones death cry.
20:46:09 #
20:46:20 # You say 'I don't think 5 people have been on here at once in years. :)'
20:46:20 #
20:46:23 # #10 - Shylar [#3001]>
20:46:23 # Giver shouts 'Oh yeah, these are a little tougher.'
20:46:23 #
20:46:56 # Griffin's Tale
20:46:56 # The warm candlelight emanates a soft glow throughout this chamber revealing
20:46:56 # the many tables and chairs that fill this large congregational. Near the
20:46:56 # southern wall sits a longer table that must serve as the bar, several bottles
20:46:56 # sit upon it. There are a few pictures near a fireplace which glow dimly,
20:46:56 # only adding to the simple elegance of this Inn. Just past a large picture
20:46:56 # stands a arch which seems to lead into a back room which is deathly silent.
20:46:56 # A door leads to the west while to the east lies an archway opening into a
20:46:56 # long hall with many doors lining it.
20:46:56 # A large barrel sits near the bar.
20:46:56 # Asylumius the Human Swordpupil is standing here.
20:46:56 # Kaervos the Dwarven Swordpupil is standing here.
20:46:56 # The barkeep, Buck, stands behind the counter spit cleaning a mug.
20:46:56 #
20:46:59 # You chuckle politely.
20:47:08 # You shout 'Just watch out for the village guard… he doesn't like fighting.'
20:47:10 # Asylumius asks 'Got color?'
20:47:29 # You say 'sure… sit at a green vt220 for green…. *grin*'
20:47:46 # Asylumius says 'Roger'
20:47:48 # You say 'actually, we only had amber or grey… green was the vt100 and nobody liked those'
20:48:29 # Asylumius says '"At revision 62." :('
20:48:56 # You smile happily.
20:49:22 # You say 'Yeah, I've been pondering the direction of attack for converting to C++'
20:50:09 # Kaervos says 'strings obviously a huge part of that'
20:50:21 # Kaervos says 'and the memory management associated with that junk'
20:50:23 # You say 'I was just saying that we can use a search-replace and then rewrite technique, OR, a rewrite comm.c and friends as redesign for C++ and then cut-paste all the logic code into place.'
20:50:38 # You say 'and I'm not sure which is actually MORE work.'
20:51:23 # Asylumius asks 'using std::string?'
20:51:58 # You say 'yes, and the STL containers to replace all the cobbled up linked lists and such'
20:52:14 # You say 'most importantly (to me), is std::map for the room/mob/obj arrays'
20:52:51 # You say 'thus allowing you to use vnums directly for array indexing.'
20:52:56 # Asylumius says 'is C++ gonna change anything in the way the update stuff works? as '
20:52:57 # #10 - Shylar [#3001]>
20:52:57 # A villager says 'Wink. Wink.'
20:52:57 #
20:53:16 # #10 - Shylar [#3001]>
20:53:16 # A villager asks 'You been around, eh?'
20:53:16 # A villager asks '…I mean you've ….. done it, eh?'
20:53:16 # A villager nudges Jewel.
20:53:16 # A villager nudges Jewel.
20:53:16 #
20:53:28 # #10 - Shylar [#3001]>
20:53:28 # A villager says 'Evening, Squire'
20:53:32 # You say 'the language itself won't, but making an event system is probably a good idea'
20:53:52 # Asylumius asks 'whats with the progs around here? are these scripted with something?'
20:53:56 # Asylumius says 'the hookers and stuff'
20:54:00 # You say 'yes, C :)'
20:54:07 # You say 'all special routines'
20:54:11 # Asylumius nods solemnly.
20:54:21 # You say 'The villagers are one of my specialties…'
20:54:31 # You say 'they attatch themselves to you and annoy the hell out of you'
20:54:35 # Asylumius says 'No color.. hard-coded C progs? You're living in the past :P (I like it!)'
20:54:43 # You say 'and they even wake you up if you try to sleep to ignore them'
20:55:03 # Kaervos says 'hah'
20:55:04 # You say '1995 lives! :)'
20:55:05 # Kaervos says 'thats evil'
20:55:24 # You say 'my berserker axe is worse…it forces you to attack elves on sight.'
20:55:47 # You say 'but it also tends to get people killed easily.'
20:56:04 # Asylumius says 'I'll be semi-AFK. Dexter is on.'
20:56:13 # You grin evilly.
20:56:17 # You say 'yes, speaking of evil'
20:56:22 # Kaervos grins evilly.
20:57:02 # Kaervos says 'Hmm'
20:58:14 # Kaervos asks 'the QuickMUD additions aren't too painful, I know 1.81 will drop in without an issue… Lope's color code and Erwins mods both have patches for them?'
20:58:16 # Asylumius says 'one thing that took me a LONG time to do was code "Shapeshifters" on my MUD'
20:58:40 # Asylumius says 'primarily because changing shape (into an animal, etc) meant changing EVERYTHING about the char. name, desc, stats, saves, their damage, skills, etc.'
20:58:46 # You nod solemnly.
20:58:58 # Asylumius says 'a million lines of "if (is_shapeshifteted())"'
20:59:09 # You say 'Applying all of my changes to QuickMUD is easy, just time consuming.'
20:59:13 # Kaervos chuckles politely.
20:59:24 # Asylumius says 'it would be cool if C++ made it easier to "change" or override all the char_data attributes'
20:59:29 # You say 'Patching QuickMUD's addons into RaM might be ugly.'
20:59:39 # Asylumius says 'aside from wht I did, which was save the struct to old_char_data and then switch it back'
20:59:41 # You say 'well, it does… if you designed it that way. :)'
20:59:52 # Asylumius pokes The village guard in the ribs.
21:00:02 # You say 'You'd just make all the methods part of a class for the body type'
21:00:25 # You say 'so a "player" would inherit "humanoid" for their basic data and commands'
21:00:34 # Kaervos says 'Aye, I was thinking more of Patching QuickMUD's addons to vanilla ROM2.4b6, then patching that to RaM based on diff'
21:00:39 # You say 'a "wolf" would inherit "quadroped"'
21:00:56 # Asylumius says 'I set my MUDs makefile to use all the flags from RaM'
21:01:01 # Asylumius says 'then I set it back :('
21:01:05 # You cackle gleefully.
21:01:12 # Kaervos chuckles politely.
21:01:17 # Kaervos asks 'Lots of warnings, eh?'
21:01:20 # You say 'there are a LOT of bugs that the compiler hides from you.'
21:01:29 # Kaervos nods solemnly.
21:01:30 # Asylumius says '112245 lines of code. too much work.'
21:01:32 # You say 'a few of them are real bugs too, not just ghost warnings'
21:01:36 # Asylumius says 'and half of the warnings I dont understand :('
21:01:54 # You say 'I found one where a staff was never casting a spell because the if comparision always ended up being false'
21:01:55 # Asylumius says 'and the other half require too much regex-foo to fix'
21:02:01 # An astral traveler shouts 'Suffer! I will make you all suffer!!!!!'
21:02:06 # Asylumius says 'On that note.'
21:02:15 # Asylumius asks 'Quix, how did you do that auto-formatting of ROM code?'
21:02:24 # You say 'the evil tool indent.'
21:02:33 # Asylumius asks 'lots of cleanup?'
21:02:40 # You say 'if you look in the checkout, you'll see a .indent.pro file with the settings I use.'
21:02:50 # Asylumius nods solemnly.
21:03:00 # Kaervos asks 'what tool is that?'
21:03:12 # You say 'it mostly gets it right, although you do have to hand tweak a few things to keep it from going insane'
21:03:32 # Asylumius says 'ill give it a shot.'
21:03:34 # You say 'of course, with C++, we'll need a new tool since indent doesn't realy understand anything but C.'
21:03:48 # You say 'but for now, we're not USING any of the C++ features.'
21:03:54 # Asylumius chuckles politely.
21:04:10 # Asylumius says 'ill be using this as a learning opportunity for C++'
21:04:17 # Asylumius says 'I took one class in school, thats it'
21:05:46 # You say 'They didnt' teach C++ when I was in school… I had to suffer with Pascal, Fortran, and the new C class.'
21:05:54 # Giver nods solemnly.
21:06:04 # Kaervos says 'heh'
21:06:06 # Giver exclaims 'pascal!'
21:06:06 # Jewel nods solemnly.
21:08:41 # Kaervos says 'So I think I may grab ROM2.4b6 vanilla and patch it with Ivan's 1.81, Lupe's, and maybe Erwins stuff'
21:09:05 # You say 'To be honest, unless QuickMUD has done other crap like adding races or classes'
21:09:12 # Kaervos says 'I don't see any license stuffs in QuickMUD'
21:09:18 # You say 'I'd probably start there'
21:09:24 # Kaervos says 'I would only do that to avoid QuickMUD license'
21:09:30 # Kaervos nods solemnly.
21:09:36 # Kaervos says 'I don't think they've added anything else'
21:09:44 # Kaervos says 'let me check out QuickMUD'
21:09:49 # You say 'It's just another set of entries in the help files, the login screen, and the comments'
21:10:01 # Kaervos says 'if it is kosher, I'll work on implementing your changes there'
21:10:02 # You say 'The original Diku license is the only one we'd love to get around'
21:10:16 # You say 'and then only to be able to use GPL code'
21:10:31 # Kaervos says 'damn'
21:10:55 # Kaervos asks 'No getting around that though, eh?'
21:11:06 # Kaervos says 'scratches his head thoughtfully.'
21:11:08 # You say 'nope, not without a full rewrite'
21:11:12 # Kaervos coughs loudly.
21:11:49 # You say 'that's why I said, even if we rewrote the basic driver in C++, by using the combat routines, spells, etc from here we'd still be bound by the Diku/Merc/ROM/QuickMUD licenses'
21:12:21 # You say 'all of which are reasonable, except the impose limits that aren't compatible with GPL'd code :('
21:13:09 # You say 'We can link against GPL licenses, but we have to require the user to install them themselves :('
21:13:39 # Kaervos says 'Hmm'
21:13:43 # Kaervos says 'that is a bummer'
21:15:06 # You say 'The Diku people had good intentions by disallowing making money or removing their names from the credits, and the GNU people had good intentions by saying you couldn't limit the ways GPL'd code is used. Unfortunately those two things don't work togethe'
21:20:08 # Kaervos says 'well, with those license woes, I suppose there is no need to worry about QuickMUD's added license'
21:23:33 # Kaervos says 'QuickMUD is definitel y bugged'
21:24:15 # Kaervos says 'I rolled 538 million for my strength'
21:24:15 #
21:24:22 # You cackle gleefully.
21:24:22 #
21:24:39 # Kaervos says 'Str: 31500(25) Int: 11(11) Wis: 12(12) Dex: 11(11) Con: 10(10)'
21:25:01 # Kaervos says 'hmm'
21:25:01 #
21:25:28 # You say 'I'm guessing some weird artifact of short ints + weird signed/unsigned bugs'
21:25:28 #
21:26:03 # Kaervos says 'QuickMUD does have added junk'
21:26:06 # Kaervos says 'races'
21:26:14 # Kaervos says 'equipment slots'
21:27:52 # You say 'nothing inherantly bad, if it isn't buggy'
21:28:02 # You say 'although I don't like added races or classes'
21:28:19 # You say 'just because, they won't be what the new admin wants and just serve as more crap to yank.'
21:28:44 # You say 'that's part of why I want to ditch (or hide) all the stock rom areas.'
21:31:14 # Kaervos asks 'say Quix, can you point me to a distribution of Lope's 2.0 color code for ROM?'
21:31:30 # You say 'probably.. hang on a sec'
21:38:19 # Kaervos says 'hmm, yeah I can't find Lope's snippet on MudMagic nor MudBytes'
21:38:28 # Kaervos leaves south
21:38:30 # Kaervos has arrived from the south.
21:38:55 # You say 'I have the feeling it's probably not called lope's in the name'
21:39:22 # You say 'google isnt' much help, ROM is too generic a term, and lope's ends up pointing to spanish entries for lopes.'
21:41:46 # You say 'You could always grab QuickMUD and reverse-apply the patches for Ivan's OLC and friends….'
That's pretty much where everyone became idle or disconnected, so 90 minutes isn't bad.
The summary:
I'm a slacker and didn't finish the project this week. *grin*
In fact, I didn't even start any coding, because I am concerned about which direction
to travel in. On the one hand, changing all the code to use STL will be a lot of grep
work, and on the other, retooling for a proper C++ design is a pretty big undertaking.
Meeting halfway is probably the ideal solution.
In any case, I'll have to search around and find the Lope's color code patch, as I *KNOW*
I found it back when we started this project.
See you all next week!