Well the formula is relatively complicated I would suggest you try writing out the value returned by the function on a track and testing it against the default meter but in my experience the default meter only displays values between 0-1 and it clamps others, but I did not test this extensively I might be wrong.
But here is a google sheet exemplifying the graph for the IshimaTurbo I enabled editing of the turbo params so you can try out other values.
Slrr_RPMvsTurbo

Whatever it returns (except the -99999 cases) is I'm fairly sure the same value the game uses.

I have a question is possible to add a 7th gear to SLRR?

Yes but the engine doesnt fully support it. I did an 8 gear shifter but there's something that fucks up so once you reach the 8th it still allows to shift forward, as if there were 9, but instead of getting a 9th gear it goes back to neutral and restarts the cycle.

If you reach the 8th gear and come back, it will also allow using the reversing.

If you reach the neutral the way i said above(after the 8th gear) and then shift down, it will still allow to use the reversing.

Probably he can do something to fix that though.

Let me search and link the files.

Added 10 minutes later:



Added 22 seconds later:

# ALAN : Iirc someone made it to use up to 10th

cough

always having the problem as above

Ah that really is not worth it...
Of corse it's plausible but there is no graphic in the font for the gears for a 7th (or up) and as you already found out the engine considers the 7th to be the reverse and things get messy if you try to play with that this is very unintended by the game designers, for a manual shift alright but to make the AIs aswell the automatic shift control able to use it, way too much work introducing potential bugs, I also dont really see the reward to risk introducing even more instability in the game.

But from the players perspective: I think the "current" ratio and the "current" gear number is directly editable with the chassis functions I introduced so for a custom GUI (which must be made for this scenario anyway as the original OSD doesn't even define a texture for the 7th gear) and a custom transmission there is no limit on the number of gears; you can set it to 2nd and let the automatic or manual control shift the gears up or down force it back to 2nd but change the ratio and the custom GUI to display the correct gear for the given ratio.
(you can even make a "continuous" transmission changing the ratio every frame for maximum torque (I hope I used the correct notions))

I dont know how slrr is inferior in controller support as I dont have a controller and I dont generally play racing games so I wouldn't know when the control feels right. I heard there is someone who added xinput for win10 maybe you are looking for that (LINK) but as I said never tested this.
Also there are numerous settings in the advanced control settings with those you ought to be able to customize your experience to your liking.

But if there is something specific that is not already in the game like a factor to modify how fast the given pedals are pressed I can look into it (though I think these particular factors are already in)

The tuning menu is built in the Mechanic.java in the

public void handleEvent( GameRef obj_ref, int event, String param )

function, you are looking for the line (in the stock Mechanic.java)

Dialog dlg = new Dialog( player.controller, Dialog.DF_FREEZE|Dialog.DF_MODAL|Dialog.DF_DEFAULTBG|Dialog.DF_WIDE, "TUNE PART", "OK;Cancel" );

Remove the DF_FREEZE flag from the flags.

In the last exhaustive bits download all cars objects just seem to bounce when there is collision is there a way to fix this and change it to default?

Thanks. I never noticed the second tab in the editor

If someone downloaded the patch in the afternoon please download it again I failed to include a crucial file in the patch, downloading it again will fix the issue.
Thanks for adnan54 for pointing the error out

The first launch can take some time because of the amount of files the game has to manage if you are not running it from an SSD wait at least 2 minutes.
If windows bothers you with a dialog that it is not responding click the "wait for the application to respond" (the last) option it eventually will.

If however it is the more simple stopped working dialog and you don't have the option to wait for the program to respond first thing first check the error.log maybe there is something there, secondly try and rename the d3d9.dll to something else (NOT_d3d9.dll for example)and hence disabling reshade because it can act up, later if you manage to get in the game once, you can enable it again for the next launch.

Also if you have reshade enabled don't try and force anything on the game form your graphics driver (nvidia control panel or equivalent) reshade will try and disable anything you try to add to it but it can fail and it's behaviour becomes undefined.

Also if you havent yet install the latest update: "Ever refreshing patchlink" for SlrrExhaustive

That's amazing, did you finally figure out how to use scaleMesh?

Well that's pretty amazing, i'm already thinking about how to fit this into rims/tyres scripts so that they become kind of like need for speed underground

Indeed!

Lagano:

---

[..]would be better with a slider though

Yeah I hear you, I updated the thing to work with a slider instead.

On the scaleable wheels though; only parts with a mesh defined in the cfg can be scaled this way, sadly wheels and tyres are traditionally missing the mesh line form the cfg (the mufflers do aswell) for the tyres this line can't even really be included as the mesh can change depending on the dimensions of the rim you are trying to attach it to, as far as I can tell this works something like the paintable parts as in the game registers the given texture (defined with the texture line in the cfg) as a dynamic property of the RenderRef but if it's missing you can't really do anything about it, it is the same with the mesh line if a part is missing the mesh line you cant force a mesh with the setMesh() either (the main problem with the code I posted above is that if there is no mesh line in the cfg the getMesh() returns 0x0000, if one tries to call setMesh() on such a part the getMesh() will still always return 0)
This leaves one not so appealing option one could look up the mesh of a given RenderRef and directly scale that in the games resource engine but this will result in every mesh of this type to be scaled (two cars with the same rims => all 8 rims will be scaled).

I was kind of intrigued so I went ahead and made a DynamicRim whose size (width and radius) and appearance can be "tuned" furthermore I added a DynamicTyre to this DynamicRim with "tune-able" mesh, size and other params (the wheel params that can passed to the SetupTyre(..) function) the result is interesting , I also maintained the paintability of the rims with a trick (I made a RenderRef with a texture array consisting of 10 of the same texture which is handily the paintable one, this ofcourse makes all textures the rim uses paintable even the reflection but reshade overwrites that so no harm done (well at least when reshade is active))
(For this(the dynamic mesh selection) to work I had to make a long list of valid mesh TypeIDs and renderRef TypeIDs for tyres and rims so the solution is not hmm portable but it can be done (and if we'll find a way to get the MeshID of a given renderRef in script it can be made portable aswell, nevertheless the method can easily be used for a single modded rim)

I know it looks silly but at least now we CAN make it look dumb without much hassle.


I added this to the "Ever refreshing patchlink" for SlrrExhaustive

LMAO MAN, i'm fucking amazed by the shit you manage to come up with, especially from the amount of time you need to make these things come true... holy fuck

that unfortunately requires overwriting the way the game renders objects and that is harder than it actually should be because the game uses the (archaic even considering the original release date) fixed function pipeline of d3d9, its not impossible but quite tedious, however if and when that happens it gives way to even more advanced effects (fixing the reflections for example(as the normal the reflection uses is per-vertex currently)), furthermore the Part native class (and its dependencies) would need to be properly reversed for the ability to give unique properties to objects(instances) (unlike the global overwrite thats used now(for the reflections))

Sorry to bother you, but do you happen to know anything about how the aero deflectors in the CFGs work?

I came around and replaced the fixed function pipeline implementation of the reflecting surfaces to a programmable one, this is good because it opens up the game for advanced lighting models, though I could not manage to get per-object data to the d3d9.dll from the javascript engine; the rendering and the virtual machine is very well separated, this is bad however because eventhough we now can manipulate the appearance of parts to quite a great extent this feature can not be controlled from the script engine and that makes the whole thing again global (each reflecting surface will have the same properties (at least the same overwrites)).
Another bad thing about this is that because Slrr uses directx in an extremely uninformed manner (a frame in Valocity can easily exceed 60000 d3d calls...) FPS will suffer a bit (it's quite playable in my opinion, and the additional visual fidelity is well worth the 2-7 FPS deficit) and there isn't really anything to be done about it (or at least not with my knowledge)
But now there is a reshadeFx\NativeHLSL\uPS_VS.hlsl file which can be used(and modified) to render the ingame reflecting surfaces (if someone is good with this kind of stuff, I do know that the hunt for the perfect car-paint shader is still interesting to some)

The good part is properly aligned relfections (from 2:30 in the video), a nicer specular reflection with "flakes", proper spot lights, per-pixel lighting, bump-mapping I must emphasise that it is bump-mapping not normal mapping (there is no available tangent or bitangent from the model format and the game is preforming slow enough as it is(without generating these at runtime) further more I'm pretty sure my bump map implementation is incorrect but I think there is another matrix needing inverting for it to be pristine but that is time consuming so I opted out)
mainly the ability to modify this aspect of the game is the plus side





I have updated the "Ever refreshing patchlink" for SlrrExhaustive and the SlrrExhaustiveBits download aswell.

(I must admit that my solution feels quite suboptimal but I honestly can't see a meaningful way to improve it this is not my expertise though and I'm fairly certain that if someone who actually knows shader programming takes a look at the .hlsl will faint let's hope after waking up he/she will optimize the code a bit and share the results )

As a last note this should be regarded as a not fully tested version there may be some obscure conditions I haven't ran into yet.

Added 5 minutes later:

Of course the current implementation is highly customisable as it has been before, there are numerous new properties in the ReflectionSettings.fx in the Reshade menu (for once the name checks out)

Mitch just likes to chill sometimes. That happens to me often but i guess it's random.

Those reflections look amazing!! Yeah i'm sure that FPS drops a bit but it should be perfect for taking photos.