Re: MTM2 Beta Patch 0.50 - Spreadsheet menus begone!

[Fila]

Ok, with Steering Sensitivity up to 20, wheel is much better. Even before hf3, the turning axis is detected correctly in menu and picks up slight turning on those bars, but in game it didn't behave the same in game as in the menu before you added sensitivity. I wonder though if the game is picking up / forcing my wheel as a Xinput device, hence the lack of sensitivity? When I initially tried the wheel in game I had the wheel itself in the wrong mode (Xinput) which didn't work at all (in all games). After getting it on the right mode (directinput, I guess), it worked in game, but sensitivity was bad. So, maybe I broke something for the wheel settings in the metal.ini on my first try? Anyway, sensitivity setting helps.

Since I am fixing this blind and have no idea about controller inputs, I have to play it by ear based on what the AI says, so it has questions for you.

There are two separate controls, and their symptom points at the other one.

Steering Sensitivity is a response curve (a pow() exponent). Cranking it to 20 makes the response aggressive near centre, which compensates for the real problem but leaves the whole curve non-linear.
Steering Range is the saturation point — what fraction of wheel travel counts as full lock. It defaults to 90, which reproduces the game's original hardcoded 1.11 factor. A wheel with no driver software reports its full ~900°, so full lock demands ~810° of turning. That's exactly "I have to turn 90° before I get any movement."
So worth asking them to try Steering Range 30–40 and put Sensitivity back to something moderate. That caps the rotation the way a driver panel would, and should feel natural rather than twitchy.

That also explains the menu-vs-game discrepancy they noticed: the menu's axis readout shows the raw device value, so slight turning registers there. The game applies range saturation, dead zone and the response curve on top — which is why the same small movement did nothing in a race.

On the XInput worry — the game isn't forcing it. di8SourceIsXInput() reports XInput only if the selected device actually enumerates as an XInput device. A wheel in DirectInput mode won't. They can confirm from the Controls page: XInput shows "Swap Gas/Brake Triggers"; DirectInput shows the axis dropdowns (Steering Axis, Pedal Axis, Camera Look). If they see dropdowns, they're on DirectInput.

On "did I break the INI on my first try" — plausible, and easy to check. The device choice is stored by product name in [Control] di8DeviceName plus inputDevice. Switching the wheel between XInput and DirectInput modes changes the name it reports, so a preference saved in the wrong mode can point at a device that no longer exists. Re-picking the device in the Controls page rewrites both keys; failing that, deleting di8DeviceName, inputDevice and the di8*Axis keys from [Control] in monster.ini gives a clean slate.

One thing I'd like back from them: whether Steering Range at 30–40 lets them drop Sensitivity. If yes, that's the correct fix and the sensitivity default is fine as-is. If they still need max sensitivity, the response curve itself needs looking at.

Furthermore, he has this to say to you.

To answer his actual question: no, "Modern Input" does not cover it. They're separate switches, and he needs all of:

Modern Input (input only — he has this)
Modern Force Feedback — separate toggle, defaults on
Force Feedback — the master toggle; FF Strength only appears once it's on
FF Strength > 0
Two more things worth telling him, because they'd defeat all of the above:

Rumble follows the selected device. The dispatcher picks wheel-FFB or pad-rumble from whichever controller is selected, so with his wheel selected the pads get nothing no matter what. He should pick the pad in Controls, not just plug it in.
A device change lands at the next race, not immediately — the mode is re-evaluated when effects are rebuilt.
If rumble still fails with all four on and the pad selected, the next thing I'd want is whether it's XInput or DirectInput on the Controls page (dropdowns = DI, "Swap Gas/Brake Triggers" = XInput) — a pad landing on the DI branch would explain a total silence.

[Fila]

https://www.mtm2.com/~mtmg/misc/Beta0.50hotfix5.zip
https://www.mtm2.com/~mtmg/misc/Beta0.50_manual.zip <--- for those that want the working original-ish MTM2 manual. Works on steam deck too. it's all in-game now, it won't open an outside file anymore. Just copy the Manual folder into your MTM2 directory. The game now searches for this folder first before searching for the .chm files (you can also delete those files, they had the wrong information to begin with)

Updated with the latest round of attempts at getting those gamepads to work. Basically I tried working on every note that has been mentioned since hotfix 3.

If you guys have any issues with the gamepads now, I probably need the exact name of the gamepad/wheel and how does it appear in the game (with the full name or xinput8 etc) and what are the settings for it (like what are the FF settings if your rumble is not working or what are the steering settings if your steering is not working right). Fixes have been attempted for all of them and now if things are not working out, it means it's finer details that need to be found.

[KF2416]

I noticed that the game won't get on demo mode despite demo mode is disabled, it black screens itself.

Wait, I realized I am actually confused.

Are you saying the DEMO MODE is ON (ticked) and it won't go into demo mode?

You said "it won't get on demo mode despite demo mode is disabled".... so that is confusing me, is demo mode ON or OFF ?

It's off I think.

[Shockwave_S08]

Feedback for Hotfix 5:

• Controller rumble works again!

• Regarding the deeper Monster Manual integration, some pictures in the Cool Stuff tab have a camera button in the lower-right corner, meaning they can be clicked on to view at a higher resolution. In addition, the Meet The Drivers page is supposed to link to the Driver.avi file in the game's main directory.

• In the pre-race Races menu tab, the D-Pad cannot be used to scroll right in one particular instance, from the Garage button to the very important GO button, as it winds up highlighting Sonic Trucks instead. Scrolling to the left, all the way to the Main Menu button, works as intended.

[Kmaster]

Ooof, I don't know what to tell you Kmaster, most of this stuff seems to be due to translation layers. Does vulkan work in this stack you have going on?
One of the things I want to point out, once i release Comm Patch 3, I plan on migrating the builds from an older toolset to the modern toolset. This MIGHT help with your translation layers issues or it might not. I don't want to try and do any changes based on this until I at least do that move.

Frame limiter was not live, needed a restart but I changed that now.
Not sure about getting rid of the backdrops honestly. Think I wanna first increase the limits and see how the engine handles that. If FPS holds steady then I will consider extending the terrain view further and drop the backdrops.

I've done those default changes. Though right now I'm dealing with some unintended consequences but I'll fix those :p

VMware has no vulkan support, all of these happened using directx11 translation. Still, the truck detail loss seems to happen to everybody else too.

by the way, are you migrating to a 64-bit executable at some point?

I agree with increasing draw distance first strategy.

[Ford-chan]

- Although both the Stock and Cale trucks now fully stage without problems, certain addon trucks still have this problem where they'll just be completely stationary without pulling up to stage. Slickster's Wild Thang is the only truck I've found so far with this issue. https://mtm2.com/~trucks/dl.php?dl=4433

Funny enough, the same thing happens to the player with this truck in particular should you choose to Auto-Stage, and you can't cancel it once you press the key/button command.

[OG_RuDeE]

Rumble also now works on my end, and dpad works in menus on PowerA controller. Nice work. All FF toggles were turned on while rumble was working. I did not test toggling them off, but from what I understood from the AI response you shared was that all need to be on for it to work.

Meant to say yesterday, but the lens flare got updated recently and looks great (maybe because I'm running 1440p now?)!

Wheel is another story. Lowering the steering range to 30% did not make a lower steering sensitivity feel better. Sensitivity at 20 still feels the best currently. I opened the metal.ini while the wheel was plugged in and noticed it's listed differently in the ini than in the game. So, maybe that's the issue; the change is not being written to the ini? Screenshot attached.

I noticed something new, I think since hf5, seems like the terrain shadows have broken, and it looks like each terrain grid square is being shadowed separately now. Two screenies attached.

[Fila]

Rudee, to make sure I'm attempting the right fix:
The monster.ini only gets updated on the disc when you exit the game, so that .ini screenshot, was it after? If not first start the game with the wheel plugged in, select it in the controllers and then exit the game and the .ini will update.

The game now saves profiles for multiple controllers but only if they show up with a different name, if they all use the xinput8 without having their own name, they will use the same profile so specific settings will not carry over (only what was last used by the last controller to use the profile)

So when you look in the ini, when you scroll down now there should be multiple profiles (if they save correctly) and each has a few of their own parameters underneath the name.

So here's the potential bug, the game does detect the wheel by name but it might be saving it wrongly as xinput. The easiest way to double check is to start the game, select wheel and then quit like I mentioned and see if the wheel name profile shows up. If not, for sanity check you could change the force feedback strength to a different number and see if ffstrength is set to the new number for the xinput profile, that would definitely double check it is saving under the wrong name.

This bug already happened for the steam deck being saved as a wheel by an intermediate behind the scenes step and it might be the opposite for your wheel and that intermediate step also sends the game the wrong signals and makes the input behave differently.

[OG_RuDeE]

Sorry Fila, I swear I had checked the file after trying the wheel and exiting, then I reopened and it was back to xinput with the wheel. With the game closed now, the correct name of the wheel shows up in the ini. I must have got my order of operations screwed up.

I will test if the wheel behaves any differently now.

[OG_RuDeE]

A couple data points:

(In all tests so far, I always unplug my pad before plugging in the wheel and booting the game, and vice versa.)

With sensitivity at zero and range at 50% (dead zone at 0 for all tests), the wheel does nothing until I turn it about 80 degrees, then it's fully locked by 90 degrees.

Sensitivity 0 and range 80%, no tire movement until around 90 degrees turn, and full lock around 120 degrees (wheel physically maxes out at around 135 degrees, i.e. can't turn more).

Sensitivity 0 and range 30%, wheel movement starts around 45 degrees and ends around 70 degrees.

So, in all, the range of motion getting picked up is very small.

I'm totally fine just cranking the sensitivity up and rolling with that.

Edit: I should have mentioned in my post above on the terrain shadows that I'm running dx11.
Just tried Vulkan, shadows broken there too. Also noticed with Vulkan that on Fila's Holiday that tire tracks are visible on top / in front of pyramids when they appear on the ground behind the pyramid.

Also, I mean to ask, are some of the settings in the controller menu wheel / pad only, e.g. sensitivity and range? If so, can wheel only settings be hidden when a pad is selected and vice versa, or can wheel only settings be labelled wheel so similar?

[KF2416]

Oh, not again. One of addon tracks, Dark Star was affected by unrecognized black texture bug.

[Fila]

Fascinating. After I had done the big rewrite, I specifically looked at Darkstar and it worked fine, wonder what have I done in the meantime to mess it up.

[Fila]

Rumble also now works on my end, and dpad works in menus on PowerA controller. Nice work. All FF toggles were turned on while rumble was working. I did not test toggling them off, but from what I understood from the AI response you shared was that all need to be on for it to work.

Meant to say yesterday, but the lens flare got updated recently and looks great (maybe because I'm running 1440p now?)!

Wheel is another story. Lowering the steering range to 30% did not make a lower steering sensitivity feel better. Sensitivity at 20 still feels the best currently. I opened the metal.ini while the wheel was plugged in and noticed it's listed differently in the ini than in the game. So, maybe that's the issue; the change is not being written to the ini? Screenshot attached.

I noticed something new, I think since hf5, seems like the terrain shadows have broken, and it looks like each terrain grid square is being shadowed separately now. Two screenies attached.

It's not the 1440. It's the fact that the palette has been done away and everything has been converted to 24bit. Stuff like the lense flare is an additive texture meaning it's supposed to blend in with the surroundings and at 24bit it has significant more color information to do it than when using the color palette.
Although saying that, amusingly, Vulkan and Dx9 worked perfect out of the box, Dx11 was stubborn and really wanted to show me that this is a low resolution dinosaur texture and still showed it pixelated. Had to do some smoothing (and if you look really hard with the right background behind the flare, you can see that the Dx11 is not as crisp as the vulkan one).

[Shockwave_S08]

In the external camera views, the bottom-center gear-shift indicator is extremely tiny; any way to allow it to use the fonts that the existing upper-left pitboard uses for better visibility?

[Fila]

Ooof, I don't know what to tell you Kmaster, most of this stuff seems to be due to translation layers. Does vulkan work in this stack you have going on?
One of the things I want to point out, once i release Comm Patch 3, I plan on migrating the builds from an older toolset to the modern toolset. This MIGHT help with your translation layers issues or it might not. I don't want to try and do any changes based on this until I at least do that move.

Frame limiter was not live, needed a restart but I changed that now.
Not sure about getting rid of the backdrops honestly. Think I wanna first increase the limits and see how the engine handles that. If FPS holds steady then I will consider extending the terrain view further and drop the backdrops.

I've done those default changes. Though right now I'm dealing with some unintended consequences but I'll fix those :p

VMware has no vulkan support, all of these happened using directx11 translation. Still, the truck detail loss seems to happen to everybody else too.

Only to Cale and he hasn't followed up on it to see what is going on.

[Fila]

- Although both the Stock and Cale trucks now fully stage without problems, certain addon trucks still have this problem where they'll just be completely stationary without pulling up to stage. Slickster's Wild Thang is the only truck I've found so far with this issue. https://mtm2.com/~trucks/dl.php?dl=4433

Funny enough, the same thing happens to the player with this truck in particular should you choose to Auto-Stage, and you can't cancel it once you press the key/button command.

I have a logic question here. In real drags, do they count the tip of the nose for crossing the stage lines/finish lines? Or do they count the front tires?

Edit: nevermind, found the rules. only front tires count.

[Ford-chan]

- Although both the Stock and Cale trucks now fully stage without problems, certain addon trucks still have this problem where they'll just be completely stationary without pulling up to stage. Slickster's Wild Thang is the only truck I've found so far with this issue. https://mtm2.com/~trucks/dl.php?dl=4433

Funny enough, the same thing happens to the player with this truck in particular should you choose to Auto-Stage, and you can't cancel it once you press the key/button command.

I have a logic question here. In real drags, do they count the tip of the nose for crossing the stage lines/finish lines? Or do they count the front tires?

Edit: nevermind, found the rules. only front tires count.

I take it that any truck with the nose longer than the front tires will create problems for auto staging, be it the player or the CPU?

[Fila]

Yeah the problem with wild thang is that it's nose is significantly too far ahead. For humans it is actually fine. The AI has two separate logics going on. The staging logic searches for tires only (as is the rule) but the AI driver logic stops when it detects hitting the line with any part of the body. And this is happening only after i made the fix a month ago for short trucks because the staging logic was actually looking for another part of the body, amusingly and i had it switched to look for tires (which solved the short nosed trucks).

[Kmaster]

VMware has no vulkan support, all of these happened using directx11 translation. Still, the truck detail loss seems to happen to everybody else too.

Only to Cale and he hasn't followed up on it to see what is going on.

Can confirm that I had none of the issues on my windows machine + latest 0.50 hotfix with Vulkan. I haven't check the latest hotfix on Mac, but yeah, it is not really that important since it is a very specific hw setup. Hope we can get offline rumbles soon! keep up the good work

[Fila]

How does one start the hillclimb track in mtm1? I never knew one existed.