First your question is answered often maybe you need to stick with your email address long enought to get a responce.
http://www.the-infinite.org/lists/romlist/ Secondly you problem if you would search your source you would see that act is a macro to act_new. If you followed your act_new snippet properly that is. So you would want to look into the act_new function to see the problem. But thats not 100% the problem. The problem is your mobs arn't flagged to use channels or to see them, you can either flag all mobs with this by adding something in create_mobile to do this. Or you can flag the mob with the communication ablites so it can see these things. Yes it would be refering the the function 'act' returns if the mob is not flagged for communications. And that it doesn't check to see if it is a person in a mobs body. ----- Original Message ----- From: "Robert Casko" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, August 06, 2003 11:24 PM Subject: Hello, once again, and two old questions. > I've been gone for a while again, and I have a new email address now, but I > am back (if anyone remembers Tegid, trying to put up a mud called > Triumvirate). > > I have two questions. The first I found asked a number of times in the > archives, but I could not fine even one answer to it. > > Basically, it has to do with the Rom Faq, section 7.13. it's text is short, > and not all that illuminating for someone not totally intimate with rom > code. it states > > .... > After adding mobprogs, some people find that when switched into a mob they > don't see a lot of the mud text, most notably communications channels. The > cause of this is the code added to the 'act' function, to check for an ACT > trigger on a mob. The code returns from the function if the mob doesn't have > such a trigger, but doesn't take account for a switched imm. Add a clause to > the 'if' check to return only if the mob has no descriptor and this problem > should go away. > .... > > No offense to the author, as the faq has helped me greatly in the past, but > this little section I find little help at all because of how vague it is. > 1) I cant seem to find the ACT function, I only have an act_new function. 2) > it sais "..the code returns from the function if.." and then it tells you to > change "the if check". Which function is it refering to? act_new? or each > individual communication function, such as say, yell, tell, immtalk, etc. > and which "if" is "the" if check to change in "the" function? > > Can someone maybe offer a bit more specifics so I might be able to come > closer to figuring this one out? maybe give an example of a fixed if check? > > Or, do you need more information to help me out with this problem? > > > ***************** > Originally appeared in: > Merc release 2.2 > Wednesday 24 November 1993 > > N'atas-Ha [EMAIL PROTECTED] > Kahn > > Modified for ROM 2.4 in January 1996 > [EMAIL PROTECTED] Gothique > > ok, second problem, also has to do with the infamous OLC version by newt. > I've fixed the problem addressed in the Faq number 7.9(mobprogs stop > working)...but I have another problem with my mobprogs that is not addressed > in the faq, and I could not find it addressed in the archives. > > > Basically. When the mud is up, and I am creating using olc. I can make a > mobprog, link it to a mob (ex. addmprog 3700 grall 100) and it works fine. > It actually works like a champ. except...for some reason when I shutdown > and try to restart, it seems to have not been saved right in the .are file. > > I keep getting: > Wed Aug 06 23:34:42 2003 :: [*****] BUG: Fix_mobprogs: code vnum 3700 not > found. > > > As an example, here is what is in my #MOB section in the .are.... > > #3799 > Hidden Presence~ > A hidden presence~ > A hidden presence stands here, looking over new souls > ~ > ~ > human~ > ABUVc BCDPQZ 0 0 > 60 60 121d20+1091 60d9+60 19d3+31 none > -28 -28 -28 -16 > 0 0 0 0 > stand stand none 0 > 0 0 medium unknown > F for AHMV > F par ABCDEFGHIJK > M GRALL 3700 100~ > #0 > > > > Then, down near the end of the .are I have... > > #MOBPROGS > #3700 > if level $n < 10 > MOB FORCE $n color > MOB FORCE $n show > MOB FORCE $n autoexit > MOB FORCE $n auto > MOB FORCE $n help auto > MOB OLOAD 2 1 room > MOB FORCE $n get coin > MOB FORCE $n worth > MOB FORCE $n score > MOB FORCE $n look > endif > ~ > #0 > > > > ....some more info... All I have to do is deleted the "M GRALL" line in the > mob section and then the mud starts without problem. But, when I go to see > what mobprogs are there, it shows that it has not loaded in the #mobprogs > section...so I have to type it all in again. It's like this for all > mobprogs.(as you can immagine, re-writing all mobprogs every reboot can get > somewhat annoying). > > (let me here apologize for typing such a long question, but I really can't > fix this on my own and I just wish to make sure I give all the information > necessary to get the help I need to fix it) > > I've tried to fix this myself, but I get lost in the code, when I search for > the Fix_mobprogs bug message....there is only one way for it to be > invoked.... in db.c in the fix_mobprogs function, there is an if else > statement within a for loop...within another for loop, within another for > loop....but I think it basically comes down to this "prog" is being set to > NULL...even though there is a mobprog of the right format in the mobprog > section of the .are....ie...I think it just isn't reading right.... > > for( list = pMobIndex->mprogs; list != NULL; list = list->next ) > { > if ( ( prog = get_prog_index( list->vnum, PRG_MPROG ) ) != NULL ) > list->code = prog->code; > else > { > bug( "Fix_mobprogs: code vnum %d not found.", list->vnum ); > exit( 1 ); > } > > So, when I track down the get_prog_index to try to get my brain around what > is going on...I see something interesting.... > > /*problem might be here*/ > PROG_CODE *get_prog_index( int vnum, int type ) > { > PROG_CODE *prg; > > switch ( type ) > { > case PRG_MPROG: > prg = mprog_list; > break; > case PRG_OPROG: > prg = oprog_list; > break; > case PRG_RPROG: > prg = rprog_list; > break; > default: > return NULL; > } > > for( ; prg; prg = prg->next ) > { > if ( prg->vnum == vnum ) > return( prg ); > } > return NULL; > } > > **Notice the comment? I don't remember putting that in there so I think it > was there from the beginning. continueing on my feeble attempt to fix, I > realize that the only way "prog" is being set to null in Fix_mobprogs is if > the prg = mprog_list; statement just isn't working. > > When I try to track down the mprog_list to see what is going on is when I > start to get lost in the code and can't figure out what exactly is going > wrong or how to fix it. > > > Thanks for anyone who is able to read all of this and offer a bit of light > in my darkness of coding hell. > > > > > > > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom >
