Could this be some sort of power saving issue? Perhaps the driver incorrectly powers the sound chip off and some action such as start of playback wakes the chip back up. The official Windows driver might be dumb enough to not know how to put the chip to sleep so it doesn't do that.
BW GP/FO8, SO Chicane rev/LX4 and SO Chicane rev/XRG have WR's set by a mouser. The are also some very solid mouse times set by pajkul and _Mateusz_ for instance, especially on FE rally cross combos. There are also many more hotlaps driven by wheelers in general which logically leads to more WR's set with a wheel.
A) I've just provided you with a list of very fast mouse times.
B) My motivation to visit LFSF does not make my opinions any less valid, nor does the time since my last race online.
C) I don't think we've ever left the topic, we simply widened it to juxtapose your claim about force view with other features of LFS that might be considered illegal tricks. D) Since when is not a discussion board a form of a chatroom?
Defined views don't mean defined ways to play LFS. Your whole argument comes down to "I don't want to drive in force view because I don't like it and I want to impose this restriction on others because I think it gives them some sort of advantage." That's a very selfish attitude IMHO...
I honestly don't know if I should laugh or feel sad for you. These are some VERY bad arguments...
Be that as it may, your assumption that the wheel will automatically make you faster than a mouse or keyboard is wrong. Let's look at some hard numbers. A racer names Ulisse drove hotlaps on KY Oval in all cars available in S2. These are his stats:
Top 10
Mouse: 9
Wheel: 11
Top 3
Mouse: 9
Wheel: 11
2nd
Mouse: 3
Wheel: 4
1st
Mouse: 5
Wheel: 6
I realize that one guy does not make any meaningful statistics, but it shows that at least SOME people can be just as fast with wheel as with mouse. This disproves your claim that wheel is inherently faster.
My Internet connection costs about 1000 CZK per month whereas even the cheapest and crappiest laptop costs about 6000 CZK. This is in direct contradiction with your claim that if one can afford broadband Internet connection one must also be able to afford a new computer. (Not to mention that my connection is a rather expensive one and that a 6k CZK laptop with an Atom CPU might not run LFS particularly well.)
There is no defined way to play LFS properly. People are free to enjoy LFS in any way the please as long as they don't break EULA.
This has been a well known trick for years and it was quite effective back in the days when LFS didn't support HVS. He doesn't have to have an ancient laptop, just one with a very poor graphics card such as some PowerVR based Intel GPUs.
This is again just a notion which you don't back up with any facts. If you look at the Hotlap charts, you'll see that there is a considerable amount of mousers in top 10 on most Car/Track combos. WR on BW GP/FO8 is held by a mouser.
The Internet is a very strange place. Normally people would get bored of arguing with someone who doesn't want to have an actual discussion and rejects everybody who doesn't share their point of view and yet, this thread has so many posts in it...
This is a very valid point. In all the years LFS has existed S.E.T.H is the only one to ever complain about force view mode - at least as far as I can remember. It's even stranger that he has no problem with external cameras and stuff which IMHO give you even better advantage due to much better spacial awareness.
No, you do not have to. It's just your twisted point of view that makes you think that. The fact that you're trying to force you opinion onto the others is also not particularly nice. LFS is a game and games are to be enjoyed. If someone enjoys playing LFS in force view mode - who are you to tell them they can't? You could use the same argument against people who drive with mouse for instance. Some hotlappers have admitted to use ridiculously low ranges on their steering wheels (like 90° or less) which is also completely unrealistic. People who play LFS on a big TV screen or a multi-monitor setup also have an advantage over those who are forced to play on a tiny laptop - should LFS compensate for that too?
There are a few ways how to do this. You can of course simulate a key press which is probably the easiest way but it has the disadvantage of screwing up things both inside and outside LFS.
Changing a byte in memory is NEVER a good idea because there is no way to synchronize the access. Your application might decide to change the value in a middle of some calculation and crash the game or make it go OOS. It'd be even more dangerous if LFS were a multithreaded application. It can do the job in some cases but as a general practice it should be a big no-no.
The most clean solution would be to make your Arduino controller a USB HID device but that itself would be a much greater task that the rest of your project. There are, however, resources on the web with some working protoypes and sample code.
Oh, and just when I thought there were no more skeletons in the closet...
Do you have any evidence to back this claim up with or is it just your biased guess based on the fact that half the guys you're racing against are faster than you? What would be the point of removing the forces view when we have fully customizable camera that can even be controlled by some external application? If this feature provided such a huge advantage, people would just create a simple hack to get it back if it was removed.
Are you looking just for a pin layout of the 9-pin connector? There are schemes for that all over the web including the color codes. Just type "g27 pedal wiring" into Google and look through the results.
It's generally not possible to read a file stream backwards, you can however store the results in a list and traverse through the list from last element to first. (It also might be a good idea to save the absolute position of the EOF and start reading from that position when you read the log file again to check if it changes. I'd have to look up how is this done in C#).
String class in C# provides a Split() method which splits a string into multiple strings separated by a given delimiter. For instance, calling Split("_") on string "Hello,_World!" will return strings "Hello," and "World!". There is also an IndexOf() method which returns the index of a given substring in a string. Calling IndexOf(",_") on the previous string will return 5.
EDIT: It is perfectly possible to read a file backwards because file is nothing but an array of bytes. Reading streams backwards is what cannot be done, because while you're reading the beginning of the stream, the end of it might not yet be available (think Youtube videos). With that in mind you could probably access the log file in a binary mode, look for EOLs and create strings from segments between two EOLs.
Serious racing sims can do just fine with one "constant force" effect. The overall force acting on the steering wheel is a sum of all forces acting on the front wheels and these forces are already known to the engine. This is what LFS does BTW.
Arcades with no actual physics engine can't do that since the game doesn't work with any usable forces. This is where all the envelopes and predefined waveforms come in handy. For instance, when a car is driving on a wooden bridge, the programmer can trigger a periodic force effect with square wave to simulate the rattling.
What's wrong with FFB on Linux? The Linux kernel provides a complete FFB API which - as far as I'm concerned - is actually easier to use than DInput because it doesn't require tons of boiler plate code. Yes, it has some limitations, but current devices most likely won't hit them. SDL2 even wraps that into a multiplatform interface that works everywhere. Linux might be lacking on the part of device specific support, but Logitech wheels (which is what most people have today) are supported reasonably well (plus there is a much better support in the pipe) and adding support for other devices will hopefully won't be that much of a problem once the updated ff-memless driver gets mainlined.
The whole idea behind SteamOS and Steambox is to create a brand new gaming platform based upon free and open technologies. I suspect that one of the main reasons (if not THE main reason) why is Valve going this way is to make their products independent on Microsoft. They'll naturally face the chicken and the egg problem (plus some devs might not be willing to move away from Windows-only development), but Valve might just have a big enough influence on the gaming market to break through this. After all the big game dev studios always go where the money is so if the Steambox sells they will target it...
The LEDs will blink once the RPM reach the value of the second parameter in the config (in your case it's 9500). If you have MS Office or LibreOffice, you can use the scaling table in the file I attached to my next post to adjust the LEDs behavior.
The second value doesn't control when the red LEDs light up but when the LEDs start blinking. Logitech API is stupid simple and doesn't offer any more precise control of the LEDs so I can't really do anything about this. Fanatec wheels are much better in this respect. Since the LEDs are (hopefully) scaled linearly, you can use the attached spreadsheet to recalculate the "first" and "redline" values to make the LEDs behave the way you like. I have no way to check if the results are correct - let me know if they aren't
The mod is kinda stuck in beta version since the über rewrite I did after the release of 0.6E. The helper app should obviously check if LFS is already running and just try to connect to InSim if it is. The original plan was to provide an InSim interface to adjust the "first" and "redline" values on the fly so that you wouldn't have to restart the mod at all. The current behavior is pretty obnoxious so I'll try to find some time to implement the check for running LFS.
LFS uses CP-1252 encoding by default, but there are special control sequences such as ^B which tell LFS that the following part of a string is in a different encoding. If you speak C#, you might want to take a look at how InSim.NET handles this (http://insimdotnet.codeplex.co ... nSimDotNet/LfsEncoding.cs).
If they really keep the Steambox and SteamOS as open as they claim it might blow a lot of fresh air into the ridiculously rigid and closed console world...
This could as well be your ISP issue. Try to disable any network filtering software that might be running on your computer (personal firewall, AV, ...). If it is possible, try to connect another PC to your network and check if the problem is present there too. If none of the above helps, contact your ISP tech support. Some ISPs try to save bandwidth so badly that they filter any "suspicious" traffic and perhaps some recent update of their filters settings accidentally cut LFS off...
I still can't decide whether the new system monitor theme looks any better than the last one, but at least I'm now a proud member of the hideous-looking conky themes makers club...
Is the laptop really dead or can you CTRL+ALT+DEL to Task Manager? If it's really dead, it's very likely a drivers issue. Does your laptop have the Optimus techniology? If that's the case might have to update Intel GPU drivers too. I don't know how is Windows Update in Win8, but is it possible that it installed an updated driver for something which causes this? You might want to check the updates history.
This is not exactly true. Thyroid problems linked to radiation have a very specific cause - Iodine 131 isotope. This isotope has a half-life of about 8 days and it does not pose a significant danger unless it is ingested. I therefore find the statement that 40 % of Japanese children exhibit thyroid problems connected to the Fukushima accident very unlikely. For comparison, US conducted 331 atmospheric nuclear tests in 50s and 60s and CDC accounts for ~11 000 deaths caused by radiogenic thyroid cancer.
LFS is IPv6 unaware at this point. On a Linux server you'll want to make sure that SYN cookies are enabled and maybe increase the backlog size a bit. Some clever iptables rules allow you to limit new connections rate from one IP which might help against less sophisticated DoS attacks. However, it all comes down to how big a gun the attacker brings...
It really doesn't matter what you use, all you need is the algorithm that checks whether a polygon contains a given point. Writing the plumbing code around it what will let you define polygons should be relatively easy...