Kodi Community Forum

Full Version: TheGamesDB.net - Open Video Game Database (wiki-based, register and contribute)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
For me, that seems like a good link between the 4 big ratings systems.

  • Added functionality to associate a rating with a game. The ratings drop down is driven by the selected region on the Game Edit/Add page.
  • Rearranged the View pages for Games, Companies, and Platforms to accommodate a ratings image.
  • Added a "Developer" field to the Game pages that pulls from the Companies table.
  • Added a "Media Type" field to the Platform pages.

  • Added Rating Search request.
  • Added Rating Detail request.
  • Modified Game Detail request to include a Developer element.
  • Modified Game Detail request to include a Rating element.
  • Modified Game Search request to no longer contain a Genre or Publisher element.
  • Modified Platform Detail request to include a MediaType element.

I still need to add API Methods to retrieve Rating Boards and the Master Ratings.
I'm going to be fairly busy with work and school for the next two or so weeks. I'll have some more developments on the site then. In the meantime, are there any other suggestions or comments?
Alright, I'm back. I apologize that took way long than I expected. I'm planning on resuming development today and hopefully start importing data soon.
Alright, I just imported all 32x games based on the export text file from http://www.ressurectionxtras.net. The process was a little ugly but it worked. I'll going to work on tweaking the process and then I'll try with another system.
jas8340 Wrote:...I would like to clarify that the design of the site is not set in stone. The data entered in the site has been mainly test data. I could really use some help in determining that level of game information to provide. This include description fields, screen shots, trailers, etc...

Wondering if a spot for trailers will be added?

Another field that I'd like to request is a Players field for each game. For example;
1 player
2 player
2 player - cooperative
Multi-player (ie; more than 2)
Multi-player - cooperative
Nice to see that this project is not dead.

It was a pain to read this xtras format but finally I got it working. If you are familiar with python you could have a look at the importer of my Rom Browser script (http://code.google.com/p/romcollectionbr...ources/lib). You will need descriptionparser.py, pyparsing.py and a working parserConfig.xml. An example how to invoke the parser can be found in temptests.py (actually commented out). After invoking the parser you will get a dictionary with all game related properties and just have to write your own code to get the data into your DB. If you are interested I could separate it as a little project for you.

I already have some exports that are known to be working with my parser. You can get them here: http://romcollectionbrowser.googlecode.c...medesc.zip (parserConfig.xml is included).

And one feature request:
Will you add the crc value as key to your API?

Sweet! I'll have to take a look at your python scripts. What are the crc values used for? I noticed that some games have more than one crc values.

Also, what about these values for the players field:

One Player
Two Player Alternating
Two Player VS
Two Player Co-op
Two Player VS and Co-op
Multiplayer VS
Multiplayer Co-op
Multiplayer VS and Co-op
Multiplayer Only

All of the Two and Multiplayer modes (with the exception of Multiplayer Only) assume the game has a a one player mode as well. I can add some instructional text to the site that explains that and cite examples of each.
Crc values are the checksums of the rom files. So all people will have the same crc value for the same file no matter if they rename the file or what system they are on. There are different crc values for one game because there exist different versions of the same game. Sometimes it is more reliable to use crc values because you don't have to take care of file naming and you can use game titles that are not allowed as filenames (length restriction on xbox or unallowed characters on all systems). If you search for one game and even if you find it at hundred different places you will only have a hand full of different crc values but a lot more different file names.

Thats why it would be handy to use it as an alternative key in your API.
Regarding the code only this should be interesting for you (the commented part in temptests.py):

print "start parsing"

BASE_RESOURCE_PATH = os.path.join( os.getcwd())
sys.path.append( os.path.join( BASE_RESOURCE_PATH, "pyparsing" ) )

from descriptionparser import *
descParser = DescriptionParser()

descFile = "F:\\Emulatoren\\data\\Synopsis\\SNES.txt"
parseInstruction = "F:\\Emulatoren\\data\\Synopsis\\parserConfig.xml"

results = descParser.parseDescription(descFile, parseInstruction, '')

for result in results:
        print result.asDict()

print len(results)

You just need to download descriptionparser.py and pyparsing.py and should be able to run the above code. I think you can also do something like "result.asXml()" if you like this more. But I have to check the pyparsing API for this.
For the API results, what would be better: displaying a comma separated list of crc values within a single xml element or a group of elements for each crc value.

Example A:
<CRCValues>1234abc, asfe2145</CRCValues>

Example B:
second. that's the xml way. in fact i would have ditched the surrounding tag entirely and just had multiple <crcvalue> tags
jas8340 Wrote:For the API results, what would be better: displaying a comma separated list of crc values within a single xml element or a group of elements for each crc value.

I don't see why you will need the crc in the result set.

I think you will have something like this as request:

Then you have to check this request against the crc values in the database. But I don't think it is necessary to have the crc as result.

But anyway you may have other items that can occur multiple times (genre for example). So you have to decide how to implemement these ones. Then I go with spiffs suggestion.
Alright, I modified the Game API calls to accept crc values as input parameters but the crc values aren't displayed within the XML.

Along those lines, should the crc values be displayed on the website itself? From what I understand, it seems to be a fairly static. Does it only apply to rom files or is it extended to isos as well?

I should be promoting these changes either today or tomorrow.
Quote:Along those lines, should the crc values be displayed on the website itself? From what I understand, it seems to be a fairly static. Does it only apply to rom files or is it extended to isos as well?

Yes, they should be static. It is no bad idea to have them on your site and make them editable I think.

Not sure about isos. They are much bigger than roms and computing the crc value takes a long time. So I don't know if they are used often. But I think I have seen that the crc value property has been used as a placeholder for other unique keys in the synopsis files (folder name for example).
Pages: 1 2 3 4 5 6