rlbot hub alpha

[ghost]

for some reason the diff tool says i removes some chuncks. im not really used to using the diff tool so maybe someone can help me out on that

[ghost]

i have resolved the conflict, can someone take an look at it?

[skyborgff]

I think you are currently undoing Tareharts latest commit changes

[ghost]

@tarehart would you like to help on this one

[ghost]

also i find that weired because i copied the code for the merge from the rlbot master repo an hour ago

[ghost]

think it should be good by now, PacificScienceScratcher is working again on local dev environment

[skyborgff]

• maximizing the GUI and then changing tabs makes is turn into the default size
• Switching quickly from one tab to the other makes it reload it all again (should be saved on cache or just hidden behind one another so the webpage doesn't need to reload).
• switching quickly ends up in the GUI losing connection to local host
• Before any filter is applied it should list all bots
• Add some kind of animation to indicate the bot is being downloaded
• Pressing More Info on a bot doesn't show anything
• Some kind of way to show which tab are we on currently, and to be able to indicate these are tabs would be appreciated (some visuals like chrome tabs have)

[ghost]

thanks @skyborgff il crate hubtodo.md what will contain this todo list. this alpha release is main purpose is to get bot devs enthousiastic

[tarehart]

It seems like your model is to have a "repo" be a git repository controlled by a single bot author, typically holding only a single bot, like SkyBot.

My preference is for a repo to be a community-maintained set of bots, e.g. https://github.com/RLBot/RLBotPack, with a json file in it to index the bots, and zip files in the repo for each bot that the index can point to, downloadable via raw.githubusercontent.

Advantages:

• The default repo (RLBotPack) will have quality control via pull requests
• We can use a central json file to index all the bots, as opposed to needing a botpackage.json file (https://github.com/ard1998/RLbotPythonDataParser/blob/master/dataParse/botpackage.json) for each bot. It could be managed by bot pack experts rather than bot makers.

[ghost]

My reason for the botpackage.json is that for the community repo you can derive the updating to the maker of the bot. The repo will have fast updates, at cost of a slight security risk

[ghost]

Accidentely klicked close on mobile github. The close button was close to the autocorrect bar ;)

[skyborgff]

Could we merge both @tarehart ? i personally would prefer to keep each bot in its own repo instead of a botpack repo. Maybe show a warning ?

[tarehart]

Security is a concern, but my bigger worry is that botmakers will push poorly tested commits in their repos. Even if the bot runs, it's very common for bots to temporarily regress in skill while new features are under development.

Arguably people could maintain a "stable" branch or something like that, but a lot of bot makers are novices with version control or software publishing in general, and I don't expect things to go smoothly.

For that reason, I want the default repo for casual users to be a centrally managed pack equivalent to RLBotPack, and I'd like the maintenance of that to be easy.

[skyborgff]

Then i think the problem is how we handle the current botpack. i think its troublesome to update it, but that may be a good thing, cause it stops botmakers from constantly updating and breaking it.

But i still think that having a "advanced mode" that could pull directly from repos would be a good idea

[ghost]

The stable repo can contain the checked community bots and the community repo contains those bot and additional bots, repo on own risk displaying repo.note. probably i should introduce an repo strin into the json file to store from what repo it is fetched so the user can choose to use from weat repo he wants to download (in advanced mode)

[skyborgff]

advanced mode would show skybot from my repo as a diferent skybot from the botpack. they are 2 diferent sets of code afterall. the version number would be diferent, and thats where the user would choose. use the stable, or the newer?

[ghost]

i can't explain that idea better then you just did

[skyborgff]

the only part i didnt agree with you was

so the user can choose to use from what repo he wants to download (in advanced mode)

As this would mean probably replacing the files that were already there. As a added note, having 2 bots with the same name may result in folder issues

[ghost]

old ones gets deleted and the new on gets downloaded. just as how linux distributions are handling those issues.

[skyborgff]

bots are not distributions, what if i want to play with old and new skybot to compare how it is improving?

[ghost]

You bring me on a good idea. Each repo gets its own folder with bots in it so mulptiple bots with the same name can be used. In adcvanced mode the main page will also show from what repo if an bot is in multiple folders

[tarehart]

It seems like this is still using a design of "one repo per bot" which I'm not a big fan of. I very much like having a pull request process like we do in RLBot/RLBotPack for safety and quality control on the main bot pack. Alt packs are fine, but for the main pack I really want to have multiple bots in the same repo to preserve that pull request model.

As a strat for downloading a subtree (i.e. one bot) from a repo:

1. Look up the latest hash https://developer.github.com/v3/repos/commits/#get-a-single-commit
2. List out the tree of the bot pack repo https://data.jsdelivr.com/v1/package/gh/RLBot/RLBotPack@a0572e408f012bfa97fe125bf2e377c02cf0aa02
3. Grab the specific files you want https://cdn.jsdelivr.net/gh/RLBot/RLBotPack@master/RLBotPack/Beast%20from%20the%20East/beastbot.cfg

This would allow us to keep RLBot/RLBotPack in its current form (except we just add a json file) and selectively download bots from inside it.

Alternatively, we could structure repos as a json file and a bunch of bot zips so we don't have to do any recursive monkey business. However, the zips would make git history pretty useless, and it would be harder to test local clones of the bot pack.

[ghost]

I have thought about it since you noticed it last time, this is my conclusion.

One bot per repo (or branch, just what the developer wants for his administration) does only download the bot the user wants to and helps with the administration of ensuring there aren't multiple bots with the same name in a repo. If you want you can add a rlbot-tested repo where each branch does get an up to date bot instead of a repo per bot where you can store the current and older versions of the bot in branches. The platform does give that freedom.

the current botpack structure does not suit the usecase(s) for the hub since git does (how far I know) only support downloading a file or a full branch, so by shrinking that branch to only one bot and only copying the botfolder from the temp download folder the amount of downloaded data will be reduced for all users.

For the bots that are using a config file to change the behaviour of the bot I want that to be editable in the main page of the gui. I still, don't know a good approch for this one but its something I am thinking of.

When the hub alpha is online it's the responsibility of the bot maker to add the packaging.json, the maintainer of the stable.json bot list only has to upload that to a git repo or branch and if needed ad a new entry in stable.json . For the bots that currently are in the botpack, are working correctly with the latest rlbot and aren't developed anymore we can make the exception of making the packaging.json our self. The process of getting the developers involve will take some time, that is why i am aiming on an early release with some of the basic features.

I hope this does explain my decision and reasoning behind it. If you have questions left feel free to ask them.

[ghost]

Got the stuff on one page now

[skyborgff]

For the bots that are using a config file to change the behaviour of the bot I want that to be editable in the main page of the gui. I still, don't know a good approch for this one but its something I am thinking of.

For this we should probably set a standard first, so implementation gets easier, i think this is a great idea!