Blockland Forums > Modification Help
RTB Development
Ephialtes:
--- Quote from: :D on August 20, 2010, 09:23:06 AM ---Will the bug where people share a name still happen?
Iv had 3 people take the user name D which I own while im on
So I keep having to use the whole NickServ Release thing
--- End quote ---
We're not using IRC - so no.
--- Quote from: M on August 20, 2010, 10:04:12 AM ---The main issue with the GUI downloader is that the GUI has to be static - we can't do things like a per-client list or dynamically generated content, unless I missed something in my (admittedly fairly brief) reading of the functions. Having some commands to do things like add/remove items to/from and clear lists, change the text of a text control, etc. for one single client would remove these limitations - probably just two clientcmds, one to call a method of a control and another to change a value of a control, would be all that is needed.
Something like clientCmdRTBG_Call(%control,%function,%arg1,%arg2,%arg3,[...],%argn) and clientCmdRTBG_Set(%control,%value,%newvalue)
And obviously restricting the controls these can affect to controls which are flagged to be managed by the RTB system (ie, anything it creates itself) as well as the values and methods to ones that RTB allows. Perhaps some other methods (such as a method for one control to create another as a child of itself, for generating lists with buttons or things like that) would be nice too.
However for non-GUI client code like specialised keybinds or GUIs using things that the RTB GUI downloader doesn't allow, the "server recommended content download" would be quite handy. I suppose a pref to turn off these downloads separate to main content downloads would also be needed.
--- End quote ---
The issue with static GUI is something I hope to address at some point later on, although it would have to be a more intricate system than what you proposed above. I'm thinking something along the lines of stored procedures (very similar to the MySQL 5.0 implementation) which are downloaded as part of the mission loading time at the same point as the gui data. It's a big task so it'll be a while before I can say anything on that.
As part of the next iteration of the add-on management side of RTB I will be looking closely at how the needs of users have developed since the last iteration was put out (RTB 3). Add-ons have been getting more complex and are putting more pressure on the client needing to have downloaded certain things to allow them to interact with those add-ons successfully. So yeah, I will be looking at this. I'll be holding more discussions on add-on management in the future.
Cyanian:
Just one of those random questions.
How/Where did you learn your scripting knowledge Ephialtes?
M:
If I remember the stories correctly, he sacrificed a cow or a goat or some other farmyard animal or assortment thereof.
MegaScientifical:
If I understand the GUI Downloader Code correctly, I don't believe there's protection in it in case it is sending a GUI not yet approved by RTB. You could use it to send any GUI as long as it meets certain perimeters.
With people always finding exploits and workarounds, do you think it'd be worth it to add another layer of protection: Making sure a GUI is part of a RTB-Approved Add-On. Sounds like a task, and not an immediate one, but another layer of protection might be good.
I'm soooooo about to get busted for what I just said in some way. :(
Ephialtes:
--- Quote from: MegaScientifical on August 20, 2010, 11:24:09 PM ---If I understand the GUI Downloader Code correctly
--- End quote ---
You do not.