Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
 parse description bug
Today, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Google, Remcon, Yahoo!

Members: 1
Guests: 13
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » SWR Problems
Forum Rules | Mark all | Recent Posts

SWR Problems
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #21 Feb 19, 2010, 7:51 pm
Go to the top of the page
Go to the bottom of the page

Andril
Magician
GroupMembers
Posts147
JoinedJun 9, 2009

Well if I'm right, hitprcnt_prog 100 will only fire when the mob has 100% hp. So all the if checks in there will never be true. Maybe try a fight prog with 100 and put if hitprcnt($i) == 90, and so on, in that?
       
Post is unread #22 Feb 19, 2010, 7:57 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,866
JoinedJul 26, 2005

Actually as far as I can tell that one is always fired because it uses a hitpercent (of mobile) < <#> so while the mobile is at 100 it won't fire. After that the 100 will always fire till they get back up to 100. (Looking at the code for it all) So if you did those programs in reverse order it should work fine. like do the hitprcnt 10 then hitprcnt 20 then hitprcnt 30 etc.... Leave 100 for last.
       
Post is unread #23 Feb 19, 2010, 8:00 pm
Go to the top of the page
Go to the bottom of the page

MagisterXero
Fledgling
GroupMembers
Posts44
JoinedFeb 11, 2010

Ahhhh.... Thanks exactly why. I remember having issues with that in the past, that sure brings back some memories.

And Yes, Andril, if you set it for hitprcnt_prog 100, it fires off 100% of the time, dunno why, but it does.
       
Post is unread #24 Feb 19, 2010, 8:16 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,866
JoinedJul 26, 2005

Well its not exactly 100% of the time since it checks for < not <= so if they have 100% of their hp it won't fire.

Aside from that though it will lol. There is also going to be a possible issue one day for you with that check if you are able to set up to like massive amounts of hp for mobiles etc... just based on the checks itself. Like if you take a mobile with like 100mil hp or something it will end up wrapping the number to the -s and make it less then what the check is also. Just thought I'd go ahead and point that out also.
       
Post is unread #25 Feb 19, 2010, 8:52 pm   Last edited Feb 19, 2010, 8:59 pm by MagisterXero
Go to the top of the page
Go to the bottom of the page

MagisterXero
Fledgling
GroupMembers
Posts44
JoinedFeb 11, 2010

The mob does have over 100 mil hp. So, I just tested that and it didn't work. hm

Any way to fix that?
       
Post is unread #26 Feb 19, 2010, 9:13 pm   Last edited Feb 19, 2010, 9:16 pm by Remcon
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,866
JoinedJul 26, 2005

in mud_prog.c
change
void mprog_hitprcnt_trigger( CHAR_DATA * mob, CHAR_DATA * ch )
{

   MPROG_DATA *mprg;

   if( IS_NPC( mob ) && ( mob->pIndexData->progtypes & HITPRCNT_PROG ) )
      for( mprg = mob->pIndexData->mudprogs; mprg; mprg = mprg->next )
         if( ( mprg->type & HITPRCNT_PROG ) && ( ( 100 * mob->hit / mob->max_hit ) < atoi( mprg->arglist ) ) )
         {
            mprog_driver( mprg->comlist, mob, ch, NULL, NULL, FALSE );
            break;
         }

   return;

}

to
int get_percent( int fnum, int snum )
{
   double percent = 0.0;

   if( fnum == snum )
      return 100;
   if( fnum <= 0 )
      return fnum;

   percent += ( 100 * fnum );
   percent /= ( snum );
   return (int)percent;
}

void mprog_hitprcnt_trigger( CHAR_DATA * mob, CHAR_DATA * ch )
{
   MPROG_DATA *mprg;

   if( IS_NPC( mob ) && ( mob->pIndexData->progtypes & HITPRCNT_PROG ) )
      for( mprg = mob->pIndexData->mudprogs; mprg; mprg = mprg->next )
         if( ( mprg->type & HITPRCNT_PROG ) && ( get_percent( mob->hit, mob->max_hit ) <= atoi( mprg->arglist ) ) )
         {
            mprog_driver( mprg->comlist, mob, ch, NULL, NULL, FALSE );
            break;
         }

   return;
}

Haven't tested it but give that a try and see if it does what you want it to.
Also went ahead and changed the < to <= since if you say 100% then 100% should fire for it also IMHO.
       
Post is unread #27 Feb 19, 2010, 9:14 pm
Go to the top of the page
Go to the bottom of the page

MagisterXero
Fledgling
GroupMembers
Posts44
JoinedFeb 11, 2010

Will do! I'll test it out once I'm done making codebase updates :)
       
Post is unread #28 Feb 20, 2010, 12:58 am
Go to the top of the page
Go to the bottom of the page

MagisterXero
Fledgling
GroupMembers
Posts44
JoinedFeb 11, 2010

Having a bit of trouble with some a line of code, which I'll post below.

 /* In mud.h */ 

const char *PERS args( ( CHAR_DATA * ch, CHAR_DATA * looker ) );

/* in comm.c */

const char *PERS( CHAR_DATA * ch, CHAR_DATA * looker )


/ * The error */ 

  Compiling o/comm.o....
comm.c:3590:59: error: macro "PERS" requires 2 arguments, but only 1 given
comm.c:3590: error: function definition does not declare parameters
make[1]: *** [o/comm.o] Error 1


Not sure what the problem is... The function has two arguments...
       
Post is unread #29 Feb 20, 2010, 1:12 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Search for
#define PERS


It sounds like you have a function called PERS, and a lingering macro definition for it as well.
       
Post is unread #30 Feb 20, 2010, 7:52 pm
Go to the top of the page
Go to the bottom of the page

MagisterXero
Fledgling
GroupMembers
Posts44
JoinedFeb 11, 2010

I seem to be struck with misfortunes constantly...

So now I've tried to upgrade the codebase of the mud to swfote, by using wincompare and implementing lines that were different while still retaining what I'd already done.
I got the mud working and booted up with no problems for EXISTING characters, save for a few bugs with skills not listing right, but now there's automatic crash when a
new character is about to be created. It happens just as they are about to enter the game.

last line being called is nanny( d, cmdline ); -- in comm.c, line 556 and it's exiting with code 1
       
Post is unread #31 Feb 20, 2010, 8:01 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

You'd probably be better off getting the changes you made to SWRFUSS using a diff against the stock SWRFUSS, and then applying those same changes to SWFotEFUSS.
       
Post is unread #32 Feb 20, 2010, 8:02 pm
Go to the top of the page
Go to the bottom of the page

MagisterXero
Fledgling
GroupMembers
Posts44
JoinedFeb 11, 2010

This code was originally swrfuss, though.
       
Post is unread #33 Feb 20, 2010, 8:07 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

And then you tried to convert it to SWFotEFUSS to preserve your changes.

What I'm saying is to go back to your backup from before you tried to change it into a FotEFUSS and diff the changes you had made out and apply them to FotEFUSS. I guarantee it'll be a lot less of a headache then trying to figure out what was changed between SWR and SWFotE that wasn't caught by wincompare. Or where you placed something in wrong or the like. Because that's what it sounds like is happening. It sounds like either something wasn't caught, or something was pasted in out of place.
       
Post is unread #34 Feb 25, 2010, 6:32 am
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008

I actually encountered the posters original problem a couple weeks ago.

The fastest and probably the best way to stop this issue is to change max_buf_lines in build.c to 49 instead of 60.


Just to clarify, there are two different settings for max_buf_lines in edit_buffer in build.c.

There is the initial setting ( 24 in stock SWR ). Then the setting for progs and help files ( 48 in stock ).

In mud.h, struct editor_data is defined. The variable line is a two dimensional char array... the first dimension must be 1 greater than whatever the higher of your two maxes are above. So if you increase max_buf_lines, you will need to increase this array as well.

DV
       
Pages:<< prev 1, 2 next >>