Menu
What's new
By:
Filters

NRage Input Plugin V2.00 BETA (an overhaul)

squall_leonhart

squall_leonhart

The Great Gunblade Wielder
i had the leaked build for awhile, testing a few things that some official users might have missed,

but i have donated now and am an official user now :)

get me the stuff to test and i'll get on it :)
 
OP
R

rabiddeity

Plugin Hacker
OK, I'll have stuff for you to test on the 1.1 spec line soon.

For now, try out the new INI code, if you're daring. Be warned that old profiles and old registry stuff won't load, and there are no default keybinds yet (because I haven't gotten around to binding them yet!) Grab it at the normal DEBUG spot if you're feeling brave:

(I've pulled the DEBUG binary. It's not ready for testing yet.)

See if the INI format makes at least some sense to you. The button configs in particular are simply not hand editable, but at least they should be readable now. Modifying stuff might break things; if it does, please tell me so I can make the INI reader more resilient.
 
Last edited:
OP
R

rabiddeity

Plugin Hacker
Alright, I've ironed out a good number of bugs and the INI stuff is ready for testing. I haven't written the conversion programs yet, so your old saved button configs won't load and you'll have to assign your buttons again. But already the INI and profile code is a lot more maintainable than it was before.

http://www.randomwisdom.com/files/NRage_Debug.zip
 
Legend

Legend

New member
Hi, thanks for the update. BTW, I love ini's and I'm glad your going in this direction. I think the world would be a better place if EVERYTHING used an ini (or a config file or something), anything but the the damn registry. Anyway....a few points....

1. What's the rom ID and description thing? When a rom is running, it doesn't show anything.

2. I think the ini should be in the plugin folder along with its counterpart. It's just cleaner to keep all that stuff together and a little bit safer to tuck it away in a folder. It's also what every other plugin out there does that uses an ini (Glide64, Rice's video, etc).

3. My force feedback device reverts to "none" everytime I close PJ64 or when I boot a game. So no rumble ever. :(

Attached are 2 logs and my ini. On the first log, I basically opened dialog, changed to my controller in the rumble pak section, closed reopened (still there), restarted the emu, open dialog again to see that my device has reverted to "none". On the second log, changed and saved my rumble pak device and then started F-zero. No rumble.

4. (old issue kinda) When a game is loaded, the "Change MemPak Directory" button in the "Controller Pak" Tab has badly cut off text.
It reads ": change MemPaks while runn". I think it's supposed to say "Can't change Mempaks while running" but it looks like it's instructing users to change mempaks while the game is running. This is probably worst than having it blank. =]

That's all for now. To save me alot of reading, could you please tell me what's changed since 2.0 release-so I can pay special attention to those areas. Thanks.
 
Last edited:
OP
R

rabiddeity

Plugin Hacker
Alright, 2 votes for putting it in the plugins folder, I guess I'll switch to doing that.

Legend:
1. That's enabled in the 1.1 spec code, which I haven't gotten around to rewriting yet. If you're running PJ64 1.7 beta, and the plugin is compiled for 1.1 spec, that would ideally show what ROM you're running, so that we could start doing settings by game. But it's not written yet.
3. Yeah, I knew about that and released anyway, sorry... Been trying to fix that stupid rumble device bug for a couple revisions, and I thought I had nailed it. Guess not. I'll look at it again and get back to you in a couple days.
4. As for the "can't change mempaks" thing, that's easily fixed.

The only stuff that's changed so far is INI settings, under the hood. Oh, that and saving and loading of profiles (which is why the old profiles don't work yet.) Mostly the INI changes are to fix the registry problems the win9x crew were having, but it's generally a better way to do things.
 
OP
R

rabiddeity

Plugin Hacker
OK, first off, I've changed the NRage.ini location to your plugins folder, so before you run this version move your NRage.ini to plugins. Here are some other things I've tweaked:

Fixed a longstanding bug which caused Test Rumble to break regular rumble in game. Rumble devices are now re-initted upon closing the config dialog box.

Messed around with the Exclusive Mouse settings. Game should no longer mess with your Exclusive Mouse toggle when cancelling from the config panel. Add an ExclusiveMouse setting in the INI? [General] (just to save the last known setting).

Fixed the rumble device GUID loading-from-INI bug. Was causing rumble devices not to load properly.

Cleaned up the debug log. Should no longer show attempts at trying to load effects into GUID_NULL FF devices.

Renamed a function or two internally to make more sense. InitBasic -> InitMouse

Fixed loading of shortcut profiles. Stupid me, I forgot to change it in shortcuts as well as profiles loading.

Fixed the cut off text in MemPaks dialog area by expanding the button width and altering the text. However, this dialog still needs some work, as you shouldn't be able to even click on the delete note or format mempak while the pak is in use. NRage did a lot of intricate coding here to try to make sure you couldn't do stupid things here, and when I switched to memory mapped files I screwed some of it up. This is next on my to fix list.

One more thing, if you guys could see if you can get the plugin to muck up a mempak file by changing mempaks in the middle of emulation, that'd be helpful. I need to see whether or not it's safe to do so. Obviously don't do this with your REAL mempak files....
 
Last edited:
squall_leonhart

squall_leonhart

The Great Gunblade Wielder
changing mempaks while emulating won't be a problem, atleast its never been for me, i switch between mempaks and other paks all the time, its only if your writing to the pak at the time, that it would have errors
 
Legend

Legend

New member
Wow, much worst now. When I close the dialog box and then go back in, my settings are fine. But now whenever I boot any game or close the emu, all my buttons in "Controls" become "unassigned" and stay that way. No way to play a game now.

Here's the log. I opened emu, opened dialog box, loaded my controls, closed box, reopened to check buttons (they're fine), closed and opened a game and then closed the emu, I think.

Looking at the log, it looks like it can't find the language.dll and then resets everything to default. Hopefully that's an easy fix.

Also, on that "cutoff" text, I think a easy and simple solution is to take out the word "dir" from the button when rom is running. It should read "Cannot change while running". It's short enough to fit and plenty descriptive. Right above it says: "Current Mempak Directory" so you don't need to reference the "dir' again. And using "Cannot" just sounds more proper than "Can't". :p
 
Last edited:
OP
R

rabiddeity

Plugin Hacker
Cool, I fixed that memory pak interface thing. You should not be able to alter the contents of a memory pak while the emulator is running. If you can, we have a big problem. But you CAN still save notes to a file, for what it's worth, and I haven't disabled switching between mempaks within a directory. No telling whether it'll work, so I'll leave it to you guys.
 
squall_leonhart

squall_leonhart

The Great Gunblade Wielder
im not having that issue here

but, i did notice that it didn't reset my controller, to keyboard when it wasn't plugged in, but when i plugged it in it reset all the not defined :|
 
OP
R

rabiddeity

Plugin Hacker
Legend said:
Wow, much worst now. When I close the dialog box and then go back in, my settings are fine. But now whenever I boot any game or close the emu, all my buttons in "Controls" become "unassigned" and stay that way. No way to play a game now.

Here's the log. I opened emu, opened dialog box, loaded my controls, closed box, reopened to check buttons (they're fine), closed and opened a game and then closed the emu, I think.

Looking at the log, it looks like it can't find the language.dll and then resets everything to default. Hopefully that's an easy fix.
Click to expand...

No, if it couldn't load the INI at all you'd see the line "Couldn't open INI file for input!". Sorry, it appears the INI file isn't saving properly. I'm taking a look at it right now.

Also, on that "cutoff" text, I think a easy and simple solution is to take out the word "dir" from the button when rom is running. It should read "Cannot change while running". It's short enough to fit and plenty descriptive. Right above it says: "Current Mempak Directory" so you don't need to reference the "dir' again. And using "Cannot" just sounds more proper than "Can't". :p
Click to expand...

Well, the list of mempaks is directly below, so I didn't want to confuse anyone. It used to say "Can't change MemPaks while running!" and that doesn't seem to be the case.
 
Last edited:
OP
R

rabiddeity

Plugin Hacker
OK, I think I caught it. Needed to pass pointers and I wasn't. I don't know if this will fix it, I have to go home to test out game controllers, and then I won't be back until next Monday. Hope this fixes things... if not, post your debugs and ini files and I'll see what I can do.

Debug DLL should be timestamp 3/16/2007, 4:13PM
 
Last edited:
Legend

Legend

New member
Ok, what's going on has to do with loading CPF files. It's loading a controller file that does'nt save I guess after opening a rom or closing the emu. It just reverts to what it was before. That's why it doesn't say anything about not being able to open the ini. All of that should be in my last log. Here's my ini if you want. This happens with a brand new ini and a brand new config cpf file.
 
Legend

Legend

New member
Ok, some more info. Here's what happens. You load a cpf config file with say keyboard buttons AND controller buttons. You save and then close the emu or load a game. You check back and your keyboard and mice buttons are fine but all of the Controller set buttons became unassigned and stay that way. Checked the 4:13 build and it's still there.
 
OP
R

rabiddeity

Plugin Hacker
Legend said:
Ok, what's going on has to do with loading CPF files. It's loading a controller file that does'nt save I guess after opening a rom or closing the emu. It just reverts to what it was before. That's why it doesn't say anything about not being able to open the ini. All of that should be in my last log. Here's my ini if you want. This happens with a brand new ini and a brand new config cpf file.
Click to expand...

Is this with the 4:13PM debug that I just released? Try the following:

Does it save mouse buttons/axes?
Does it save keyboard binds?
Does it save gamepad binds?

You should be able to tell by looking at the NRage.ini file, under the [Controls] section. The file you posted doesn't have any buttons saved there, but I don't know what exact build version it was saved by (I guess I should add that as well).
 
Legend

Legend

New member
rabiddeity said:
Is this with the 4:13PM debug that I just released? Try the following:

Does it save mouse buttons/axes?
Does it save keyboard binds?
Does it save gamepad binds?

You should be able to tell by looking at the NRage.ini file, under the [Controls] section. The file you posted doesn't have any buttons saved there, but I don't know what exact build version it was saved by (I guess I should add that as well).
Click to expand...

Again, it was on 4:13 build, it saves everything except gamepad binds. Can anyone else try this out there. Load a cpf file with gamepad bindings and then close emu and reopen and check to see if there are still there?
 
You must log in or register to reply here.

Top