This is how it's done, but these flags are not defined in LFS_External 1.1.0.0 so it won't work with this library.
Doesn't LsC also use LFS_External?
Heh, the most awesome Nokia ever built:-P Mine can go almost three weeks without recharging if it's left at total idle. The battery life is the only thing that keeps me from getting a device that 21st century considers a cell phone.
Okay. To set facts straight, iC is not an InSim library, but an open source cruise server application. It uses LFS_External library to talk to LFS via InSim. I cannot find any specific information about the version of LFS_External this application uses, but it looks like it's v. 1.1.0.0. This is quite outdated version which doesn't support InSim packets introduced in LFS 0.6B.
As far as I've heard the updated LFS_External is rather buggy, so the only real solution is to switch to InSim.NET. Unfortunately you'd have to rewrite a big portion of the application to do that.
As far as I've heard the updated LFS_External is rather buggy, so the only real solution is to switch to InSim.NET. Unfortunately you'd have to rewrite a big portion of the application to do that.
I can't unless you tell us which InSim library and version are you using. For instance the latest official release of LFS_External 1.1.1.4 doesn't support any of the new packets introduced in LFS 0.6B.
You have to set these as flags in IS_ISI packets. I assume you're using some library for the InSim interface, so check out to its documentation for details.
Unfortunately Windows doesn't come with a tool that would allow you to check if there are any problems with IRQ, but most BIOSes have a "Plug and Play aware OS" option. According to MS it should be set to "No", but perhaps in case of a buggy BIOS it'd be better to set it to "Yes". Another step would be a BIOS update.
It's difficult to even guess what could be wrong without any meaningful diagnostics output... which I have no idea how to get on Windows. Do you see performance problems everywhere or is it just LFS?
It's difficult to even guess what could be wrong without any meaningful diagnostics output... which I have no idea how to get on Windows. Do you see performance problems everywhere or is it just LFS?
Even if it's just a PS/2 mouse without any PS/2 keyboard connected? This looks like some sort of problem with IRQ handling.
Can you actually reproduce the problem like this?
- Shut down the computer
- Swap an USB keyboard for a PS/2 one
- Boot up, check the performance under various circumstances, particularly the CPU load
- Repeat with the USB keyboard
- Shut down the computer
- Swap an USB keyboard for a PS/2 one
- Boot up, check the performance under various circumstances, particularly the CPU load
- Repeat with the USB keyboard
The way LFS sends packets was indeed updated. There is a lot more buffering now so it's very common to get multiple packets in one shot. CInsim appears to handle it just fine though
LFS supports up to 8 InSim applications connected simultaneously, but I guess that each of them must report a different name in IS_ISI.
You could probably do a nice multimedia server with DLNA support and wireless capabilities if you have a compatible TV set. Or maybe a network router/server with shared storage, it might be particularly useful if you download a lot of torrents and stuff.
WinRT is for ARMv7 only and it's much too bloated to run on RPi's hardware. Besides a gazillion of other issues the price of the OS would exceed the price of an RPi.
WinRT is for ARMv7 only and it's much too bloated to run on RPi's hardware. Besides a gazillion of other issues the price of the OS would exceed the price of an RPi.
I might be wrong but judging by the 1.1.1.7's source it looks like DarkTimes used some reverse engineering tool to extract the source from the binary. If this is the case, it's likely that either the decompiler got it wrong somewhere or DarkTimes overlooked something in the chaotic code of some methods.
I was thinking about updating LFS_External for proper 0.6E support, but the occasional unholy mess made me change my mind. It might be a good idea to get in touch with T-RonX and ask him for the source if he still has it.
I'm confused... Bans are issued by the LFS username, not racername, so how exactly did he get you banned? Did he gain access to your account?
Latest official update by T-RonX is about 4 and a half years old so the library can't work well even with 0.6B. DarkTimes released an unofficial update to 1.1.1.7 to at least make it compatible with InSim v5 introduced in 0.6B. LFS External is a quite outdated library which doesn't handle stuff like variable sized packets; if you're working on a new .NET based project, you really should be using InSim.NET instead.
To my knowledge LFS just discards packets that would overfill the buffer (see this post) without disconnecting the guest. LFS error messages could certainly benefit from some documentation, but I think chucknorris was right on the money with his explanation. If the InSim application stops processing data from LFS, the outgoing buffer in LFS or even OS will eventually fill up. Because InSim operates over TCP, the packets can't just be dropped.
0.6E introduced a new buffering system which packs multiple packets into a single burst. This new system unraveled problems in quite a few InSim applications and libraries. You are by any chance using an InSim library which hasn't been updated to handle this properly?
0.6E introduced a new buffering system which packs multiple packets into a single burst. This new system unraveled problems in quite a few InSim applications and libraries. You are by any chance using an InSim library which hasn't been updated to handle this properly?
I'm sorry joordy, but you seem rather confused. Port forwarding has nothing to do with server's firewall settings. To set things straight:
1) Do not disable Windows firewall unless you know what and why you're doing it.
Windows firewall is a rather basic tool but it can do it's job if it's configured properly and... well, enabled. Instead of switching it off completely just make sure you allow LFS through.
2) Port forwarding is done on the gateway (which is usually your router). Incorrectly set up port forwarding cannot be compensated for by messing with your computer's settings.
1) Do not disable Windows firewall unless you know what and why you're doing it.
Windows firewall is a rather basic tool but it can do it's job if it's configured properly and... well, enabled. Instead of switching it off completely just make sure you allow LFS through.
2) Port forwarding is done on the gateway (which is usually your router). Incorrectly set up port forwarding cannot be compensated for by messing with your computer's settings.
Update to 1.99B. Although it doesn't do anything more that the old series did yet, most (if not all) possible crashes should be resolved now. It can launch LFS automatically so you don't have to click the "Launch LFS" button anymore, but be sure you have everything set up correctly before you enable autolaunch in the configuration.
Although that would be much more reliable solution than version string matching, it still has all the major disadvantages I dislike about the previous approach.
Although that would be much more reliable solution than version string matching, it still has all the major disadvantages I dislike about the previous approach.
I didn't watch the video because I'm of very strong opinion that video games do not affect human behavior in any way and I don't think I need anyone's suggestions as to how to defend that opinion.
The history of crimes - even the most violent ones - is much longer than the history of video games, action movies and whatnot. Is it so frikkin' hard to fathom that people with certain tendencies will be fond of certain kinds of video games, not the other way around? Sometimes I understand why my brother can't make it through a newspapers issue without at least two outbursts of anger
.The history of crimes - even the most violent ones - is much longer than the history of video games, action movies and whatnot. Is it so frikkin' hard to fathom that people with certain tendencies will be fond of certain kinds of video games, not the other way around? Sometimes I understand why my brother can't make it through a newspapers issue without at least two outbursts of anger
As much as I find it weird to have to pay for a text editor, I'm willing to give this one a shot - nicely found Dygear! I'm missing a pure VIM-like mode and the Clang analyzer also doesn't work for me (known issue, I just don't feel like messing with the workaround right now).
Apart from that it looks very good and I certainly have a couple of projects I can test-drive it on
Apart from that it looks very good and I certainly have a couple of projects I can test-drive it on
It most certainly was not
1.99A doesn't zeroize certain area in the memory which is why the LEDs flash until you get OutGauge data. I'll fix it in a further version.It's interesting that the mod works on Win8 but crashes LFS on Win7. I was able to reproduce this behavior, but I can't quite figure out what the problem is. Thanks for the report. Could you spend a few minutes testing another version I know that crashes on Win7? If there is a difference between Win7 and Win8, the mod has to take it in account.
System32 on x64 Windows contains 64bit libraries, 32 bit libs are in SysWOW64 (how logical is that?
) Given the size of the x86 and x64 packages it's likely that you need the x86 packages on any architecture since the mod is 32 bit; sorry I didn't notice that before.1.99A is rather broken in a somewhat peculiar way so don't get your hopes up too much
My guess would be that the crash on the first attempt left the network sockets open which is why the controlling app couldn't connect to LFS. Can you try again after a reboot please?
msvcp110.dll is a part of the VC++ redistributable package, are you sure you installed the correct version for your architecture (either x86 or x64)?
It is not as simple is it looks because even the LFS version string doesn't have a fixed position in the memory. If the OutGauge buffer becomes allocated dynamically at some point, it will make the whole thing even more obnoxious. Current approach is universal and it will work with anything as long as the OutGauge packet format remains unchanged. It will operate as seamlessly as the previous version did once it's finished.
Thank you for the feedback.
Can you reproduce the crash every time? Does it happen even when your G27 is disconnected? If you start LFS without the controlling application running, do you also get the crash? Do you have any other gaming gadgets DirectInput might be picking up?
I'll look into this but ATM I have some other business to take care of.
Using InSim or OutGauge from within the proxy DLL is rather problematic which is why I decided not to go this way. The plan is to make the controlling application launch LFS automatically, but I need to sort out all possible problems before I begin with implementing some extra functionality.
Can you reproduce the crash every time? Does it happen even when your G27 is disconnected? If you start LFS without the controlling application running, do you also get the crash? Do you have any other gaming gadgets DirectInput might be picking up?
I'll look into this but ATM I have some other business to take care of.
Using InSim or OutGauge from within the proxy DLL is rather problematic which is why I decided not to go this way. The plan is to make the controlling application launch LFS automatically, but I need to sort out all possible problems before I begin with implementing some extra functionality.
Thanks. I reuploaded the mod and now it links only to files available in the MSVS 2012 redistributable package.
V 1.99A has been released.
Please note that since I rewrote the whole helper app and substantial parts of the DLL, I consider this a testing version. Please give it a try and let me know if you come across any problems. Once I'm certain that the basic functionality is working correctly, I'll start adding some extra features and make it less of a pain in the ass to use.
- This version has been built with MSVS2012. If you get any complaints about missing DLLs, you'll probably need this.
- Debugging output to file is enabled by default. Unless you hit any trouble I suggest you disable it in the config file.
- Format of the config file has changed a bit, don't use the old config with this version.
- Make sure you've configured the mod properly and read the README before reporting any bugs, thanks.
Please note that since I rewrote the whole helper app and substantial parts of the DLL, I consider this a testing version. Please give it a try and let me know if you come across any problems. Once I'm certain that the basic functionality is working correctly, I'll start adding some extra features and make it less of a pain in the ass to use.
- This version has been built with MSVS2012. If you get any complaints about missing DLLs, you'll probably need this.
- Debugging output to file is enabled by default. Unless you hit any trouble I suggest you disable it in the config file.
- Format of the config file has changed a bit, don't use the old config with this version.
- Make sure you've configured the mod properly and read the README before reporting any bugs, thanks.
Are you sure there aren't the warnings related to WINE setup tools which are run after WINE's first installation or an update? These tools have a GUI but they are not necessary for WINE's operation.
FGED GREDG RDFGDR GSFDG