truck lua object

@sodoma said in truck lua object:

WOW, Nice to see your response here, this is what I wished for, but haven't expecting it much.
I am impressed!
I will go thru it, hopefully I'll be able to manage some more accurat-ish RPMs 🙂
Thanks a LOT!

I assume the more accurate rpms could be applied to the In game rpm gauge?

I have to admit, I am kind a impressed.
Honestly, I was worried that whole thing is worse. I don't know what kind of education you have, but with presumtion that it's more likely something with programming and less with gears and engines, your solution is not bad. It is not 100% accurate, but by my opinion, it is not fundamentaly wrong.

And because you've shared what you've shared and you've also asked, I tell you what I need/wish for:
Engine, that will behave like real one (or close enough) so I will be able to really enjoy my wheel, shifter and three pedals.
And based on what I know now, I think that it is possible and even better, relatively easy, to improve this a lot, without rebuilding whole thing!

Right now I am at work, but later today and by the weekend I'll prepare specific suggestions, with pictures and solutions.
I dont't have a chance to do it right now and I don't want to mess it up in hurry, but IF I am right, it should be possible to solve it with some small addon to current status. The worst thing, that may this cause to your current solution, is rescaling Optimal AngVel for each gear in trucks' XMLs... 😞 (I have to double check this)

Also, please, bear with me, I am from that mechanical part of world and I am just barely able to read some code, not many expiriences in this, so maybe I am missing something, but this seems to be very promising!

Now I hope that you are not a rocket scientist or mechanical engineer or something, that could be very embarrassing for me... 😰

This is theoretical diagram for gearbox ratios somewhere from the internet. Y is for RPM, X is for speed. Colors are for ratios for each gear, black line is what you are driving on. In theory obviously.
And this is what I've got from game:
Light blue line suppose to be RPM. Because this is taken on flat ground on tarmac, there is no better chance (AFAIK) to achieve top speed, but that is more or less reached in the end of 2nd gear, rest of gearbox is just reducing already low "RPM"
So I've rescaled ratios and this is what I've got from that:
pretty familiar to me 🙂
Important here are dark red for speed (RPM of wheel) and light blue ("rpm of engine") rest is just supporting material from my "research".

There is still few things those I don't understand, but I think I already can name things, those are missing in game and therefore spoil immersion (based on topic of propeling) (I hope those words exist):

  • rpm-o-meter
  • engine underspin
  • engine overspin

I hope that I'll manage to post something else tommorow.

@8up-local said in truck lua object:

Mind Blown
alt text

Yea that lol this is freaking awsome and @Sodoma yes a word tachometer 👍

last edited by DrGoNzO1489

Well, I was too happy too soon probably. As far as basic idea looks feasable, I am afraid that putting whole thing back into a real life is more complicated than I originally thought. I am not saying it is impossible, but amount of effort seems to be bigger than I presumed. So sorry for that, I feel myself embarassed already...
I've done some (many) trials, refreshed some math and algebra from basic school (when somebody will ask you "what is it good for?", so for this is) slept too few and in the end, I have something, that is far from perfection, but probably best possible (AFAIK). It is based on "fake angular speed", which is based on Gear ratio, actual angular speed and some coefficients. If it is possible to feed formula with Gear ratio (optimal AngVel from XML) and actual AngVel, it should works universally.
Doing thing in Excel, it looks reasonably well. I will do some other trials and hope it will work.
Is somebody interested in formula of calculation?
If you know about some way, how to feed values into a game gauges or how to make some external for secondary display, please let me know. Real-time testing could be much more usefull...

I've got this idea very recently and it seems to be so obvious, that I am a bit worried to be considered as an I**t by telling everybody things, those everybody know already, but probably I'll can't fall asleep today without saying this on loud...
Ok, here I go, I hope this will be taken as reasonable idea, not as a teasing...
Thanks to you and @skipper_is I had this opportunity to take a peek into functionality background of my most favorite game of several last years. I am very thankful for that, as for that opportunity, as for the game itself.
Writing this, I am fully aware, that it was said (somewhere by somebody) that, there will be no major changes on engine emulation (or something around that line).
By my opinion, drivetrain is the thing that decrease fun in this game the most and for realism it is pure kill. I think that I can see the story why you (we as well) ended up with current solution, I think there are understandable reasons for that, so I don't blame you at all.
But I also think, that improving this part might be a HUGE improvement for game expirience, specifically for players with wheels and shifters, also for gamepadists and even a user of the most proven combiation, mouse and keyboard, will be pleased.
Three points of what I miss in here I've posted earlier, so I'll skip it now.
I also mentioned, that half of current "gearbox" is more or less useless (or at least I can't see any use for it), but I get back to this later probably.
Main result of solution I want to describe in here is about getting a more accurate engine into the game and as I see it, it shouldn't be impossible with reasonable amount of effort.
From technical point of view, what we have now is, based on shifted "gear", some optimal RPM of wheel with some torque. From that is calculated some minimal wheel RPM and maximal as well. Exceeding those lines makes engine lose it's power. That is not wrong at all, engine with no (or low enough) RPM stops working, on the other end there is limiter of some sort that makes exactly same thing. I am not completely sure how is torque calculated, but it doesn't seem to be related to RPM, more likely it is constant with some delay after pressing a throttle.
Difference between "gears" are just in "optimal RPM", keeping the rest same.
With this, there is last gear with fast RPM and same torque as 1st has. To reduce this (causing incredible acceleration) there are some "slowdown" coeffs, those Pavel mentioned. Honestly, I wasn't going thru this part with deep understanding so I have just rough idea how power is handled.
But finally, getting to the point: We have basically engine in each wheel. Keeping aside such things as torque from zero RPM, engine actually have quite flat curve of torque and some Optimal RPM with some min and max as well.
Therefore my proposal is: Keep everything as it is, just consider current wheel-values as engine-values and put gearbox behind it. Gearbox is pretty simple thing, despite how complicated it looks, it just multiply engine values. Or more precisely, it multiply RPM and divide torque.
Each gear has gearing ratio that (for a 1st gear for example) reduces RPM and by same value increases torque.
Higher gears do less and less and highest may go even opposite way (4th gear is usually +- 1:1 for a common car).
With this, you'll end up with low torque and therefore, because of resistance of enviroment, top speed will be limited. And by completely natural way without artificial coefficient.
Yes, with this change, XML values for torque might need some rebalancing, gearing ratio will look similarly, just with different numbers (1st gear highest). Due to this, those "speed reducing coeffs" might need reduce itself, maybe abandon entirely (I don't know if it has some other use), but I see these as a cosmetic changes, rebalancing values, not building entirely new thing from scratch.

Soo..., I've put in here a lot of text, just hope it makes sense even for somebody else, I am not that confident with my english.
As a very last thing, I want to say, that I really wish for this to happen, so if you consider this as a solution that you can follow, ask me anything. I will be happy to help with anything that I will be capable to...

One way to do it would be through an arduino,either built from the ground up or through an allready existing application who need a plugin to get live telemetry from the game.

A good start with source available on github and a large community and working great on Ets and Ats.

last edited by Raphael

@sodoma Hello again!
Thank you for the analysis!
Like I said, I'm sure there are better ways to simulate the gearbox in the game - but I've never even researched that - because the vehicle in Mudrunner is driven by the wheels (physics bodies) - not the engine! And wheels don't interact "mathematically correctly" with the ground.
So before changing the math of the gearbox, we need to change the math of the wheels - that's a planned improvement! When the vehicle starts to move fast, physics bodies of the wheels need to be replaced by the procedural wheels (their positions computed mathematically, and this allows you to compute everything else mathematically) - without player noticing of course.
Thats the easy way 🙂

The hard way is to do our own physics of the wheels instead of Havok - and this is actually planned too, because I want the wheels to be truly soft! Stay tuned!

Best regards!

Very nice to see that you are observing forum!
Also nice to know that you and rest of the gang are working on another improvement!
Thanks for your reply, I will stay tuned and play on my own meanwhile.

THX, I will check it as soon as possible!

Really interesting and i guess it explain explain why the frame of the truck doesn't twist on acceleration or while the trailer is stuck.

@Sodoma, Ah nice! You guys have taken the idea and run with it! I've been busy with teaching for the past couple of weeks, so haven't been able to look any further into this.

Still the question though, the truck object (and the wheel objects too...), what other properties do the objects have? Ideally I'd like something like - then we can have a lookup table for gear ratios.
In @Pavel 's explanation of engine mechanics, you're referring to a number of variables from the xml file, eg fGearAngVel. Is this exposed to any of the objects/classes in the lua?
The wheels object, for example, takes wheel.radius from the wheel XML, same with wheel.width.

Nice you're back! 🙂
This is a bit of problem. For those calculation I've presented, current angular speed and gear optimal angular speed are needed.
Current one is available from LUA, but the rest I've put in calculation manually based on "current gear" (LUA available) and known values from XML. For proving of working principle good enough, for actually working dial not at all...
So far I haven't found a way how to get those, but honestly, I've spent time on other things recently.
I will try soon again.

There allways the possibility to attach a debuger and find diverse value and dissect those after that,i allready started to watch for other thing but not the 2d dashboard.

Some info that may be handy

Contents of the 'truck' input to functions :

airHissInterval |  0
chassisPrevAngVel |  table: 3A4AB490
chassisPrevLinVel |  table: 3A4AB670
elapsedDropletsTime |  0
elapsedStartTime |  4.6509867571294
engineHeavyVolume |  1
engineStartDelay |  1.6499999761581
engineTension |  0.12244302619981
exhaustCoolFactor |  3.6316114464784
exhaustLargeSmokeCooldown |  0.30169040337205
exhaustSmokeFogTensionSumm |  0.19766143224991
exhaustSmokeFogTimer |  0.64636128768325
exhaustStartFactor |  2
exhaustStartTime |  0
heavy |  0
intakeSubmergedTime |  table: 0B353638
isBreakPulled |  false
isSteaming |  false
linVelPrev |  0
prevGear |  1
prevPedalAccelerate |  0
prevPedalBrake |  -0
prevSteeringAngle |  -0.070868775248528
revving |  0
soundAbruptStop |  userdata: 1DBE39A8
soundBrakesSqueal |  userdata: 1DBE4668
soundChassisStress |  userdata: 1DBE4188
soundDiffLock |  userdata: 1DBE4068
soundEngineHeavy |  userdata: 1DBE4008
soundEngineHigh |  userdata: 1DBE3948
soundEngineIdle |  userdata: 1DBE3828
soundEngineLow |  userdata: 1DBE3768
soundEngineRev |  userdata: 1DBE3EE8
soundEngineStart |  userdata: 1DBE3708
soundEngineStop |  userdata: 1DBE3F48
soundEngineTrans |  userdata: 1DBE4128
soundExhaustShot |  userdata: 1DBE3E88
soundHandbrake |  userdata: 1DBE3DC8
soundHeadLight |  userdata: 1DBE3D08
soundWaterDropping |  userdata: 1DBE4DE8
soundWaterGurgle |  userdata: 1DBE4368
soundWheelExtrude |  userdata: 1DBE43C8
soundWheelGrass |  userdata: 1DBE4D28
soundWheelMud |  userdata: 1DBE44E8
soundWheelSkid |  userdata: 1DBE4D88
soundWheelSpinning |  userdata: 1DBE4848
soundWheelSteer |  userdata: 1DBE4788
soundWheelWater |  userdata: 1DBE4C68
steamFactor |  0.049124785291675
suspStressFactors |  table: 0B353228
this |  userdata: 13861F98
trans |  0.029329785162929
transReverse |  0
turbo |  0
wasAllWheelDrive |  false
wasDifferentialLocked |  false
wasHandbrake |  false
wasHeadLight |  false
wheelsHeatFactors |  table: 0B353318
wheelsSteamFactors |  table: 0B353250
wheelsSteaming |  table: 0B3536D8

contents of the 'truckInput' input to functions :

pedalAccelerate |  0
pedalBrake |  -0
damageFactor |  0.031640626490116
torqueFactor |  0
isDifferentialLocked |  false
angVelVector |  table: 3A3CFA58
hissOrg |  table: 3A3CF9E0
gear |  1
isInWorld |  true
isAllWheelDrive |  false
isHandbrake |  false
hissScale |  0.53741586208344
linVelVector |  table: 3A3CFB98
waterColor |  table: 3A3CF990
steeringAngle |  0.082679130136967
isHeadLight |  false
isEngineIgnited |  true

These are taken from a truck in motion for an example of the data. where it says table, it is either a vector (x,y,z) a color (r,g,b,a) or wheel data table (wheel1,wheel2,....)

mostly 😛

last edited by TemplarGFX

wow awesome thank you 🙂 I m curious though did you return all this with LUA or you attached a debuger and took a look through the assembly or a bit of both.

last edited by Raphael


Its just a very simple logging function I wrote :

function doLog(logString)
  local file ="debug.txt", "a")

And then to say get the truckInput values I added this code to the processTruck function

    for key, value in pairs(truckInput) do
      doLog(tostring(key).." |  "..tostring(value))

Well that's an efficient way to get those data out thank you for sharing.

@templargfx blowing doors wide open as always!🕶


I forgot to include the contents of the Wheels input to functions to finish it off :

wetCoef |  0
contactFriction |  1
angVelDamped |  4.7226829528809
waterDepth |  0
org |  table: 38B491E0
debrisCoef |  1
radius |  0.55000001192093
suspStressFactor |  0.73803532123566
suspDir |  table: 38B49280
dustCoef |  1
mudDepth |  0.59404754638672
mudCoef |  1
width |  0.40000000596046
wheelDir |  table: 38B490A0
linVelVector |  table: 38B491B8
linVel |  1.1202852725983
isRightSided |  true
isPointInside |  false
axleDir |  table: 38B48F88
waterColor |  table: 38B49028
angVel |  6.2339134216309