Analysis of the second strace file reveals four syscalls that take longer than 250 msecs. All of them happen around "poll([{fd=35, events=POLLIN}], 1, 0) = 0 (Timeout)". File descriptor 35 and 36 point to your "/dev/input/js0" device so there might be something going on when WINE tries to read the status of your controller, I assume it's a wheel?
It also seems that you have selected the wrong device in LFS configuration. WINE should pick your wheel up twice, once through the legacy joydev interface ("/dev/input/js0") and once through evdev ("/dev/input/eventXX"). You can try to select the other device and check if the problem goes away. Even better test would be to disconnect your wheel completely and try it without it.
It also seems that you have selected the wrong device in LFS configuration. WINE should pick your wheel up twice, once through the legacy joydev interface ("/dev/input/js0") and once through evdev ("/dev/input/eventXX"). You can try to select the other device and check if the problem goes away. Even better test would be to disconnect your wheel completely and try it without it.
If it happens only online, your system clock might be running too fast. In the other case you might wish to run "strace -tt wine LFS.exe" and check the timestamps to see if there is something specific that takes too long to finish.
Pit limiter indication should be already there.
It's quite clear that this is not a problem with LFS but with Fanatec drivers. You should take this up with them. If there is an older version of their driver available you can try to install that one. When you mess about with the drivers, always make sure that you have fully uninstalled the previous version before you try to install another one.
Let me get this straight. Seven months ago you were asking for a cruise mod (https://www.lfs.net/forum/thread/86906), therefore at least at that time you had no idea how to make one. Your grasp of programming is questionable to say the least (https://www.lfs.net/forum/post/1888838#post1888838). You also use cracked LFS (https://www.lfs.net/forum/thread/86908). Yet, here you are offering a ridiculously overpriced cruise mod with no trial version or any other proof that it actually exists. I know you're just a 16 years old kid, but is this really the best you can do?
A word of advice. If you're going to scam people, at least don't put your name (Alexandros Imeridis) which leads directly to your Facebook account into your LFS profile.
I realize I have just circuumstantial evidence here, but I hope that anybody with a brain won't fall for this. Apply yourself, friend!
A word of advice. If you're going to scam people, at least don't put your name (Alexandros Imeridis) which leads directly to your Facebook account into your LFS profile.
I realize I have just circuumstantial evidence here, but I hope that anybody with a brain won't fall for this. Apply yourself, friend!
What wheel exactly do you have? All Logitech wheels have a compatibility mode which should work with any OS. You'll be missing force feedback and separate brake and throttle pedals though. Perhaps this is a limitation of WINE on MacOS?
You might want to get ThrottleStop and check the CPU clock while you're playing. Your CPU and GPU are on the same chip and if they're both working at full power, it might easily overheat and throttle down.
Intel HD chips are actually pretty good as far as IGPs go. HD 3000 can run Left 4 Dead 2 which taxes the GPU far more than LFS ever could. Given the state of Abone's laptop by guess would be it's overheating and clocking down.
On a somewhat more generic note, I wonder if a lot of these reported FPS drops can be accounted to overheating and stuff. The new Westhill causes a far greater CPU load so maybe people with older systems and clogged up fans just see their CPU throttling down.
So do I. If he ever starts selling it I'll be the first in line to get it. Projects with this kind of sweet silliness should be cherished and treasured
This is so effin' insane. At 31:26 when he looks left to check for traffic I swear I glanced to the left at that very same moment - talk about realizm
. I didn't watch it to the end because I almost choked on tea at 32:20.
. I didn't watch it to the end because I almost choked on tea at 32:20.A switch to D3D12 or Vulkan actually could boost performance if the engine were coded properly. D3D12 and Vulkan use new approaches in the GPU API design which give programmer more direct control over the GPU. This allows for a more efficient use of GPU's resources and reduces the API overhead. AFAIK the API overhead was complained about a lot with previous D3D versions. The downside is that it requires more in-depth knowledge of how the GPU works inside if one wants to use its full potential.
On the other hand LFS probably doesn't stress the GPU enough to benefit from this.
Is it a quad core with hyperthreading enabled?
This seems to work.
#include "stdafx.h"
#include <cstdio>
#include <Windows.h>
#include <PowrProf.h>
int _tmain(int argc, _TCHAR* argv[])
{
UINT pwrSchemeIdx;
SYSTEM_POWER_STATUS pwrStatus;
SYSTEM_POWER_CAPABILITIES pwrCaps;
MACHINE_PROCESSOR_POWER_POLICY cpuPolicy;
MACHINE_PROCESSOR_POWER_POLICY fullCpuPolicy;
BOOL acConnected;
if (CanUserWritePwrScheme() == FALSE) {
fprintf(stderr, "You do not have sufficient privileges to modify power settings.\n");
goto err_out;
}
if (CallNtPowerInformation(SystemPowerCapabilities, NULL, 0, &pwrCaps, sizeof(SYSTEM_POWER_CAPABILITIES)) != 0) {
fprintf(stderr, "Cannot get system power capabilities.\n");
goto err_out;
}
if (pwrCaps.ProcessorThrottle == FALSE) {
fprintf(stderr, "Your CPU does not support dynamic throttling.\n");
goto err_out;
}
if (GetSystemPowerStatus(&pwrStatus) == FALSE) {
fprintf(stderr, "Cannot get current system power status.\n");
goto err_out;
}
switch (pwrStatus.ACLineStatus) {
case 0:
acConnected = FALSE;
break;
case 1:
acConnected = TRUE;
break;
case 255:
fprintf(stderr, "Power adapter status cannot be determined. Assuming that the adapter is connected.\n");
acConnected = TRUE;
break;
default:
fprintf(stderr, "Unhandled power adapter status, I do not know how to deal with this.\n");
goto err_out;
}
/* Get index of the currently active power scheme. We will be modifying this scheme in a moment */
if (GetActivePwrScheme(&pwrSchemeIdx) == FALSE) {
fprintf(stderr, "Cannot get current power scheme index.\n");
goto err_out;
}
if (ReadProcessorPwrScheme(pwrSchemeIdx, &cpuPolicy) == FALSE) {
fprintf(stderr, "Cannot get current power policies.\n");
goto err_out;
}
printf("System is running on %s power.\n", acConnected ? "AC" : "battery");
printf("Current CPU power policy: %u\n", acConnected ? cpuPolicy.ProcessorPolicyAc.DynamicThrottle : cpuPolicy.ProcessorPolicyDc.DynamicThrottle);
/* Enforce full CPU power at all times */
fullCpuPolicy = cpuPolicy;
fullCpuPolicy.ProcessorPolicyAc.DynamicThrottle = 0;
fullCpuPolicy.ProcessorPolicyDc.DynamicThrottle = 0;
if (WriteProcessorPwrScheme(pwrSchemeIdx, &fullCpuPolicy) == FALSE) {
fprintf(stderr, "Cannot write CPU power scheme.\n");
goto err_out;
}
if (SetActivePwrScheme(pwrSchemeIdx, NULL, NULL) == FALSE) {
fprintf(stderr, "Cannot set power scheme.\n");
goto err_out;
}
printf("Press RETURN to restore throttling settings...\n");
getchar();
if (WriteProcessorPwrScheme(pwrSchemeIdx, &cpuPolicy) == FALSE) {
fprintf(stderr, "Cannot set CPU power policy. You might want to restore the throttling settings manually.\n");
goto err_out;
}
if (SetActivePwrScheme(pwrSchemeIdx, NULL, NULL) == FALSE) {
fprintf(stderr, "Cannot power scheme, you might want to restore the throttling settings manually.\n");
goto err_out;
}
return EXIT_SUCCESS;
err_out:
fprintf(stderr, "Press RETURN to exit...\n");
getchar();
return EXIT_FAILURE;
}
There are, however, a few things that come to mind. It should be the job of the CPU governor to scale the CPU power accordingly to the load. Newer Intel CPUs in particular seem to suffer from the governor not getting it right every time. Tracking the problem down and filing a bug would be the right thing to do rather than hacking around it. Another problem with the code above is that it overwrites the current power scheme and restores it back to the original settings right before the application exits. Obviously, if the application happened to crash, you'd be stuck in "full steam" and have to change it back manually. Last thing is the MSDN documentation. Apparently there is "XP way" and "Vista+" way of adjusting power settings. Although it is not documented anywhere it looks like some of the legacy functions could behave differently on Vista and above. To make matters even more obnoxious, admin rights are required to change the power settings.
(VS 2013 redist package is required to run the attached executable.)
Invisible buildings on the new Westhill
I suppose the screenshots explain the problem:
With my absolutely standard WINE configuration I need to have both of those files in my LFS directory. As long as they are there LFS works absolutely fine. I came across a few glitches related to graphics but I suppose they are related to the reworked open configs code.
What is StrMsg? Is that a string or an array of strings? The compiler is most likely telling you exactly what's wrong, just read the error message.
It's not just lately, it's been always like this. This section of the forum has about four actual programmers; the rest is composed of people who are under the impression that programming means changing text colors and button captions in a piece of code they don't really understand.
If you can "code the rest", what problem specifically are you having with buttons?
If you can "code the rest", what problem specifically are you having with buttons?
This looks like an issue caused by WINE's incomplete D3D9 support. Put D3DX9_43.dll and D3DCompiler_43.dll (you'll have to get them from DX9 redistributable package first) into your LFS directory and you should be OK.
There is only up to 8 CompCar structs in MCI packet. If there are more than 8 cars on track, LFS sends two MCI packets to cover all cars. If the cruise mod is improperly coded, it might try to read more than 8 CompCar structs from one MCI packet when there are more than 8 cars on track. This will make it crash.
Read what Gutholz said, AFKTick doesn't count more that 60 seconds of inactivity.
"(time - sec) / 60" would work even if "time" were a float (with a small floating point error). On the other hand using "floor(time / 60.0)" might be a better thing to do such a case. Another thing is that the truncation of the decimal part happens only in some languages. If you do this in Ada for instance you will get a rounded value instead of truncated
1) Make sure you know what the value of Conn.AFKTick is, maybe it means something else that you think?
2) Better way to convert seconds to minutes and seconds
3) Create the output string like this to avoid the string concatenation mess
2) Better way to convert seconds to minutes and seconds
int time = Conn.AFKTick;
int sec = time % 60;
int min = (time - sec) / 60;
3) Create the output string like this to avoid the string concatenation mess
string result = String.Format("Idle: {0} ({1}:{2})", PlayerName, min, sec.ToString().PadLeft(2, '0'));
The InSim object doesn't appear to be reusable. I guess you're supposed to create a new instance of InSim each time you connect to LFS. This works for me:
--- Program.cs ---
-- InSimConnector.cs---
I'm not sure gow .NET manages memory in this case, in the worst case this code could be leaking the "old" InSim object.
--- Program.cs ---
using System;
namespace ISN_Reconnect
{
class MainClass
{
public static void Main (string[] args)
{
InSimConnector isc = new InSimConnector("127.0.0.1", 29999, '!');
isc.InitAndConnect();
Console.ReadLine();
isc.Close();
}
}
}
-- InSimConnector.cs---
using System;
using System.Threading;
using InSimDotNet;
using InSimDotNet.Packets;
namespace ISN_Reconnect
{
public class InSimConnector
{
private InSimSettings settings;
private InSim inSim;
public InSimConnector(string host, UInt16 port, char prefix)
{
settings = new InSimSettings {
Host = host,
Port = port,
Prefix = prefix,
Admin = String.Empty
};
}
public void Close()
{
inSim.Disconnected -= OnDisconnected;
inSim.Disconnect();
}
public void InitAndConnect()
{
inSim = new InSim();
inSim.Disconnected += OnDisconnected;
inSim.Bind<IS_MSO>(IS_MSO_Handler);
while (true) {
try {
inSim.Initialize(settings);
} catch (InSimException ex) {
Console.WriteLine("Waiting for connection..." + ex.Message);
}
if (inSim.IsConnected) {
Console.WriteLine("InSim connected");
return;
}
Thread.Sleep(2000);
}
}
private void OnDisconnected(object sender, DisconnectedEventArgs ea)
{
InitAndConnect();
}
private void IS_MSO_Handler(InSim inSim, IS_MSO mso)
{
Console.WriteLine("Got message: " + mso.Msg);
}
}
}
I'm not sure gow .NET manages memory in this case, in the worst case this code could be leaking the "old" InSim object.
Unfortunately Radeon 9250 is a R200 series chip which doesn't support Direct3D 9 so LFS 0.6G won't work on this GPU.
I'm pretty sure that the discussion above already explains what could be wrong and provides some suggestions how to fix it.
FGED GREDG RDFGDR GSFDG