RTB Development

[AGlass0fMilk]

Or of course, an RTB server tag system would be quite useful. Allow users to filter by tags, and use a list of tags you can select from. Some could be:

• Team Deathmatch
• Deathmatch
• RPG
• Events
• Freebuild
• Medieval Themebuild
• Futuristic Themebuild
• Modern Themebuild
• Citybuild

There's likely a lot of other tags you could use, but by combining these tags you could probably get a decent idea of what a server is about (providing the host has accurate tags on - of course, if they don't, it's up to the user to determine things. Just because the system is there doesn't mean is has to be a catch-all idiot-proof system)

This and:

A server ID system
Such as "c2127c2o8476duj3f62etj1np0"
Basically like a session ID

This would be quite handy together. Having server ID's would be useful for storing server favorites and searching. They could be set up when you first run an RTB server and they never change under normal circumstances. The tag system could help you find what type of server you want.

That would be awesome, but I'm sure you're going to find a better way to do this.

[Ad Bot]

[mctwist]

Implement md5 algorithm in Torque...
You will get a special session ID for that server, from like the name of the server, or who is hosting.

[Ephialtes]

A server is identified by a joint key of it's port and blockland id. Again, you can leave the technical bits to me - it's unlikely that any of you have an adequate understanding of the RTB server architecture to make these kinds of calls and you'd be wasting your time.

As far as I've planned, Favourites will operate in basically the same manner. You specify a bl id to get all the servers for that user - or bl id and port to get a specific server.

Server tags are on the drawing board but I haven't decided if they're actually going to be useful yet. We have like ~160 servers at peak usage times which means it really doesn't take long to check out the list of servers manually. It'd probably be a low priority thing since it'd only really be handy when looking through the server list becomes a real pain in the ass.

[yuki]

If I'm understanding this correctly, you want a button that removes the add-ons that aren't zipped from the add-ons folder? Besides freeing disk space, I don't see a point in that, since we'd have to re-download everything when we joined a server.

What we need is for badspot to create a goddamn "Cache" folder.

[Ephialtes]

What would a cache folder accomplish? Do you mean just to store all the server-downloaded files in?

That'd require some severe hacking of the resource manager which is already pretty hacky as-is and I don't think it'd be worth the effort unless Badspot actually rewrites it at some point.

[yuki]

What would a cache folder accomplish? Do you mean just to store all the server-downloaded files in?

That'd require some severe hacking of the resource manager which is already pretty hacky as-is and I don't think it'd be worth the effort unless Badspot actually rewrites it at some point.

A cache folder would store all of the server-downloaded files, as you said, the point being organization.

[Ephialtes]

My hope for RTB is that at some point you just won't have to look in your messy Add-Ons folder ever again (from a normal user's point of view - not a modder or anything) and anything you'd ever want to do in that folder you could do from RTB.

[mctwist]

A server is identified by a joint key of it's port and blockland id. Again, you can leave the technical bits to me - it's unlikely that any of you have an adequate understanding of the RTB server architecture to make these kinds of calls and you'd be wasting your time.

First paragraph is correct. After that, I know you are really good at what you are doing with RTB, but you are not the only one that can script. Sure, we give all hard work to you. It will be accurate, precise, and secure. Also, you will know exactly how everything is working. But it will take so much time. Badspot has the same problem.

What would a cache folder accomplish? Do you mean just to store all the server-downloaded files in?

Store files there temporarily, and when Blockland closes, it clears the folder out.

[Kalphiter]

Store files there temporarily, and when Blockland closes, it clears the folder out.

What about irregular quitting? If you close the console window it doesn't go through the quit function.

[mctwist]

He could still hack the engine and execute his own function when the game is going down. When pressing the "X", it still needs to throw a PostQuitMessage and leave the head loop.

[Ephialtes]

Store files there temporarily, and when Blockland closes, it clears the folder out.

What yuki meant was to store all downloaded files into that folder permanently. Cache would probably be the wrong name, but a cache of server-downloaded files is redundant.

[Truce]

What yuki meant was to store all downloaded files into that folder permanently. Cache would probably be the wrong name, but a cache of server-downloaded files is redundant.

Well, I can think of a few benefits of having Add-Ons and "Cache" as seperate folders. Management, backing up when reinstalling / updating, etc.

[Ephialtes]

Well, I can think of a few benefits of having Add-Ons and "Cache" as seperate folders. Management, backing up when reinstalling / updating, etc.

I think you're confusing the meaning of a cache with what yuki meant (a separate folder for storing all server-downloaded files). A folder for all server content would help organise things, but the changes to the resource manager probably wouldn't be worth it.

[Truce]

I think you're confusing the meaning of a cache with what yuki meant (a separate folder for storing all server-downloaded files). A folder for all server content would help organise things, but the changes to the resource manager probably wouldn't be worth it.

No, I had put it in quotes for a reason. I was thinking Yuki meant a folder for Add-Ons, as in the .zips you download and can run in a server, and a seperate folder for downloaded content, as in, well, the downloaded content. This would provide the benefits I mentioned before, and probably some others I can't think of off the top of my head.

[Ephialtes]

I'm beginning to plan the server->client rtb gui manipulation but I need to know what kinds of things you guys would need to be able to do. These things include changing colors, bitmaps, control values etc.

I will also be looking at introducing cached procedures that can be run from the server. I don't know how many of you are familiar with stored procedures in MySQL but it would be a very similar concept to that. I'll explain for those that don't; As a client is loading the gui, you would also send essentially a "function" which can do various gui operations and take a number of parameters from the server. This means each time you want to do something like clear a list and re-populate it with values, you can call the client stored procedure with a bunch of parameters and that procedure will then clear the list and add each parameter. This saves a bunch of time and network bandwidth because it means you just call that single function instead of sending a "clearlist" and a bunch of "addtolist" functions.