Author Topic: Blockland Glass 4.2  (Read 190881 times)

Does not work for me.

Figured it out, it's control M for some reason?

thats the old default keybind

Beta 4 is out.

  • Fixed preference dropdowns
  • Reorganized server control administration tab
  • Fixed preferences not working on restart
  • Fixed checkboxes printing 1 and 0 instead of true and false
  • "No Preferences" text instead of a blank screen when there are no preferences

Thanks to those who have reported bugs, you've been extremely helpful in tracking down issues.

glass is almost two years old holy stuff

Beta 5

  • Fixed preferences not working (again, for real)
  • Fixed preferences not defaulting
  • Removed console spam
  • Tweaked graphs

Hopefully getting close to release. I'm feeling fairly confident about preferences, a lot of bugs have been ironed out.

does preferences read values straight off of live, ingame prefs now and save to prefs.cs instead of an alternate "BLGlass" prefs?? cause that was my biggest problem with it and it almost made me uninstall glass out of pure hatred of such shortsighted design

edit: i get its not your fault though. its just so incredibly frustrating as a modder who uses eval a lot
« Last Edit: July 17, 2017, 03:55:41 PM by Conan »

It doesn't save non $Pref::* variables in prefs.cs, it keeps them in their own file and sets global variables when they're loaded. I believe RTB did the same. It should be updating the cached copy of the variable and sending it to clients when it's changed directly now too.

real question though why is it caching the variables in the first place? why not read the variable directly and cache it for that client's gui? and when someone confirms changes, notify all clients with window open that the values have changed?

im p sure thats how rtb worked, correct me if im wrong. basically what i want is that if i manually set a pref value using eval, opening the prefs window will display correctly, for all clients. if the values are cached and glass reads the cached values it wouldnt show the correct value if it was manually set earlier

Yes, it will. It checks once every second to detect changes in the variable and updates them accordingly.

There's a cached copy of the value because Support_Preferences is designed to operate objectively while RTB preferences were primarily global variables. Directly registering a preference instead of using RTB adds a bunch of callbacks in flexibility to how the pref operates, however I don't think a single add-on uses default preference registration.

A default registered pref has the following callbacks available:

Preference::onUpdate
Preference::onLoad
Preference::onDefault

Where a custom namespace can be set similar to how TCPClient works. Since these are objective, it makes sense to keep the value as such, Preference.value. Support for global variables is integrated throughout, but it's not the primary design.

fair enough, though i still think having a loop check to handle updating cached variables is bad design compared to straight reading from established global pref values. it seems like a lot of design cruft that wouldnt actually be put to use.

in addition RTB has it easier for modders where updating a value would immediately call a function (if one was put in when registering the pref) which would allow modders to do every callback you just listed without requiring the server to have a function loop constantly running. such a loop definitely gets in the way when doing traces and makes it harder in general to debug problems with anything on the server.

although my main issues with preferences would be fixed i dont think i will use it still cause it sounds like its got way more moving parts than it requires (which lead to more obscure bugs and slower performance) and the last thing i need when developing is more function calls to sift through when tracing.
« Last Edit: July 17, 2017, 06:57:51 PM by Conan »

How exactly do you catch a global variable changing? We have direct callbacks in the same way RTB does but they still need to be triggered in addition to the objective callbacks. To detect changes outside of the preference system, you have to do check the variable for a change at some point. Doing checks upon opening the GUI adds delay to the user and can cause things to become out-of-sync if the value is updated while the GUI is open. Doing it periodically allows it to be caught and there's no more than a second delay.

Also, changing a variable alone with the RTB system doesn't trigger it's callback. The callback is only called when changed via the GUI.

While re-transmitting the values every time the GUI is opened is a simple solution, it's prohibitive and has a lot of network traffic and therefore lag, especially when there's many many add-ons installed.

ah i see what you mean now, god damn workarounds. totally missed the problem about callbacks when set outside of rtb

maybe you should make glassbot PM users with warnings rather than posting it in general, people think it's really funny to provoke the bot because they have an audience

maybe you should make glassbot PM users with warnings rather than posting it in general, people think it's really funny to provoke the bot because they have an audience
Or perhaps make the message only show up for the user. A whole new PM window would be a bit much.

Or perhaps make the message only show up for the user. A whole new PM window would be a bit much.
I agree with this - most of the time I see people getting warns from Glassbot I see people going "oooooohhhhhh" and then try to do stupid things to also get themselves a warn/kick