Party System
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.
[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.
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
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.
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: Select all
if ( GetGlobalProperty("#restartingserver") )
return 0;
endifThere 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.
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: Select all
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;
endfunctionYou should do some simple packet capturing, because this looks recursive to me. This is the reason:
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:
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.
Code: Select all
sending_stat :=1;
packet.SendPacket(member);
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: Select all
// sent by this script.
if ( sending_stat )
sending_stat := 0;
return 0;
endif
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.
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.
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.
Re: Party System
Code: Select all
# $Id: pkg.cfg 523 2006-06-30 17:36:14Z tekproxy $
#
Enabled 1
Name partysystem
Version 1.2
CoreRequired [b]97[/b]Re: Party System
there's complete pol96 party system in WoD shard files
ya can download it here:
http://forums.polserver.com/viewtopic.php?f=8&t=1755
ya can download it here:
http://forums.polserver.com/viewtopic.php?f=8&t=1755
Re: Party System
thx )Targun wrote:there's complete pol96 party system in WoD shard files
ya can download it here:
http://forums.polserver.com/viewtopic.php?f=8&t=1755
Re: Party System
Tekproxy, nice party system indeed. Used this as a base to add party system support on my shard aswell.
I just want to point out that I found a typo where you were looking for packet.Length() instead on packet.Size()
and then you should Remove the property "#PartyCanidates" when leader removed.
and then you should add checks if "#PartyCanidates" prop has a value of 1 or what when using it, because I got many problems with this when the prop value dropped to -1.
I fixed the Logoff part where Pol gives exceptions due to start_Script launched on server shutdown or restart. I fixed this by adding a check in logoff if the character is in a party and then almost copy pasted the handlePartyRemove code in it.
Automatic decline after 10 seconds after invite does crash the client. I packetlogged RunUO party system and found out that they just simply throw some partyremove packets. This fixed the client crash, but after this I had to add some checks for "#JoiningParty" props in handlePartyDecline, handlePartyAccept and a check for prop "#Party" in handlePartyLoot. This fixed the wrong messages you got later after force declined by remove package.
Use party packeted messages only when really sending a PartyChat or PartyMessage, because during remove from party, the leader get the message [character] Joined the party. even if you make the packet send something else, and sysmessages were the only workaround I found for this.
Then suggestions:
- Notify the whole party when someone is invited.
- Notify the whole party when someone joined and was removed.
- Add different messages for different situations when party was disbanded ( by leader, members < 1 and so on. )
and after all this Thank you Tekproxy for this, thx to this I was finally ably to build the packets correctly and with some small repairs and editing in this it works very nicely
I just want to point out that I found a typo where you were looking for packet.Length() instead on packet.Size()
and then you should Remove the property "#PartyCanidates" when leader removed.
and then you should add checks if "#PartyCanidates" prop has a value of 1 or what when using it, because I got many problems with this when the prop value dropped to -1.
I fixed the Logoff part where Pol gives exceptions due to start_Script launched on server shutdown or restart. I fixed this by adding a check in logoff if the character is in a party and then almost copy pasted the handlePartyRemove code in it.
Automatic decline after 10 seconds after invite does crash the client. I packetlogged RunUO party system and found out that they just simply throw some partyremove packets. This fixed the client crash, but after this I had to add some checks for "#JoiningParty" props in handlePartyDecline, handlePartyAccept and a check for prop "#Party" in handlePartyLoot. This fixed the wrong messages you got later after force declined by remove package.
Use party packeted messages only when really sending a PartyChat or PartyMessage, because during remove from party, the leader get the message [character] Joined the party. even if you make the packet send something else, and sysmessages were the only workaround I found for this.
Then suggestions:
- Notify the whole party when someone is invited.
- Notify the whole party when someone joined and was removed.
- Add different messages for different situations when party was disbanded ( by leader, members < 1 and so on. )
and after all this Thank you Tekproxy for this, thx to this I was finally ably to build the packets correctly and with some small repairs and editing in this it works very nicely
Re: Party System
Anyone have this version for POL 095 pls???
Re: Party System
No one. Packethooks available from 096 AFAIR.
Re: Party System
If you're still using 095, it's about time to update anyway.
Re: Party System
EH, anyone know the auto converter of scripts? XD
Re: Party System
There is no auto converter from 095 to 096 because there weren't as many syntax changes but there was some restructuring in the way systems worked. It may take you a while (took me months) but its worth it in the end.
Re: Party System
I'm converted the 096 party to 095 but ingame the command for add ecc.?
Re: Party System
I have been very busy with school lately, but I think I have some time now since I quit some other activities. Yeah, I see now that there are some problems and I'd like to fix them. However, it seems the package was removed from the latest distro because the core handles it now. I remember someone telling me it wouldn't be added to the core because they wanted to keep party functionality configurable. 
Re: Party System
hehe. Configurable it is. All config and syshook for the majority of everything 
Re: Party System
lol. so if you want to play with it, figure out some of the hooks for us! 