The online racing simulator
Need help with some structures [reading LFS RAM - highly questionable]
I was poking around the Live for Speed code inside ghidra and I found a feww structures.
One is a SoudLevels structure and another one is the KeyboardMapping structure.

What I need helpo with is:

struct SoundLevelSettings {
float m_InterfaceBoost;
float m_MusicBoost;
//These two unk floats. They dont seem to be exposed to the end user
float unk0;
float unk1;
float m_WindVolume;
float m_SkidVolume;
float m_EchoVolume;
float m_CarVolume;
};


struct KeyboardControllsSetting {
struct Controll {
char Buttion;
//And I need help with these 3 bytes here. They dont seem to be changing while debugging
char unk0[3];//Might be some flags
};

Controll m_Accelerate;
Controll m_Brake;
Controll m_ShiftUp;
Controll m_ShiftDown;
Controll m_Clutch;
Controll m_Handbrake;
Controll m_LeftView;
Controll m_RightView;
Controll m_RearView;
Controll m_Horn;
Controll m_Flash;
Controll m_ResetCar;
Controll m_SpeedLimiter;
Controll m_TractionControll;
Controll m_Ignition;
Controll m_ZoomIn;
Controll m_ZoomOut;
};

Any help is appretiated. Thank you in advance.
#2 - gu3st
I don't think anyone is going to help you reverse engineer LFS on the official forums.
What exactly are you trying to do? It for sure smells like a no no.
Quote from rane_nbg :What exactly are you trying to do? It for sure smells like a no no.

Im developing a project called LFSEx(tended).
Amongst a plethora of features one of them is lua scripting simmilar to lfs scripts.
So setting the controlls should be a feature.

Another feature in development is more detailed sounds. Ambient sounds, Creaking, tyre thumps ober bumpy surfaces, more detailed echo and wind sounds.

As I dont wish to be destructive and change functionallity just extend it I was requesting help.
I see. Even though this is for the benefit of everyone and I know that you have only the best intentions, I still think that you should drop it. Many times in the past skillful people offered lfs dev team some programing help and they kept refusing it. This is how they chose to go with this and there's nothing we can do about it.

Even if you do sucseed, how do you plan to keep your app up to date with every single new patch? Lfs lazy got killed exactly because of it. It's simply not a viable solution in the long run, even if lfs devs may be ok with it.
We are trying to move away from people directly accessing LFS memory.

The proper way to proceed is to request access through InSim, maybe in the programmer section or improvement suggestions. Sometimes a new packet can be added or changes can be made. We can discuss these things in public and different people can add to the discussion leading to well planned updates. It's not a really quick process but avoids a lot of problems.
Quote :Even if you do sucseed, how do you plan to keep your app up to date with every single new patch? Lfs lazy got killed exactly because of it. It's simply not a viable solution in the long run, even if lfs devs may be ok with it.

I already tested it out starting from version 0.7A up to D and Ghidra more or less finds things automatically.
Structures are more or less always the same and the differing ones could be updated.

Quote :Even though this is for the benefit of everyone and I know that you have only the best intentions, I still think that you should drop it.

Ive invested way too much time into this by now, no point in stopping.

Quote :We are trying to move away from people directly accessing LFS memory.

The proper way to proceed is to request access through InSim, maybe in the programmer section or improvement suggestions. Sometimes a new packet can be added or changes can be made. We can discuss these things in public and different people can add to the discussion leading to well planned updates. It's not a really quick process but avoids a lot of problems.

I know Scawen but some things cannot and would be ill advised to implement inside InSim.
Changing the controlls via InSim packets could introduce a vector for exploits and remote code execution.
Again to reitterate I dont want to change LFS behaviour just extend it. You cannot create an anti-cheat using InSim nor could you perform a raycast/pathtrace/hittest to create a AI driver. Soo many options could be opened. Not trying to sell you on Reversing just that there are limitations to InSim.
Quote from rane_nbg :Lfs lazy got killed exactly because of it. It's simply not a viable solution in the long run, even if lfs devs may be ok with it.

Daniel stopped updating LFSLazy because of the so many patches and not a stable version, its not viable to him to keep updating it every single time, so other people did it and keep doing it, but not here. I know there is already an update to LFSLazy that works with the latest patch, but there are some bugs when it comes to driving mods.

Real shit is LFSLazy and others did more than what devs did in some aspects, thinking more about the trully useful stuff that is needed in the game.
Pedro, others did a tiny tiny amount compared to what lfs devs did with entire lfs code. If it were not for lfs devs, we wouo
ld not be having this disscusion. My oppinion is that we need to request access for more stuff through inSim, then making all kinds of apps would be possible.

FGED GREDG RDFGDR GSFDG