Hi, i have v0.5 set up and running with all games loaded, is there any way to update it to your image without reflashing my card?. thanks
Custom D.E.O.T. V2.0+/Clockwork OS v0.5 image - With customised DEOT interface, Kernel 5.7, Optional 1400MHz OC, Debian 10 Buster, Retroarch 1.9.0, Mupen64+ plus more! (Current build: 200903)
At this stage unfortunately not.
I could possibly make a script to do all the changes, but the amount of testing I would have to do to make sure it is a process that won’t break peoples installations would be far too great. Not to mention, having to check files against every possible iteration. I’ve thought about it, and probably would only do upgrades to my own version, since I know what files to expect.
ok, thanks for your time. i have a spare 16gb card in will try that first. could i ask you? v0.5 recognises my 64gb card as 64gb, does the new image do the same? thanks.
It’s been a while since I’ve been here, I was wondering if this can update the firmware like the original OS.V5? If not how do I update it to OS.V5?
Yes it can! It is based on 0.5, and won’t need to be updated.
This is assuming things stay the same re: updates only applying to items in the ~/launcher directory.
If it updates anything in the ~/apps or ~/games directory, things might get a bit hairy. But precedence says that it should stay the same.
You may just lose the custom splash screens. I removed the custom settings menu items for this reason. I will mark the files in future to not be changed, if it becomes an issue.
@gordi711 I suppose this applies to your query too.
Everything the official 0.5 image does, this image will also do. It IS the 0.5 image essentially.
So what are the commands to update without erasing everything on my gameshell
Sorry, I wasn’t 100% onboard with what you meant.
My reading was that you were asking if a fresh image can be updated to the latest firmware, as if you were using 0.5.
Re: upgrading from 0.4 to this; Yes it can, but I decided not to include this, given the problems users had with the stock 0.4 to 0.5 update, with slightly different systems, modifications and states of files.
I made this image initially to help people install standard updates/modifications that should be fairly straightforward, but due to differing configurations, people had trouble with. Remember when I was trying to help you get mupen64plus set up? That kind of troubleshooting.
Having an update script would no doubt lead to every post in this thread being someone having trouble applying it, and having to differentiate between user error, configuration error, or something on my end; especially given the nature of some of the modifications to system files.
I hope you can understand why I chose to omit this.
If I was to do an update, it would be one directly applicable to users who have used this custom OS as a base.
In short, were you actually asking the same thing as this post?
Oh ok, yeah that was not fun
Alright so how do I update from OS.V4 to OS.V5?
Have a quick read of my last post again.
If you’re talking about the stock 0.4 to 0.5, have a look at the official thread. But please read through the posts. You may run into some problems. It’s definitely targeted at the more advanced user:
I don’t have a single scripted process made. I would have to run you through every single change.
Part of the process would involve doing exactly what I was trying to help you with re: mupen64plus. I did the exact same process. That was the easy part.
I have decided to not include any instructions on how to do it, but instead have links to all of the components I used for people to put together themselves.
As per @HalfBlood’s response in another thread, you can see why I have steered clear of having an upgrade patch from other versions:
As a small update that you can apply now (and will appear in the next release), here is an updated skin for the DEOT OS. Unifies the launcher icons to use the hexagonal blue filter.
Just decompress the archive, then put it in the skin folder.
N.B. The OpenTyrian and GSPLauncher icons have their own icon in the /apps/Menu/21_Indie Games directory that override any icons changes in the skins, so you’ll need to change that one manually. Likewise with DinguxCommander in the utilities directory.
This should also update the fonts, masquerading as the set system fonts. The splash screens, and wallpaper should also be updated to the DEOT standard.
I have posted this in the skin development thread, since I figured it should be placed in the correct place if it is to have any direct discussion pertaining to it.
@Petrakis Just wondering, what was needing to be fixed/removed with
exec ~/apps/launcher/load.sh & line in the .xinitrc file? Was it just removing the line?
I haven’t modified the .xinitrc from the stock 0.5, so may need to mark it to avoid any changes I’ve made being overwritten by an update.
Thanks in advance!
Basically ~/apps/launcher/load.sh its a legacy path, it doesn´t exist anymore
Hmm, I may need some elaboration. Both of those files and paths seemingly exist in my installation, based on 0.5
Currently .xinitrc looks like this:
feh --bg-center ~/apps/launcher/sys.py/gameshell/wallpaper/loading.png exec ~/apps/launcher/load.sh & exec ~/apps/twm.mod
So I removed the line referencing the legacy load.sh path, like this:
feh --bg-center ~/apps/launcher/sys.py/gameshell/wallpaper/loading.png exec ~/apps/twm.mod
All started up normally.
I then thought to remove the ~/apps/launcher/load.sh file, thinking that it would be unused, however this resulted in being unable to load the launcher.
I replaced the file, changing the mode to
rwxr-xr-x, and everything went back to normal.
So from what I can gather, it seems safe to remove the reference to it in startup in .xinitrc, however it may still be being used by another start up process.
That aside, I haven’t noticed that much difference in performance or startup time removing the line from .xinitrc. Was there any other benefits to doing so, besides keeping things clean?
there is nothing in apps. I think that xinitrc is currently useless as we use the one in /home/cpi/launcher
Also twm is something that is not used anymore. Refer to my pull request
OH HAHAHA!! I thought you were referring to the .xinitrc in the /home/cpi/launcher!
I must have skimmed past it potentially being in /home/cpi/apps/launcher, since nothing should be there!
If there’s been pull request, it should be something that will be updated in the next git update. I’ll still get rid of it, now that I know that it’s a thing! It will haunt me if I don’t!
Thanks for letting me know about twm too. There seems to be a lot of unused assets. Thanks for looking out and cleaning them.
There are god knows how many leftover bits and pieces all over the place, like the /opt file that looked like leftover configs from an Emulation Station port attempt.
Then there’s all the leftover configs in /home/cpi/ like the .gnukem/, .hurrican/, .hydrascastlelabyrinth/ etc. I am half tempted to delete most of them, but fear doing so in case a) they’re somehow for a custom configuration, b) there are future plans for it, or c) if it is something that someone out there will be disappointed in seeing gone.
I would love to take part in an extensive audit of the entire structure of the gameshell OS.
You think that would be a worthwhile topic you’d be wanting to partake in, as a new thread? Or is it easier to submit pull requests? I guess it would come down to whatever the devs notice more readily.
My pull request does not contain that removal, as my pull request is cleaning the launcher, but that file comes from the iso file, so it can´t be removed with a pull request.
Apart from that, my pull request is not merged
but that file comes from the iso file, so it can´t be removed with a pull request.
I mean, its outside the git repo
Right! Gotcha! I see what you mean, what with both entries being things that have moved. That said, I guess it’s still good for the loading.png screen - OH WAIT, that’s also referring to a legacy location.
You’re absolutely right. The .xinitrc file is completely useless. Wow.
Its small things that I find while developing that get me confused until I realize what is going on.
Yeah! It caught me off guard, having to do a double take.
If you catch any more in future, I am more than happy to take them on.
Also, if there are any other relics from the past that you know for certain are cull worthy, I’d love to know.
Since a lot of these are outside of the launcher git-pull request realm, is there any effective channel to communicate this to any of the devs? Things like the legacy file paths you mentioned, and the leftover directories/config files I mentioned earlier.
Ahem. Back on topic.
Another thing updated that I’ll be adding to the next release. Icons for the individual ID software WAD files. You’ll still need to provide your own WAD files in the /games/ChocoDM directory, but at least they’re a bit neater now, and matching the DEOT theme.
Just move this to the
/home/cpi/apps/Menu/20_Retro Games/ directory, and remove the
/home/cpi/apps/Menu/20_Retro Games/05_ChocoID directory.
I couldn’t work out how to have these applied to the skin file, and instead just put the icons in the same directory as their corresponding script.
These are such small updates, that I’d almost be inclined to say that they’re easy enough to do yourself to your existing installation, so you don’t need to wipe your card.
Other things I’ve done are just cleaning up the mupen.sh script a bit. It had a lot of superfluous parameters. I’ve also updated to Retroarch 1.8.4, but honestly I can’t notice any groundbreaking differences. It’s mainly pertaining to multi disk games, but personally that only applies to playstation games, and I normally just use the standalone PCSX+ emulator. If you so update to 1.8.4, here’s the config than I had to remake:
Oh and of course, the battery monitor! In the skin file Skin Development! I have included a themed DEOT coloured battery monitor. I have however moved it to the Utils directory, since the home screen was messy enough as is!