AFAIK, most of the skin loading related stuttering is to do with LFS being largely single threaded.
This:
Light cluster from the Citroen AX, which is what the XF is mostly based on
4 years to get the answer to a question... is that a new record?
Ah, that explains a lot, thanks
DCon TEST2 seems to have got rid of all the X errors & warnings
$ wine DCon.exe
Track loaded
This works on Windows, but doesn't seem to work with WINE:
http://msdn.microsoft.com/en-g ... s686047%28v=vs.85%29.aspx
#include <iostream>
#include <windows.h>
using namespace std;
/*
defined by Wincon.h:
FOREGROUND_BLUE = 1
FOREGROUND_GREEN = 2
FOREGROUND_RED = 4
FOREGROUND_INTENSITY = 8
BACKGROUND_BLUE = 16
BACKGROUND_GREEN = 32
BACKGROUND_RED = 64
BACKGROUND_INTENSITY = 128
*/
#define BLACK 0 + 16 + 32 + 64
#define RED 4 + 8
#define GREEN 2 + 8
#define YELLOW 2 + 4 + 8
#define BLUE 1 + 8
#define MAGENTA 1 + 4 + 8
#define CYAN 1 + 2 + 8
#define WHITE 1 + 2 + 4 + 8
#define GREY 1 + 2 + 4
int main()
{
HANDLE hCons;
hCons = GetStdHandle(STD_OUTPUT_HANDLE);
SetConsoleTextAttribute(hCons,YELLOW);
cout << "Live";
SetConsoleTextAttribute(hCons,WHITE);
cout << "For";
SetConsoleTextAttribute(hCons,CYAN);
cout << "Speed" << endl;
SetConsoleTextAttribute(hCons,GREY); //this is needed or the colour won't reset after the program has terminated
}Regardless, trying to get colours to work properly in the console is probably more trouble than it's worth.
That would be a good idea I think.
It would also be nice to have an option to not show the messages as well - as TAA (kind of) said, it's not really needed when LFS is configured to start up at boot, but would be nice to have in some situations.
It is possible to have messages displayed in the top x lines of the console, while leaving the bottom line clear to type commands. It's been several years since I've done anything like that though, so I'll have to look up how. Something tells me implementation would also be different for Windows and Linux, as with practically everything else on the console, but that's probably more likely to work with WINE than colours.
Doing it like this would probably break the stdin/out functionality though.
*this is all based on TEST 1, I was writing this just as you posted the new one.
A local TIMER BOUNDED should only happen on Windows if LFS was starved of CPU for >6 seconds afaik. http://www.lfsforum.net/showthread.php?p=1743340#post1743340
As you were away from the PC at the time, it's hard to know exactly what happened.
LFS uses a timer that should never jump in time. WINE's implementation of that timer is wrong and it can jump, which is the WINE bug.
Yeah, it's a minor annoyance, no show-stopper.
Yep, it's like that for me, good spot.
I guess it's to do with the way that the messages are now displayed from the server rather than locally, so it doesn't make it into the local history buffer?
Dygear: Have you tried any other DX8 games? As DX10+ is completely separate to DX9 and below, it's possible that the Intel driver has broken something old that LFS uses.
I don't know how Intel's driver availability is, but is it possible to revert to an older driver version to see if it still crashes?
I don't know how Intel's driver availability is, but is it possible to revert to an older driver version to see if it still crashes?
Having the in-game driver do any functions other than steering never works without looking weird.
Animations for pushing buttons and changing gear can only happen after you actually do it, which IMO is much worse than not having the animations in the first place.
Animations for pushing buttons and changing gear can only happen after you actually do it, which IMO is much worse than not having the animations in the first place.
Limited range was (ie no stupidly stiff or soft etc), but there was no mention of changing the granularity.
As pärtan said, reducing precision could make it more realistic, but I don't think it would really make a significant difference.
It's also used in international motorsport (including LFS) to mean "no limit"* on the exit of pitlanes.
I've also very rarely seen it used by anyone else - if there's an actual no-entry sign, more people might think to use it.
*Which was its original meaning in the UK, before the national speed limit was introduced.
I've also very rarely seen it used by anyone else - if there's an actual no-entry sign, more people might think to use it.
*Which was its original meaning in the UK, before the national speed limit was introduced.
*sigh*
As you can see, what I said bar the last sentence is what we have been told (or basic maths), not speculation.
I could have speculated on other/specific reasons for their delay and other things, but I chose not to.
I even sat on the fence as to whether Eric has been working on other tracks or not. There haven't been any announcements or hints (other than "Westhill updates" whatever that means) so I'm not going to try to guess.
LFS ceasing to be indie would IMO be the worst thing that could happen to LFS. Sure, it would probably sell a hell of a lot more in the short term (mostly because of marketing) and while I'm sure quantity of content would increase with more people working on it, quality of the program would unlikely be any better, if not worse.
LFS exists because it's indie and is as good as it is because it's indie. Publishers have a nasty habit of rushing buggy code through, overworking employees and, especially more recently, throwing developers out to dry. Publishers are in it for the money first and the game later - indies on the whole are the opposite.
I've always wondered about that one.
It does make sense to not show a message if a player is /spec'd by an InSim program, because it's easy to automatically show a custom message.
However, if it's a manual /spec by an admin, it can be confusing as there can be no automatic message. It can also be tricky to keep track of it in replays, as InSim messages aren't recorded.
It's not a big deal, but slightly annoying sometimes.
While we're on the subject of autocross objects, it would be really useful to have a no entry sign (like the keep left/right ones). That'd make it a lot easier to navigate some of the more complicated autocross layouts, especially as chalk arrows can be hard to spot sometimes.
The VWS was originally (and still is) intended to be S1 & S2 content.
Both the VWS and S3 content (Rockingham and the Mystery Car initially) are waiting on the tyre physics for various reasons.
Making Rockingham S1/S2 would mean that the initial S3 licence would have even less content (that's assuming Eric hasn't completed any more tracks by that point, but either way would mean less S3 content). Having Rockingham at S1/S2 would be nice, but wouldn't make much business sense.
I've never tried using a prefix on a client InSim app, but I guess this is what's happening:
If the server's prefix is the same as yours, you get an MSO_PREFIX
If the server's prefix is different (or it doesn't use one) you get an MSO_USER and your prefixed message is shown to other players
If you want to send hidden messages to a client InSim, you probably should to use /O <message>, which will send an MSO_O
If the server's prefix is the same as yours, you get an MSO_PREFIX
If the server's prefix is different (or it doesn't use one) you get an MSO_USER and your prefixed message is shown to other players
If you want to send hidden messages to a client InSim, you probably should to use /O <message>, which will send an MSO_O
The automatic gearbox already knows where the optimal shift point is - as does the shift light on the cars that have it.
AFAIK, the only thing that affects the optimal shift RPM is the torque curve and ratios.
Ratios are a known quantity, as is the effect of the restrictor on the torque curve - assuming there's anything more complicated than just a constant % reduction in torque. Either way, LFS needs to know what the effect is to be able to output the torque in the physics engine.
I dunno if there's an equation to work it out or whether you have to run through each RPM value per gear, but VHPA can calculate all gears and graphs in close to realtime, so it can't be too complex.
The /wait command probably won't work:
The only thing I can think of to do this would be a client InSim app.
I hope you're not doing that to get multiple /say messages past LFS' spam restriction
The only thing I can think of to do this would be a client InSim app.
I hope you're not doing that to get multiple /say messages past LFS' spam restriction
The speed you can reach in a gear @ max RPM is pretty useless information on the whole TBH.
In most cars, if you're changing gear at the rev limiter, you're being inefficient and in the highest gear you should never reach the limiter.
What would actually be useful is optimal shift RPM and speed.
Top speed would also be nice, but would be much harder to calculate as it needs to take into account friction (which is affected by drag, tyre compound, pressure, camber, toe etc) - the VHPA needs to do a full simulation to work that out afaik.
Unfortunately, all this data takes up space so it'd probably need quite a bit of shuffling to fit it in. VHPA is a very good solution for now, even though it is a little inconvenient if all you're changing is ratios.
In most cars, if you're changing gear at the rev limiter, you're being inefficient and in the highest gear you should never reach the limiter.
What would actually be useful is optimal shift RPM and speed.
Top speed would also be nice, but would be much harder to calculate as it needs to take into account friction (which is affected by drag, tyre compound, pressure, camber, toe etc) - the VHPA needs to do a full simulation to work that out afaik.
Unfortunately, all this data takes up space so it'd probably need quite a bit of shuffling to fit it in. VHPA is a very good solution for now, even though it is a little inconvenient if all you're changing is ratios.
As Scawen said above, that shouldn't happen any more with the new patch.
Also, the ideal racing line isn't necessarily what you'd calculate mathematically - it usually is for simple corners, especially when not laterally grip limited, but more complex corners or close sequences of corners can be very different.
It often also varies depending on the car. For example, the different drive configurations (RWD/4WD/FWD) of the TBO cars mean that one corner have very different fastest lines for the different cars, even though they have similar performance.
It often also varies depending on the car. For example, the different drive configurations (RWD/4WD/FWD) of the TBO cars mean that one corner have very different fastest lines for the different cars, even though they have similar performance.
The ignition button doesn't actually turn off the car, only the engine, so there is no full off state in LFS where the entire dash would be off. All dash lights and gauges work at all times, regardless of the state of ignition/rpm/whatever.
Unfortunately, the LFSManual entry is fairly useless unless you want to use Python.
All of the information you need is in LFS/docs/InSim.txt (at the end).
The structs & enums in that document are all C/C++, so you can just copy paste them as Arduino also uses C/C++. You may need to check the types though - I don't know if the type lengths are different for the Arduino than 32/64bit PC.
All of the information you need is in LFS/docs/InSim.txt (at the end).
The structs & enums in that document are all C/C++, so you can just copy paste them as Arduino also uses C/C++. You may need to check the types though - I don't know if the type lengths are different for the Arduino than 32/64bit PC.
Turbo boost is properly simulated and reported through OutGauge, with both +ve and -ve pressure.
Oil pressure (based mostly on RPM iirc) and Engine temp are faked ingame, but not simulated. I had assumed they'd work in OutGauge as well, but they appear not to.
Oil temp isn't simulated or faked at all afaik.
If you just want to show the temp & oil pressure dials doing *something* and not really bothered what, you could use the pedal input info.
Oil pressure (based mostly on RPM iirc) and Engine temp are faked ingame, but not simulated. I had assumed they'd work in OutGauge as well, but they appear not to.
Oil temp isn't simulated or faked at all afaik.
If you just want to show the temp & oil pressure dials doing *something* and not really bothered what, you could use the pedal input info.
FGED GREDG RDFGDR GSFDG