Round: 2
Grid: 2
Session of Incident: Race 1
Protestor's LFS Lap: 2
Timecode of Incident: MPR ~2:50.00
Your Car number: 083
Protested Car number(s): 105
Brief description of incident:
We're entering turn 5 side by side, with me on the inside and 105 attempting to overtake around the outside. 105 attempts to take a normal/tight racing line to cut the curb, ignoring the fact that my car is already on the inside. I see him there and try to move over to leave more room, but it seems that even me leaving the track completely isn't enough to avoid their car and we collide at the apex.
This results in my car spinning out, which causes some chaos to the cars behind and I fall to last place.
------
Round: 2
Grid: 2
Session of Incident: Race 2
Protestor's LFS Lap: 1
Timecode of Incident: MPR ~0:40.00
Your Car number: 083
Protested Car number(s): 112
Brief description of incident:
112 completely cuts turn 1, resulting in overspeed compared to the cars around. 112 does not slow down enough and taps the rear left of my car, causing it to become unsettled. I have to slow down briefly to regain control, but 112 has accelerated again resulting in a couple more taps and us both going off track.
112 then rejoins the track aggressively and hits the side of 056.
Grid: 2
Session of Incident: Race 1
Protestor's LFS Lap: 2
Timecode of Incident: MPR ~2:50.00
Your Car number: 083
Protested Car number(s): 105
Brief description of incident:
We're entering turn 5 side by side, with me on the inside and 105 attempting to overtake around the outside. 105 attempts to take a normal/tight racing line to cut the curb, ignoring the fact that my car is already on the inside. I see him there and try to move over to leave more room, but it seems that even me leaving the track completely isn't enough to avoid their car and we collide at the apex.
This results in my car spinning out, which causes some chaos to the cars behind and I fall to last place.
------
Round: 2
Grid: 2
Session of Incident: Race 2
Protestor's LFS Lap: 1
Timecode of Incident: MPR ~0:40.00
Your Car number: 083
Protested Car number(s): 112
Brief description of incident:
112 completely cuts turn 1, resulting in overspeed compared to the cars around. 112 does not slow down enough and taps the rear left of my car, causing it to become unsettled. I have to slow down briefly to regain control, but 112 has accelerated again resulting in a couple more taps and us both going off track.
112 then rejoins the track aggressively and hits the side of 056.
083, Chris McElroy, Degats, [TC] Racing
AFAIK, most games use shaders these days instead of traditional alpha testing - probably way more efficient and likely prettier.
Alpha testing has been deprecated in DX10+ probably for that reason.
http://msdn.microsoft.com/en-g ... c308047%28v=vs.85%29.aspx
Alpha testing has been deprecated in DX10+ probably for that reason.
http://msdn.microsoft.com/en-g ... c308047%28v=vs.85%29.aspx
083, Chris McElroy, Degats, [TC] Racing
AFAIK, the jumpyness of keyboard drivers is because of the low packet rate. LFS uses prediction to make movement seem smooth, which works pretty well for analog inputs, as it takes time for the inputs to change.
Keyboard (especially Kn) inputs tend to be much faster and at any one time don't really represent where the driver intends the car to go. By the time the next packet arrives 167 - 250ms plus network latency later, the prediction can be quite far out.
DX10 was a complete rewrite, not an upgrade, so does not include full DX9 support.
You need to run both DX9 and DX10+ on Vista and above.
Technically, with the /me command, the whole line (including the name) is the actual text/message, whereas with normal messages the name just tells others who is speaking. The "player name" doesn't really exist in the same way in /me messages - it's treated like any other word (colours removed).
I guess the "after player name" bit could be confusing, but InSim itself is behaving as expected IMO.
Fraps is notoriously delicate when it comes to games going in and out of fullscreen/changing resolution/alt-tabbing. I've heard many cases of it crashing/causing games to crash/stopping or corrupting the recording when you try it, or even when some games/engines (*cough*unity*cough*) change scenes.
It probably didn't happen in older versions of LFS because Fraps uses software capture for DX8 rather than directx hooks.
It may be possible for LFS to work around some of Fraps' failings, but I dunno if it's worth the bother - I guess Scawen can decide that one.
FWIW, OBS can handle LFS going in and out of fullscreen, changing resolutions, changing monitors or even completely closing down and starting again with no problems at all. Even when using Game Capture mode (DX hooks, not software mode).
Pretty certain the acceleration forces are along the world axis. (My old code corrects for that and the output looks perfect)
Edit:
I wrote my code over 6 years ago, so I can't remember exactly how it did things, but I did have to work out what most of the values represented the hard way.
I can glean some info from reading the code and looking at the output display, however some outputs are correct and others aren't so it's going to need a bit of testing to work out exactly what's going on.
Edit:
I wrote my code over 6 years ago, so I can't remember exactly how it did things, but I did have to work out what most of the values represented the hard way.
I can glean some info from reading the code and looking at the output display, however some outputs are correct and others aren't so it's going to need a bit of testing to work out exactly what's going on.
Last edited by Degats, .
I guess it all depends on what you're trying to achieve (accuracy vs realism vs type of driver/driving).
Peak torque/power @rpm values probably aren't actually all that useful for picking decent shift points, although using peak power probably isn't going to be too terrible for up-shifts.
Your percentage calculation seems like a nice simple way of trying to keep in the power band, but how well it would translate to decent shift points would depend on the car's specific torque curve.
Using Keling's method is delving into machine learning and could get quite complex (in both programming and processing), but would indeed represent someone getting into a new car blind so to speak.
If you want it to be like a vaguely serious racing driver, finding out more or less where the shift points are for a specific gear ratio set should be fairly normal.
You probably have two ways of working that out the *actual* ideal shift points (other than trying to use the auto box, which would only be reliable for up-shifts anyway):
1. Pre-compute the torque curves for every car (IIRC there have been a couple of pretty good attempts on the forum already) and read the ratios from the setup. This would be the cheaty way that I suppose you're trying to avoid.
2. When the AI first starts driving, attempt to calculate a rough torque curve in one gear (preferably not traction limited) based on acceleration readings. Work out rough relative ratios by comparing acceleration at the same rpm at different gears.
This would be a compromise between human style complex learning and fully cheating using external/pre-cooked resources, with the added benefit of being generic without having to pre-calculate stuff.
As I said, which method you use depends on what you're ultimately trying to achieve.
Peak torque/power @rpm values probably aren't actually all that useful for picking decent shift points, although using peak power probably isn't going to be too terrible for up-shifts.
Your percentage calculation seems like a nice simple way of trying to keep in the power band, but how well it would translate to decent shift points would depend on the car's specific torque curve.
Using Keling's method is delving into machine learning and could get quite complex (in both programming and processing), but would indeed represent someone getting into a new car blind so to speak.
If you want it to be like a vaguely serious racing driver, finding out more or less where the shift points are for a specific gear ratio set should be fairly normal.
You probably have two ways of working that out the *actual* ideal shift points (other than trying to use the auto box, which would only be reliable for up-shifts anyway):
1. Pre-compute the torque curves for every car (IIRC there have been a couple of pretty good attempts on the forum already) and read the ratios from the setup. This would be the cheaty way that I suppose you're trying to avoid.
2. When the AI first starts driving, attempt to calculate a rough torque curve in one gear (preferably not traction limited) based on acceleration readings. Work out rough relative ratios by comparing acceleration at the same rpm at different gears.
This would be a compromise between human style complex learning and fully cheating using external/pre-cooked resources, with the added benefit of being generic without having to pre-calculate stuff.
As I said, which method you use depends on what you're ultimately trying to achieve.
AFAIK, the auto gearbox mode uses the optimum shift points, that might be easier to use for measuring than AI drivers.
I guess you'd have to use the up-shift values to work out at what points a kick-down is needed, as the auto box's downshifts while decelerating are pretty shocking for actual racing (mostly because there is no one optimum down-shift point when braking - it can vary massively based on engine braking, limits of traction etc)
To reduce the advantage of knowing the optimal shift points, you could add a bit of randomness to it.
I guess you'd have to use the up-shift values to work out at what points a kick-down is needed, as the auto box's downshifts while decelerating are pretty shocking for actual racing (mostly because there is no one optimum down-shift point when braking - it can vary massively based on engine braking, limits of traction etc)
To reduce the advantage of knowing the optimal shift points, you could add a bit of randomness to it.
Regarding the Adaptive AA;
I can't reproduce the bug on my system, although mine only calls it "Adaptive Anti-Aliasing" not "Adaptive Multi-Sample Anti-Aliasing", which might have some bearing on it. It does have two quality settings though.
Radeon HD4890; Driver Package 8.97.100.7-121116a-151639C-ATI; Catalyst 13.1 (legacy, latest version for the card); D3D Version 7.12.10.0911
This may be a reason the bug hasn't been fixed. If DX10 doesn't even support the alpha test method, it may be that it is now more common (perhaps even in DX9) to do the same thing with pixel shader trickery. If that's the case, I would guess a shader method would have much better performance, considering how fast shaders are on modern GPUs.
Pure wild speculation on my part though.
I can't reproduce the bug on my system, although mine only calls it "Adaptive Anti-Aliasing" not "Adaptive Multi-Sample Anti-Aliasing", which might have some bearing on it. It does have two quality settings though.
Radeon HD4890; Driver Package 8.97.100.7-121116a-151639C-ATI; Catalyst 13.1 (legacy, latest version for the card); D3D Version 7.12.10.0911
This may be a reason the bug hasn't been fixed. If DX10 doesn't even support the alpha test method, it may be that it is now more common (perhaps even in DX9) to do the same thing with pixel shader trickery. If that's the case, I would guess a shader method would have much better performance, considering how fast shaders are on modern GPUs.
Pure wild speculation on my part though.
The InSim (CompCar/MCI) Heading is an integer range with zero looking down Y+ and 16384 looking down Y-
OutSim Heading isn't really a heading at all; it's a float representing radians left (positive value) or right (negative value) of the Y+ axis.
If you convert them both to degrees:
Between 0 and 180 degrees they're identical
InSim 181 = OutSim -179
InSim 359 = OutSim -1
If you want them both the same:
<?php
if (OutSim_deg < 0) OutSim_deg += 360
or
if (OutSim_rad < 0) OutSim_rad += 2*PI
?>
Probably because Aero requires DX9 hardware - it probably has to run DX8 stuff in a limited mode.
From my limited subjective testing so far, I seem to be able to get better in-game framerate now, while recording 1080p30 fullscreen in OBS, than I did before with no recording at all.
I haven't had any bugs/crashes as yet.
Win8.0
Radeon HD4890 (DX10.1 hardware)
I haven't seen any documentation to confirm other than the only other acceleration values mentioned in insim.txt are m/s^2 (in CarContact).
However, I also tried dividing by 9.81 and the outputs seem to match the G-Forces displayed in the in-game F9 view perfectly.
So, no documented proof, but I don't know what other unit they could possibly be.
However, I also tried dividing by 9.81 and the outputs seem to match the G-Forces displayed in the in-game F9 view perfectly.
So, no documented proof, but I don't know what other unit they could possibly be.
80, Chris McElroy, Degats, [TC] Racing
I add 10 and 11 together, because 11 includes 10 in the same way that 9 includes 8. I have a DX10.1 GPU, but I have DX11 installed, not DX10.
The difference is that 9 and 10+ are fully incompatible - 10 is unique in that it was a rewrite, rather than an upgrade (10.1, 11, 11.1, 11.2 are all upgrades). Vista/7/8 have both 9 and 10+ installed separately, but they don't have individual versions of 10, 10.1, 11 etc installed at the same time, because they are all part of the same thing.
Also, I was not suggesting that Scawen move to DX11 any time soon; I said there's no point. I just wanted the statistics to be represented properly.
Yeah, that sucks and I have no idea why they removed that feature.
However, the GPU manufacturers came to the rescue eventually - every 5000 series and later AMD GPU supports at least 2 monitors as one screen ("Eyefinity"), and nVidia began to support 3+ ("Surround") soon after.
So you can do it in W7, but you need the right hardware (the situation still sucks compared to XP, but at least it's not impossible)
That one was HP's decision, nothing to do with W7. HP do provide full, separate W7 drivers for some printers, but for many (especially simpler or older ones) HP only bother to provide simple, feature limited, often broken ones via Windows Update.
More like 4% on DX9 hardware or lower.*
Targeting DX11 (and not 9) would probably still mean the game should work on DX10 hardware, just without the DX11 pretty (or some of it running in software, I dunno how DX fallback works these days).
Either way, there's not a lot of point aiming for optional DX11 components in the near future. DX9c/Shader Model 3 would be a much bigger step than tessellation IMO, and should take a lot less effort to target. Also, you are correct in that 37% can't run the DX11 specific features anyway (but the game would still run for 90-96% if those features are optional).
*Legend:
63.45% - DX11 GPU; Win8/7/Vista
26.31% - DX10 GPU; Win8/7/Vista
6.38% - DX10/11; WinXP
1.57/.99/.28%; DX9b+9c/DX9+9a/DX<=8
If you add up the legend, you get 89.76% fully DX10/11 capable, a further 6.38% are running DX10/11 hardware on XP (which is most of the XP userbase).
That leaves <4% on DX9 or lower hardware.
Yeah, I wasn't suggesting Scawen rushed into DX11, I was just making some (hopefully useful) points if he, or anyone else, decides to do it at some point.
As far as LFS goes - it's amazing what DX9 shaders can do...
As far as LFS goes - it's amazing what DX9 shaders can do...
AFAIK (from random Internet research - I could be wrong) you can target/fall back to a reduced D3D9 feature set in D3D11 for hardware compatibility (albeit limited - shader model 2? probably targeting the original D3D9 rather than 9c which had newer shaders).
However, I believe that's still actually running DX11 software and you'll have the OS/driver requirements/restrictions associated with it - ie still no XP.
AFAIK to run on XP, the program itself needs to link to D3D9 instead (D3D11 can't fall back to anything if D3D11 can't even run) and only link to D3D11 if it's present for the shiny new features.
From what I've read, you only need link (at runtime) to whichever version; there's no need to have two separate compiles.
As Becky Rose said, if you design for D3D9 by default and only in D3D11 for specific features to give an (optional) extra level of pretty, it should be much more straightforward to maintain compatibility.
However, I believe that's still actually running DX11 software and you'll have the OS/driver requirements/restrictions associated with it - ie still no XP.
AFAIK to run on XP, the program itself needs to link to D3D9 instead (D3D11 can't fall back to anything if D3D11 can't even run) and only link to D3D11 if it's present for the shiny new features.
From what I've read, you only need link (at runtime) to whichever version; there's no need to have two separate compiles.
As Becky Rose said, if you design for D3D9 by default and only in D3D11 for specific features to give an (optional) extra level of pretty, it should be much more straightforward to maintain compatibility.
80, Chris McElroy, Degats, [TC] Racing
Last edited by Degats, .
The latest development version is the 'HD' Rift, with a much more useful resolution (probably 1080p).
80, Chris McElroy, Degats, [TC] Racing
FGED GREDG RDFGDR GSFDG