Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
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
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
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, Yahoo!, DotBot

Members: 0
Guests: 19
Stats
Files
Topics
Posts
Members
Newest Member
477
3,705
19,232
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SmaugFUSS » Bug (?) with projectiles?
Forum Rules | Mark all | Recent Posts

Bug (?) with projectiles?
< Newer Topic :: Older Topic > Bug or unintended result?

Pages:<< prev 1 next >>
Post is unread #1 Dec 14, 2016, 8:42 pm   Last edited Dec 15, 2016, 1:02 am by GatewaySysop
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts367
JoinedMar 7, 2005

Hi all,

While my older, patched up Smaug base (I want to say from the 1.4 FUSS days) has been kept more or less current, I am fairly certain most flavors still have this kind of behavior to one degree or another, so thought I'd post up since I've been on a MUD kick lately and had ran into this while testing something related (thrown item code, which is heavily based on projectiles, obviously).

Issue: you fire a projectile into a portal, e.g. "fire bow portal" and, because portal is often the direction "?" or "somewhere", if and only if the projectile doesn't hit anyone and tries to continue on (not yet out of range) in the same direction, it will do so by coming back through the portal at you.. :lmao:

As I said, some may call that a bug, some perhaps an unintended side effect. Personally, if I fire an arrow or throw an axe into a portal at someone/thing, I would not expect nor want it to potentially fly back out at me and strike someone in the room.

Again, my code is somewhat different from Smaug FUSS 1.9 as it exists today, but you can find the relevant code for the current release in skills.c, look for the function
ch_ret ranged_attack( )
and, in particular, this part:
      if( dist == range )
      {
         if( projectile )
         {
            act( color, "Your $t falls harmlessly to the $T.", ch, myobj( projectile ), dir_name[dir], TO_CHAR );
            act( color, "$p flies in from $T and falls harmlessly to the ground.", ch, projectile, dtxt, TO_ROOM );
            if( projectile->in_obj )
               obj_from_obj( projectile );
            if( projectile->carried_by )
               obj_from_char( projectile );
            obj_to_room( projectile, ch->in_room );
         }
         else
         {
            act( color, "Your $t fizzles out harmlessly to the $T.", ch, stxt, dir_name[dir], TO_CHAR );
            act( color, "$t flies in from $T and fizzles out harmlessly.", ch, aoran( stxt ), dtxt, TO_ROOM );
         }
         break;
      }


My suggestion, if you want it to go through the portal and just stop trying to continue on, is to simply augment the ifcheck at the top, i.e.

	if ( dist == range || dir == 10 ) 


I thought about something more involved, i.e. have it pick a random, viable direction on the other side of the portal, but that just seemed silly. If your destination has more than two exits, and they are opposite each other in at least once instance, sure, you can say it comes in from "somewhere" and "flies north", say, but in the case where your only exits are, say, N and W, the idea that the projects "flies in from somewhere" followed by "flies west" would suggest it changed direction in mid-flight. Personally I prefer the approach that traveling through a portal robs it of momentum so when it pops out the other side, if it doesn't hit anyone, it basically flops to the ground, and so that's what the above achieves.

The astute observer might notice that falling to the ground "to the somewhere" is probably not the most ideal message to the person who fired/threw the projectile into a portal. In the code I have (and I don't even know if I changed this or someone else did, it's been a while), it is split up by direction so that in some cases (i.e. up, down, 'somewhere') it doesn't return a direction. That's something of a separate issue from this bug, but if you're picky like me, you might think about tinkering with the ACT( ) calls while you're in here.

Example:

	    if ( projectile )
	    {
                if ( dir == 4 || dir == 5 || dir == 10 )
  		    act( color, "Your $t falls harmlessly to the ground.", ch, myobj(projectile), NULL, TO_CHAR );
                else
 		    act( color, "Your $t falls harmlessly to the ground to the $T.", ch, myobj(projectile), dir_name[dir], TO_CHAR );

		act( color, "$p falls harmlessly to the ground here.", ch, projectile, NULL, TO_ROOM );


Again, beside the point of this post, but there you have it, in case it helps anyone.

As for the bug itself with projectiles returning back, open to suggestions, but for me, the above seems to work just fine and is a relatively painless fix. As I said, I found this while testing thrown item code which is heavily based on the projectile code, so if you've gone the same route (and I know many have), you probably have to fix it there as well.

Hope this helps someone!
       
Post is unread #2 Jan 7, 2017, 8:39 am
Go to the top of the page
Go to the bottom of the page

Sadiq
Fledgling
GroupMembers
Posts24
JoinedJan 7, 2010

Implemented. Thanks! :smile:
       
Pages:<< prev 1 next >>