For real? This would be hands down the most useless feature of LFS. It is still a racing simulator, not a high seat simulator, you know?
I do not believe there would be any licensing issues if any real tracks were distributed free of charge and created by hobbyist modders with no affiliation to the LFS team.
Given the current state of LFS a bit more openness towards modding could be beneficial. I am, however, not so naïve to think that people would rush back to LFS in a stampede just because of a track editor.
Given the current state of LFS a bit more openness towards modding could be beneficial. I am, however, not so naïve to think that people would rush back to LFS in a stampede just because of a track editor.
HD 7850 and the entire Southern/Sea Islands family definitely won't cut it under Linux because its Vulkan support in the drivers is experimental possibly not even enabled by default on some distros. The GTX 600 series should be OK though.
Someone with a hi-tech simracing set is probably not going to run Linux on their gaming machine in the first place.
Given the bump on GPU requirements that come with DX11 I wonder if having gone straight to Vulkan instead of DX wouldn't have been a better call. Regardless, its very nice to see LFS adopting new technologies.
As far as I remember the G920 cannot be switched to XBox mode, nor does it need to be. When the G920 powers up, it sets itself to the XBox mode by default. If it's connected to a PC, the driver then picks up the device's ID and switches it to PC mode with a magic packet.
From your post it is not entirely clear what is happening. XBox is not really good for diagnosing this though. Does the G920 show up at all if you plug it into a PC? If it's not even listed in the Device manager, you may be looking at a faulty HW. You shouldn’t be looking for the G920 in the default mode amongst HID devices because the XBox mode doesn't work as a HID device.
From your post it is not entirely clear what is happening. XBox is not really good for diagnosing this though. Does the G920 show up at all if you plug it into a PC? If it's not even listed in the Device manager, you may be looking at a faulty HW. You shouldn’t be looking for the G920 in the default mode amongst HID devices because the XBox mode doesn't work as a HID device.
It kind of looks like a Z-fighting issue. In fact, the rendering is not entirely OK even with 24-bit Z-buffer depth, you can see the poles holding the turn signs protruding through the signs in a few places. It happens even with DXVK so it's probably a glitch in the game itself. Weirdly enough, the problem doesn't go away even with 32-bit Z-buffer but actually becomes a bit worse than with 24-bit depth. FWIW I tested with POLARIS10 chip.
Just FYI: Neither of the videos play for me on an iPhone with iOS 12.1.4, regardless of the browser. I guess it is a codec issue.
I have to admit that I don't follow. At all. I went through the thread once again to check if there was some weird development since the last time I had read it, but there was not.
Yes, there were some people asking somewhat off-topic or silly questions, a few people who didn't get quite as excited about it etc. But hey, if you are looking for a fruitful discussion you have to expect that not everybody will share your points of view.
The devs have an option to just post the progress report and lock the thread immediately. If they do not wish to read what others have to say, don't have a discussion at all. Answering a few posts in a progress report thread doesn't take that kind of time to slow down the overall progress, come on. Having people point out "small things" is actually pretty damn important. When you create something complex, you tend to get lost in the big picture and miss details that may turn out to be of great importance.
And last but not least, allowing people to criticize an unfinished product is always dangerous. If you don't want to deal with that, then just don't demo unfinished stuff.
Yes, there were some people asking somewhat off-topic or silly questions, a few people who didn't get quite as excited about it etc. But hey, if you are looking for a fruitful discussion you have to expect that not everybody will share your points of view.
The devs have an option to just post the progress report and lock the thread immediately. If they do not wish to read what others have to say, don't have a discussion at all. Answering a few posts in a progress report thread doesn't take that kind of time to slow down the overall progress, come on. Having people point out "small things" is actually pretty damn important. When you create something complex, you tend to get lost in the big picture and miss details that may turn out to be of great importance.
And last but not least, allowing people to criticize an unfinished product is always dangerous. If you don't want to deal with that, then just don't demo unfinished stuff.
No, they are not. The sound is generated by a computer simulation that calculates the physical effects responsible for making the water make its distinctive sound. That is quite interesting although apparently very far from practical use at this point.
OK, my first impression was that of an overwhelming "WOW". I really wanted to jump into XRT and take it for a spin around a night South City. Unfortunately then I realized that the year is 2019 and nVidia has working consumer hardware with support for real raytracing lighting. Uhat LFS seems to have is a static lighting model with lightmaps and textures. It still looks pretty good but it is the technology of late nineties and you can tell. For instance the cockpit shot of SO looks pretty unnatural. I know that this is a WIP and things will improve until it's released but real dynamic lighting just looks better, especially when things are in motion.
Damn straight, right? It was so weird seeing all these people here with pre-2010 registration dates whom I haven't heard of in years...
Damn straight, right? It was so weird seeing all these people here with pre-2010 registration dates whom I haven't heard of in years...
Blade element theory is useful only for calculating forces acting upon a flying airfoil. Calculating tyre grip is a completely different ballgame and Scawen already has a pretty good approach to that. Also, there is this "new tyre physics" that may be released some day 
You can sell your user account to someone else if you want to quit playing.
If this laptop really has a RC350-based Radeon GPU (check with lspci) there really isn’t much you can do. These GPUs were not OpenGL 2.0 nor D3D9 compliant and that is what you need to run LFS. Since these old ATI GPUs were never supported very well you might have better luck on Windows. If the GPU really doesn’t suport D3D9, I’m afraid you’re out of luck regardless of what you try...
This reads even better when you can see the manifestation of this philosophy in LFS itself. No hasty releases, no random additions to accomodate the latest fads and no 3rd parties pushing you around and demanding stuff. Too bad that not all of us get to live their lives entirely on their own terms...
We have had bugfix versions released quickly without a test patch phase, 0.6T2 could carry such a fix...
Perhaps resetting the read only bit like this wouldn't require a whole new round of test patches?
Completely untested, used SetFileAttributes docs as reference. The "allowedBits" field is used to clear any extra bits that GetFileAttributes() may return but SetFileAttributes() cannot work with. MSDN does not seem to mention whether such bits would be ignored or cause SetFileAttributes() to fail.
DWORD allowedBits = 0x31A7;
LPSTR pszFileName = "copied_file.dat";
DWORD attrs = GetFileAttributes(pszFileName);
if (attrs & FILE_ATTRIBUTE_READONLY) {
attrs &= ~FILE_ATTRIBUTE_READONLY & allowedBits;
SetFileAttributes(pszFileName, attrs);
}
Completely untested, used SetFileAttributes docs as reference. The "allowedBits" field is used to clear any extra bits that GetFileAttributes() may return but SetFileAttributes() cannot work with. MSDN does not seem to mention whether such bits would be ignored or cause SetFileAttributes() to fail.
pthread library bundled with Event Control is outdated and unnecessary. Development toolchain that comes with CodeBlocks should include a working pthread library. Just use that one and you should be good to go.
If it is a test patch issue you should report in to the test patch thread instead of here.
Position of the steering wheel alone is not enough to get the force acting on the wheel. What kind of a wheel you have? Is it a commercial kit or something that you built yourself? In the first case there is a good chance that it comes with a DirectInput driver and it will work fine with LFS without any hassle. If you built it yourself you may need to write a force feedback-aware driver for it.
Does this work in Python?
I assume that you need to send an array of bytes down the socket and float or Python 2 string cannot be treated as such directly.
rpmBytes = "{.1f}".format(rpm).encode("latin1")
ser.write(rpmStr)
I assume that you need to send an array of bytes down the socket and float or Python 2 string cannot be treated as such directly.
Did you really have to pollute this thread that tries to rise awareness of a serious environmental issue with your weird part conspiracy part end-of-the world nonsense?
Really? And what would that be?
Which is a pretty easy policy to maintain if you have copious alternate energy sources and a relatively low electricity demands. When your only options are either to burn coal or split some uranium atoms, I'd go with the uranium every day.
Really? And what would that be?
Which is a pretty easy policy to maintain if you have copious alternate energy sources and a relatively low electricity demands. When your only options are either to burn coal or split some uranium atoms, I'd go with the uranium every day.
This parallelization done by the GPU drivers can only do so much and its efficiency depends a lot on how the rendering engine of a game works inside. In some cases it can even hurt performance. It can also only help with the rendering speed. If a game needs a lot of CPU power for something else (advanced AI, complex physics) the GPU drivers obviously cannot help with that. A proper parallelization implemented in the game itself will always be more efficient.
There are plenty of ways what LFS could do to take real advantage of multicore CPUs. Perhaps the easiest one would be to decouple physics and rendering loops and have them run on separate threads. The physics loop itself could then use one thread per car. This would theoretically scale very well with the size of the racing grid which is pretty much exactly what we need.
LFS 0.6E used Direct3D 8 for rendering, 0.6F and beyond use Direct3D 9. Increased use of multiple cores most likely comes from the graphics drivers trying to process the command stream in parallel. nVidia definitely does this with OpenGL, I imagine they have done something similar with D3D because until D3D11 there was no easy way for programmers to create multithreaded display lists. Direct3D 8 code path most likely does not make use of this behind-the-scenes parallelism because multicore CPUs were not around back in those days. When LFS moved to D3D9, it got a little bit of parallelism for free so to speak.
I understand where you are coming from but imposing this sort of global restriction is IMHO not a very good solution. If we introduce this in the Programmers' section, one might suggest that we add similar restrictions to other sections of the forum. Also, what should the driven distance be for a person to be allowed to access the Programmers' section? What would stop the crackers from running a phoney server where they could easily amass the required kms? Putting together a non-trivial InSim application is indefinitely more difficult than driving around in circles for an hour. There are a few mods available on this very forum that could even automate this to a great extent.
IMHO I think that we as a community have been doing a pretty good job at keeping the crackers away from the cake. Yeah, it is annoying to bust yet another leecher but the human common sense can tell a cracker from a fair demoer far better than a series of restrictions.
IMHO I think that we as a community have been doing a pretty good job at keeping the crackers away from the cake. Yeah, it is annoying to bust yet another leecher but the human common sense can tell a cracker from a fair demoer far better than a series of restrictions.
I don't know the code you're working with but it looks like "components" is an object of "IContainer" type. AFAIK in C# a variable that refers to an object can be either "null" (object does not exist) or not null (the variable references an object). You can do only "someObject == null" or "someObject != null", anything else does not make sense.
Crackers could just set up a VPN with LAN address range. It would raise the bar a bit until somebody wrote up a step by step tutorial how to do it, it's not that difficult. I had been using this for years back in the days to fool various LAN range restrictions. "Fixing" LFS to make life more difficult for crackers treats the symptom, not the actual disease. Every copy protection mechanism gets broken sooner or later if there is enough people who want to break it.
A LAN server lookup feature would be a nice feature to have nonetheless.
A LAN server lookup feature would be a nice feature to have nonetheless.
FGED GREDG RDFGDR GSFDG