Aperture-Development/MSync-2

Bugreport - Addon writes to users.txt still

Bryantdl7 opened this issue · 12 comments

Hi there,

in the latest version I realized ranks done either via ulx adduserid or ulx adduser end up in the users.txt. Surely I could just make the file read-only, however, I wanted to report this bug.

Also, it would be nice to have a verbose entry in console for when someone is updated in the database successfully, for peace of mind. I found out the hard way that this was still writing to the users.txt, and thus someone kept their rank despite me removing it!

This is not a bug and in fact intended behaviour. As I stated in the past, MSync is supposed to work alongside ULX and not intrusive and overwriting. And normally MSync should load the ranks after the user has already been loaded by ulx, so that the rank gets set to the default rank after the user loaded

The problem we run into, is sometimes the users.txt doesn't update, only msync does. As both are still considered, this can cause for people to not be properly adjusted, and in our case, someone who was supposed to be demoted wasn't. This problem did not occur prior to using your addon.

I have implemented a bugfix for that behaviour, users should now be removed from the MRSync database when you demote them, and if MRSync notices that the user is not in a nosync rank and that his rank isn't user, it removes him entirely from ULX

Well, the bugfix is not yet published

There has been no activity in this issue for 6 days. If there is no reply within the next 24 hours, this issue will be closed and marked as "resolved"

Yes, I would like you to try out the development branch if possible

This appears to be functional. I am able to pull my rank from the one server, and joining the other I keep the rank applied.

I still worry that users.txt will hold priority, but I will need further testing to see if that is a problem. The code seems solid functionality speaking, but when traversing between three different servers is when I will know for sure.

Alright, I will PR it into the development branch then

While running this development branch on my server, I have noticed that we will periodically get extremely laggy until the entire map is cleaned up. I have reverted to the stable version at this time. Perhaps one of the functions you added in runs inefficiently and uses more CPU than necessary?

Not really, the addition is so small it shouldn't affect the performance at all also it has nothing to do with the map, this would imply that MSync would spawn anything on the map, this is more likely caused by something else

I am currently in the process of implementing the advanced logging abilities into MSync. In the future you will be able to set a debug level to get more or less console output from whats happening in the background