Home Page
So I thought I might give Mess a try. I download the package, read through the manual several times, and still cannot get the damned thing to run an NES game. No matter what game I pick, I get an error notice that says "Could not load controller file (followed by some Japanese characters and garbage).cfg, which also happens to completely hide my mouse pointer, making it next to impossible to try to close the window. When I do finally guess-click the window closed, the whole emulator gui closes. Yeah, that's real fucking great!

First off, what the hell is it talking about? 'Controller file' leads me to believe I need to map the controllers, but the options tabs for these give me no option to do so. This is totally retarded that you can't just follow intructions and load a damned game. It has to be this big mystery that isn't covered AT ALL in the documentation. I've just about had it with this crap!
as you can see, this board is not full of people complaining about this problem. quite the opposite: there is a lot of people which have no issue at all starting NES games (or any other system for what it matters).

therefore, you should have wondered if the problem was at your end rather than in MESS... and that maybe complaining the way you did would have made *you* sound retarded.

anyway, trying to be constructive, why don't we try to debug the issue and see if there is an easy solution for you as well?

1. try to delete the ctrl/ & the cfg/ directories inside the MESS directory, and launch again MESS. Does the issue still appear?

even in the case that 1. fixes your problem (which I cannot even test, since I use MESS on MacOSX) could you please also try the following?

2. copy mess.exe (not messui) in your C:\ folder, put a NES games in C:\, open the Command Prompt and type first

cd C:\

and press enter to move in the C:\ folder, and then

mess.exe nes -cart YourNESGame.zip

and press enter to launch command line MESS

The answers to this second question might help us to understand if the problem is in the User Interface.
I thought somebody might try to claim it's somehow my fault, but the simple fact is I followed instructions exactly, and its the PACKAGE at fault, not me. This is my first time trying MESS (the package is 142). I have MAMEUI64, which works perfectly fine, so I'm already familiar with the layout.

So yes, let's be constructive here and prove that it's the package's fault:

1. When I opened the zip, there was the following files in it:

An artwork folder.
A hash folder.
mess.chm file (which I've read every word of over a dozen times now).
mess.exe file.
messui.exe file.
sysinfo.dat file.

2. Upon extracting the contents and running the messui.exe, I then set the NES roms directory under the gui directory options.

3. Now the Gui shows my roms list, and upon trying to run a game from that list, I get the controller file not found error.

4. Upon closing messui, I can now see there is an additional MESSUI.ini file, an additional ini folder, and an additional nvram folder. That's it. Nothing else.

5. The messui controller options tab does not allow me to map a controller. Additionally, the tab where you are suppose to be able to select a controller file has 'standard' listed.

6. I further discovered I could copy my MAME cntrlr folder over into the MESS folder, and this would allow me to select the 'Sample Controller File' that was contained in the MAME cntrlr folder (although the error I now get is "Could not load Sample Controller File.cfg").

This leads me to conclude that the messui is not generating a proper controller folder and file, thus causing the error. The problem is I have no means to fix this. Whoever made this package needs to set it up so that either:

A. The controller folder comes included with an intact and working controller file.

Or

B. Actually fixes messui to generate a controller folder and working controller file so that new people to MESS like myself don't think the package designers are missing a blatant flaw.




Update:

I was able to fix the issue myself, and it WAS the fault of the package download. As I stated above, I was able to reason out that the messui.exe was expecting a 'ctrlr' folder to exist with the appropriate 'standard' controller file. I was able to generate a nes controller file by running mess in command prompt and assigning controller buttons. When I exited mess, a 'cfg' folder was created, which contained the nes controller file. I took this file and placed it into a 'ctrlr' folder I made myself in the mess directory. I then loaded messui, went to the controller tab, and was able to select the nes controller file I had copied over. FINALLY the game loaded with no error warnings.


So to conclude:

Those downloading the mess package for the first time like myself WILL encounter the exact same problem if they try to use messui to run their games. This is because the package fails to include the ctrlr folder and 'standard' controller file, nor does messui properly generate such a folder to begin with.

I was 100% correct in my findings that the package as released is broken.
I was not excluding that it's a problem in the package, but since I'm on MacOSX, I had no way to test it directly. thanks to your investigation, we might avoid making again the same mistake with next release.

in conclusion, the problem seems to be in MESSUI (and not MESS) requiring something in the ctrl/ folder to properly start. this should not be mandatory (nor it was in older versions), and we will try to find a fix. probably other users did not encounter this new problem because they had already an old version and therefore all the files had already been created in the past.

as you might have noticed if you use MAME too, the UI code is not really developed anymore (e.g. MAMEUI 0.142 has huge memory consumption which nobody has been able yet to track down exactly, in order to find what is the cause) and MESS uses the same code having the exact same issues (+ some more, apparently).

a workaround (until some of the devs using windows found and fix the problem you have experienced) is to use mess.exe with a frontend and simply ignore messui.exe.

EDIT: and, to conclude, maybe if in your first post you would have simply said 'the released package has an issue' instead of claiming the documentation being incomplete and the emulator being not working (when it clearly is working, as trying command line would have proven), maybe you would have received more help. otoh, based on your posts I can conclude that your attitude sucks. period. go back using a different emu, if you prefer.
Originally Posted By FirebrandX
Yeah, that's real fucking great!

First off, what the hell is it talking about? 'Controller file' leads me to believe I need to map the controllers, but the options tabs for these give me no option to do so. This is totally retarded that you can't just follow intructions and load a damned game. It has to be this big mystery that isn't covered AT ALL in the documentation. I've just about had it with this crap!


Talking like that about something that is free, and others have put years of time into, is not the way to get friendly help. With your attitude, perhaps you should use something else and get out of here.
In fairness to the OP, MESSUI is pretty broken at the moment and that should be made more clear.
http://bugzilla.mess.org/show_bug.cgi?id=2037
Actually, for me at least, MESSUI seems to be working quite fine.

After talking on the channel, I decided to replicate the problem, only to find that my mess.ini has always pointed to a non-existent ctrlr folder. Both MESS and MESSUI seem to cope with this perfectly well.

So not only could I not create the issue, but I should have been the subject of it for some time!
Try the related problem of starting MESS without specifying any options. WinXP SP3 Home 32-bit

C:\mingw\mess>mess
0022E858: 0140DE30 (not found)
0022EAD8: 01227BE5 (not found)
0022EB68: 010747BD (not found)
0022F938: 0109D3D9 (not found)
0022FBB8: 011E5964 (not found)
0022FF28: 00BC41AF (not found)
0022FFC0: 004013B9 (not found)
0022FFF0: 7C817077 (RegisterWaitForInputIdle+0x0049)
Could not load controller file τǵτ░⌐w%d x %d.cfg

C:\mingw\mess>

An empty ctrlr folder is present and mess.ini points to it. Regardless, this should not happen as no system was specified.
Originally Posted By robbbert
Actually, for me at least, MESSUI seems to be working quite fine.
...
So not only could I not create the issue, but I should have been the subject of it for some time!


I can only confirm it as well that MESSUI has no problem with something like that.
I started MESS/MESSUI 0.136 from scratch and i had no problem at all, i tried also MESS 0.139 and 0.141 and i have never had an issue like that!

Maybe another build of MESS (unofficial)?
you have to try 0.142. older version are known not to have the problem.
Robert Gault: i do not get that problem. All works as it should.
OK, I've tried, no problem at all, MESS/MESSUI runs without a ctrlr/cfg dir and without any options.
(I've tried various Systems and games)
Originally Posted By Ganellon
OK, I've tried, no problem at all, MESS/MESSUI runs without a ctrlr/cfg dir and without any options.
(I've tried various Systems and games)


Confirmed
Very strange, that error (starting mess without options) is with svn 11119. MESSUI starts without errors, mess + emulation starts without errors.

Tonight I'll make a completely clean build and see if the error persists.
OK Clean compile of MESS and the error is still present whether or not OSD=winui is used. No problems with messui.

The garbled characters can be removed as follows:
C:\mingw\mess>mess
0022E858: 0140E9B0 (not found)
0022EAD8: 01228695 (not found)
0022EB68: 0107526D (not found)
0022F938: 0109DE89 (not found)
0022FBB8: 011E6414 (not found)
0022FF28: 00BC4C5F (not found)
0022FFC0: 004013B9 (not found)
0022FFF0: 7C817077 (RegisterWaitForInputIdle+0x0049)
Could not load controller file τǵτ░⌐w%d x %d.cfg

C:\mingw\mess>

Now do it this way:
C:\mingw\mess>mess -ctrlr coco
0022E858: 0140E9B0 (not found)
0022EAD8: 012288AC (not found)
0022EB68: 0107526D (not found)
0022F938: 0109DE89 (not found)
0022FBB8: 011E6414 (not found)
0022FF28: 00BC4C5F (not found)
0022FFC0: 004013B9 (not found)
0022FFF0: 7C817077 (RegisterWaitForInputIdle+0x0049)
Could not load controller file coco.cfg

C:\mingw\mess>

In both cases, there are cfg and ctrlr directories both containing coco.cfg.

There is no need for the ctrlr directory for the Coco family and this error was not seen until quite recently. It is not present in build 141b. I have not yet downloaded 142b to test it.
I just tested build 142b and did not get the error. That did not seem consistent with svn tests so I decided to delete the mess.ini file from the svn directory.

A new mess.ini file was created with mess -createconfig and now the error is gone from the svn build. I don't know what was in the ini file that caused the problem but replacing this file will probably help other users with similar startup problems.
Interesting, I found a MAME user who has the same error. I've advised him of your solution. Have to see what happens.
To throw in my 2 cents because I came across this problem and after typing into Google "could not load controller file MESS" it brought me to exactly where this guy is complaining so figure I'm not the only one.

My issue came from trying Mess 64, I used to get it from Bob Z and never seen it there anymore...anyhow.

Mess 64 never worked for me, I tried to see what improvements to ADAM (which should be called Coleco ADAM) and it could not find the boot ROMs. Regular Mess runs exactly as expected. Yes, I know it's not perfected so don't dog me.

After deleting Mess 64 I tried runing regular Mess x86 and got the error message mentioned when in fact everything was running before I tried the X64 version.

I deleted everything in order to start over yet still the error is there so I will use a backup and take note that it is looking for a non-existent .cfg file.

I'm just telling my story so someone can address it but I will fix it.

As far as attitudes go, the old saying you catch more flies with honey still applies but the old adage if you don't like it because it's free then go bugger off...come on guys, we are trying to improve the software and criticism and bug reporting is how it gets fixed not shooting the messenger just because he's frustrated.

MessUI for me has been a nightmare over the years and that's why I never took it seriously because the Coleco controllers have been crap and never improved for several years. Even assigning a single keypress is the same as pulling teeth. Well, it's free like you say and I never gave my thoughts but now that I gave you guys the bins for the 6801's I hope that some progress will be made.

I'm still looking for a used ADAM disk drive so I can pull the data off it but even on EBay they want the price as when the darn thing first came out 25 years ago.

But seriously, someone needs to re-write the MessUI for a modern system.
Originally Posted By KevinP
As far as attitudes go, the old saying you catch more flies with honey still applies but the old adage if you don't like it because it's free then go bugger off...come on guys, we are trying to improve the software and criticism and bug reporting is how it gets fixed not shooting the messenger just because he's frustrated.

But seriously, someone needs to re-write the MessUI for a modern system.


except the original poster was not trying to help. just shouting out as an asshole and then leave to go on complaining on other forums he visits.

I almost regret to have tried being supporting. Maybe the standard 'Ask for your money back' would have been more appropriate with that guy, but I thought a discussion would have helped other users with a better attitude, so I forced myself to help.

Overall, anyway, I was always convinced that fully taking out MESSUI would have been a bad move, despite myself being unable to help because I know nothing about Windows API and because I cannot test any change being on a Mac. Always, until this thread started. Now I think MESS should only be released as command line and users should use frontends to have a nice GUI.

Originally Posted By KevinP
MessUI for me has been a nightmare over the years and that's why I never took it seriously because the Coleco controllers have been crap and never improved for several years. Even assigning a single keypress is the same as pulling teeth. Well, it's free like you say and I never gave my thoughts but now that I gave you guys the bins for the 6801's I hope that some progress will be made.


you should simply start Coleco (or Adam) emulation and press TAB. In the Configuration menu you choose the controller you want and then you go in the Input (This System menu) to configure the chosen controller. of course, changes are saved for next time you launch the system.
Originally Posted By etabeta78
Now I think MESS should only be released as command line and users should use frontends to have a nice GUI.


The problem is, at moment no other external GUI alternative exist to replace messui (with all his features) completely. The other frontends are not specific enough.
Maybe in the future, a new MESS specific GUI should be developed which is platform independent.

That's my opinion.

qmc2 works very well (with softlist support in progress)
Originally Posted By etabeta78
qmc2 works very well (with softlist support in progress)


Of course, qmc2 is no bad but for me not really a alternative to MESSUI.

For beginners too complex and for extended user, some MESS specific features are missing.
Agree with AnnaWu. I'm not even sure why MESSUI is being picked on now, as the standard command-line builds of MAME and MESS also can display the OP's problem. (Although I personally have never seen the problem no matter how hard i try.)
eta, please do not misunderstand me. My wish is to win more MESS user in the future.
The vast majority of normal user does not use the command line with parameters to start the emulator.
A specific and user-friendly GUI can be helpful in this case.
I dont like to answer the first poster.
His posting is just abusive and deconstructive, nothing else.
Originally Posted By Anna Wu
eta, please do not misunderstand me. My wish is to win more MESS user in the future.


mine is too, of course

Originally Posted By Anna Wu
The vast majority of normal user does not use the command line with parameters to start the emulator.


true. that's what frontends are for. but if no MESSDev wants to work on one (be it MESSUI or any alternative frontends), we should simply help front-end authors to improve their MESS support, rather than try to keep alive that zombie that MESSUI has become.

Originally Posted By Anna Wu
A specific and user-friendly GUI can be helpful in this case.


except nobody seems to have the skills and the wills to create it and maintain it.
Originally Posted By etabeta78
true. that's what frontends are for. but if no MESSDev wants to work on one (be it MESSUI or any alternative frontends), we should simply help front-end authors to improve their MESS support, rather than try to keep alive that zombie that MESSUI has become.


I'm a bit ambivalent about it as we move then into a dependency.
If the external frontend developer stop the development or for a long time no any updates or bug fixes comes, the normal user is the loser.
See MAMEPGUI which had very good approaches as example.

Originally Posted By Anna Wu
If the external frontend developer stop the development or for a long time no any updates or bug fixes comes, the normal user is the loser.


the sad reality is that MESSUI itself has currently no developers at all, and therefore it is MAMEUI/MESSUI developers who have stopped both development and bug fixes.

as a result MESSUI has the same problems as MAMEPGUI, plus the fact that people expect it to be fully working since it is shipped together with the command line version

if we had 2 or 3 developers who love to work on UIs and want to spend time rewriting MESSUI to work with the latest core, I would 100% agree with you.
But these 2 or 3 developers do not exist and MESSUI is simply dying
Dying? It's clearly dead, given that it's an active impediment to ease of use. Hell, even MAMEUI is dead in the water now - it uses 2 GB of RAM and poor John IV isn't a developer so he has no idea why. This is exactly why MAMEdev has always been against integrated UIs.

The plan is to implement IPC capability on all OSes to allow external frontends to be able to change settings and mount and unmount images while the emulator continues to run. This capability will of course also be available to MAME. Once that's ready and frontends start taking advantage of it MESSUI can be eliminated.
Originally Posted By etabeta78
Originally Posted By Anna Wu
If the external frontend developer stop the development or for a long time no any updates or bug fixes comes, the normal user is the loser.


the sad reality is that MESSUI itself has currently no developers at all, and therefore it is MAMEUI/MESSUI developers who have stopped both development and bug fixes.

as a result MESSUI has the same problems as MAMEPGUI, plus the fact that people expect it to be fully working since it is shipped together with the command line version

if we had 2 or 3 developers who love to work on UIs and want to spend time rewriting MESSUI to work with the latest core, I would 100% agree with you.
But these 2 or 3 developers do not exist and MESSUI is simply dying
What exactly isn't working? Worked fine for me so far.
1. memory consumption (less evident than in MAMEUI, but still there)
2. ctrl/cfg issue reported here
3. no proper support for softlists and no devs interested to implement them
4. no dev available to fix problems with future changes from Aaron

am I forgetting anything?
Well there is time when you have to say goodbye, and thing is that burden of UI is quite long there, and we have done lot on fixing it, but it became more and more unstable, and complete rewrite is only option, and that is going to take time.

And since there are already existing GUI's with authors willing to improve them, and us willing to help them, it's natural thing to move toward that solution.

Surely we are not going to remove MESSUI until there is proper replacement for it, and we are already in talks with GUI authors about that. Think users will benifit with this change, since that way they will get stable solution, that is maintained and done in proper way.

Support for new features will be handled in giving info in proper time to developers of GUI and that way their solution can be ready to cover releases of MESS, but also of MAME, since most of GUI's support both.

As RB mentioned, adding some more feature in core, would give much more flexibility and made those GUI's much better then MESSUI ever was.

This is live project and such things occure. Sometimes there are unpleasent things that leads to better solutions.
Originally Posted By Anna Wu

...
See MAMEPGUI which had very good approaches as example.


M+GUI works just fine with MESS too...
A quick fix was achieved for me as far as the config file.

#1, of course is if you already have the mess.ini inside the ini directory. Aparently this is the default file that is copied when you run a particular emulated machine.

#2, use Mess .141 or earlier to rebuild the mess.ini after you delete it...REMEMBER the one inside the ini directory. After then you can use .142.

#3 and I don't recommend it is to edit the mess.ini and delete the foreign characters leaving only quotes. As an experiment it worked but I prefer the best method and that is #2

Now...x64 does work for me I just forgot that ADAM changed the rom structure for .142 and the x64 version I tried was .141 so there you go.

As far as ADAM goes...PLEASE whoever is making the driver I hope that it is just a skeleton and you don't start thinking Digital Data Drives are Cassettes. They are exactly like disks and have directories and file addresses. They certainly aren't .wav files.

I am hoping that this isn't due to some young guy who wasn't alive when ADAM was first released. I hate to admit my age but was in my teens and had one at the time. Believe me $800 was reasonable for that machine and only 64k memory.
Originally Posted By Ganellon
Originally Posted By Anna Wu

...
See MAMEPGUI which had very good approaches as example.


M+GUI works just fine with MESS too...


It depends on one's own claims.
Im too tired to enumerate all pros and cons between the different frontends.

BTW, I was able to reproduce this issue with the invalid controller name: When you change properties in the context menu of the driver and apply them, the ini file of the driver gets a ctrlr entry inserted with these invalid characters.

Seems as if the messui fails to deliver a value for this setting. I don't have insight into the implementation either, sorry. My knowledge about Windows and UI programming is null.

In any way, this is a severe problem for users, definitely.

Michael
Originally Posted By robbbert
Interesting, I found a MAME user who has the same error. I've advised him of your solution. Have to see what happens.


Got feedback on this. The solution of clearing out the ini files worked, so we have a solution there. The next problem he had was that due to general memory requirements, the game ran slow then froze. So he has abandoned the use of MAME 0.142 and gone back to an older version.
Originally Posted By KevinP
A quick fix was achieved for me as far as the config file.

#1, of course is if you already have the mess.ini inside the ini directory. Aparently this is the default file that is copied when you run a particular emulated machine.

#2, use Mess .141 or earlier to rebuild the mess.ini after you delete it...REMEMBER the one inside the ini directory. After then you can use .142.



Thanks, had the same problem (Win XP 32bit). Fixed the cfg issue, however, Messui takes up an unusual amount of memory in this version.
I've a better description of this problem and it is not as simple as I thought. The following applies to mess.exe compiled with the OSD=winui option.

There are two core options in the mess.ini file,
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0

Depending on whether writeconfig is 0 or 1, the bug is sometimes catastrophic.

With the settings as above, starting mess without any options, and selecting emulation from the random list, the Image Device entries in specific emulation ini file are ignored.
When that emulation is terminated and the same emulation immediately restarted without leaving mess, then the entries in the Image Device list are used.

The above is annoying but not a serious problem. However if you want any mounts or changes to settings remembered and set
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 1
then really bad things can happen. I have had specific ini files completely erased clean. I've also seen what seems to be incorrect data written into ini files as if the data applied to different emulations. This latter problem seems to be why the can't load cfg file sometimes occurs.
As an example, I've seen the memory size for coco3h changed to 64K which can prevent that emulation from running as the minimum should be 128K.

Now since the emulation selected at random seems to depend on the number of ROMs available in the ROM or sub-directories, the user results will not be easily reproducible. That's why this bug is not seen by all users.
I can now very easily reproduce the "wrong cfg" issue (in MESSUI).
At the "Default System Options" choose as "Default System Layout" (tab: Controllers) "Standard", if it's already selected, select it once again and then press OK. From now on none of the systems is working (the usual error msg).
Without the "ctrlr" dir and the "Standard.cfg" file in it the mess.ini file gets an ""猀慮癰敩w%d x %d" value for the "Ctrlr" entry!!

MESSUI 0.142 has indeed serious problems, in fact is almost unusable.
I found out that no changes can be saved individually for the systems. If you try to change -twice- the properties for a System then all values return back to defaults!!
You must restart MESSUI if you want to change another value.
Originally Posted By Ganellon
MESSUI 0.142 has indeed serious problems, in fact is almost unusable.
I found out that no changes can be saved individually for the systems. If you try to change -twice- the properties for a System then all values return back to defaults!!
You must restart MESSUI if you want to change another value.


check your mess.ini. if it contains

writeconfig 0

change it to 1, and it might work (or maybe not)
Originally Posted By Ganellon
I can now very easily reproduce the "wrong cfg" issue (in MESSUI).
At the "Default System Options" choose as "Default System Layout" (tab: Controllers) "Standard", if it's already selected, select it once again and then press OK. From now on none of the systems is working (the usual error msg).
Without the "ctrlr" dir and the "Standard.cfg" file in it the mess.ini file gets an ""猀慮癰敩w%d x %d" value for the "Ctrlr" entry!!


... ehh, actually i was wrong!, something else is happening, it is not the "Ctrlr" dir the problem nor the "Standard.cfg" file!!
There is a "Standard" entry in the "Default System Layout" but this is NOT the "Standard.cfg" file!! it seems that this entry is somehow a default value in the list-box but it's like a "dummy" value - it has nothing to do with the "Standard.cfg" file, if someone select that value, no matter what files are in the "ctrlr" dir gets always the same error-msg!
Originally Posted By etabeta78


check your mess.ini. if it contains

writeconfig 0

change it to 1, and it might work (or maybe not)


Yep, i had the same thought too, but no, unfortunately is not working either.
Thinking about alternative UIs - what does messui actually do?

- Handle the ini files and configurations
- Allow for software/media selection
- Launch mess

Say if I had the time and ambition to build a Java-based UI (whether system-specific or general), would it basically mean to let the UI start mess in a new process and pass it a list of arguments "-flopN XXXX -cartN XXXX ..."? Or is there a special call interface?

Michael
MESSUI parties directly on the core internals, which is most of why it ended up being so fragile. There are probably dozens of frontends out there that do exactly what you suggest as far as starting a new process and passing a list of arguments and/or a prepared .ini file.
© Forums