Aperture-Development/MSync-2

MRsync does not show existing groups ingame

Bryantdl7 opened this issue · 32 comments

Ingame I am presented with this:

image


cat mrsync.txt 
{
	"nosync": [],
	"syncall": {
		"owner": true,
		"member": true,
		"retired-staff": true,
		"serveradmin": true,
		"grandmaster": true,
		"mod": true
	}

This behavior exists upon disconnecting and reconnecting. When I try and add an existing rank to the ingame window, I get the following error:


[ERROR] addons/msync-2/lua/msync/client_gui/modules/cl_mrsync.lua:74: attempt to index field 'settings' (a nil value)
  1. DoClick - addons/msync-2/lua/msync/client_gui/modules/cl_mrsync.lua:74
   2. unknown - lua/vgui/dlabel.lua:237


As a workaround, one can edit the txt file directly.

Are there any other errors happening at startup, maybe something like "Timer failed" ?

Is that the whole output of your mrsync.txt ?

I was able to re-produce your bug by modifying the mrsync.txt file to look like this:

{
	"nosync": [],
	"syncall": {
		"owner": true,
		"member": true,
		"retired-staff": true,
		"serveradmin": true,
		"grandmaster": true,
		"mod": true
	}

but it actually has to look like this:

{
	"nosync": [],
	"syncall": {
		"owner": true,
		"member": true,
		"retired-staff": true,
		"serveradmin": true,
		"grandmaster": true,
		"mod": true
	}
}

there is a missing } in your file as it looks like, otherwise I am unable to re-produce the bug

Here is the only timer thats failing:

Timer Failed! [Simple][@addons/acfmissiles/lua/autorun/server/sv_acf_missiles.lua (line 268)]

Also in other news, when I delete my users.txt and reboot it is still setting me to new, despite the rank being correct on the database when I disconnect. I don't know if that is worth troubleshooting at the moment, as last time I had weird issues it was my fault, but getting it out there.

The final right curly bracket I accidentally did not copy. it is in my file as you said it should be

I am unable to reproduce either bug. Without being able to reproduce the bugs I am also unable to fix them. I can only suggest you to maybe try deleting the addon and settings folder, and install it again using the new v1.0.3 release

Is there a specific file which pulls the contents from the setting file I can try running?

The initial startup of the addon manually gives no warnings or messages of concern:

lua_openscript autorun/msync_autorun.lua
Running script autorun/msync_autorun.lua...
[MySQL Ban Sync] Module loaded
[MySQL Rank Sync] Module loaded
[MBSync] Recieved ban data
[MSync] Module querys have been completed successfully
[MSync] Server saved to database
Compressing fragments (1244 -> 1138 bytes)
[DSTM] Bryant: !msync
L 05/12/2020 - 13:57:32: "[DSTM] Bryant<2><STEAM_0:0:26745653><Team>" say "!msync"


You can try to do:
on server:
lua_run PrintTable(util.JSONToTable(file.Read("msync/mrsync.txt", "DATA")))
lua_run PrintTable(MSync.modules.MRSync.settings)
lua_run MSync.modules.MRSync.loadSettings()

on client:
lua_run MSync.modules.MRSync.getSettings()
lua_run PrintTable(MSync.modules.MRSync.settings)

1

L 05/12/2020 - 14:13:06: "[DSTM] Bryant<2><STEAM_0:0:26745653><Team>" say "!msync"
 lua_run PrintTable(util.JSONToTable(file.Read("msync/mrsync.txt", "DATA")))
 lua_run PrintTable(util.JSONToTable(file.Read("msync/mrsync.txt", "DATA")))
> PrintTable(util.JSONToTable(file.Read("msync/mrsync.txt", "DATA")))...
nosync:
                1       =       true
syncall:
                member  =       true
                owner   =       true
                regular =       true
                retired-staff   =       true
                serveradmin     =       true
                superadmin      =       true


2

 lua_run PrintTable(MSync.modules.MRSync.settings)
> PrintTable(MSync.modules.MRSync.settings)...
nosync:
                1       =       true
syncall:
                member  =       true
                owner   =       true
                regular =       true
                retired-staff   =       true
                serveradmin     =       true
                superadmin      =       true



3

lua_run MSync.modules.MRSync.loadSettings()

MSync.modules.MRSync.loadSettings()...






 lua_run MSync.modules.MRSync.loadSettings()
 lua_run MSync.modules.MRSync.loadSettings()
> MSync.modules.MRSync.loadSettings()...


client---

1

] lua_run MSync.modules.MRSync.getSettings()
No output from this one...

2

lua_run PrintTable(MSync.modules.MRSync.settings)

One discovery I have made is that rank called simply "1". I never made that.

Steps I got to, in order to get the mysterious #1

  1. Wipe all configs for this addon
  2. Reboot
  3. Reconnect to db
  4. Enable rank sync module
  5. Reboot (as module tab is blank)
  6. Remove member rank from excluded (making excluded field completely empty)
  7. add member rank to included
  8. Start adding in other ranks mentioned
  9. Add another rank to the excluded field, such as guest

This mysterious #1 rank shows up ingame too:

image

Interestingly, not in the settings:

{
	"nosync": {
		"member": true
	},
	"syncall": {
		"superadmin": true
	}
}

Upon button mashing the sync server ranks button a few times, deleting number one, and pasting in a known rank, in this case VIP, I get the settings to finally update to this:


{
	"nosync": [
		true
	],
	"syncall": {
		"owner": true,
		"member": true,
		"retired-staff": true,
		"regular": true,
		"serveradmin": true,
		"superadmin": true
	}
}

Which does not line up with
image

Next, I will reboot. Giving me the initial problem:

image

It seems like the issue is that the settings stored locally do not know what to do when no values are present.

Do you have addons installed that modify default GMod behaviour? Like DLib for example.

We run ULX, Ulib, and WUMA for our restriction systems.

We do not run DLib.

We have a development team inhouse which make scripts, but nothing which affects systems like this.

I have removed our aWarn and gBans systems just in case this was the issue. This was way earlier than testing this issue.

It really seems like part of your code does not handle the removal of all restricted ranks properly. Perhaps have a dont-touch rank in there, and script the frontend to not see it as a quick fix?

Once things get messed up, even deleting the mrsync file and rebooting makes it come back to this error.

[ERROR] addons/msync-2/lua/msync/client_gui/modules/cl_mrsync.lua:74: attempt to index field 'settings' (a nil value)
  1. DoClick - addons/msync-2/lua/msync/client_gui/modules/cl_mrsync.lua:74
   2. unknown - lua/vgui/dlabel.lua:237

I will try rebooting the server under a different group to see if that helps.

Edit: Nope. Still missing.

Try commenting out line 131 and 133 in the cl_mrsync.lua

Commenting those lines worked to get me back to the original state. When removing the member field and replacing with user, on reboot it gets replaced with 1 again.

Removed 1, put in the group rankman, and now the group rankman wont do anything when I click add, it just stays stuck in the textfield.

I found a mistake in the code that I fixed and will commit in a second.

Please try downloading the Bugfix branch and see if that works for you: https://github.com/Aperture-Development/MSync-2/tree/bugfix

https://github.com/Aperture-Development/MSync-2/tree/bugfix resolves this issue, however, on the same theme of the UI, you may leave the rank field empty, and click apply. The system will not stop you from providing a nil value.

For example, I can leave the rank field empty, click apply, and there will be an empty rank field in its place in the list, that you can right click, and delete.

You may be able to add nil ranks to the list but

  1. They do not get saved to the config file
  2. This GUI is supposed to be used by professionals that know what they are doing

buuuut I did put in a verification for empty fields which seemed to not work, but I fixed that now.

Please try the newest commit from the same branch

2. This GUI is supposed to be used by professionals that know what they are doing

You have not been dealing with the Garry's mod community for long then! 😂

I agree, as I did notice and remove the mistake myself, but I guarantee if there's a thing that can break, someone will break it.

I will test the new bugfix commit and report on my findings.

I know the SUP principle, I tried to idiot-proof my addon, but with a development process of 2 years with a long break in between, some things got overlooked, I thought I tested the addon to the nerve, but without actuall usage scenarios its hard to find such things

The fix provided makes it so people are unable to enter any text into the box.

All I did first was try hitting add with nothing in there, then trying to add a rank to either field.

I will say the prior version is running great. I have it running on both of our servers now without issue. Happy to keep debugging this part on my dev server

I hope you are not talking about MSync 1, that reached EOL

MSync 2. The prior bugfix version which fixed my frontend UI issues. As mentioned above the latest bugfix branch made it so I could not add any ranks, so I opted to not add that version.

Try this bugfix, it should fix the SUP check and prevent you from being able to add empty strings or strings that just consist of whitespaces or strings that end with a whitespace

Did you try the bugfix version? I would push it to development now and then start to implement the GroupChanged hook of ULX

I am testing this now, I will update in 5 minutes or so with my findings

  • Confirmed Ranks can be added, and show up in appropriate settings file
  • Confirmed Ranks may be removed and necessary updates happen in file
  • Confirmed empty fields / spaces do not work
  • Confirmed trailing spaces do not apply e.g. "mod "
  • Failed leading spaces DO apply e.g. " mod"

This also leads to saving into the file as well:
image

I added a check to prevent the user from adding ranks with a leading whitespace, you can find the latest update version in the MRSync branch:
https://github.com/Aperture-Development/MSync-2/tree/MRSync

This is now working in the MRSync branch. I retested based on the applicable use-cases above and did not run into issues.

Great! I will close the issue now as it seems to be resolved