For me, Profiler 4.40 + the centering fix has worked the best for Momo Racing. Profiler 4.60 is supposed to have the centering fix integrated to it, but I got centering problems when using 4.60 profiler, and the centering fix didn't help, so I went back to 4.40 + centering fix and it has worked fine ever since... 
Good. Why couldn't you have stopped there then instead of having to resort to name calling?
Yup, but talking like you think you know the facts when you dont is worse
What useless errorenous info have I spread? And it was you who started talking about nvidia and ati.
Actually I think its more like A) Yes, quite often and B) no, almost never.
Do you mean the target of triplehead2go? I thought it is targeted to people who already have fast cards from other manufacturers and want to have triple monitor gaming. That is people who already have these cards that output no-so-good analog signal, there is no way triplehead2go could (truly) improve the signal, only make it worse. The question is how much. Because of that it would also make sense to make a version with DVI input and high quality analog outputs, so 'gaming card' owners would get high quality analog vga video out of it at the same time too.
I haven't said such things.
Reference cards are designed by nvidia/ati, yes, but its up to the card manufacturers to choose a) if they use the reference design at all and b) if they use the same components in it.
My point was that working with analog signal is not a good thing, and is going to affect the image quality. No need to try to start a debate about it, wait until the device is available and we'll see.
Neither nvidia or ati make the cards themselves so it is propably mostly up to the card manufacturers. Though there propably are some minimum requirements on the quality of the components on the card, at least they used to vary from cheap junk to ok in older cards but all seem ok now. And for the card manufacturers it propably isn't a question of being able to do it, but if it is worth it to put in expensive components that will be useful for only a minority of their user base (for "average" consumer cards).
I really dont think this is possible. If you have ever used those switchboxes that allow you to switch between multiple VGA inputs for one monitor, you'll know that having anything in between the monitor and the video card can have a massive (negative) impact on the image quality. The VGA signal is very 'vulnerable', even a bit of extra solder, or one extra component somewhere along the path of the VGA signal can cause the quality to get noticeably worse. In fact I'd guess that this is the reasons why it is limited to such low refresh rates and resolutions, at higher ones the image quality would suffer too much.
Also for desktop use it would be nice if it would have an integrated 'switchbox', so it would have three inputs (DVI!) and three outputs. In normal desktop resolutions each monitor would display their own input signal, but when changing to a surround resolution on the middle monitor the side monitors would automatically switch to display the side views.
The 75Hz limitation seems a bit worrying. I find 75Hz to be barely bearable when using a single monitor, but with multiple monitors at least 80-85Hz is a must for the side monitors since the eye has higher 'refresh rate' at the sides which causes flickering when not looking directly at the monitor. It would not be a problem with LCD screen of course, but then with those the analog input and output signals are not a very good choice.
And even with CRT monitors it would be better if the input would use a digital signal as converting the analog VGA signal back to digital, and then back to analog again is surely going to affect the image quality.
I also wonder if it is possible to disable the triple monitor thing from it and just pass through the vga signal to one monitor. This would allow using the desktop with a higher resolution on one monitor, and play games with three monitors without too much hassle...
edit: After re-reading those specs, it seems this is possible in "VESA-compatible single screen modes", I wonder if my 1456x1092@84Hz is VESA-compatible :P
And even with CRT monitors it would be better if the input would use a digital signal as converting the analog VGA signal back to digital, and then back to analog again is surely going to affect the image quality.
I also wonder if it is possible to disable the triple monitor thing from it and just pass through the vga signal to one monitor. This would allow using the desktop with a higher resolution on one monitor, and play games with three monitors without too much hassle...
edit: After re-reading those specs, it seems this is possible in "VESA-compatible single screen modes", I wonder if my 1456x1092@84Hz is VESA-compatible :P
Last edited by Kegetys, .
At least with nvidia cards you can use whatever resolutions you want. Though I have never tried that large ones myself, I would guess it is only limited by the RAMDAC and video memory.
I'd also like to see the date of the last modification made to the set to be visible somewhere, and maybe the setup could also automatically store the amount of laps and the best laptimes I have driven with it...
This is exactly why rFactor is a poor example to look for when speculating what would happen to LFS if modding would be 'allowed' - It seems that most rFactor mods suck, and, in my opinion the whole game is a mess now because:
- There is almost no standards to which a good mod could be compared, only the default cars and tracks that come with rFactor, and as you said they are not of very high quality. This makes people release all kinds of junk, and even the good mods end up being built entirely differently so they dont fit together well.
- There is very little content in the game by default, so there is a huge need for mods, which makes everyone rush their mods out so they would have something to play with. This will propably improve over time though.
- Despite being built for modding, the mod suppot is crap. There is almost no official information available, no tutorials, no proper documentation, nothing. The tools aren't very easy to use, and the way the files are organized for mods isn't very good so your whole game ends up being a mess after installing a bunch of mods.
For LFS even the starting point would be different since everyone would compare the mods to the stock LFS content which is already high quality, and (hopefully) modders would try to get their things to match that quality. I think, that to make things work there should be:
- Good documentation. Not just how to use the tools, but what you should do; recommendatios on how to make the visual appearance match that of the default content, how many triangles there should be, how many LOD levels there should be, what kind of texture mapping and what kind of texture styles you should use, what elements should a good track have, and so on.
- Good mod organization. Mods should be easy to install, and easy to uninstall. Extracting 50 files to your game directory that go to ten different subdirectories is a mess. A single mod (ie. a car or track addon) should be a single packaged file that you place in a addon directory, making it easy to install, manage, and uninstall. A decent example of this is Operation Flashpoint, where regular addons are archive files that you put to a directory named 'addons', or you can make mod directories that can be used from the command line to load a bunch of addons and files that replace the default game files. For a bad example look at MS Flight simulator, where the easiest way to uninstall an addon plane is to reinstall the whole game :P
- Some feedback and interaction from the developers. For example, one important thing to keep things looking good is to have the cars all have the same visual style. This can be very difficult, so it would be great to have some comments from Eric on how he does the models and textures so other people could try to make their work look similar.
If there will be official mod support for LFS, it would also be great to have the best mods to be picked by the devs to be sort of "officially" supported. They could be added to be part of LFSworld and be promoted on the official website. These should have very strict requirements to make sure they integrate seamlessly with the official content in every way.
I do think the LFS forces could use some work. Sure, they are much better than what any ISI engine delivers (imo.), but they still are far away from providing the kind of feedback Richard Burns Rally does. Though a WRC car is of course different than what we have in LFS, but still the feedback effects feel so much more real in RBR; When I'm accelerating or braking I can feel the slight change in the wheel's stiffness to know how much grip the front wheels have, when I lock the front wheels when braking I can instantly feel a slight change in the wheel etc...
For LFS everyone always just says the forces "come through the steering column", but no one seems to know exactly what forces from the "steering column" are there. For example, I would assume the amount of weight on the front wheels would affect the stiffness of the steering wheel, so when I'm braking heavily the wheel should feel different than when I'm accelerating and most of the weight is on the rear wheels. But I haven't felt such in LFS, maybe the effect is there, but it certainly doesn't feel as good as it does in RBR.
For LFS everyone always just says the forces "come through the steering column", but no one seems to know exactly what forces from the "steering column" are there. For example, I would assume the amount of weight on the front wheels would affect the stiffness of the steering wheel, so when I'm braking heavily the wheel should feel different than when I'm accelerating and most of the weight is on the rear wheels. But I haven't felt such in LFS, maybe the effect is there, but it certainly doesn't feel as good as it does in RBR.
Those artifacts are most likely caused by the DXTC compression, which only permit two "true" shades on one block of pixels... There propably isn't much you can do, except make the whole texture larger (ie. double the size) which would make the blocks smaller.
This could be done with an external application that watches the replay directory for certain files, for example all files that begin with "hotlap" would get uploaded to lfsworld. This way you could save your replay as "hotlap_bl1" for example and the app would automatically begin uploading it and you could just continue driving.
No you wouldn't "need" to offer such, if there were a DLL that offers the current UDP interface then you could just use that with whatever language you want just like you do now. Just that if there were LUA, python, or whatever language DLL, that would make it even easier as you wouldn't need to worry about the UDP protocol, and it would be fully synchronous.
How would this be any different than with the current system? If there were a change to the InSim protocol then it would not matter what interface you would be using, you would still need to update everything to use the new protocol.
I'm not talking about my mods. Why would it be so bad to offer both the ability to use a synchronous DLL interface, and a UDP based asynchronous interface (Through a DLL)? Currently, if you make some simple insim application (Say, for example an app that displays a welcome message whenever someone joins the server), you'll most likely end up with over 90% of the code being used to handle the UDP connectivity. If you would use a "local" scripting language interface instead, you could do it with just a few lines of code without having to worry about anything else. It would be much easier and faster to code and it would be much less bloated.
You could code DLL's with PHP if you'd have a compiler that would be capable of compiling your PHP code to a DLL. A language doesn't usually define such restrictions.
I'd say making a simple dll that exports a function is much more simplier to code with any language than what an UDP interface with InSim is. Not to mention that the asynchronous nature makes it impossible to make some things work with 100% reliability, for example with my Ghostcar mod this caused problems and headache for me.
If InSim would be a native dll interace, then you could use that to do whatever you want, including a dll that would emulate the current UDP based insim functionality and you could use it as you are doing now if you want. Or you could make a DLL that offers a direct LUA interface to insim functions that would make it very easy for anyone to make insim "scripts".
If, in the future, there will be proper telemetry (All suspension, engine, etc. data at whatever rate the internal physics calculations work at) added to InSim then the UDP interface will propably cause even more problems as sorting through that amount of data for UDP transmission failures (lost packets, proper order) would cause quite a lot of problems and "wasted" cpu cycles.
I think injuries would be nice for cup/league races, where a serious injury could mean you cannot race in the next one or two races.
Combining everything to one application is not a very realistic idea in my opinion, not only because they are made by different people (and propably with different languages) but also because it would be difficult to keep it up to date, and for someone who would only need one part of it everything else would be just unnecessary bloat.
It would be best if Scawen could fix InSim so that multiple connections would work "natively". It now gives the impression that multiple insim connections would work, but when you try it the apps just end up in a race situation where the other one gets disconnected when the other connects, and the disconnected one then tries to reconnect and disconnects the other and so on... In fact I would personally like an all new DLL based insim system, which would be alot easier to use, wouldn't have the overhead of UDP for local things, and wouldn't be asynchronous like the current system.
It would be best if Scawen could fix InSim so that multiple connections would work "natively". It now gives the impression that multiple insim connections would work, but when you try it the apps just end up in a race situation where the other one gets disconnected when the other connects, and the disconnected one then tries to reconnect and disconnects the other and so on... In fact I would personally like an all new DLL based insim system, which would be alot easier to use, wouldn't have the overhead of UDP for local things, and wouldn't be asynchronous like the current system.
In addition to this I would also like to see interpolation to be done to the wheel position both when watching a MP replay and when viewing another player's car from incar view. I like to keep the look function at steer and the 'look sensitivity' at a rather high value but when viewing other players cars from incar view the 'jumpyness' of the steering wheel causes the view to rapidly snap from side to side too which is quite annoying to watch.
You cant, its an LFS limitation (Only one InSim app works at a time for some reason). However you can switch between then in-game with the insim command, though its propably best to do it while in the menus so pitspotter/ghostcar will properly 'see' the race start and all cars joining.
If by "best of both worlds" you mean Firefox/Opera user interface with the rendering engine bugs and security holes of IE, then you are correct
A good soundcard will also make a difference in FPS in games, though in case of LFS the difference isn't that big (About 6% for me between an integrated SoundMAX chip and an Audigy 2 ZS). Bad news is that Creative cards seem to be the only ones that have true hardware acceleration, and creative sucks. I wouldn't have wanted to buy this Creative crap myself but there was no other choice.
As far as I know, most FF hardware has supported "hardware" damper and spring effects for a long time, LFS just doesn't seem to be using them.
The ghost files use the following format:
First there's a header with the following structure:
struct {
char hdr[4]; // "GHST"
float laptime; // Laptime in seconds
float sp1, sp2, sp3; // split times in seconds
int numPck; // Number of packets
int carID; // Car ID
int trackID; // Not used
} GCHEADER;
then there are numPck amount of the following structures:
struct {
float tbase; // Time in milliseonds
float x, y, z; // Position (from OutSim, in meters)
float rx, ry, rz; // Orientation (heading, pitch, roll, directly from OutSim)
float speed; // Outsim x + y velocity
} GCPACKET;
The file size must be exactly the size of GCHEADER + numPck*size of GCPACKET or the ghostcar will not be loaded.
All the motion is interpolated between the packets, so they can be saved at any rate. The mod itself currently writes them at 20FPS.
The header carID is one of the following:
0, "UNKNOWN"
1, "XF GTI"
2, "XR GT"
3, "XR GT TURBO"
4, "RB4 GT"
5, "FXO TURBO"
6, "LX4"
7, "LX6"
8, "MRT5"
9, "UF 1000"
10, "RA"
11, "FZ50"
12, "FORMULA XR"
13, "XF GTR"
14, "UF GTR"
15, "FORMULA V8"
16, "FXO GTR"
17, "XR GTR"
18, "FZ50 GTR"
FGED GREDG RDFGDR GSFDG