• 1
  • 4
  • 5
  • 6(current)
  • 7
  • 8
  • 84
IARL - Deprecated
#76
@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
Reply
#77
OK, I set up a repository (finally Big Grin).

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. 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!
Reply
#78
(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 Big Grin).

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.
Is there a good step-by-step HOW-TO guide in the Kodi wiki on how to setup up a such repository?
Reply
#79
(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.
Reply
#80
(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!

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?

Then, IARL would show up as a video plugin on vanilla kodi and both on RetroPlayer kodi

(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.

I agree, setting up add-on repositories is heavily lacking in documentation. If you start a stub with what you know, I'll fill in the details that I've figured out from crawling the code.
Reply
#81
If anyone can write down the info on creating repository's I can transfer to the wiki and make it look pretty Wink

Happy to help!
Reply
#82
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?
Reply
#83
(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?

I like this idea better. I'll do that for the next repository push in the next few days and get rid of those settings.

(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?

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.
Reply
#84
(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.
So it was a decision of eyecandy over logic Wink Your add-on does not provide videos, so it should also not be in video add-ons IMO
Reply
#85
(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)

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.
Reply
#86
(2015-09-24, 20:38)da-anda Wrote: So it was a decision of eyecandy over logic Wink Your add-on does not provide videos, so it should also not be in video add-ons IMO

Well... yeah. I mean one of the main points of Kodi is for the eye candy right?

But, like I said. I see you're point. When in doubt the user should probably decide. I could make an 'advanced setting' to allow the user to put the addon wherever they want. It would be a moot point if/when Retroplayer was part of Kodi.


(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.

Yeah, thats how I started to implement that advanced search section, but I ran into a few problems. I scraped all of my current xml files and came up with:
- 25 Genres, lots of games were tagged with multiple which in itself isn't a big issue. Some games listed say "Driving" while others listed "Racing" while others (that I would consider to be in the same genre) listed "Simulation"

- 25ish options for "Players". Depending on where I scraped the data from, some sites would list "1 - 4" while others would list "4", while others would list "2+", while still others would list "4 Alt" or "4 Sim" depending on if it was simultaneous or alternating turns for players.

- 750 options for "Studio". Not really feasible to scroll through 750 options for this one.

- 33 Options for Region. Some tagged "US", some tagged "USA", etc. In addition, some sites would use the Region or "Rom Tag" to list game versions like "V1.1", "Beta", "Proto", etc

- Years for games from 1977 to today

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.
Reply
#87
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?
from util.py:

Code:
def getTempDir():
    tempDir = os.path.join(getAddonDataPath(), '%USERGAMESPATH%/%CONSOLEDIRECTORY%')

where the
Code:
%USERGAMESPATH%
is a user-specified location and
Code:
%CONSOLEDIRECTORY%
is the corresponding system name.
Reply
#88
(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.

I would heavily suggest taking a look at heimdall for this kind of thing. Heimdall will be integrated into a Python module (script.module.heimdall), available to all Python add-ons that want to augment their metadata.

ATM, there's no add-ons that use Heimdall, so there isn't really a defined API. I'm planning on creating service.metadata, a Python service that reads a file from the contentdb:// VFS, calls Heimdall on that file, then writes the derived metadata back to the contentdb:// VFS. Because it's so simple, service.metadata will be the reference Heimdall add-on, unfortunately I haven't written it yet Smile

I'm putting my game library and content scraper stuff on hold while I work on more pressing matters like input and gamestream, so it might be a while before I'm able to write service.metadata. If you don't go with heimdall today, I highly recommend putting all your scraper complexity behind an API. Besides leading to far cleaner and more maintainable code, it'll be a no-brainer to swap in Heimdall when it's ready and instantly benefit from all the stuff it can do.

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 Wink 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.
Reply
#89
(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?.

I think what you're requesting is already baked into the addon. If you right click / bring up the context menu for the archive of interest, you can select Update Download Path. All games downloaded from that archive will go to the folder you define with that setting. The only caveat is that it's not a cached / size monitored folder at all. I thought that would be to risky, potentially deleting files that a user didn't intend to have deleted, so the only folder thats cached is the addons temporary folder.
Reply
#90
(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 Wink 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.

I'll take a look, thanks!
Reply
  • 1
  • 4
  • 5
  • 6(current)
  • 7
  • 8
  • 84

Logout Mark Read Team Forum Stats Members Help
IARL - Deprecated10