Ok, here is with verbose and new build: http://paste.ofcode.org/fdPTfvm9umEC2vtcARn5r4
Ok I have found your problem, when using the -s switch to specify your save directory, the libretro interface is working correctly and saving in the correct location but, RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY is not getting populated,
So the path is being set correctly and the frontend can use it but the core can’t use it on it’s own. To confirm, run without -s please and let me know if it works
Yes, I can confirm, without the -s flag it saves correctly into the srm folder. I don’t think this clashes with the use of the flag for the HyperSpin frontend, since HyperLaunch is only concerned about savestates, the -S flag, this one works fine as you already know.
-S always works because cores don’t save states on their own they always use the libretro implementation. It’s a bug but may not be fixed since the command line options are old stuff from the SSNES era, probably maister forgot about them when he added RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY.
I’ll open an issue anyway. Not a core issue but a RA issue.
Well, I get lost on these details, but I’m happy the issue has been narrowed down. I keep it on my bug list as always as a reminder. Thanks for help.
I’m worried that after almost 3 weeks, this simple fix have not even been assigned to anyone. Will we still be getting mcr files in system folder for v1.1?
edit: I remember this issue now. Lots of stuff being done elsewhere so I guess this hasn’t really been looked at. My advice for now is to remove the -S and -s settings from the commandline and use only the paths from the custom config
I know they are busy, and as I suspected over-optimistic. I already complained about that in the blog news.
I sometimes wonder if you are shooting too high. There are many things “in paper” and I fear that focusing on too many things will make the whole poorer:
I got a reply that time is on their side, but we are only 2 weeks off the next major version.
Hmm no… Also you complained about these: -RA port to new systems (PSP, Blackberry, etc ) (pretty much done) -Lightguns and Sticks support (works, needs core support but SNES/GENESIS/NES already have this support in place) -New GUI (partially working) -Watch movies (soon) (ffmpeg works) -augmented reality, etc (works, proof of concepts only, no cores are using these)
About the answer… I don’t know who is Kane.
Launching via CLI or hyperspin is just not a top priority atm I guess. CLI used to be a first class citizen but it isn’t anymore. RGUI is mature and it just works now so the attention is elsewhere at the moment. There is a huge settings refactor underway and it will result in easier interaction from internal menu drivers and external applications.
The september dead line isn’t set in stone if it has to be delayed I guess it will be delayed again, (I’m not implying it will). Second, you’re confusing your priorities as an end user with the team priorities. Libretro is a lot more than an multi system emulator. It’s an ecosystem. Improving the API and the frontend are top priorities as always. I guess core work is next, and niche features last.
Complain? haha no! You didn’t get the point, I don’t want any of those “features” if that is going in detriment of what is already established. Why put augmented reality if it’s going to be poorly implemented? Why put video recording if it’s going to be poorly implemented, and so on…
I think they should iron out current issues, instead of adding a bunch of non realistic (and IMO not very necessary) features. You know “bugs” and “stable release” don’t go well together.
Things that should have preference as I said are first bugs then half finished stuff like RGUI video recording, lightgun and stick support, multitap support, things like the above with the PSX (remember this is a bug not a feature), and real custom DAR/PAR. You already know, here is my bug list, not the one in the blog.
3 more weeks, and still bug isn’t assigned to anyone. Yes, release was delayed to end of September, mind you I’m not complaining about the bug itself, I worked out a workaround using autohotkey for automatic deletion of the file, but what saddens me is the full-of-bugs release they are amassing, this is a real example of how development works when at a professional level it should be bugs first, features after, otherwise the ball just gets bigger and bigger.
3 more weeks, and still bug isn’t assigned to anyone
Sure I’ll hire a dev to fix the issues you report, $2k a month should do… :rolleyes:
You’re using a commandline option that hasn’t been updated since… forever. Since your last post a lot of stuff has been changed or refactored Anyway they are just busy. Lots of stuff going on.
Keep it real; the issues I report; no, the bugs of RetroArch, yes. To fix a bug you first have to acknowledge it and this one just represents one of surely many that aren’t acknowledged because developers are busy adding augmented reality, or video players.
Once again you have no idea of what’s been going on. There is no point fixing some small setting when you’re refactoring how settings work completely.
I have the idea developers let others know, no more no less.
I spotted a new issue FFIX won’t play, using PAL version, patched, I can hear the intro but screen is black. My guess the header or some part of the image changes and thus RetroArch can’t read it anymore, probably ePSX has no issues.
Yet one more unplayable game. “Legend of Zelda, The - Majora’s Mask (Europe) (En,Fr,De,Es) (Rev A)”. This time using last build “10-07” (although doesn’t work on previous ones either). It triggers an in-game disclaimer saying:
“this game is not designed to use on this system”
if no one confirms I might add it to the buglist, among other great unplayable games (Red Earth, FFIX, etc). My guess is we won’t see any changes on this on the already late “stable” release, they are busy with augmented reality grins