What part of the display is tactile?

Quote from Scawen :

It just plays the left pipe a tiny bit louder in your left ear and the right pipe a bit louder in your right ear. This is good because with headphones on, the sound doesn't seem to be coming from a point in the middle of your head.

I have not been able to solve this problem with single pipe engines though which only have one sound source. The separation methods I tried gave bad results, like I wanted to turn my head sideways, etc. So they are a bit too "mono".

But it works nicely in the V and flat engines, giving a "fuller" sound.

I'm an engineer and I do work in signal processing, but have limited experience in sound processing. However, that said, I have a few comments:

1. You are getting a fuller sound since you are effectively adding a simple form of reverberation. Depending on the frequencies present in the engine sound and the delay that you add you can actually work out what kinds of effects you are introducing in the frequency domain. I'm guessing that it will be low pass in nature, but you could be introducing a null (like a notch filter) in the sound if the separation is large enough.

2. Have you tried using a smaller delay (equivalent to the separation of the left and right ears) for the single exhaust case? This could be a simple hack/fix and would give you a similar effect as you're experiencing, just more subtle.

You may already do some of this already, but if you really want a more realistic sound model then you'll have to (in no particular order):

1. Model reverberation from the cabin.

2. Model reverberation from the driver's head, chest and pinna. This is usually done with a head related transfer function (HRTF). You will probably get the most pronounced improvement in sound localisation using this technique as our brains are accustomed to receiving such information.

3. Model the position of the driver's ears in real time. This can provide a great deal of immersiveness as the sound that the driver hears changes as his head moves via the g-forces that he/she experiences. Just like stereo vision, such movement can give better sound localisation in 3D space.

I'm just trying to be quick in this post, PM me if you'd like more detailed info.

Quote from m4vrick :

THis is a great little mod. Helped me a lot.
However, im running it in Vista and every time i set a lap record LFS crashes. Any ideas?

THanks

Drive slower

Quote from Dajmin :

Keep chat where it is now, but add a single line ticker to display system messages in a sort of LCD pager style at the bottom of the screen. It'd be great if it could be added to the dashboard, but I think that might be too small and would probably mess up the skins.

+++ Dajmin has connected +++ . +++ Downloading dajskin.jpg +++ .

Just giving this idea a *bump* since I really like it. Everyone seems to have ignored it. I think a little one-line ticker at the bottom of the screen with system messages is way less intrusive than what we have now.

Also, don't know if this has been mentioned before, but it would be nice if PgUp/PgDn scrolled the chat history.

I don't think it's a good idea for 2 reasons.

1. We should be racing, not hotlapping.

2. If you are coming first and battling with the second placed car then your laps will probably be a bit slower as you're driving more defensive lines. If you can hold that first place then you deserve pole for the next race.

Perhaps the setting could be modified to move racers who finish in the last half of the results up a few places if they do really fast laps. That way you don't affect the people who are competing more closely.

Quote from the_angry_angel :

If its assumed that vehicles are the only sound source, excluding echos, then yes its possible to get the sort of data you're after.

I had already thought of that and it wouldn't be hard to do at all. I was just hoping to do something a little more immersive.

Quote from Shotglass :

...with good headphoes it will sound better than any multispeaker arrangement (discounting wavefield synthesis systems)

You may know this already, but for the other interested readers: The weakness of wavefield synthesis systems is that they can only accurately reproduce a wavefield within a certain region of space. More speakers (more money) leads to larger regions over which the soundfield is accurate, but if you move outside the region then it all falls over.

The weakness of the HRTF filtering method is, of course, that you need to wear headphones. But then again, it's a lot cheaper.

Quote from thisnameistaken :

Ooh. So does synthing this stuff create good results then?

Yes, very good results, provided that you're "average". The reason being that the HRTFs are created for a person with an average sized head/features. That said, I would say that most people find the effect very realistic and immersive.

We've got the freakiest looking dummy sitting in the sound lab right now. I get scared every time I walk past and catch him in the corner of my eye.

There is a project at my work using head related transfer functions to simulate directional audio using stereo headphones. I was thinking that we could use LFS to demo the technology.

My question is whether it is possible to get each incident sound source (including echoes from the environment) and its angle of incidence from LFS. We could then filter each sound source separately with the HRTF and mix them after the filtering.

I was actually asking how it would be possible to enforce the blue flag.

After thinking it over, I guess you could give someone a time penalty if they are driving under a blue flag for longer than a specified continuous period (e.g., 1 lap).

Quote from Hankstar :

Bob the Mod, you oughta know better than to encourage and participate in such pointless activities

I agree. All this speculation about how much the devs earn leaves a bad taste in my mouth. It really isn't polite to do such things, and I don't see anyone else talking about how much they earn themselves.

Quote from duke_toaster :

Blue flags should be auto-enforced..

What do you mean by this? I don't see how it would be possible.

I think that the biggest problem is trying to convey 4 different types of status in a 16x16 pixels. One idea would be to have the 16x16 pixel icon just have online/offline information. The larger icons could however have all 4 status types.

Anyway, is it really important to know that someone is in the pits or spectating? If I see someone that I want to talk to, all I need to know is that they are online. Chances are that they are racing or about to race. Right?

Quote from keiran :

Decided to have a quick bash Might give other people some ideas.

I don't think that the icon should be animated because you have to wait for the animated icon to 'blink' if you want to see the status.

It's actually not that hard to do this sort of thing. All you need is a good HRTF (head related transfer function) model and you're set. We've got people where I work doing research in this area.

I think the hardest thing is getting a HRTF that works for a wide proportion of the population as everyone's head is different.

Quote from Tweaker :

How am I missing the point? I already questioned that there might not be much else to be done other than to "dumb up" the netcode to make it smoother.

I now think that we are actually talking about different things.

You seem to be talking about cars lagging online and reappearing inside each other for a fraction of a second. You then go on to discuss what should happen in such a situation: Should we consider this a collision? What should be done about it?

I am talking about an actual collision. One where two cars have genuinely collided (or a car has collided with a wall), in this case lag is not the problem. The issue here is what do we do in the case of such a 'genuine' collision?

These issues aren't mutually exclusive, but they are both important and the final solution needs to accomodate both of them.

Quote from Orangutan :

Peptis, I agree implicit integration will not solve the lag induced collision problems, but it would make run of the mill stiff (in the mathmatical sense) situtations more stable. There are lots of factors in deciding on an integrator. My main point is that
IF a moddable simulator chooses to do so, it would be useful to know as a modder with respect to directions of exploration with mod parameters or extensions.

I completely agree. However, from my experience I do think that the current integrator is probably doing a good job, I just think that it is being fed the wrong information in some rare situations.

Anyway, I agree with an earlier poster, you should have posted here a lot sooner. Welcome

Quote from Tweaker :

If this still isn't clear, I give up.

It is clear, I just don't agree with you. I have seen flyng cars in single player too, it isn't just limited to curbs and walls.

I think that Blowtus summed it up well.

Quote from dadge :

i thought piracy only came into play if he/ was planning on distributing these .ogg files and gaining a profit :S. if he already owns an original copy of the sound track and converts it so he can listen to it when he drives (without using a 3rd party media player) i don't think he has broken any laws

Well, that's what the 'fair use' laws are about. In other countries, such as the USA, you are entitled to make backups of CDs. This is only true as long as you don't break any copy protection, which is a law that was introduced with the DMCA (digital millenium copyright act). In Australia, however, we do not have such fair use laws. Hence, you may not make a copy of a CD, even if you own it. That being said, it isn't really policed, and they're not likely to go after you if you're not sharing/profiting from the music.

I know that there was talk about changing the law as it is now technically illegal to rip a CD at all. That means that everyone who has copied their songs onto an iPod has actually broken the law (unless they bought the song of iTunes).

Quote from Davo :

F1perfview is totally over my head and I'm still learning how to use it, but Analyseforspeed is easy enough to use and gives a nice and easy view.

Personally, I prefer F1perfview as you get to see any paramater (speed, braking, etc...) over a period of time. Analyseforspeed, OTOH, only gives you a(n animated) snapshot of what is happening NOW.

I suggest giving F1perfview another go and just keeping it simple at first. Open 3 graphs, speed, braking and throttle (y-axis) all plotted over distance (x-axis). Turn on the cursor on all the graphs and drag it around. You can then compare your lap to, say, the world record lap, and see where the he/she is braking, accelerating, going around corners faster than you. It's also easy to compare racing lines by having the map view open as well.

Quote from orangutan :

Well written stuff about discrete time integration and its approximations.

While I agree with what you have said, I think that it is a minor point in this discussion. Although using more approximate integration methods can result in less realistic motion, on the scale and time frame that we are looking at I don't think that they are what is causing the cars to 'shoot off into space' (don't take that phrase seriously, I'm just being colourful).

I think that the problem is that the forces that are initially generated when the collision is detected are (orders of magnitude?) out. Following this argument, using semi-implicit integration to 'bleed energy from the system' is not a genuine solution. Again, without knowing how the forces are currently being generated I can only guess at how to remedy the problem.

P.S. Sorry for the 3 posts in a row, but I think it is neater to respond to each person individually. (I'm not trying to spam the forum.)

Quote from jtw62074 :

I'd like to just interject here for anyone interested that collision detection and response is an entirely separate area from the handling stuff. I'm perhaps unfortunately right now needing to rewrite my own collision detection/response system, which in no way effects how the car drives. The vehicle dynamics code that controls how a car moves when you haven't, err., I want to use an f word followed by "up" here but will be civil, "hit something," is entirely different and separate from what happens when you're out on the track and haven't hit something or somebody.

I did engineering at university and have done a lot of dynamics and finite element analysis and I don't see why this has to be the case. Am I overlooking something?

Perhaps it makes your model simpler, but there is no reason why an external 'collision force' cannot be added when a collision is detected. I believe that if your model cannot deal with such things then obviously you have oversimplified. Surely you can't assume away collisions when your model is supposed to be simulating cars that CAN crash into each other.

Quote from jtw62074 :

No vehicle handling software model intended to investigate handling and aid in an engineer's chassis design and setup job, even those that will absolutely reproduce results within the error margins of the data that can be collected (even within my wet dreams of Ferrari's F1 labs), is even remotely interested in what happens once the car has hit a wall or another car. Does this mean "the physics are wrong?" Well, it sure is wrong indeed once it hits a wall, because during the course of the computational studies the walls didn't exist in the first place, so it'll just run right through them. They don't care what happens when it hits a wall or another car. They want the car to react under driver inputs *exactly* as it would in reality. Period. If the driver hits another car or crashes, well, that's another problem for another study. That one will be concerned with crash safety instead.

This follows from what I said above. In the cases you describe here, the engineers are not interested in what happens when the car hits a wall as they're studying the (non-crash) vehicle dynamics. They're not making a computer game so why should they simulate something that they're not interested in?

Quote from Tweaker :

Besides, it is both lag and the model... but the reason for it all happening IS the lag in the first place. Because as you know when two cars are inside each other, like in Auto-X when you exit the garage or whatever..., they will fly apart when trying to break free.

The fact that 'dodgy' collisions occur in single player as well as multiplayer suggest that it is not lag that is the issue. Perhaps I didn't explain it well in my last post, but the problem of one car being inside another arises from the fact that the simulation must use discrete time steps to update itself. Basically we have a situation where there is no collision, we update to the next time step, and bang, one car is inside another. Lag in multiplayer effectively increases the size of the time step (making the problem worse), but it is not the source of the problem with collisions.

The real problem is how the model reacts when it detects that one car is inside another. I don't know what algorithm is used to generate the collision reaction forces that each car experiences, but that is not important. What is important is that it is not currently giving 'realistic' results.

Quote from dadge :

you can get a free mp3 to ogg convertor, do a google. i think he wants to put the sound track from tokyo drift into his ogg folder which is not illegal

He's from Australia. AFAIK we still don't have any 'fair use' laws. (Unless the law has changed recently.)

Quote from Tweaker :

If you have a car that is being flung to the side or "in the sky" it is not just the collision model. Cars are able to 'merge' into each other from a substantial amount of lag. If you've ever looked closely how it happens (down to each frame), you can see that once a car lags it will not appear for a brief moment, and then reappear as being blended into another car. Once this happens, it is like magnets that bounce away from each other (opposites attract, "likes repel").

The collision model is not entirely at fault when you put lag into the mix. And there is almost nothing we can do about it, because once someone lags, the car is updated as being in an entirely different position all of a sudden, and LFS can't really do any better than to let the laggy player be resuming from hiccups... even if next to (or inside) another car.

In singleplayer, multiplayer, it is all the same if you hit buggy walls, but what I am speaking of is an entirely different subject, and hardly related to the 'collision model'. This is about multiplayer connectivity.

There is a problem with the collision model. If one car is inside another, then it should be obvious to the model that something has gone wrong, be it lag (multiplayer), too little time resolution (multiplayer and single-player), or whatever. The reason that one car is inside the other is not the issue here, the issue is what, as the physics model, should I do about it when I find one car inside the other?

Obviously, the repel like magnets approach isn't realistic. IRL you don't normally see two bodies occupying the same space as each other, so another approach must be taken. I have ideas on what could be done, but I won't present them here as they will cloud the real issue; I don't want people responding to my ideas, I just wanted to point out that there is something wrong with the physics model.

That being said, we all know that the physics model isn't finished. I have faith that the problem will not exist in S3.

Quote from nosliw :

[O/T] actually, I've heard from a few sources that carrots were once purple... I dunno if its true [O/T]:spam:

You're right

Even better, you can buy purple carrots. Here's a story from 2002.