Mutual buddies do not seem to work

[uPlayEveLLC]

Hello!

I've recently started writing a custom buddy persistence class for my server. I've written the most of it, however, I noticed some issues which I cannot figure out.

Here's the config.xml settings, related to BuddyList:

Screenshot_2.png

(12.1 KiB) Not downloaded yet

Whenever I use _server.addBuddy and _server.removeBuddy, even though the mutual options are on, mutual buddies are not added or removed (buddies are removed from the owner's list, though). Edit: according to this thread: viewtopic.php?f=4&t=6133&hilit=removeofflinebuddy we also need addBuddyPermission set as true. However, it won't work still. I decided that it could be something to do with the _server instance so I decided to try zone.removeBuddy. These docs: https://www.smartfoxserver.com/docs/1x/ ... /index.htm did not make it clear whether the both arguments have to be strings or one of them should be a user instance. I found this javadoc: https://www.smartfoxserver.com/docs/1x/ ... /index.htm which apparently states that both have to be an instance of a string. Decided to try both ways and here's the scenario in both cases - no errors are thrown and it just stays silent. If I decide to close the connection within 1-2 minutes from my browser, it shows a thread writing error, otherwise it handles userLost gracefully. No functions from the persister are called.

Edit 2: Apparently, _server.removeBuddy does remove the offline buddy from SmartFoxServer's local buddy list, but it does not call saveList or removeOfflineBuddy.

Does anybody have any idea how to get those mutual add/remove buddy working? While working on this issue I've realized that what I'm doing is pretty useless as I could've handled everything from the server API itself and not the persister but I decided that it'd be nice to practice some java and try a custom persister class.

I also have yet another question: is there any way to check buddy blocked status apart from iterating over the whole buddy list? Basically, on login, I have a zone.checkBuddy thing which, if evaluates to true, sends a packet to show that buddies are online in the zone. However, I do not want to send that packet if all of them are blocked, or it is just a single buddy that's blocked.

Thanks in advance for the help!

[uPlayEveLLC]

Hello everyone!

Since my question has been ignored for more than 24 hours and it was a very urgent problem to solve, as a bonus the documentation does not even make it any clear, I decided to do a workaround. It does apparently save the local sfs buddylist but that's it and I'm not sure if another function has to be overridden in order for removeOfflineBuddy to be called in the persister.

The workaround algorithm is simple - use your extension where you typically would handle buddies - whenever removing a buddy, remove it from the user's list who has requested the removal with _server.removeBuddy, check if the buddy is online somewhere around the zone with getUserList() (apparently we gotta iterate through the whole list), if they are, get their user instance and perform _server.removeBuddy for them as well. However, if they aren't, just go ahead and execute the code you would typically put in removeOfflineBuddy. In my case, I use a database to store buddies (more efficient that writing everything to files like the basic BuddyList does).

Honestly, I would've loved to use the persister, well, because that's what it's made for and as I've previously stated, to just keep it organized.

My second question has not been answered either but I figured it out myself (not sure if what I'm doing is good practice or many people do it) - since I'm already going through the whole user's buddy list in order to perform checkBuddy for each one, I figured that actually you can just call on that one isIgnored() and execute the code needed. When you go through loadBuddyList(user).buddies, please note that it returns LoadableBuddyItem and not StorableBuddyItem.

[Lapo]

Sorry for the delay. SmartFoxServer 1.x is an old product that we only maintain in terms of security issues and has lower priority in the forums. In any case, if you have a commercial license, you can contact us directly via email (support@...) to expedite the process.

As regards your post there are a few things that are unclear:

Whenever I use _server.addBuddy and _server.removeBuddy, even though the mutual options are on, mutual buddies are not added or removed

This seems weird, those two operations are independent of the custom persistence class, unless maybe if there's a runtime exception during one of those calls.
Have you checked the logs for problems?

Apparently, _server.removeBuddy does remove the offline buddy from SmartFoxServer's local buddy list, but it does not call saveList or removeOfflineBuddy.

It should work as the removeOfflineBuddy is called when BuddyListManager.removeBuddy is invoked, provided the BuddyList is configured in mode ADVANCED and mutualRemoveBuddy is active.

Cheers

[uPlayEveLLC]

Sorry for the delay. SmartFoxServer 1.x is an old product that we only maintain in terms of security issues and has lower priority in the forums. In any case, if you have a commercial license, you can contact us directly via email (support@...) to expedite the process.

Alright, I understand.

This seems weird, those two operations are independent of the custom persistence class, unless maybe if there's a runtime exception during one of those calls.
Have you checked the logs for problems?

There's nothing in the logs about errors (log level is FINE) and that seems to be weird. There's only a row which states that the user who has accepted the buddy request has got his buddy list saved.

It should work as the removeOfflineBuddy is called when BuddyListManager.removeBuddy is invoked, provided the BuddyList is configured in mode ADVANCED and mutualRemoveBuddy is active.

Doesn't seem to happen. One of the topics I have mentioned above was about the same issue but the starter never replied back, so I suppose it happens in certain cases. I've got it fixed in my case with a workaround, it was just that somebody else might come across this topic and won't figure it out as well.

Thanks for your time, though.