Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 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, Yandex, Google

Members: 0
Guests: 8
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 » Not my fix, but...
Forum Rules | Mark all | Recent Posts

Not my fix, but...
< Newer Topic :: Older Topic > Thought I would throw it out there

Pages:<< prev 1 next >>
Post is unread #1 Mar 18, 2005, 9:50 pm   Last edited Feb 2, 2006, 5:50 pm by Samson
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

I didn't find it, or fix it, but here it is none the less...
Scenario:
A player with a descent amount of bounty on his head auctions a vibro blade for a newbie, and during the auction, he is attacked and killed. So when the auctioneer tries to pay off the credits that the newbie had paid for the vibro, the auctioneer can't find the seller because at this point he is dead, and logged out of the mud.

Fix:
This little bug comes from before SWR, when the codebase was originally Smaug. In the Smaug codebase, players aren't disconnected from the mud when they die. They just go back to recall, and start over again. To fix this little problem all we have to do is just check if the player who is dieing has auctioned anything. We can add something like this to the function raw_kill in fight.c which is where all the death stuff happens. Right under the line that reads ..
/* swreality changes begin here */

add ...
/* Check if they have an ongoing auction */ 
        if (auction->item && (auction->seller == victim))
        {
                talk_auction("Auction has been halted.";);
                obj_to_char(auction->item, auction->seller);
                auction->item = NULL;

                if (auction->buyer != NULL
                    && auction->buyer != auction->seller)
                {
                        auction->buyer->gold += auction->bet;
                        send_to_char("&YYour money has been returned.

",
                                     auction->buyer);
                }
        }



This comes from here: http://www.swreality.net/auctionfix.htm

There are also several other fixes from this page: http://www.swreality.net/Coders.htm

I'll make replies to this shortly outlining them. Again though, not my fixes.
       
Post is unread #2 Mar 18, 2005, 10:27 pm   Last edited Feb 2, 2006, 5:51 pm by Samson
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

I learned about this little bug the hard way. The player had no ill intentions, he just wanted a spiffy title for his room. Something along the lines of "-==-". Well, the entire problem lies with the tilde sign. "~" This is used to designate the end of a line in some parts of the area file, one of which is the roomname.

Fix: Lucky for us, SWR already comes with a function to remove the tilde symbol from strings. It's called smash_tilde. This little function parses through a string and changes all of the tilde symbols to "-". So to fix this little problem all we have to do is add the line ...

smash_tilde( argument );
right before it actually allocates the name to the area file. That line looks like ...

room->name = STRALLOC( argument );
So if we put our smash_tilde line anywhere before that line, we should be safe.


For example:

   if( argument[0] == '\0' )
   {
      send_to_char( "Set the room name.  A very brief single line room description.\n\r", ch );
      send_to_char( "Usage: Buyhome <Room Name>\n\r", ch );
      return;
   }

   smash_tilde(argument);
   STRFREE( room->name );
   room->name = STRALLOC( argument );

   ch->gold -= 100000;
       
Post is unread #3 Mar 18, 2005, 10:29 pm   Last edited Feb 2, 2006, 5:52 pm by Samson
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

This little bug was brought to my attention by one of my Imms (Ravious) that had figured it out. This little bug is very hard to track unless you know what to look for, because the entire process is totally legit.

Scenario: A player, along with one of his friends enter an empty aparment along with all of their belongings and gold. Since this is totally legit for two players to enter an empty apartment, there is nothing wrong with this. One player buys the home, and drops all of his belongings and gold, and logs out. The second player can then pick up all of his belongings, and gold. Then the second player logs back in, and the mud resets all of his belongings in his room not knowing that these objects were already picked up by his friend who was waiting in his home. He can then get all of the objects that were loaded ( on the floor ), plus the objects his friend had picked up on his absense. Then drop them again, and repeat the process until he can't hold anything else, or his credits are about to roll over. They then leave the player home a lot richer for their endeavor's.

Fix: There is a simple fix to this, and that is just to make sure that there is noone else in the apartment when the apartment is bought. We can edit the do_buyhome function, and put in something along these lines to it.

(At the top of the function)
CHAR_DATA *vch;
int ppl=0; 
(Then later on in the function where it seems relevant)
// This part loops through the room to see if there is anyone else in the 
// room and increments the integer "ppl" accordingly. It does not take into 
// account if an Immortal is standing in the room. ( If you can't trust
// your Imms, who can you trust? 
for ( vch = ch->in_room->first_person; vch; vch = vch->next_in_room )
        for (vch = ch->in_room->first_person; vch; vch = vch->next_in_room)
                if (vch != ch && !IS_IMMORTAL(vch))
                        ppl++;
        if (ppl > 0)
        {
                send_to_char("The room has to be empty first.\n\r", ch);
                return;
        }

Note: I have also had some players asking if I could put in something so they could invite people into their homes. I wonder why?
       
Post is unread #4 Mar 18, 2005, 10:34 pm   Last edited Feb 2, 2006, 5:53 pm by Samson
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

This little function will remove color codes from strings. This is used primarily for makearmor, makeshield, etc. etc. So that engineer's can make all those pretty colors in the names of their EQ and not have to worry about whether or not they'll be able to wear it.
An example of using it can be found in do_makearmor instead of using something like this ...

obj->level = level;
STRFREE( obj->name );
strcpy( buf, arg2 );
obj->name = STRALLOC( buf );
strcpy( buf, arg2 );

We could change the line obj->name = STRALLOC( buf ); to look like ...

obj->name = STRALLOC( smash_color( buf ) );
WARNING TO NOVICE CODERS: The smash color function returns a pointer to a static variable, so although changing the example line to obj->name = smash_color( buf ); will compile very nicely, it has "undetermined" effects. In theory what will happen is the next time someone makes a piece of armor, any other piece of armor that was made, and is still "in the game" since the last reboot will be renamed to the same name that was last used. Although this could very well be humorous, I doubt it is the desired effect anyone would like.

INSTALLATION:

All you really need to do is cut and paste this little function in any file you want and add this line to mud.h somewhere ( preferrably where all the other function declarations are ) char *smash_color args( ( char *str ) ); Once you have added this little line to mud.h and put the following code in a file, it's ready to use. Just remember to use those STRALLOCS!

NOTE:

I just opened up swskills.c and did a search for do_make and anywhere I saw

obj->name = STRALLOC( buf );
I changed to ...

obj->name = STRALLOC( smash_color( buf ) );
char *smash_color( char *str ) 
{ 
    static char ret[MAX_STRING_LENGTH]; 
    char *retptr; 

    retptr = ret; 
    for (; *str != '\0'; str++ ) 
    { 
        if (*str == '&' ) 
            str++; 
        else 
        { 
            *retptr = *str; 
            retptr++; 
        } 
    }  
    *retptr = '\0';
    return ret; 
}



I found this particularly annoying before I ever started coding and only played on SWR's, if you hade something called "A blue lightsaber" in a light blue color, every time you needed to reference it you had to add the color, like "get &bblue". I guess this could also be added to the get function, but this does make the object alot cleaner.
       
Pages:<< prev 1 next >>