Dependancies are easy… I almost made the makefile self-modifying, but didn't want to scare people.

Once you've got things compiling to your liking, just do a "make dep" and replace everything below the comment with what it spits out.

Sounds like you're making good progress! Let me know how you'd like to go from here… probably the easiest way is to give you a branch directory to play with. Alternately, you can upload your changes to the file area and I can snag them from there. Whatever works, I'm easy.

Also, if you haven't used any C++ specific things, the same changes will probably apply to both Fire and Ice, since Fire hasn't really taken off yet (mostly planning work, little actual code).

Self-modifying sounds pretty evil to me: it would make versioning it kind of annoying. Better to just use auto-dependencies that generate files in an auxiliary directory, and have a Makefile include statement for those.

I agree with David, manually adding dependencies to the Makefile just seem awkward, whereas using a file that the Makefile generates at the end that you never have to actually look at or touch is wonderful. SmaugFUSS does this. ;)

I have completed the OLC 1.81 patch conversion for RaM Fire.

I have uploaded an archive to the Code Repository under the RaM directory. Features and instructions included in the description.

Seems to be a good merge. There may be some sh_int and TRUE/FALSE (instead of true/false) variables still floating about. They can easily be located and replaced, so I wasn't too worried about it.

I've been playing around in the OLC all day, and I have to say I'm quite pleased with the results. I think I accidentally learned a few things in the process. =)

Check it out. Let me know your thoughts.

We should definitely meet this Sunday somewhere to discuss whats next. I was so engrossed with the patch port I forgot all about the meeting last Sunday.

[Edit:] Ooops. Looks like I broke something with movement just before I uploaded it. I'm checking into it.

[Edit2:] Found the problem. I uploaded a new mob_prog.c file to the repository that fixes the issue. Looks like the late night coding sessions took some tolls. :redface:

Kaervos: You can use MudBytes update feature to install the patch yourself and send the file for upload. That way, everyone who downloads it wont have to download the patch as well. Once the update is submitted, I can remove the fix file if you want.

Davion,

Nice! I used the update feature to replace the tar.gz with a corrected version.

Please remove the "… FIX!" file.

Thanks!

I'll see if I can get that patched in tonight, awesome! :)

We probably should do a bit of cleanup in the RaM file area too. I don't think most of those individual patches need to be there now that svn is working. I'll see which ones, if any, are actually worth keeping.

Cool. Let me know if you run into anything. You shouldn't have any trouble though.

Again, I'm pretty sure that some sh_int and caps booleans snuck through. There may have been some args(…) style function declarations left too, but I don't think so.

Mind that I removed all the REDIT(…), OEDIT(…) etc around defined function names, and also removed the DELCARE_OLC_FUN(…) for the act functions much like what was done in the rest of RaM… I suppose the PPDs for this can be removed as a result.

I would run the OLC source files as well as the patched files through indent again.

Let me know if/when you merge this into the SVN, I'd like to grab the latest.

Cheers.

I just noticed a bug in RaM. It goes back to Fire prior to my modifications.

Just log in and stat yourself. Take note of your flags.

Stat yourself again. Take note of the doubled flags.

Stat yourself about four more times. Take note of the buffer overflow.

GDB isn't much help…

[Edit: ] Ohh… its obvious now whats happening…

const char             *off_bit_name( int vector )
{
    static char             buf[512] = "\0\0\0\0\0\0\0";

    if ( vector & OFF_AREA_ATTACK )
        strcat( buf, " area attack" );
    if ( vector & OFF_BACKSTAB )
        strcat( buf, " backstab" );

…

Anything wrong with using non-static local variables and returning a str_dup(…) copy?

Yeah, I overoptimized here… It should clear the static buffer first, of course. :)

I wouldn't return str_dup() here, because the caller is not likely to free the result, which means if you use real strdup() it's a memory leak, and if you use the share string str_dup(), you eat away at your compile-time limited space for strings.

I hate that entire shared string mess, and I'd spend the time to nuke it all if switching to C++ wouldn't make it go away by itself (IE: using std::string instead). It's another case where optimizing for memory was vital because you had to run your game on a shared machine with a very low footprint… but nowadays my cell phone has more memory AND CPU power than they had to work with back then.

Ok, this is silly….. what the *explative* does a "surrender" command have to do with OLC???



Was this just some annoying test command so they could write an example mprog that would honor surrendering? *grumble*
The subsystems in these games are far too entwined…

So if I used str_dup(…) there, and used stat a thousand times I could eventually hit the whole "MAX PERM BLOCKS – TIME TO REBOOT" scenario? I never really understood the memory management system in ROM. So it basically allocates a big chunk of memory to use for strings on boot, then starts handing out blocks of that big chunk for new string allocations, just hoping they get freed somewhere down the line?

Damn, std::string really would be a godsend for ROM.

Haha, yeah, I just noticed the whole surrender thing for the first time doing this patch. I guess it is so when you are beating on beastly fidos, they can whimper and then surrender to you. If implemented correctly, it could actually be a good RP tool in the situation that you don't want to fight back, but I'm not exactly sure how it works in PvP situations…

Hey, I coded drunken speech code (rewrote the envy code from scratch) and targeting (the "$$" replacement snippet) into Fire. I think these are good stock features for RaM. It always annoyed me that getting drunk in ROM didn't really seem to do much to you, and Maniac's string modification routine is quite good. The targeting code is real handy and unless there are concerns over the replacing of $$ in user input, I think there is no reason not to have it. You agree these are good additions? What about a proper scan command?

*shrug* I'm just looking for something to do I guess. =P

It's kind of dumb, or at the very least odd, that the total amount of strings you can allocate is limited. :thinking:

Yep, the reasoning behind the whole string managment system comes from the Old Days(TM), when they system calls for malloc() and free() were very expensive to use (which goes back to how sbrk() works, and how paging was done in those OS's). I think it also allowed people to show their sys-admins that there was an upper bound on memory usage, so they'd get permission to use the university mail server for their game. Remember, linux didn't yet exist as something you could really just download and use back then, and the idea of a student having their own machine on the campus network was absurd.

Drunken speech is cute.. although it would be more fun if you turned it into a generic language translation system, so evil basta…. I mean mud administrators like myself could entirely remove the "common" language from the game and force everyone to speak in their racial language unless they went to the trouble to learn the other racial languages. :)

Not sure what targeting is in the context of text muds…. sound like some new fangled bell and whistle to me. I'm kindof working towards merging ALL output generation into a single routine that would parse ALL codes (act-style, colour, etc), so keep that in mind.

scan… ugh. We hates its. Nassssty playerses, trying to cheats usssss and not goess into roomses with nice orcses waitings to jumpses them! Personally, I put scan into the same category as ascii maps. They both only work right if you have an assumed room size, and the area is euclidean in layout. They're both ways for the player to try and shortcut content by not exploring. And… they're both things people seem to want. :)

You know… thinking about it from a gameplay perspective… scan should only be available to rogue-type players, and then only when they're sneaking or hiding. If you think about what it does, you're trying to sneak up to the edge of the next room and peek in without being noticed… seems a sneaky thing to me.

This does bring up one of the points we talked about early on in the project though… Adding commands that give the player easier access to information they already have is good. Adding commands that give players advantages in the game which they didn't have before is treading into gameplay, which is not what we're really concerned with here. In short, it changes the game balance because it lets players do something the ROM designers didn't take into account. Perhaps if MOBs also used scan….

That's one that I think I'd leave in the snippet bin for people to add if they want it.

Maybe this is just a pipe dream, but it might be a nice occasion to design a module system of sorts. So, 'scan' becomes a plug-in module that requires (more or less) nothing more than sticking the file somewhere.

That would be nice, but it would require both a solid API for the added commands (IE: the game has to be able to ask the command itself about security issues, level/class/race restrictions, etc) and the use of dlsym to allow the module to be loaded at boot time without having to hack around the command table. Same thing for spells and such. More complex modules are… a problem.

If we get to the point of having all the commands/spells/skills in boot-time loaded files that get matched to functions by dlsym, I could see that being quite possible.

It would be a lot easier with a decent scripting language, really. Then you wouldn't have to deal with the fun times of dlsym etc.

Like I said, probably a pipe dream, but it would be really pretty nifty.

Oh, found a logic error in one of the patch chunks….

diff -ur old/act_info.c new/act_info.c
— old/act_info.c      Mon Sep 14 17:46:16 1998
+++ new/act_info.c      Mon Sep 14 17:46:53 1998
@@ -1027,7 +1027,8 @@
          */
         ch_printf( ch, "%s", ch->in_room->name );

-        if ( IS_IMMORTAL( ch ) && ( IS_NPC( ch ) || IS_SET( ch->act, PLR_HOLYLIGHT ) ) )
+        if ( (IS_IMMORTAL(ch) && (IS_NPC(ch) || IS_SET(ch->act,PLR_HOLYLIGHT)))
+        ||   IS_BUILDER(ch, ch->in_room->area) )
         {
             ch_printf( ch, " [Room %d]", ch->in_room->vnum );
         }

I think it really wants IS_BUILDER to be equivalent to IS_IMMORTAL, so that people who have build privs to the area in question can use holylight if they want. I'm changing it to work that way… the way it is now, immortals can toggle holylight on and off, but builders always have it on (at least for the purposes of showing the room number).

Hehehe, going through the patch by hand, I'm reminded to mention one of the other things about RaM that you'll probably find quirky. :)

The way you've learned how to do line endings over the years is probably WRONG. *grin* Of course, that's only if you learned how to program by looking at the DikuMUD source, or almost any of the derivatives. Namely, you'll find line endings presented as "\n\r" throughout the code, throughout almost every snippet you can find, and in almost every codebase out there. Despite how many people have used that for 15 years, it's wrong, and it actually does cause issues with some things – albeit unusual things.

The TELNET specification says that because various architectures have different mechanics for end-of-line tokens, they chose the symbol combination "\r\n" as the standard which any TELNET compliant clients and servers would use. They even went out of their way to say that if you wanted to send just "\r" by itself, you had to send it as "\r\0".

Of course, we don't (yet!) fully implement the TELNET protocol, even though we pretend to be a TELNET server to the rest of the world. Still, it annoys me that whenever I bring this up, it gets pooh-pooh'd as unimportant by most, and met with outright hostility by one admin/dev, whom I think was as outraged at my telling him he was doing it wrong, as by the idea that I might be right where every other MUD out there was wrong. *grin*

In any case, the way this manifests is when you're using a client that allows you to do pattern matching. If you've ever used tinyfugue (or tintin) and wondered why anchored patterns at the start of the line don't seem to work properly, this is why. UNIX uses "\n" alone to act as an end-of-line symbol. When TELNET sends "boo\r\n", the line shows up to a UNIX client as "^boo\r$". Of course, if the client understands TELNET properly, it will translate that to be "^boo$" internally. If you do it backwards, it shows up as "^boo$\r", where the "\r" token becomes part of the NEXT line.

So, if you're trying to match a pattern like "^([\w]+) says", it won't match because there's an extra whitespace character you have to absorb. Sure, that's fairly obscure… but 12 years ago it was driving me nuts when I was trying to add color to combat messages and heal messages (back when color wasn't normally in the driver), and I kept having to add wildcards to get it to work right.

I mention it because, of course, the code fragments from Lope are all done the "wrong" way, which I'm correcting, and it gives me another change to soapbox about one of the nitpicky things that bug me. *grin*

Just tossing this one up to see if anyone has a comment. This is in comm.c, and is another chunk of the OLC patch.

@@ -2551,7 +2594,10 @@
         *( ++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 );

         if ( ( type == TO_VICT ) || ( type == TO_CHAR ) )
             return;

If I'm reading this right, it's probably intended to write the output to the target's buffer ONLY if they have a descriptor (normally only true for players – although switch and snoop could affect that), and otherwise to do an mp_act_trigger() so a mob script can parse the output if one exists.

I'm wondering if that really should be an exclusive or. In other words, if the victim has a descriptor (via snoop/switch/etc), wouldn't it be good to have it still get the trigger?

Throughts?