RTB Development

[Bushido]

the one on the top left seems most practical and is also awesome to look at

but maybe it should be brightened a bit, assuming the text is still black

[Ad Bot]

[Ephialtes]

The text would be white like the numbers in the corners of the brick box when you're playing.

[Destiny/Zack0Wack0]

I'm going to go with either 1 or 2 for in-game (probably 1 because it is the exact same style as the paint/tool/brick HUDs) and 3 for the out-of-game notification. I don't think allowing people to customise them is worth the work.

I agree. It would be a useless feature.

[M]

If we really want to customize them we can always overwrite the objects/bindings to them, I'd done this to a few things in regular BL and possibly some RTB GUIs in the Aero UI files...

I like the idea of having it all fit with the default GUIs, and using their profiles so they'll share skin changes though. I also like the idea of 'just a white box' popping up (the box within 4) since it's very minimal. Perhaps if it was the same semitransparent black as the background of 1, staying semitransparent with semitransparent text and fading out if you don't activate the cursor to click on it before it disappears (or just activate the cursor in general, have it refresh and pause the fade timer when you activate and start when you deactivate it, removing notifications when the GUI is opened, etc)

I'm still no better at describing things. Go me!

[Masterlegodude]

I like style 3 (bottom left), it's like Blockland's current window style :D

[lordician]

I like style 3 (bottom left), it's like Blockland's current window style :D

This.

[M]

Would it be at all possible to allow arbitrary RTB mods to be downloaded? Like your own content zip that you've uploaded and had approved for a mod you don't want to release the entirety of - except it could also include some clientside code for GUIs and the like.

You'd probably also want the mod to be flagged for this kind of use by a mod reviewer, to stop people from uploading weapons and flagging them this way then forcing people to download them when they join the server, thus cluttering their Add-Ons list. Generating content zips for these could also assumedly be skipped since they're essentially player-made content zips anyway (by their intended use).

Obviously I mean to integrate these mods with the RTB content downloading, just based on the server maintaining a list of the mods the clients should download off RTB if applicable and sending it to the client before content downloading begins.

I ask because it would be nice for RTB users to be asked to download a GUI when they join the server with more functionality than the RTB GUI Downloader would allow, as well as content such as models without having to release the whole mod on RTB.

[Ephialtes]

Yes. This is something I've noticed happening quite regularly with people wanting to host CityRP GUIs on RTB for the content downloading. At the moment I've moved them into the Bargain Bin so they still work but aren't displayed in the standard listings but in the next iteration of the Download Manager I will be building a more effective system for this.

I'd like to see people offering up more suggestions for the GUI downloader. I feel it's got potential but people want to see it able to do more things.

[:D]

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

[M]

Yes. This is something I've noticed happening quite regularly with people wanting to host CityRP GUIs on RTB for the content downloading. At the moment I've moved them into the Bargain Bin so they still work but aren't displayed in the standard listings but in the next iteration of the Download Manager I will be building a more effective system for this.

I'd like to see people offering up more suggestions for the GUI downloader. I feel it's got potential but people want to see it able to do more things.

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.

[Ephialtes]

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

We're not using IRC - so no.

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.

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]

If I understand the GUI Downloader Code correctly

You do not.