NRage Input Plugin V2.00 BETA (an overhaul)

[rabiddeity]

Yep, Iconoclast, that should be fixed in 2.1 DEBUG. Take a look and see if it works as expected.

OK, summary of current issues in 2.1 DEBUG, just to let you know I haven't fallen off the planet:
-loading of profile resets rumble device (fixed 5/8/2007?)
-should add support for separate RTC file
-removing a device at unexpected times should not cause problems, but it does

 

[Iconoclast]

Okay, sorry, just haven't had a lot of time to read through all the pages of every thread, so thanks for going easy on me there.

And you can change the mpk while running, just not the directory, I do it all the time. I boot the game with the rumble pak (default), if the game uses an mpk, I open up the dialogue pick the mpk for my game and click "use". Then I can toggle between the rumble and mpk with shortcut keys. I think that's adaquate.

There is a difference between switching mempaks and switching between a mempak and a rumble pak.

Changing from one mempak to a different mempak does not work on this system.

 

[Legend]

I swear, I can boot a rom with a mpk in, during gameplay, open Nrage options, click on any of my other 20 mpks and then "use" or "save". Weird that you can't. And I believe this is good functionality.

 

[squall_leonhart]

im pretty sure i can as well actually :/

 

[rabiddeity]

I swear, I can boot a rom with a mpk in, during gameplay, open Nrage options, click on any of my other 20 mpks and then "use" or "save". Weird that you can't. And I believe this is good functionality.

That is so odd that you can still do that. I thought I'd disabled that because it's not really supported functionality. If you can still get at it and it doesn't completely bork your mempaks, I guess that's OK. But keep in mind that it COULD break them without warning. Consider it an "unsupported feature" for now, if you can get it to work.

 

[Legend]

I'm glad the way it is. If people are'nt dumbasses and don't swap mempaks while the game is trying to write or read to it, then there's no problem. I don't think the game is constantly pulling or writing information to the mpk, only at certain moments, i.e. the end of level and it usually tells you as well.

I mean people on the real console could physically change mpks during the game and so long as it was'nt trying to write to it, no harm done. If people are stupid and pull the mpk at a saving or reading moment, then they deserve what they get. But the rest of us should not be punished for the acts of people who are'nt running on all cylinders. If people in the real world can do this, I think we should too.

And even if you DID get rid of this freedom, people could always switch to the rumble pak during a mpk write and boom there you go, possible corrupted mpk. Or they could close the emulator during a write. I mean there's a dozen ways they could corrupt mpks. We can't stop them.

About 30% of my games need a mpk. So I keep my rumble pak plugged in since 90% of the games have rumble. If the mpk system did not let you change during gameplay then I would have to:
1. Change from rumble to mpk and then pick the mpk for the game I'm going to use and save.
2. Boot game
3. When prompted, open dialogue and select rumble pak and use
4. When prompted, toggle with shortcut keys to plug back in mpk to save
5. Then when done with game, close rom and then open up dialogue, select rumble and save to get ready for next time

As opposed to current system:
1. Boot game, when prompted for mpk, open up dialogue and select the right mpk for this game and click *USE*
2. When prompted, toggle shortcut keys for the rumble pak
3. At end of level, shortcut keys to save to mpk and the shortcut back to rumble
4. When done with game, simple close and that's it.

This is how its been forever so I don't think it needs changing. Even the easiest system is kinda a pain in the ass (especially when compared to PSX-memcards separate from rumble system). So I think it fine the way it is. It's more convenient and gives people more freedom with how it is.

 

[squall_leonhart]

speaking of PSX memcards.... :| my ones in epsxe somehow corrupted and i lost all my ff8 and ff7 data... luckily i had save states :\

 

[Legend]

Yeah, that happens all the time. I started making sure I made backups of all my memcards. And I believe from all that I read that this is linked to using save states in conjuction with native saves. So your savestates which saved your ass were the reason you're ass need to be saved in the first place.

 

[squall_leonhart]

nah, my saves were usually fine, im pretty sure it was actually coz my FF7 isos were corrupted, causing EPSXE to lockup and force me to reset the entire system

 

[rabiddeity]

Alright, I uploaded another DEBUG version. I couldn't replicate the bug on my own machine; it might be because you guys have more than one of the same controller installed? (Or DirectInput is seeing multiple controllers, like how one PSX controller adapter can support 2 controllers, or some controller drivers install extra "virtual" controllers for some reason.) I made the device detection a bit more tolerant for modifiers and rumble devices. It might work, or it might cause problems.

Download the newest DEBUG and see for yourself!

 

[Legend]

Good job guy, all fixed!!! I'll let you know if I run into any regressions. Is there anything else your planning to work on before the big release day?:bouncy:

 

[lion10]

Alright, I uploaded another DEBUG version. I couldn't replicate the bug on my own machine; it might be because you guys have more than one of the same controller installed? (Or DirectInput is seeing multiple controllers, like how one PSX controller adapter can support 2 controllers, or some controller drivers install extra "virtual" controllers for some reason.) I made the device detection a bit more tolerant for modifiers and rumble devices. It might work, or it might cause problems.

Download the newest DEBUG and see for yourself!

In Mupen64 and 1964 everything works great, but in Project64 I am still unable to load a language pack successful. No language pack functions, the buttons remain in English. See the attachment for more details.

 

[rabiddeity]

In Mupen64 and 1964 everything works great, but in Project64 I am still unable to load a language pack successful. No language pack functions, the buttons remain in English. See the attachment for more details.

Your log shows that NRage is not able to open the language library, but they're showing up in the language selector. This would seem to mean those files are corrupted in the PJ64 folder, or maybe those files aren't the updated language DLL files?

Are the NRage-Language-XXXX.dll files in the "plugins" directory or the Project64.exe directory? I don't think this is the problem, but they must be in the Project64.exe directory; remove any that are in "plugins".

I've uploaded a DEBUG that should tell me specifically what file it's trying to open, just in case it's trying to open a bad filename.

 

[lion10]

Your log shows that NRage is not able to open the language library, but they're showing up in the language selector. This would seem to mean those files are corrupted in the PJ64 folder, or maybe those files aren't the updated language DLL files?

Are the NRage-Language-XXXX.dll files in the "plugins" directory or the Project64.exe directory? I don't think this is the problem, but they must be in the Project64.exe directory; remove any that are in "plugins".

I've uploaded a DEBUG that should tell me specifically what file it's trying to open, just in case it's trying to open a bad filename.

Ok, sorry for the delay, I’m busy at the last time…. Nothing changed, still the same error on pj64. In contrast to this, Mupen64 and 1964 works fine. The language files are in the correct (emu) folder and these are all 100% intact. As you say, I can select them in pj64, but the language not changes….

The German translation contains a little error, see attachment for more details. I’ am also not really sure about the effect meaning of “range”. I believe in German it is translate with “Reichweite,” but this sound otherwise also uncommon…. Let’s stay by the English word “range”, at the end its ok. In contrast to French, the German language has a lot of English foreign words....

 

[rabiddeity]

Yep, it's trying to open a bad filename. Since I can't replicate the problem on my end, it may take a few tries before a fix works. Try this DEBUG next.

 

[lion10]

Yep, it's trying to open a bad filename. Since I can't replicate the problem on my end, it may take a few tries before a fix works. Try this DEBUG next.

Still the same situation, mupen64 and 1964 runs ok, project64 sucks… I’m not sure but it’s possible that I have exposed an other little problem. Every time if I press the “input settings” on 1964/mupen or the “configure controller plugin” on pj64, the “numlock” buttons on my keyboard became inactive, the numlock LED is going out. Really strange, I observed this issue some time ago, but I haven’t until now see the link to this input plugin; I believed the keyboard would be broken It’s a normal (and newer) PS/2 (not USB) type, the exact model name is Microsoft Wired 500.

 

[Kruci]

So, I tested nrage in pj64, all worked, language worked for me too(tested french and german).
But after testing become weird situation, nrage didnt loaded controls(after change - quit emu, start emu,...), but after restart PC it worked. In debug files with HEH on end, HEH due my shock
I wasnt able reproduce this bug again, maybe system bug.

For me numlock led is not going out, but once when I was quiting emu, led was not shine, and on begining was, maybe.

 

[rabiddeity]

OK lion10, let's fix the language problem first... try editing the INI file manually and set the Language= line to something that matches one of the language files you have (so if you have a file NRage-Language-1031.dll, set Language=1031). Then open up the plugin config and see if the configuration screen is in a different language. This isn't intended as a fix, just to try to figure out where the problem is.

 

[lion10]

OK lion10, let's fix the language problem first... try editing the INI file manually and set the Language= line to something that matches one of the language files you have (so if you have a file NRage-Language-1031.dll, set Language=1031). Then open up the plugin config and see if the configuration screen is in a different language. This isn't intended as a fix, just to try to figure out where the problem is.

I have tested with manual language setting (Language=1031), unfortunately with no effort. After save a fresh controller profile, the load / save function of profiles woks correct. As mentioned, except the "numlock" and "language load fault on pj64" everything works great. For me it was not possible to reproduce Kruci's errors.

 

[rabiddeity]

OK, try the manual language set with this DEBUG and see if it works...