XGUI - Fully featured modular GUI for ULX! (Included with ULX v3.51 and SVN)

[JamminR]

RE: Server sbox limits
1) server.cfg will always overwrite at server startup whatever you set previously, even with/in 'old' ULX menus. This is a Source file that Gmod uses. You wouldn't want an admin mod to overwrite it, as an admin mod can't know all that you may have set in it.

2) If you set an sbox limit that isn't set in server.cfg, the _ONLY_ way it will save for next time is IF the server is shutdown normally.
It will not save if the server crashes. This has been a Gmod 'bug' for a long time.

Though we could write code to enhance the sbox limit saving/restoring, it would complicate what is already a, well, mess of Gmod code that doesn't handle settings across crashed sessions already.

[gte6495]

Thanks so much

I'm glad I could help the debugging process, with a bug I accidentally found xD!

And in regards to saving sandbox limits, adding that feature would be great, because manually adding each limit to the .cfg can be a bit troublesome :3

Thanks again

[JamminR]

Aaron, Gte, the limit setting not saving between servers isn't a ULib/XGUI bug.
Garry never wrote in the ability of saving updates at the time they are set, he waits until the server gets shut down using 'exit' or 'quit'.
And, of course, we all know how often that gets to be done naturally. 

[Stickly Man!]

However, It wouldn't be too *horribly* difficult to at least put an option in there to have XGUI save them to a file when the cvar limits are changed... I think...

Then again, back when I started XGUI, I thought I could have it done in a couple months, tops! 

[JamminR]

Stickly, though adding it is an option, we then run into the problem with those who use server.cfg to set things.
They may go to another forum and ask "I set blah blah in my server.cfg, it never remembers" "What admin mod do you use" "Oh, ULX with XGUI" "Then ask the author to fix it, it overrides server.cfg"

[Stickly Man!]

I'd save them in my own file on the server, so that every time XGUI loads, it will load the defaults from that file, thus overriding the default server.cfg. Plus, I don't think you can write outside of the data folder without something like a rawio module

[JamminR]

"I set blah blah in my server.cfg, it never remembers" "What admin mod do you use" "Oh, ULX with XGUI" "Then ask the author to fix it, it overrides server.cfg"

thus overriding the default server.cfg.

That's just what I'm saying. There's no easy (that I see) non complicated lesser evil way to do it.
You could read in server.cfg then not override what ever is there, but that in itself would add complication.

[Stickly Man!]

Oh I see what you were saying, Thought you were talking about me actually CHANGING the server.cfg file.. Even though I used the same wording in my own post.

Either way, If I did implement something like this, it would definitely be a toggleable option, probably NOT enabled by default, if that eases your fears

[gte6495]

I found an XGUI bug that I thought I might point out, considering it has forced me to restart my server twice:
(And it's  not something I can take screens of or show an error message, unfortunately)

I finished setting up all my teams and groups the other day, through XGUI.
But once everything was finished, I decided to rename the "operator" group to "moderator".
And that was a bad idea;

For some reason, when you change the name of a group through XGUI, it prevents any more changes to the teams.
I cannot add, remove, change, apply teams through XGUI, it simply does not respond.
Not sure what to tell you as for errors, because there are no errors in the console, it just stops working, until you restart the server.

Even when I change the newly renamed "moderator" group back to "operator" it is frozen up, nothing can fix it besides a restart.

[Stickly Man!]

Hmm, that's an interesting issue, There might have been something I've overlooked. I'll check it out later tonight when I get home from work.

[Stickly Man!]

<bug>

Hmm, I checked it out and found out it was an error on both ULX and XGUI (due to how XGUI handles teams). I have fixed both the ULX and XGUI versions, but unfortunately we won't be able to push them just yet. (At least, Megiddo might, I can't )

In the meantime, you can use "xgui getadata teams" in your console to manually refresh the teams in the XGUI groups module.

Thanks for reporting this!

[Stickly Man!]

Alright-- tis' about time for an Update! 

Bugfixes and LOTS of optimizations in this update! I made lots of changes to the backend that deals with processing data retrieved from the server. Another key optimization point is that now when a ban is added/updated, it doesn't trigger a re-download and re-processing of the ban data.

Also, you can now set the "can_target" field on groups! This is used by default for immunity purposes, but can be configured to your liking. All you need is knowledge about Megiddo's targeting system

The "maps" module is now fully permissible, and has been polished so that each button behaves properly (enable/disable)

The last main thing to note is that XGUI now supports the setting of a Derma Skin!:



You should note that the support is very basic, and there may be some bugs/drawing issues based on which skins you use.


Anyways, update your SVN's! Download your gits! Checkout the full changelog below, and enjoy!


 

Code: [Select]

08/29/2010
-----------------
+Added: Preliminary support for applying a derma skin to XGUI.
 -Can save to the clientside XGUI settings file.
+Added: You can now set the "can_target" value for any group via textbox.
+Added: For admins, individual votemaps are the maps module are now distinguishable from the non-votemaps.
*Changed: Optimization: XGUI no longer refreshes ALL of the bans when a ban is added or updated.
*Changed: Maps module now completely obeys permissions-- Buttons are enabled/disabled based on access, if a map is selected, or whether there is a need for a veto.
*Changed: Major optimization changes in clientside processing:
 -Created a duplicate of ULib's queueFunctionCall specifically for XGUI use.
 -Processes 3 queues at a time (Significantly faster while still reducing lag jumps)
 -If there is more data to be sent after a batch is finished downloading, XGUI will automatically start the next batch while concurrently processing datas that aren't being reupdated.
 -Chagned 50 bans per "chunk" to 25, reduces major network spikes and increases performance on full refresh.
=Fixed: Issue where if a user was not properly assigned to a group, XGUI wouldn't handle it properly. (Thanks CRussian!)
=Fixed: Issue where team data wouldn't refresh itself after renaming/removing a group. (Thanks gte6495!)
=Fixed: Duplicate entries in rare cases where some old datas would get processed along with new ones.
=Fixed: Received a ULX error when attempting to set the inheritance of or rename group "user"
And many other small optimizations & fixes!

[CRussian]

I love the new update 

*Edit* - For some reason the teams turn yellow in DarkRP, And when i do change classes it changes the color, but over time it goes back to yellow?

[Stickly Man!]

Hmm, DarkRP probably has it's own team stuff that's conflicting with UTeam... I've yet to look into UTeam on other gamemodes. I think there's an option to disable UTeam completely if you're in another gamemode, but I'm not 100% sure.

[Aaron113]

Your SVN link seems to be broken.