Party System

Repsak · **Posted:** Thu Aug 24, 2006 1:25 pm

Thanks, he is a few more bug reports (and fixed when I was able):

BUG1: P1 send an invitation to P2. When P2 declines(either automatic or /decline), he is informed that â€œYou notify them that you do not wish to join the part.â€

tekproxy · **Posted:** Thu Aug 24, 2006 2:33 pm

I'm not sure how I missed all of these. I tested all of this stuff and now it's broken. Wahh. Ok, fixing now...

[edit]
Ok fixed the first two bugs. The third looks like the packets are not formed correctly. The fourth bug has to do with looting, but that text about "You've chosen bla bla." is handled entirely by the client. I'll have to check if I am not forming the packet correctly.

Repsak · **Posted:** Thu Aug 24, 2006 2:59 pm

Thats what I call fast responce.
Let me/us know when you make a release, and ill start the testing right away.

tekproxy · **Posted:** Thu Aug 24, 2006 5:23 pm

Ok fixed the first three bugs and tested it. The fourth one I mention in the readme and I don't think I'll be able to fix that without some time or some packet logs. Thanks for testing it and lemme know if I messed something up.

Repsak · **Posted:** Thu Aug 24, 2006 5:49 pm

Fast worker.
Ill start testing tomorrow.

OldnGrey · **Joined:** Sat Feb 04, 2006 10:26 pm **Posts:** 533

There is one bug in this that annoyed me until I finally did something about it.
It was when a shard initiated a shutdown and forced the players to logoff.
The shard would save and then start a shutdown. It would then bring up an exception if there was someone in a party.

I think the exception is caused by the PartySystem\logoff.src trying to Start_Script during a shutdown.

The fix is easy enough though:
Add 3 lines to the start of PartySystem\logoff.src

Code:

if ( GetGlobalProperty("#restartingserver") )
   return 0;
endif

In your shard restart or shutdown timer script, simply set the #restartingserver global property. I do it 5 minutes before the actual shutdown. I also use the gprop to stop decay of items and corpses.

OldnGrey · **Joined:** Sat Feb 04, 2006 10:26 pm **Posts:** 533

There is still one other bug that spams the console from the party system.

doPlayerStatus.ecl exceeded maximum call depth.
Return path PCs: 12 12 12 12 ......etc

Since the party is only 3 people I doubt it's anything to do with overload. It still seems to work fine in the game though.

Anyone any ideas?

This is the entire packethook. It's very simple and isn't recursive.

Code:

const DEBUG := 0;
const OFFSET_UPDATE_STAT_PLAYERID := 1;
const PARTY_PROP := "#Party";
const PARTY_STATUS_UPDATE_DISTANCE := 19;

exported function handleUpdateStat(character, byref packet)
   // Sending the stat packet will cause the core to want to handle THAT packet as well
   // So if we are sending stat packets out, ignore the packet as it is probably being
   // sent by this script.
   if ( sending_stat )
      sending_stat := 0;
      return 0;
   endif
   
   var id := packet.GetInt32(OFFSET_UPDATE_STAT_PLAYERID);
   var party := GetObjProperty(character, PARTY_PROP);

   if ( DEBUG )
      Print("handleUpdateStat - character: "+character.name+"   packet: "+packet);
   endif

   // Is the character in a party?
   if ( Lower(TypeOf(party)) == "array" )
      var member;

      foreach member_id in (party)         
         // Do not send modified packet to character since they are already getting one
         if ( member_id != id )
            member := SystemFindObjectBySerial(member_id);
            
            // Only send this packet if the party member is close enough to the character
            if ( member && Distance(member, character) <= PARTY_STATUS_UPDATE_DISTANCE )
               sending_stat := 1;
               packet.SendPacket(member);
            endif
         endif
         SleepMS(2);
      endforeach
   endif

   return 0;
endfunction

Xpatriat · **Joined:** Sat Aug 04, 2007 6:51 pm **Posts:** 7

You should do some simple packet capturing, because this looks recursive to me. This is the reason:

Code:

sending_stat :=1;
packet.SendPacket(member);

You're sending the same packet back out, which causes the same packet hook to again be called - and they work critical. If it weren't for the maximum call depth thing, this packet hook would freeze your shard.

With a party of two, you won't get your error because of the code at the top that checks for the sending_stat global var:

Code:

   // sent by this script.
   if ( sending_stat )
      sending_stat := 0;
      return 0;
   endif

But look closer: That code also sets sending_stat back to 0. So with the third and subsequent player, the packet hook WILL run again, causing recursion that only ends when the maximum call depth is exceeded.

Packet hooks run critical, in a single 'process'. Check the script profiles some time and you'll see that only one copy of doPlayerStatus.ecl is ever executed.

OldnGrey · **Joined:** Sat Feb 04, 2006 10:26 pm **Posts:** 533

What you say makes a lot of sense, but I must admit I still don't quite get it. Does packet.SendpPacket go through the packet hook all over again or just get sent out?

If what I read is correct, a sendpacket packethook should simply return 0 if the core is allowed to send it and not have it's own sendpacket. But I guess what the hook is trying to do is create an extra packet to ensure that all the party status bars are onscreen.

Now to solutions:
It occurs to me that the v5 and above client automatically keep a status bar open but greys it out while you are out of range of the player. Therefore the only reason to want this packethook at all is to initiate a status bar for all party members. So maybe we can simply create a single packet when you join a guild. TekProxy wrote this and would have a better idea about how it all hangs together.

However, not all shards use the v5 client, so that may not be enough as older clients drop the status gump when you are out of range.

PenUltima Online

Party System

Who is online