I'm feeling like a goof. Having installed the latest test version which supports caching, the BDEMU2 package and having set ext game data on a couple split games, system information never indicates syscall 8-even after a complete restart of MM with Hermes set (which is the default.)
Can anyone point out what I overlooked?
EDIT: I did FTP to the USRDIR & verify the size of BDEMU.BIN as 4992 bytes. I simply receive a message stating to set the Hermes option under settings for emulator type upon attempting to launch any split game.
EDIT2: I neglected to do a complete system restart to apply the changes after updating multiMAN. My bad-all working now.
could you increase the horizontal navigation speed i.e between columns to match the vertical navigation speed in xMMb mode??
Thanks for the response, but I got it sorted out with dean in IRC... one of the fonts was .TTF (in caps) and I hadn't noticed
Originally Posted by whompus60
Awesome possum, good to hear it all worked out!
Originally Posted by spengh
Some more news:
Latest test version 2.00.00T14 supports games with up to 10 BIG files (not that there are any games with more than 2-3 4GB+ files).
It allows games like Killzone 3 3D and God Of War Collection to be ran from external USB with caching big files to internal (since they have more than one big file). Don't confuse number of split files with number of big files.
Originally Posted by deank
How far is your work with the Video Subfolders? This is the only thing I need for the best Media and Game Center ever
thanks..tried that, didn't work .. still shows empty drive, no files .. also did chkdsk, it just lumps fragments files into FOUND.000 dir .. didn't help .. although right now, I"m using File Scavenger and Easeus Data Recovery Wizard .. they're able to see my files .. hopefully I'll be able to recover once they're done scanning (takes about 40 hours for 2TB lol) .. i think what went wrong was when I was copying one game from USB to USB, it somehow deleted or corrupted a partition table or something that stores the file structure ... 'cuz I see the data recovery app detecting the first level directories as Unknown and sub directories accordingly .. like for instance, I have all my games in their respective folder name under Games directory and all games w/ 4GB+ file under Gamez directory .. the Games and Gamez folders are lumped as Unknown and the sub directories under Unknown list all my games folders ... soooo, if anybody knows how to recover or edit the hard drive table structure to fix my problem, please let me know .. then I can stop the scanning and start playing with multiman lol ..
Originally Posted by caipi
sorry Dean, didn't mean to deviate from the thread's main subject .. keep up the good work .. don't go on vacation just yet :)
The exact same thing happened to me-except with Vanquish. When I attempt to boot it from the disk icon, it initially appears to be loading then nothing but a blackscreen.
Originally Posted by joshuab
EDIT: Saw Dean's response to your post. I tried with no game options selected(I.e. ext game data) and still ended up with a black screen requiring a system restart. The files seem to be cached fine, however. I'll try another game.
I've noticed two minor problems with some of the recent updates.
I haven't yet had time to test the very latest, but I read the change list and have reason to believe that those problems are unchanged.
Problem #1: Joystick sensitivity weirdness.
I noticed that your new default values for the joystick deadzone has another effect apart from preventing response at lower tilt percentage. It also has a major effect on the arrow movement speed, which really has nothing to do with real deadzone usage.
My guess is that you take the analog value and subtract an amount matching the set deadzone percentage in order to calculate the speed, and suppressing all movement if that speed is negative, but this also results in a very low top speed for very high deadzone percentage, such as your new default of 90%. (Perhaps that guess is wrong, but it does match the observed behavior.)
IMO the deadzone setting should only be used to suppress the movement completely for a tilt lower than the setting, but should allow the same top speed regardless of what deadzone setting value is used, since it is not intended as a speed setting though it currently works that way too.
As a workaround I just set both deadzone values back to the old default of 30%, which raised the arrow speed sufficiently to make it useful in the file manager again. (Which it definitely was not at 90%.)
Problem #2: Theme mixture, for themes with 'holes'.
For quite some time now we've seen some odd phenomena with themes that don't use all alternate file features of recent MM versions, and that includes not only the very old themes, but also some of the latest which claim to be fully updated for MM 2.00.00...
The odd effect is simply that whenever a theme has ignored including an alternate file, the corresponding file will be used of the last theme that was active, sometimes with horrible side effects. Apparently the authors of those themes have assumed that the 'holes' in their own theme implementation will always be filled by corresponding files from the 'Original theme', and have adapted their design to this. But that only works if that theme was the active theme at the time of activating a theme with such holes. For other cases we will see a mixture of two non-original themes, with sometimes wildly conflicting choices of color etc.
As I see it there are four ways to deal with this situation:
1: Simply ignore it, leaving it up to each user to manually switch to 'Original Theme' before activating any theme with holes. This is of course the easiest to implement, as the users do all the work... :lol:
2: Issue a demand that ALL theme designers must include all variant files, possibly borrowing them from 'Original Theme' if needed, before making new theme releases. This is still quite easy for you to implement, but is likely to be ineffective, partly because some will ignore the requirement and partly because new theme features will continue to obsolete existing themes even if they tried to include all that was defined at the time.
3: Change the MM method of activating themes, such that it always reactivates the 'Original Theme' first, before activating a different user-selected theme. This too would be quite easy to implement, but would have the drawback of making theme switching much slower.
4: Change the MM method of activating themes, such that it keeps track of all files that the newly loaded theme includes, and for each standard alternate file it does not use, MM then copies the corresponding file from the 'Original Theme'. :)
I believe that solution #4 would be the best, as it ensures fully consistent behaviour while keeping the increase of the theme switch delay to a minimum. But it does mean a lot more design work for you, as well as a new 'role' for the 'Original Theme'. It will no longer be just another theme like any other, since it will be used to fill in any holes of other themes. Because of that new role you may need to protect that theme from user tampering, and perhaps not even include it in the same storage folder, where users might delete it just like any other theme, when accessing them through the file manager.
Best regards: dlanor
I noticed this really early on and release my themes with "dummy" useless variants. For a while there, there was a newly added file about every day to the set and plenty were designed to replace others. I always tried to stay on top of all that and keep mine future proof.
Originally Posted by dlanor