|
|
Hi everybody.
I was wondering... is there something wrong with the new MAMEUI (version 0.276)?
I can't seem to be able to "add folders/directories" in the "options/directories" section...
I mean: I can add them - obviously, and they work just fine after the rom audit. BUT when I restart MAMEUI it "reverts to default" and forgets my custom settings.
Strangely enough, it DOES remember where to "fetch" the background image - and that is from the same storage unit (so not a hardware issue).
I tried numerous times, thinking that the error was on my end but... now I´ve subsided to the "inevitable" and moved all my "roms" to the default folder.
This works well in MAME, but perhaps not with other applications.
Help, anyone? Feel free to comment |
|
I can confirm this.
It looks like mame.ini gets saved correctly when you add folder paths but then gets ignored and overwritten with the default one when you start MameUI 0.276.0 again.
I tried making mame.ini read-only but then MameUI 0.276.0 still ignores it; it just can't overwrite it.
It also seems that MameUI is compiled from a different source than Mame 0.276 is, it contains 2 more romsets, so hopefully that gets fixed, too.
|
|
0.276.0 was replaced by 0.276.1
It's recommended that you change all relative paths in .\mame.ini and .\ini\mame.ini to absolute paths.
In other words, change "roms" to "c:\mameui\roms" (or wherever your roms are located), same with all the other paths in those 2 ini files. |
|
Hello,
I had the same problem. I copied the mame.ini and ui.ini files, where the mameui.exe file is located, and now I no longer have the problem of always having to re-enter my ROM folders.
Just for your information. |
|
Yes I forgot to mention ui.ini
One thing that is absolutely required is that the inipath MUST point at the ini directory just off the emulator root, so for example
C:\mameui\ini - don't put any other paths there.
All this stuff about absolute paths applies to arcade,hbmame,mame itself and all other derivatives. Some are affected more than others, but you shouldn't use relative paths anywhere. Otherwise, sooner or later some strange thing will happen. |
|
Hello again.
I had a few initial problems with the "new" build - it did reset itself once...
I made some small changes though: copied "mame.ini" from the ini directory to the root directory and changed my ini-files path to just "ini".
It seems to work now.
Thank you for the help! MAMEUI - to me - is more than an emulator frontend or a GUI, it´s the absolute best way to play vintage games/computers and to collect pictures of "memorabilia" as well (such as flyers etc). And with the added "manual preview" function it has excelled from good to brilliant.
Thank you once again! |
|
This is starting to get embarassing , but... I think I´ve found another bug (in the latest build - 0.276-1).
For some unexplicable reason the GUI was closed down occasionally when pressing the "A" key.
Example: I highlighted the game "Battle Shark" and then tried to "jump" to the "A" section, searching for another game. BUT - when I pressed "A" the GUI shut down... completely. It only happened in a specific section of MAMEUI (I think), because I tried a similar scenario starting from "Street Fighter" and nothing happened...
Strange... Anyway - I switched back to the original 0.276-release and the issue was gone.
Personal note: I´m not sure if it is an issue with my computer or the build itself. I´ve searched the registry and removed any trace of previous programs that could have interfered with MAMEUI (such as JoyToKey - now removed).
Problems with keyboard settings perhaps? I don´t think so - I have english (british) and swedish "virtual" keyboards installed in windows and there have been no issues with those functions so far...
The first release works - for me anyway, and I´m more than pleased with that.
Big thanks to Robbbert for making MAMEUI possible and available! |
|
Just tried here and no crash. If you think you could reproduce it, start mameui from the command-line with
>mameui > x.txt
Then should it crash, the file x.txt should contain the crash dump at the end. Please send it to me.
|
|
About crash/MAMEUI:
I just PM:ed you the "result" - couldn´t find a way to attach the file, so I pasted the result instead...
Same thing: highlighted exactly the same game (Battle Shark), pressed "A" and MAMEUI closed down immediately... |
|
Hi Robert, in the Mameui emulator,
when I record an INP, it gives an error reading the INP.
Fatal error: ioport_manager::record_init: failed to open file for recording (generic:13 permission denied).
I have to delete the INI file, for example: hsf2j.ini,
in the root of the emulator, and then it works normally.
This shouldn't happen, but it does in Mameui and MESS.
I hope for a solution.
Greetings from Argentina. |
|
Bad_A_BillyMember68 posts Nicorobin - 1 possible solution -
Do you have it trying to record the file in a place where you're not allowed to? Check that locations security permissions (and take it off the C: drive if that's
where you have it).
|
|
Hello again, I noticed a detail.
The ini file is created in the game's root.
But there's a similar file inside the ini folder.
I don't know why this happens, but it does.
I hope for a response. Greetings from Argentina. |
|
@jrideburg: looks like your SWPATH isn't defined in the file ini\discmate.ini , so leading to a null reference and a crash. That's a bug.
@Nicorobin: that's normal to have 2 mame.ini's . It's because mame looks twice, first time in the root, sees where the ini folder is, should be ini off the root, then reads again, this time ini\mame.ini, which contains all the actual setups from the global settings and directories.
If the inipath doesn't say c:\mameui\ini (or whatever your emulator root is) then there will be problems.
This business of reading twice was to cater for unix-based mame, where each user has their own work area. That isn't an issue in windows, so the double read will be removed in the upcoming rewrite. Therefore ini\mame.ini will no longer be used, and the location of your ini files will no longer be locked to "ini".
I don't know anything about INP files as I never use them, but it sounds like another issue with relative paths. |
|
@jrideburg I've committed a fix for your problem. If you'd like to download the latest build from github (when it finishes) and try it out?
|
|
I was running version 0.275, I updated to version 0.276.1 and all my roms and artwork were "not found" despite the .ini files not having changed. Launching any game resulted in all game roms "not found". I reverted to 0 275 and everything was working again. What is going on? |
|
Hi Robert!
About the software path: yeah, I realized this when I started updating my "personal library". I hadn´t been using MAMEUI for quite a long time and the "software path" was a remnant from a previous system setup (old computer). I USUALLY delete my software paths after using them - must´ve forgotten a few.
Still - it´s strange. It shouldn´t be an issue, because pressing an alphabetical key is not the same as pressing "Enter"...
I will try out your fix - whenever I´m able to, and if I can find it. I did find the link to your Github though... 
/jr |
|
Hello again, I noticed a detail.
The ini file is created in the game's root.
But there's a similar file inside the ini folder.
I don't know why this happens, but it does.
I hope for a response. Greetings from Argentina.
Hello.
I had exactly the same problem - mame creating duplicates of gamefiles.
Example: playing the game "Aladdin (bootleg). Every time I deleted the file it kept "coming back" after running it or even changing the settings (like changing the game from running in fullscreen to windowed mode).
My "remedy"/solution for the problem was:
-copying mame.ini from INI folder to root
-setting both mame.ini-files and mameui.ini to "read only"
-following Roberts advice about the *.ini-file settings and having just ONE "ini" path in mame.ini - only one directory instead of two or three.
...sort of like this:
(scroll down the ini-file to this line below:)
inipath ini
I also simplified my storage structure by trying to remove "auxiliary paths and folders" - moving among other things my extensive collection of machine manuals to a subfolder under MAMEUI...
I have not encountered any more problems with mameui duplicating ini-files - so far anyway...
/jr
|
|
Creation of ini files for games is on purpose. For MAME, you enter parameters on the command-line. But mameui doesn't have a command-line, so instead the game's settings go into the game's ini-file. These settings are then picked up by the MAME portion when you run the game. So it's intentional.
I've just made a whole bunch of changes which you guys might like to try out. If you do, ini\mame.ini is no longer supported so you need to copy it to .\mame.ini, and then delete ini\mame.ini
|
|
Don't see the point of moving mame.ini outside inis directory. Always worked fine that way and now you have to copy it to that folder again if you want to launch mame from the same folder.
Also using only absolute paths is bad if you plan to use the emulator as portable, for example from a usb disk or pendrive. Please reconsider some of those fixes. There's no need to rush things :) Retro Danuart Youtube |
|
Bad_A_BillyMember68 posts
Don't see the point of moving mame.ini outside inis directory. Always worked fine that way and now you have to copy it to that folder again if you want to launch mame from the same folder.
Also using only absolute paths is bad if you plan to use the emulator as portable, for example from a usb disk or pendrive. Please reconsider some of those fixes. There's no need to rush things :)
I agree. I've used mame & mameui in the same folder forever and never had any problems until ini's got moved around recently. I often wondered why mameui.ini isn't located in the ini folder as well(If for nothing else besides consistency.) Unless there is something I'm overlooking, mameui uses the same settings that are in mame.ini and ui.ini as regular mame.exe and all the different mameui.exe pertinent data is kept separate in it's own file, mameui.ini. ??? I could be wrong on that though...
Anyone who needs to go through and alter something manually knows where they're at either way. It would just be more consistent and less data files to muck around with in the end. Just my opinion for consideration...
As to the absolute pathing issue. I can see the benefit from both sides. I myself don't use mame mobile and if I did I'd just unplug an external backup drive & take it with me to wherever I was going but I know a lot of people do travel a lot and take things on the go and need to travel light. Either way doesn't affect me for the better/worse so no opinion.
And besides, if people don't like it they can always STFU, make their own changes and compile their own!
Whichever way you end up going, Thanks again for all your time & effort with keeping UI alive & well Robert! |
|
Looking at the latest mame.exe, it now saves mame.ini and ui.ini outside the inis folder...
So the beahaviour with mameui now it's almost the same, the only difference seems it still saves ui.ini in the ini folder, that the only thing should change to match mame behaves. Retro Danuart Youtube |
|
Well tried both mame.exes and the latest mameui from github:
-By default mame generates ini files in this order --> ., ini, ini/presets. You can remove "." so all the ini files go to the ini folder, if not, mame.ini and ui.ini goes to root folder.
-By default mameui sets the same paths in the mame.ini file, but the first time is generated inside ini folder, ignoring the "." path. Again something is wrong with relative paths here... Retro Danuart Youtube |
|
More changes have been made that you might like to try.
Now ui.ini and mame.ini are saved both to the emulator root as well as to the ini folder.
There was also a bunch of other fixes made. |
|
Hi RetroRoms, the console INP error is still there, in Mameui version 0.277.
In this case, on Sega Genesis/MegaDrive,
I record INP and another game plays it,
but not the game recorded in INP.
The good thing is that the configuration is retained when I exit the game.
And something else also fixed it, in Mameui,
which records arcade INP. Much appreciated.
I hope for a solution. This is the only problem for now.
If I find anything else, I'll let you know.
Greetings from Argentina. |
|