Mamehooker WIP update 2014

[Howard_Casto]

Last tutorial is up.  I'll get the updated release ready tomorrow and officially add everything to the website. 

[baritonomarchetto]

I gave a read to the new tutorial, in particular to the "Tweak effect" part, and it's something great!! This will for sure be of incredible help for those using a FF wheel with MAME games.

I have a couple of questions regarding those effects handling:

1) is the creation of an effect with Fedit mandatory? I mean: as you know i wanna tune the FF strenght by maintaining the factory wave structure (let say to keep as much as possible the arcade feeling) with the exception of the gain. From what i read, i can create a custon wave with a determined wave amplitude via fedit, but i cannot easily modify the "factory" wave ... this would force to create a custom wave as much similar to the factory as possible via trial and error for every single game, right?

Could a twk file like

1|Gain|%s%

(i saw "gain" as a property in the TweakFiles.txt, not sure if it could be used this way; the "1" would refer to no layers being an effect not loaded/defined i suppose...)

and an output definition like

ma_steering_wheel_lamp=fft 1 0.5 0|fft 1 0.5 1

work?

2) customwheel.twk you attached with mamehooker5 is

-1|CMagnitude|%s%

what the "-1" refers to? Shouldn't it be the "layer" of customwheel effect so a positive number?

Thanks and sorry if i missed something trivial !

[Howard_Casto]

The one you posted looks like the 1axis twk file, so unless I included the wrong one.....

-1 is a special flag, it means to tweak ALL layers.  The 1axis one included is what mamehooker defaults to if it can detect a wheel (not always possible) and you try to use the regular ff advanced function. 

I'll make sure I included the correct one though. 

To answer your other question, I can't, unfortunately magically alter the rate at which the mame output is fired.  There isn't a way to change that.  That being said, I think you need to take a close look at how 90% of the racing games with a simple "rumble" motor operate.  They all use a simple offset brake, similar to a rumble motor on a gamepad... so the output isn't pulsed at all.  It's on (1) the whole time you are offroad or getting hit and off (0) the rest of the time.  The physical motor itself creates the pulsing, thus why we used a wave effect.

Long story short, there isn't a factory wave.  True force feedback wasn't invented until the mid 90's and anything resembling it wasn't really used in the arcades until we got to full-on 3d games.  Most of the time it's just a digital on/off signal.  Sometimes motion cabs gave a motor speed and direction but that's about as advanced as it ever got. 

Now if it were a different game with pulsing output, what we would do is create a constant force instead and tweak the gain or magnitude to tweak the strength of the effect... as for the timing, well we can't really alter that all that much. 

I'm not sure what that .5 is though in your example.  The second variable in the tweak function determines if mamehooker plays the effect or not.  You can't "half play" an effect.  The last variable controls the completely optional %s% value manually.  This just stores that particular value in %s% for use with the tweak file and in reality doesn't control anything.  Like I mentioned in the tutorial, you can use buffers, hardcoded output names, anything to tweak any aspect of a effect and use multiple ones at once. 

[Howard_Casto]

Ok 5.1 is ready.  It fixes that issue with turning off effect files mentioned in the first tutorial and baritonomarchetto, you'll be happy to know I've improved the functionality for generic Force-feedback Advanced commands... they should work better with gamepads now (strength has an effect on a xbox1 gamepad anyway.)

Unless there is a bug, I'll up it tonight and make the official announcement. 

MameHooker 5.1
 

[baritonomarchetto]

Tested this bad guy and i can say that, for what concerns the "classic" features, it works fine (like MH5.0 did).

[...]  baritonomarchetto, you'll be happy to know I've improved the functionality for generic Force-feedback Advanced commands... they should work better with gamepads now (strength has an effect on a xbox1 gamepad anyway.)

I really am  but unfortunately strenght has not the hoped effect in my wired Xbox360 controller. 
It works differently from MH4 anyway: With MH4 by setting a different strenght you had no differencies at all, now (MH5.1) it only rumbles with the max strenght set (10000 if i remeber correctly). If you set a lower value it doesn't rumble at all.

What am i doing wrong? What should i set?

[Howard_Casto]

Well it's a 360 controller, not a xbox controller.  So you are using xinput, not force-feedback.

[baritonomarchetto]

Actually not: i am using a 360 controller with modified drivers (not XBCE but a japanese alternative).

So the protocol in use is direct input. Not sure if the problem comes from the drivers, but rumble would not work at all if it was the case...

[Howard_Casto]

Nope not at all.  I pretty much guarantee you the problem is the drivers. 

Setting up force feedback to do *something* at the driver level is fairly simple, setting it up to properly read the variables and apply them is a bit harder.  I want to help, but an unofficial driver is going to be buggy to say the least.  Just to give you an idea the old XBCD drivers.... for the longest time only official xbox controllers would rumble... even though third party gamepads showed up exactly the same and used the exact same protocol. 

[baritonomarchetto]

Well, for sure i cannot ask to hack a good program (MH5.1) to work with my buggy drivers.

AAAAAND

i now HAVE to rollback them to test your Outrun2K6C2C work, so... 

[Howard_Casto]

I worked on various things last night when I couldn't sleep that will compliment my outrun 2006 hacks.

The display file system has gotten a bit of cleanup:

1.  Display files no longer steal focus when they load up.  This should help pc games and other emulators that minimize when something else gets focus.
2.  Display files now clean up more robustly upon exit... should prevent errors when you are loading a bunch of different display files in one session.
3.  Monitors are now properly enumerated and while the manual positioning is still available  (For spanning multiple monitors) If you define the position and size with "%#", where "#" is the number of the monitor, the display file will be auto-sized to fill it. 

Somewhat related is the fact that you can now set a value to a single character in a buffer instead of the whole thing via "%b#p#2%"  where "#" is the buffer number and "#2" is the position of the character (positive values to start from the left, negative to start from the right).  This is in case a troubleshooter 2 game or pc game sends a multi-digit value like a speedometer speed and you want to use a digital speedometer display file.  You can set each character of a 7 segment display individually that way. 

Example:  If the mph output is set to 150, set image 1 to "0"  image 2 to "5" and image 3 to "1" via setting buffer one to the whole value and then using the variables "%b1p-0%", "%b1p-1%" and "%b1p-2%" respectively. 

Expect these additions to be included in 5.2 which I'll release sometime soon.

[baritonomarchetto]

Great.  Mamehooker made my racing cab  run the extra mile, and i must thank you and your ability to think out-of-the-box. I could never even think how to have it running without your efforts. Thanks.