Making premade gamelist.xml with xtra media collections
-
@meleu Good question. Thanks for asking since I didn't think of that before. :)
Any empty tags should just not be put in the
synopsis.txt
files. This is because on the XBox they are displayed "as-is", so if there were a bunch of empty fields it would look messy and would take more scrolling to get through the whole thing.You probably also thought of it, but any media tags we make for the locations in the
gamelist.xml
file should also not make their way back into the synopsis files. (No artwork, videos, gamefaqs, etc.)Essentially, the only tags that should make their way back into the synopsis are the ones that were there originally. The only exception would be data/information tags that had information that I added in the spreadsheet before converting back to the
gamelist.xml
. For instance, if I realized in the spreadsheet that a game was missing thePublisher:
information and I filled it in the spreadsheet, then that information would then make it back into the synopsis file.Now that I think about it, I'm wondering if we should make a separate tag for the synopsis cited website at the end of the
<desc>
tag? This way we could still have that information in the synopsis.txt, gamelist.xml and the spreadsheet, but we don't have to take extra steps to remove it so it doesn't show up in the RetroPie romlists. The only thing we'd need to do is make sure that they get placed back at the end of the<desc>
after two line breaks when it's covnerted back to thesynopsis.txt
.Maybe call it
<citation>
? -
Maybe call it
<citation>
?Do as you prefer.
On the code side it would be easy to consider that "if the very last line of a synopsis.txt is an URL, then it's a
<citation>
". -
@used2berx said in Making premade gamelist.xml with xtra media collections:
You probably also thought of it, but any media tags we make for the locations in the
gamelist.xml
file should also not make their way back into the synopsis files. (No artwork, videos, gamefaqs, etc.)Please, confirm if these are the ones to be ignored:
path image video marquee xtrasname cart title action threedbox gamefaq manual vgmap
-
On the code side it would be easy to consider that "if the very last line of a synopsis.txt is an URL, then it's a <citation>".
That will work. :)
Please, confirm if these are the ones to be ignored:
path
image
video
marquee
xtrasname
cart
title
action
threedbox
gamefaq
manual
vgmapYes. That is all correct.
-
Hey man. I'm not getting any traction on my thread about trying to get more image types supported in RetroPie. Do you know who I should hit up for that idea?
The thread is here: https://retropie.org.uk/forum/topic/16535/multiple-image-types-tags/2
Thanks :)
-
I'm not sure how linux scripting works, but I'm assuming after we run our desired command to start the script that we could have it ask a few questions for our image setup? I just found out from the other thread today that we currently have access to 3 image types.
<image>
<marquee>
<thumbnail>
The thumbnail tag is used to show a screenshot before a video plays if you set a delay. @EctoOne actually uses this in such a way that the video isn't played at all and it acts as a third image type. This would be perfect for the Pi Zero setup that I'm building that won't have videos.
With this, there is actually currently coverage for
Box Front
,Cart
andAction
images.So what I'm asking if we could do is two things...
-
Make a tag for every image type. (The default script now doesn't make
<boxfront>
because it makes the box<image>
instead. I would like to see this become it's own tag... I'll explain why later.) -
Ask a few questions about image types after desired script command is run, but before the script is executed. These following questions:
Image type for
<image>
?- Box Front
- Cart
- Title
- Action
- 3D Box
Image type for
<marquee>
?- Box Front
- Cart
- Title
- Action
- 3D Box
Image type for
<thumbnail>
?- Box Front
- Cart
- Title
- Action
- 3D Box
If we do it this way and leave the regular image tags we decided on for the image type, this should be very easy to change them in the script (or a separate script) in the future. That way we could run it and just swap out the locations for different image types without having to rebuild the entire gamelist from scratch. The image changing script could ask the same 3 questions and then just replace those tag lines with the image location of the desired art type. :)
Thanks bud... sorry to change this on you like that, but I think this is the best way to go forward with this new image information we just got.
-
-
Also... Below is an example of one of the game entries the script currently makes. I've highlighted where in the entries the new tags should be generated for ease of viewing/usage.
Along with the image tags, there are a few other ones that we've discussed from time to time in here along with some notes about them.
<game> <name>American Gladiators</name> <path>/home/pi/RetroPie/roms/nes/(1) Licensed/(1_1) US Licensed/American Gladiators.zip</path> <image>/home/pi/RetroPie/Media/nes/Artwork/Box Front/American Gladiators.jpg</image> <video/> <marquee/> `(This was already in the script)` <thumbnail/> (**New addition**) <desc> [Body text removed to simplify this post]</desc> <link>https://www.gamefaqs.com/nes/563382-american-gladiators</link> (**Our new link code**) <releasedate>19910101T000000</releasedate> <releasetext>1991</releasetext> (**Our text based release year from the synopsis `Release Year: ` line**) <hackreleasedate/> (**New addition**) <transreleasedate/> (**New addition**) <developer>Incredible Technologies, Inc.</developer> <publisher>GameTek, Inc.</publisher> <genre>Game Show / Competitive Events</genre> <players>2</players> <playerstext>1 to 2 VS</playerstext> (**Need this to properly convert back to synopsis after edits. Just a pure rip of the synopsis information without your code for converting it to an ES friendly field**) <region>USA</region> <platform>nes</platform> <media>Cartridge</media> <controller>NES Gamepad</controller> <gametype>Licensed</gametype> <xtrasname>American Gladiators</xtrasname> <originaltitle/> <alternatetitle/> <hackedby/> <translatedby/> <version/> <boxfront>/home/pi/RetroPie/Media/nes/Artwork/Box Front/American Gladiators.jpg</boxfront> (**Same as <image>. Our code defaults <boxfront> to <image>, but this should also be a separate line for scripting quick changes to image types on a script re-run**) <cart>/home/pi/RetroPie/Media/nes/Artwork/Cart/American Gladiators.jpg</cart> <title>/home/pi/RetroPie/Media/nes/Artwork/Titles/American Gladiators.jpg</title> <action>/home/pi/RetroPie/Media/nes/Artwork/Action/American Gladiators.jpg</action> <threedbox>/home/pi/RetroPie/Media/nes/Artwork/3D Boxart/American Gladiators.png</threedbox> <gamefaq/> <manual/> <vgmap/> <license/> <programmer/> <musician/> </game>
I can't think of anything more right now that we were talking about. I hope this all makes sense. Please let me know if I need to clarify anything. :)
-
@meleu I forgot about the "real date" tag. I added that to the example I gave above. :)
EDIT: I also forgot about two tags we haven't even discussed yet.
In the synopsis for both hacks and translations I have lines
Translation Release Year:
andHack Release Year:
as well as the original game release year.I've added both tags to the post above:
<hackreleasedate/>
and<transreleasedate/>
Thanks :)
-
Hey man. I mis-remembered our prior conversations and just found out that the FDS games aren't being built with the NES gamelist.xml. I was hoping you might have some time to work on that because now that I'm done with the cart artwork I've re-run the gamelist script and I can't verify any of the FDS stuff is working and the artwork is good. I'm considering going back into the FDS synopsis.txt files and changing the system name back to Nintendo Entertainment System just so I can finally get these things working if it's too difficult to make the code do this part.
Let me know.
-
Thanks for adding the option to remove the
FULL
out of the gamelist.xml files man. That feature works flawlessly and will save me a lot of time renaming files down the road. :) -
@meleu Hey bud. You alright man?
I think I found a bug in the ointment. It seems that when scraping the synopsis files, the script is not grabbing the body text for all of the games.
I found this out a few weeks ago, but I haven't brought it up since you haven't replied for so long. Just making sure that you're still around is all. :)
-
@used2berx hello friend.
I'm sorry to say I'm moving from this code. I started to work on this to work out my skills to manage data on text and xml files (basically improving my
sed
andxmlstarlet
skills) and it was a great exercise. I'm glad to make something useful for someone during this exercise, but now I'm quite busy with other projects and don't have enough free time to maintain this script.If you find another shell programmer, tell him/her that the script is always available at that github repo. And if they have questions about the code I can try to answer at some time. I can also try to review others code if they submit Pull Requests to that repo.
Cheers, and take care!
-
@meleu Well... that's going to put a huge damper on any future Rx releases for the RetroPie scene....
Bummer.
Maybe somebody else will help out down the road.
Good luck with whatever you've got going on man. Thanks for the work so far.
-
@meleu I had some time to sit down with the synopsis files and I believe that I figured out the common theme to any of the entries where the body text wasn't filled out with your script. In Notepad++, the ones that don't work right are listed as an "ANSI" file. All of the ones that work that I've checked seem to be listed as "UTF-8".
I don't know much about this other than they're two forms of character encoding and that UTF-8 is far more advanced than ANSI was. I have no clue how some of these files were saved differently. I'm going to try re-saving all of the non-working files and see if I can somehow save them as UTF-8.
Just wanted to let you know what that bug was.
EDIT: Yep. I believe that's what the problem is. In Notepad++ I can go to the "Encoding" menu and then select the second option "Encode in UTF-8". Some characters, like alternate apostrophes and quotes then change to weird things like "x92" and are highlighted. I can then just select them and put in a regular character and save it.
I'm going to do this to about a dozen of the bad ones and re-run the script before I sleep. They should all be working correctly with the new gamelist.xml.
-
@used2berx Awesome. That worked. Now I just need to go through and figure out which files had the ANSI format and convert them all to UTF-8 and the game descriptions will all be good. :)
-
Okay. Some weird things were happening. Lot's of characters that were in the synopsis files had bad characters that showed up as a floating box in both the XBox and the RetroPie. RP seems to have been able to display more of them though. What I can't figure out is why some files were ANSI when I opened them in Notepad++ and others were UTF-8, even though they had the same bad characters. Once they were fixed and saved though, they were automatically UTF-8 and I couldn't even manually save them as ANSI if I wanted to (which I didn't, but I was just testing it out).
I'm glad this issue came up now, actually. For years it has always bothered me that the strange characters looked so lousy on the XBox. The fact that they were actually breaking the script meant that I had to do something about them finally. I'll know for sure if I got them all after the new gamelist.xml is generated, but I think it's pretty safe to say that all 2,116 NES/FDS synopsis files are clean now. :)
I'm working with somebody to hopefully make a script to automate this process for future systems. I don't like automation unless I know exactly what it's doing, but after having spent 8 hours with this last night I feel pretty comfortable with it as long as it does exactly what I need it to do... which is the following:
Change all characters on the left side to the ones on the right side of the equal sign:
à = a
ā = a
é = e
ñ = n
ṇ = n
ø = o
ō = o
ǚ = u
ū = u™ = Nothing (remove it entirely)
– = -
— = -
‘ = '
’ = '
´ = '
… = ...
“ = "
” = "That's it.
There may be a few different characters that I find here and there as I move on to other systems down the line, but they could be added to the automation process as I discover them. This list should take care of 99% of any future issues. :)
Oh... and as a bonus, this also makes the gamelist.xml slightly smaller since every one of these characters were a long series of numbers in the XML files such as
–
and”
. It won't really make much of a difference on an XML file that is over 3.3MB, but every little bit helps... especially on the Pi Zero.Those numbers are actually how I found all of these problems. I just did a search in Notepad++ on the last generated gamelist.xml for
&#x
and I found all of those one-off accented letters that I never would have found using my eyeballs. :) -
Thanks to my bud Nemesis I've learned a lot about the code in this script. I'm no coder, but using existing code I was able to make a few changes so far that I wanted in this script. I'm re-running it now, and all of the desired changes I made this time around are taking effect. :)
I was able to add code to add and find all data for Famicom Disk System games that are in NES subfolders without having to have manually changed the "Platform: " line to erroneously read "Nintendo Entertainment System" instead of the legitimate tag of "Famicom Disk System".
I was also able to add a
<boxfront>
tag as a placeholder for all Box Front images, so now we have one for Box Front, Cart, Titles, Action and 3D Boxart images.I was also able to make the code put the Cart images in the
<marquee>
tag, so now a skin that uses both tags can display both the Box art and the Cartridge art simultaneously.The next thing I want to do is a bit trickier. I've heard from somebody here that if you don't have a video for a game, the <video> tag can be used as a third image type. I'd like to add some code in there that will search for the video as it is already doing, but if it doesn't, it will add either the Title image or the Action image shots in that tag.
Once all this is taken care of, I'm hoping Nemesis and I can come up with a quick script that will change which images populate the <image>, <marquee> and <video> tags on the fly after the
gamelist.xml
is created. Right now, on the Pi Zero it takes about 3 hours for the script to run on the NES alone. But after it is created it should only take a few seconds to run a script that will change which folder each image tag points to for every game.Another thing on the list now is to add every single tag from the
synopsis.txt
files to thegamelist.xml
file so when I convert them and then use @mitu 's script to convert it to a spreadsheet, I can make all the edits I want in the spreadsheet and then convert it back to agamelist.xml
file and finally back to thesynopsis.txt
files without losing any of the original data.This is exciting. If we can get this working it's going to make editing game information for both the XBox and the RetroPie easier than it ever has been before.
Thanks again for all that hard work @meleu
-
Awesome.
I don't really know crap about coding, but I'm pretty good at pattern recognition and logic puzzles. Even though I don't know exactly what @meleu 's code is doing, I'm slowly figuring out ways to manipulate it.
So far I've been able to add a line for
<boxfront/>
that's separate from<image/>
. At least temporarily, I've pointed the secondary image type<marquee/>
to the Cart location as well. This will make it much easier to switch between which image types are in the "hot spots" and are actually usable in RetroPie in an alternate script. The reason you'd want to do this is because it would literally take a few seconds to switch the file locations in the completedgamelist.xml
instead of generating an entirely new one from scratch with different image parameters (which on a Pi Zero right now takes over 3 hours for just the NES gamelist).That being said, I'm going to want to figure out a better way to get the
<image/>
and<marquee/>
tags now that I've done all of this. I should be making it simply "copy" the file locations from<boxfront>
for the image tag, and from<cart>
for the marquee tag. I believe right now it's looking in the same location twice now, adding a lot of code run time to a process that already takes hours to finish. I'm sure this is a really simple thing to do. I'll figure it out eventually. It doesn't make any sense to do it the way that I'm doing it now.Meleu had to do some coding wizardry to make my
Players:
andRelease Year:
fields work in RetroPie as well. This was great, but in order to preserve all data when transferring thegamelist.xml
to a spreadsheet, doing massive editing on the spreadsheet, then converting back to a gamelist and further back into individualsynopsis.txt
files for the XBox, I need to preserve the data exactly as it is found in those fields.By copying and pasting some existing code that populated other fields, I have managed to add an
<xtrasplayers>
and<xtrasreleaseyear>
tag to the gamelist. Though not useful at all in RetroPie, these tags will preserve the data in its entirety when converting from format to format. :)I've got some other various tags to add as well that I'm going to get around to sometime today hopefully. It's taking me a pretty long time since I'm documenting everything pretty heavily as I go just so I remember what I've been doing and I don't get lost.
No wonder why @meleu wanted out. This is a lot of stuff to keep straight. :)
Thanks again bud. Sorry it took me almost a year to get around to actually learning anything about the code. Probably better that you stopped so I would be forced to learn some of this on my own.
-
Does anybody know how to copy a location put in an XML tag into a 2nd tag?
I want to change @meleu's script to search for all image location tags first (
<boxfront>, <cart>, <titles>, <action>, <threedbox>, <xtrasmarquee>
).Then, based off of which image types are selected when running the command, I would want the actual tags used by RetroPie to be populated by these image locations without having to re-scan for them. (Default locations pasted here would be the
"Box Front"
folder for the<image>
tag, and"Marquee"
folder for the<marquee>
tag.In this example, it would fill
<image>
with whatever info was just scanned and put in the<boxfront>
tag for the game. And it would fill the<marquee>
tag with whatever info was just scanned and put in the<xtrasmarquee>
tag.This will accomplish 3 things.
-
It will cut down the time needed to run the script quite a lot by not having to scan for the same image twice for two separate tags.
-
This will allow me to create a script that will (hopefully) easily be able to change which images are considered
<image>
and<marquee>
after the gamelist is made. It currently takes 3 to 4 hours to run this script on the Pi Zero for my NES/FDS collection of 2,116 games, so running it several different times to change these image types is foolish, and creating a script to do this on the fly would be much easier than what I've been doing, which is constantly going into Notepad++ after creation and manually running a few "find and replace all" commands to change the directories after the fact. -
This would allow me to hijack the
<marquee>
tag for whatever secondary image I want to use in a particular skin easily. Ideally, we'll see more possible image types in RetroPie in the future, but with the addition of the Marquee tag at least a skin could display both the Box art and the Cart art at the same time.
I've managed to do quite a bit of things I wanted to do with this script now, but because I don't really know what the code is actually doing I'm lost at this point. I'm going to keep trying to Google the answer I'm looking for, but since I'm not even that familiar with Linux jargon and terminology, I'm having a difficult time finding anything relevant.
Thanks to anyone who reads this and has any ideas! :)
-
-
Interesting...
I finally put some random stuff over to the Pi in all of the media folders (including new ones that I added). All of them were filled out with the proper file in the location except for my new tag
<xtrasmarquee>
. I didn't figure it out right away since the media was there and all of the code for the new tag seemed to be in order.That's when I figured out that I had improperly set the following code:
# xtrasmarquee : find it boxfront="$(find_file "Artwork/Marquee" "$file_name" png jpg)"
It should have read like this:
# xtrasmarquee : find it xtrasmarquee="$(find_file "Artwork/Marquee" "$file_name" png jpg)"
The "interesting" part to me was that rather than create a 2nd entry, it simply re-wrote the <boxfront> image location that it had previously just found with the Marquee image instead.
This:
<boxfront>/home/pi/RetroPie/Media/nes/Artwork/Marquee/8 Eyes.png</boxfront>
Instead of This:
<boxfront>/home/pi/RetroPie/Media/nes/Artwork/Box Front/8 Eyes.png</boxfront>
I'm actually happy to see this happen, and I'm learning things. Now I'm pretty sure if I can figure out how to code it correctly that it shouldn't be hard to copy the existing
<boxfront>
tag into the<image>
tag for each game since it seems to wrap up what it's doing for each game entry before moving on. I was worried this was going to be a pretty complex solution.Also, I fogot to mention that I added "PDF" images to the search for game Manuals as well as zip files. Last time I checked there is no way for RetroPie to actually view manuals, but in case it ever gets added, the script will look for either PDF files or Zip files that house PNG or JPG images of the manuals.
So the existing code will successfully output all media for a game now like this.
<boxfront>/home/pi/RetroPie/Media/nes/Artwork/Box Front/8 Eyes.jpg</boxfront> <cart>/home/pi/RetroPie/Media/nes/Artwork/Cart/8 Eyes.png</cart> <title>/home/pi/RetroPie/Media/nes/Artwork/Titles/8 Eyes.png</title> <action>/home/pi/RetroPie/Media/nes/Artwork/Action/8 Eyes.png</action> <threedbox>/home/pi/RetroPie/Media/nes/Artwork/3D Boxart/8 Eyes.png</threedbox> <xtrasmarquee>/home/pi/RetroPie/Media/nes/Artwork/Marquee/8 Eyes.png</xtrasmarquee> <gamefaq>/home/pi/RetroPie/Media/nes/GameFAQs/8 Eyes.zip</gamefaq> <manual>/home/pi/RetroPie/Media/nes/Manuals/8 Eyes.pdf</manual> <vgmap>/home/pi/RetroPie/Media/nes/VGMaps/8 Eyes.zip</vgmap>
What I'm looking to do now is find a way to create the
<image>
tag by simply copying the image location in the<boxfront>
tag. And then create the<marquee>
tag by copying the image location in the<marquee>
tag. These would be the defaults, and would ultimately be able to be changed upongamelist.xml
generation and/or with the yet to be created script that could change all of the locations for these tags on the fly after it was generated.Though this isn't absolutely necessary to figure out, it would save a lot of time during the creation of the gamelist.xml file by not having to find the same image twice for two tags. This might be a moot issue on a Pi 3, but with how long it takes to make these files on a Pi Zero every little bit helps.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.