Quote from PeterN :

Quote from NeverEatYellowSnow :

I'm using wine on linux and after auto-update from 0.6F to 0.6G I get this screen (see attachment). In-game graphics is looking also very weird ...

Use winetricks to install "d3dx9_43" and "d3dcompiler_43"

Thank you Peter, it is probably the d3dcompiler missing - I'm gonna try out tomorrow.

EDIT: Works like a charm! Thanks!

Last edited by NeverEatYellowSnow, Tue 30 Sep 2014, 20:59.

I'm using wine on linux and after auto-update from 0.6F to 0.6G I get this screen (see attachment). In-game graphics is looking also very weird ...

Quote from TFalke55 :

A question: If setups were removed from the mpr files (please don't blame me on exaggerating this), could it turn the cars in the replays just to floating objects? I can imagine that the setup data is in someway needed to recreate the car paths and car movements for the replay. So if that part is lost I fear it increases the number of unclear incidents in league racing. I could also imagine it could decrease the will of video makers to do their projects.

I guess there is no solution without disadvantages. And if it is really the case that you need the setup to create/recreate the detail of the cars, the problem of a hacking program would move from the mpr files to the live racing, with programs running live and fishing the setup files from the live data, that needs to be created for the racer to see what's happening around. Atleast these are the options I see, deriving them from my limited knowledge in that topic.

I believe that LFS.exe needs to have the sets of all online players because it needs to extrapolate the state of a car over a time which is determined by the player's ping time (or maybe two times the ping, because the traffic might be routed through the server). This time is somewhere in the range of 100ms-300ms assuming fair network connections. Note that this process is a prediction into the future from a given car state at some point in the past (the time where the last network packet has been sent by this player).

When we just want to watch an .mpr file, this situation is different, because the future is already stored in the .mpr file and can be used to estimate the car state between two (or also more) samples of network packages. I don't think that you will be able to notice a difference, if the sample rate of the .mpr files is high enough. 50 Hz (-> 20ms between the samples) shall be more than enough...

The drawback is development time and larger replay files.

And yes, Dave is right about the possibility to get the data from the running LFS.exe file. Preventing this would probably require a lot of effort. I suppose that there would be much less people using the "LFS.exe live extractor" than the .mpr extractor because the latter feels much more illegal than the former.

Quote from Scawen :

As some people pointed out, it can't be made impossible. Your LFS.exe must decrypt a setup and hackers can figure that out. Setups in replays are already encrypted but as LFS can read them, hackers can read them too. It would be nice to make setups impossible to read and LFS licensed content impossible to crack but unfortunately that is not possible.

IMO the best way to prevent setup stealing from replays is just not to store them in there. As I understand, the setups are needed for interpolating the vehicle's dynamic values between the samples stored in the mpr file. I remember the sample frequency being 10 Hz for multiplayer replays. Increasing this slightly to, e.g. 50 Hz, and use a linear interpolation might help there. Just my 2 cents...

Just want to mention that the antialias settings finally are working in my linux / wine setup using the nvidia driver. It seems that the dx9 change caused this. Before the patch I had to set antialias settings globally; the in-game settings had no visible effect...

Good stuff

of course dreaming is always allowed :sleep2:

Quote from dawesdust_12 :

That said, at this point LFS is basically cross platform as it is. Because the code base is fairly reserved and only uses older technologies, WINE support for LFS is unreal.

Yes I know - and I appreciate that - and Scawen's conservatism (is this english ?!?) - very much... there are really more urgent things on the LFS Todo list than a revolution of the graphics engine :-)

Hey, let's forget about that directX sh... and move to opengl! Let's build a native linux version Hope that dreaming is allowed on this forum :sleep2:

One important thing related to OS/DirectX discussion might be the ability to run LFS through linux/wine. Wine currently supports directx 9 but not directx 10 (http://wiki.winehq.org/FAQ#hea ... 640cc10b6d0c48abc741260b2)

I think that we might have to distinguish creating cars and creating tracks. I agree that creating user cars in LFS might not be the best idea, because it somehow destroys the "state-of-the-art balance of power".

A different story might be the idea to create user tracks: I can imagine that it might be possible to form interest groups which are able to create very interesting content (I am sure that many germans already thought about having the legend "Nordschleife" track in LFS ...).

I would offer to spend some of my spare-time and help with the know-how I can help with. Using laser scanner techniques as used for the Rockingham track sounds like a very reasonable approach - the problems begin probably when optimizing the model to fit to the graphics engine and when modelling the different surfaces of the track...

I could imagine that there are some more people like me willing to contribute without monetary interests, but this would require an opened framework. Another way this could be done is by contributing content through a review gate (or similar), so that the devs have the possibility to judge the quality of new content and decide about the integration or rejection of submitted new content (similar to what's been going on in the linux kernel development).

But at the current state this is just a dream what could be ...