If it works using the Git method then I think any error with the ZIP method is beyond my control. In any case, using the Git method will make updating more bandwidth friendly.
I don’t know what GitHub would do if my bandwidth started getting in the TB range. 
I did some more work on this.
I changed the color of the Gel image and lowered the CRT on Diffuse amount to actually lower the CRT opacity instead of just faking it.
For the night I lowered the Diffuse Image brightness. It’s dark but that is more like how it would look in reality. (It looks brighter in a dark room.)
To be honest I don’t have any way of telling if there were any errors. The command line didn’t give any errors, as far as I know…
I did zip the downloaded contents to a file locally, with no error. I am assuming something to do with a max master zip size.
There are limits to the size of repos, the size of individual files etc.
This is one reason I have never created an actual GitHub release. If I did just 3 versions it would be almost 15GB. I need to conserve that space until I finish this. I have no way of knowing how large this will end up being.
I was thinking that uzebox_all might be better without the LED and just set LED Opacity to 100 on those. Just a thought.
thank you very much for your help Duimon, and for your professional work
That’s the way It is set up now. So the color of the LED can be changed.
Technically, I could do this to most of my presets and graphics but I don’t really intend for the colors to be changed on all of them, so I won’t.
There is also a visible difference in the LED appearance when it is not built in to the background. (Both in normal mode, and night mode.)
Especially the LED outer glow.
I put this thought through because if I changed the Background Layer color the LED would change as well, on Custom-Bezel_002, PVM20, and TM20. I found a way to do it and keep the color without removing the LED from the Background.
Edit: Don’t know if its intentional or not but the LED is still attached to uzebox_all image that is why the LED changes with the Background.
Not desirable but necessary. This image is used in presets that don’t have enough layers left to split the uzebox into 3 separate layers.
In these you won’t be able to change the color of the uzebox with the same freedom.
The Decal layer has to exist if you want to increase the brightness of the Device and still keep the Decal black.
I could still separate the LED though.
On a related note.
When I designed the PVM presets it was my intention to showcase the Mega Bezel as much as possible. For this reason I have the drop shadow separate so it can me scaled etc.
It occurs to me that this is a feature that may never get used.
At some point (Not soon.) I will bake the shadow into the Device Layer and free up the Top Extra Layer.
I have done some more work on the new Game Boy style screen.
I think it is about as good as we can get without actually having the DMG shader.
I have also done some more work on the Apple II.
After looking at some more reference images I removed the texture from the bottom half of the floppy drive face.
Then, for the background, I created date appropriate software manuals and swapped out the 3.5" floppy disk box for 5.25".
Finally, I tweaked the CRT settings to be more in line with the monitor technology. (Removed the mask, adjusted glow and scanline properties.)
I would say that is what my mine gripe would be. I can see why uzebox_all image is necessary seeing why those three need so many layers.
Apple II is in the repo.
I also added default cropping to the Tomy Tutor. This means that it won’t work correctly with other content. (Which shouldn’t be an issue.)
I will do this, but I caution you to take care.
I will not consider doing the same thing to all my graphics and presets.
Keep in mind that I have almost 5000 presets. Even with search and replace tools, making even simple changes to all of them is work I won’t do without a very good reason.
Not to mention the time it would take to go into all my source, make changes, export, and do post on the graphics.
Please don’t take my time and effort lightly.
I am not asking for all of them just Uzebox.
hey i’ve managed to get this far with apple2 in retroarch/mame but can’t seem to get the games to run any idea how i can do this, i’ve checked for a solution but everything i read is not working. some people say using a certain bios will work (apple2e) but not sure how to achieve this in retroarch mame core. thanks for any help you guys can give
You got that far so I assume you have some experience, but anyway…
Using the standard Software List method the bios is defined by the name of the folder the roms are in. So apple2, apple2p, appl2e would be the folder name. (And the bios of the same name needs to be in the same folder.)
Try the same method using the “apple2p”. (I have the same issue with the “apple2”.) It uses the same romset so it makes no real difference. Also make sure to use the “apple2_flop_clcracked” SL roms.
The MAMEDev page says the main difference between the appe2 and appl2p is the ability to autoboot. I am assuming we would need an autoboot command for the apple2, which is inconvenient unless all the executables have the same name.
Perfect, thanks ever so much again for the help 
and as always thanks for the awesome work you do with all of these 
ATARI JAGUAR CD
I already put Jaguar 64bit to work with Retroarch and Advance-Duimon and it looks super nice
but I try to run Atari Jaguar CD and I can’t play it in Retroarch, it has some bios, and I use CDI rom
AFAIK Jaguar CD support doesn’t exist outside of MAME. (And it doesn’t really work there.) That is why I am not doing a Jaguar CD graphic.
I had not noticed that there was no Advance-Duimon bezel, sorry
