Party Bug in DS3.0

[Sluggy]

Ok here I go again with crying wolf, but this time it's confirmed for a virgin install of DS3.0. Actually, it's been around since like 2.7 or 2.8 and I mentioned it in one of my old threads.

If a player creates a party and then the mud is warmbooted or rebooted, they can no longer use that name for any future party.

As well, I just learned that if a player creates a party called 'test' they gain access to the 'test' intermud channel even if they haven't yet been given access to intermud.

[Sluggy]

Ok, for the first problem it appears that when the mud is shutdown the player is never properly removed from the party. This leaves the channel for that party in their save file which is then re-added to their channels list when then log back in (didn't think to check to see if the channel still worked). Now when the same player issues the part create command, it calls PARTY_D->eventCreate() which in turn calls PARTY_D->CanCreate(). This function checks to see if the player already has the channel for the party in their list and if so, says they can't create the party because the name is in use. I tried creating the party with another character and it worked fine.

As far as the second issue is concerned, I'm guessing their is a hidden channel called test that is common for intermud. When creating a party it must check for the preexistence of a channel and simply attach to that. In this case, it's an intermud channel. At least, that's my guess. Haven't really had time to look into it.

[cratylus]

Fixed in 3.1a10.

Thx

[Sluggy]

Awesome! Thanks.

I don't suppose you could tell me if you edited any files other than /daemons/part.c to fix this?

[Raudhrskal]

Download 3.0 and 3.1a10, run diff -Nru on the dsX.X/lib/ dirs, and use Common Sense parsing the results?
That's what I always did whenever a new version came out. Added bonus - the diffs can often be /usr/bin/patch'd onto a customized lib with no additional effort.

[Sluggy]

Normally I would do something like that if I were doing a full merge of all the code.

I have made numerous changes to hundreds of the Stock DS files. As a result, perfomrmng a full merge is time consuming and always adds an element of instability. Right now, my current version merged with 3.0 is quite stable and I don't want to ruin that.

Checking for differences might tell me what's changed but it takes a little more time to see what is directly related to this particular situation. Hence, the reason I asked. It's just faster and easier.  If Crat can't tell me for one reason or another then, yeah, I guess that's exactly what I'll do.

[cratylus]

I can barely remmeber what I had for breakfast just this morning

You're better off with the diff.

-Crat

[quixadhal]

diff -bura --brief works well, just to find which files have changed.