(2015-09-22, 23:18)zachmorris Wrote:

(2015-09-21, 05:23)garbear Wrote: @zachmorris if you want, you can create a repo for IARL. that way the add-on will stay up to date and users will always get the correct dependencies

I figured out how to host a repo entirely through github. You can follow the repo I set up at https://github.com/kodi-game/repository.kodi.game

Then, I can add the addon.xml (like this) and users can install IARL from retroplayer builds

OK, I set up a repository (finally ).

The repository file can be downloaded from here.

I had *a lot* of trouble figuring out how to make this work, a lot more than I should have.

(2015-09-23, 12:04)RockerC Wrote: Is there a good step-by-step HOW-TO guide in the Kodi wiki on how to setup up a such repository?

(2015-09-22, 23:18)zachmorris Wrote: Anyway, I had been testing my repository on a non-retroplayer version of Kodi and my addon wouldn't show up as an option to install if I left the <provides>game</provides> in the addon.xml.

So I came up with a bit of a compromise. The addon.xml initially is set to <provides>video</provides> so that users can download the addon regardless of what version of Kodi they're using. There's a new addon setting that allows users to change what the addon provides (until retroplayer is in a stable Kodi release anyway). Hopefully it makes sense to do it this way.

Thanks!

(2015-09-23, 21:17)zachmorris Wrote:

(2015-09-23, 12:04)RockerC Wrote: Is there a good step-by-step HOW-TO guide in the Kodi wiki on how to setup up a such repository?

Not that I could find, which was probably most of the issue I had. I used Garbears example and a few other random examples from other addons to stumble through it. The 'how to setup a repository' in the Kodi wiki was lacking. Should be updated with a good example that people can follow with some explanation of how exactly it all works.

(2015-09-24, 01:43)garbear Wrote: Would this be fixed if you add <provides>video</provides> first and <provides>game</provides> second, and then I fix RetroPlayer so that an add-on can have two kinds of content?

(2015-09-24, 17:03)da-anda Wrote: why not simply make your add-on a program, so that it shows up under programs like all the other few games we have so far?

(2015-09-24, 17:35)zachmorris Wrote: Thats a good point. I chose video mainly due to all the skins I've tested with the addon. The view types available in many skins for the programs section aren't that great in my opinion simply because it's most likely an afterthought on the skinners list of things to do. Videos seem to (by default) have the most options.

(2015-09-20, 20:14)zachmorris Wrote: Update 09-20-15
- Added search window. It's functional, but I found it can be slow if you search across the entire list of archives. I think it could be much more efficient code wise, but I'll have to look into the best way to implement it. If anyone has suggestions let me know
- Various code updates/cleanups/fixes
- Added random play option, but it's not currently implemented (coming soon)

(2015-09-24, 20:38)da-anda Wrote: So it was a decision of eyecandy over logic Your add-on does not provide videos, so it should also not be in video add-ons IMO

(2015-09-24, 22:14)Heat Wrote: Tried it now, the advance search is good, but it would be better if some areas like region, genres and players had a drop down menu with options. For example, instead of someone writing NA on region and finding nothing, since USA is the correct term, you put a drop down menu with USA, EU or JP making it faster and easier for the person to choose. Adding genres will also help. About players, not to sure what the maximum is, maybe 10?

An option to disable the "Start search?" prompt when hitting search would also be good, since it seems a little redundant.

(2015-09-24, 23:41)zachmorris Wrote: For the metadata for all of the games, I created a script to scrape from four main sources:
TheGamesDB
GameFAQs
MobyGames
MAME History.Dat Files

The info on a particular game depended on which site had the better / available info. The problem then is that each site had their own method for defining some fields. Rather than massage the data, I just put it in as it was available (which coincidentally, I'm curious how Heimdall will take care of such issues, if it will at all, or if it will only look at one particular source of info for games). Anyway, it all became such a hassle I figured why not just let the user put in whatever they want.

If anyone has the fortitude, take a look at all the values for each field in the xml files (or I can send you the list I made). If there's a better way of tackling search altogether I'm willing to update how it's currently done.

(2015-09-25, 01:06)sudopinion Wrote: Love this addon.
I'm not really all that familliar with python, but
I would like to direct downloaded ROMs to categorized folders of a user specified location.
Do you think it'd be possible to do something like this later?.

(2015-09-25, 01:36)garbear Wrote: If you do decide to use heimdall, I'll help out with the API, seeing as how I'll need to fix this anyway. And not sure how much free time topfs2 has, but I'm sure he could push things around to work on Heimdall again Minus the rough API, script.module.heimdall should be ready to drop in a project. You can then copy the Python rules from https://github.com/topfs2/heimdall/tree/master/src (e.g. thegamesdb.py is a rule that looks up games in thegamesdb.net). default.py and recurse.py are two example Heimdall clients.