Managed to do 13.33 with mouse. Interesting... using mouse has less effect than i would have thought. Even my clutch and gear change use different keys (auto clutch). Really makes me think is there sense dragging... but of course i haven't been doing it much

1. F1 GP (Amiga - MicroProse ~1991)
2. Test Drive I and II(Duel) (Amiga - ~'87-'89)
3. Slick'n Slide (PC - early '90s)

I remember playing 100% length races and full seasons in F1 GP (mother wasn't happy when I spent hours next to computer)

I've tryed Test Drives with emulator in PC, but I have to say that the control of the car doesn't feel quite so realistic as in LFS

He he.

But why I cannot make donuts?
Like the 'Grannies do donuts' game here
http://www.topgear.com/content/timetoburn/sections/games/
That would be cool, like 'LFS donuts'

Quote from spankmeyer :

Tough one, I think we've covered all Finnish personalities in F1 already with Häkkinen talking gibberish English and Räikkönen mumbling incoherently with only a couple of random consonants audible.

Heh heh Maybe Räikkönen has a constant hangover after constant partying.

And if that's not enough, more Finnish personalities can be found at javelin like Seppo Räty and ski jump like Matti Nykänen.

Returning to that Mercer T35 Raceabout...
Here are some pics for it... (nice car )
http://www.sealcoveautomuseum.org/1913mercer.html

Another good old American race car...
Stanley Steamer from 1906. Steam engined land speed record car with over 127mph average speed
http://www.steamcar.co.uk/Challenge/Stanley_Steamer.htm
(we want a steam engine! illepall )

American muzzle cars? Sure. I would like to see Mercer T35 Raceabout. Magnificent piece of machinery. Big 5 liter engine (4916cm3) and amazing 58bhp at 1500 revs/min. Only 150 been built between 1911-14. Very prized nowadays among collectors

Seriously it would be interesting to change gears with manual clutch in LFS and use the 'double cluthing' used in cars of those days

Or maybe Bugatti Type 35 from 1920s would be more interesting, but it's not American and you probably need a license for it unlike Mercer (nobody owns the 'Mercer' product name?).

Sad to hear

This sounds now like there is some similar 'thing' in your computers. I might try reinstalling gfx drivers (bit older might work better than the latest). You have to remove the old drivers completely (with Driver Cleaner if nothing else). If the new drivers are installed over the old ones, you might get things like these. If this doesn't help I'm running out of good ideas.

Since your PC is so new it is probably very unlikely that the Windows is trashed (unless you have played with registry etc).

BTW. Do other games work correct? Even if they do some other driver version might work better with LFS (yes, I've seen this with other games, although they used more complicated 3D effects ).

Good luck. I hope you get your system running well soon.

My solution:

Made a car radio app into LFS. (Actually it's part of a larger package with more tools). It uses WinAmp to play music, but to me this is no prob, cause WinAmp seems to use 0%(<1%) all the time and it has no noticeable effect on LFS (usually playing MP3s). If that foobar and others have decent remote controller plugins it would be easy to support them too (otherwise needs to write a new plugin like for WinAmp)

It doesn't use any global keys so it cannot interfere with anything. You just bind some message key(s) in LFS. Good in this is that it sends back information too (like song names). This is useful especially when you have no idea about the music it is playing (like listening to a network radio station) The attached pic has some text it displays.

Quote from Scawen :

[ TECHNICAL POST WARNING - only read if you are interested in UDP protocol ]

If we find that the car does not vanish in a replay saved on the computer of the player whose car vanished on the other people's computers, then I am starting to suspect an issue with the ephemeral port number. I've just been reading up about how these work because until today I didn't know the name for them and my knowledge of them was quite vague.

An ephemeral port number is a port number assigned by the operating system when you make a TCP connection and also when you send UDP packets (I guess in the UDP case, because it is connectionless, this is when the first packet is sent). It is the port that the packet is "from" and the host can reply to that port number and it will be routed to the computer on your local network that sent the original packet. The router can also play around with the ephemeral port numbers for reasons of avoiding conflicts.

LFS servers assume that the ephemeral port number for any particular guest will never change, after the initial connection. It ignores incoming packets from unknown ports. I think I need to insert some code that, instead of ignoring those UDP packets, it could compare them with its known connections and see if a guest with the same IP address has recently appeared to stop sending any packets. In which case it can strongly suspect that that guest's epemeral port number has changed. By examining the data inside the packets it could verify that the correct car index is included and at that point, reassign the "known" port number for that guest, to the new number.

Very interesting idea. But why some people claim that it would happen more often if running InSim apps? In this case they shouldn't make it any worse, I think.

@CSU1
"- no slags" - Hmmm... Is this a big problem for you?

Quote from der_jackal :

I hate to nitpick here, but LFS is a multi-threaded application already. What LFS is not, is optimized for multiple hardware thread environments.

Yes, heh heh. I realized it too when studying it more after i wrote the message but was too lazy to do any editing

Quote from der_jackal :

How were you targeting your threads? I'm assuming you were using SetThreadAffinity, but what priority levels did you have your threads set at?

Targeting? You mean processors? Nothing. It lets OS choose them as it sees best. Actually i don't know how this is understood in HT CPU

Priority is normal.

And the idea in the data was just to show what kind of improvement you can expect in this kind of machine. So that people don't think it is 2x (100% improvement).

Splitting a screen calculation is actually quite simple, but some jobs can be really hard to split.

Quote from der_jackal :

You have to remember the Windows scheduler works on a quantum, if your threads are set at lowest level they will be interrupted more frequently by not only higher priority threads, but all other threads running at the same level as you.

Yes. And using the highest is not really recommended.

Actually this conversation makes wanting to try little bit more testing

But maybe this conversations is not for this forum

You seem to have more information about the LFS server code. Since i don't have access to it (or have any information about it), this is more like blind guessing.

Quote from Honey :

the reason underneth this could be of any kind, some examples that come to my mind right now:
1-i connect and join->lfs adds an element to the vector/array of clients connected and in race, let's assume lfs handle this array in its way and not with stl containers or whatever, IF removing elements from this array is not "thread safe", it may happen that two thread may modified it asynchronously and thus having unpredictable results i.e. adding an element (rejoin race) could fail.

"unpredictable" indeed. Often they die a horrible death.

Quote from Honey :

i don't really think this could be the cause because join/spectate are handled by tcp connections and car position by udp packets...lfs has (i guess) some timerthread to check the lag of each client and if it is too high it disconnect you, thus according to this and to lfs-network-debug udp position packets are received by lfs and "recognised" it is just that the server ignore them, maybe because of one of the guesse i made above

With TCP, okay i see. I got idea from your earlier posts it's UDP too. Like i said, this is guessing when don't know even the facts about the code.

Quote from Honey :

it never happened to me that the first join didn't work, except on the autox compo test, again a leak in the handling of the array of joined people is a good candidate to be the cause

You only said that spectate/join causes it, so i suppose it can happen from the first join operation then too. I never played the autox test thingie and just here trying to follow your thinking

I've only noticed that when somebody joins a race it causes a small break when game freezes for a fraction of a second. No idea what it is doing then.

Quote from Honey :

i don't have anything against insim apps, i find some server apps quite useful, i just guess that having insim enable on the server may "stress" more some parts of the code and make some sort of avalanche effect

But since it happens in servers which do not use Insim apps, it cannot be because of them (even it might make it happen more often). I actually wonder do they burden the server much more than 1 guest player.

The only sensible way to make it 'multi processor friendly' is to use multiple threads. That's my opinion. That has the best changes to work correctly in most situations and with least amount of work.

How much you benefit from multithreading depends on the 'job' you are trying to split. Some jobs are are really not so easy to split into multiple threads (or that they would benefit from it). I've made few multithreaded apps. If you are really interested i got these results for my fractal program calculating a picture:

threads time relative
--------------------------
1 8.032 100%
2 6.625 82%
3 6.281 78%
4 6.110 76%
5 6.265 78%
6 6.266 78%
7 6.141 76%
8 6.172 77%
...
After 3 threads it is not getting any better, so it seems. (if the difference is significant between 2 and 3 threads is in doubt, even though the times are averages over multiple runs).

I have Hyperthreaded P4 2.8GHz(Northwood) (1 core). I haven't had change to test on 2 core system.

The only processor aware thing i would try to do is like, HT CPU ->2 threads, dual core->4 threads etc...

Quote from Honey :

so, since then i went around lfs servers and test my hypotesis:
- on regular servers (i.e. without InSim applications) it never happened till now...but i remember in the past to be happened

I've seen this only once and it was with 99% certainty a 'regular' server. Was some months ago, so cannot remember which one. I thought it was lag, so didn't pay so much attension (but it didn't print lag texts so it wasn't).

Quote from Honey :

- on servers with InSim applications it is more frequent and the more InSim messages, the more frequent the problem is...

- the problem is triggered by spectate/join actions, i.e. if i connect to a server and i never go to spectate, the problem seem to never arise!!! (<- important!!!)

Hmm.. maybe. I've tested my insim app on dedicated and non-dedicated host long and haven't seen there. Nobody complained me about this, but cannot be sure if nobody else wouldn't have experienced this. It's been running on dedicated now for few months and admin hasn't told me any problems. But, of course this doesn't prove anything.

To be specific, if the InSim app sends much messages it is bad, not that if server sends them to app? Or is both bad?

About the last point("...never go to spectate, the problem seem to never arise"): Interesting, but how to prove that, unless you know what causes it and you can track the logic out of the code? Otherwise you can only prove it wrong (by finding a situation where it does not hold). Could be true but hard to prove.

Quote from Honey :

- my guesses are that when under udp flood some lfs queue of packets overflows and it misses to process some udp from clients...this is is irrilevant for udp position, but missing the udp command for "join to race" causes this problem. Another possibility is that the server is running on a windows pc with unpatched tcp.sys that limits connections, in that case the problem would be of windows, but i don't think it is the case since the lfs network debug clearly shows that udp packets arrive correctly to lfs!!!

Sounds a good candidate for the cause. But doesn't server ACK these packets (im not sure)? Of course that's not 100% sure way (if all resends get lost too, but the client should disconnect then IMHO). Maybe it could be tested by building a 'box'(relay) which looses some of the packets to LFS (like those where player joins a race).

Quote from Honey :

so to summarize:
- udp packets arrive to lfs according to lfs network debug, ping and traceroute (-> verified!)

If they wouldn't how could you even join the server? Or do you mean that you were able to reproduce it and netstat showed that correct packets arrive even when the car goes into 'invisible mode'? Yes, that would prove it's a server side issue (like a queue overfow).

Quote from Honey :

- "invisible car bug" is triggered by spectate/join sequences of actions

When you enter a server you are in a spectate mode and then you just click "join race" to join it. So isn't this what everybody needs to do? I guess you mean that after joining i go back to spectate and then joining again and maybe repeating this multiple times, right? But basicly this could happen even if you don't jump constantlty between spectate and race states (the first 'join' packet gets lost).

I'm as eager as anybody else to find the cause. Especially if InSim app coders need to do something to less burden the servers.

Quote from ORION :

Running over nicht might not be a good computer, because ram can get quite hot when its stressed a lot for a very long time, and it doesnt like being hot.
So 12 hours or something might be a bit extreme if you have a crappy cooling

Usually its not a problem though, but I dont want you to burn down your house while your sleeping

I was suggesting leaving it overnight because I cannot see my computer being in 'nonproductive' use for such a long time. I get withdrawal syptoms for not playing LFS within 2 hours

I don't know how long you sleep but 12 hours sounds quite extreme to me. Have you been playing LFS all night and feeling sleepy?

Anyway the time I mentioned (6-8 hours) is quite long and I think it should emergy earlier if you really have a faulty memory chip. If you have many memory chips (like 2x512MB, 4x256MB etc) you might remove them one at the time to see which has the problem (when it start working the faulty is probably the one not inside). This is often faster than running RAM test, but not so exact (better test with RAM test too to see if it really is faulty). But to me it sounds more like GFX card problem.

BTW: And off course these tips have no warranty - if you burn your PC, house, cat, dog, father or even mother in law don't blame me

Traxxion: I'm glad you liked my quick tip about not running it in your daddy's PC. Always happy to help (idea was that if you play it rarely there it might not be worth try finding hard where the problem is)

If you try that RAM test, make sure it runs for couple of loops. I had one machine which needed like 6-8 hours of RAM testing and several loops before it spotted the faulty RAM chip. Better leave it running over a night or day (if going to work/school etc).

As a side note. I have Radeon 9700 and the drivers must over a year old and I've never had any problems (lucky me). If it's your daddy's PC and he doesn't play any 3D games (right?), it well be problem in the gfx card. If so try some other 3D games or a 3D test. I had once a card which worked fine in 2D, but crashed after 1 min of 3D gaming.

As a quick fix: Don't run LFS on your daddy's PC

Anyway good luck and I hope you find the cause of the problem.

Is the pack is full of (C) music? I'm sure the music makers are really happy

Anyway did I miss something here? Why don't you listen what ever music you like with some player like WinAmp. I do that sometimes and even coded a car radio into LFS (that i can control it while driving :tilt.

So it seems. The incorrect race results I was complaining are still there too. I guess there is nothing they can do to them anymore.

I think it has nothing to do with Westhill, because my races there have been logged fine after that. I wonder what happens if some of the messages from a server to lfsworld get lost ...hmmm...

Hi

LFSWorld seems to display some erronous race stats for me and at least one of my friends (Arni Arnason). Did few races last night (August 18th) and it claims we raced in WE International, even we did not (1st race in my race list for that day). In nut shell at least these are wrong...

1) The list of drivers is wrong and clearly in wrong order (like me being almost last even it says i am "1st of 4"). And there were no 4 drivers even according to that stat - only 3. In reality i think there were only 2 of us.
2) Never raced in WE1 for the last week or so. Should be AS Historic
3) It says in details we did 4 laps even it is said to be 3 lap race in race list (and it was, but not in WE1)
4) if you look at the details only the last lap for both of us can be right. There is no way doing 2:1x times in AS Historic with XFG. They look more like WE1 times

To me it seems like our race in AS Historic got mixed into some other race in WE1 (possibly earlier in this server?). There was one bot racing with us. I suppose that couldn't have caused it or what?

The other races (AS historic) for me are correct what i can see.

Rtsbasic - if the 'thingie' looks to be moving in LFS 3D space then it is definately related to LFS itself.

Some games do not like switching between programs. I have Rome - Total War which start to have errors in unit pictures after switching back and forth. Also Il-2 Stormovik Forgotten battles start to have weird black spots/clouds in sky textures. Maybe that was the cause.

However, I have never seen errors in LFS textures myself - no matter how many times I switch to windows and back.

See if it reappears after your start LFS next time. It looks quite small, so maybe it doesn't disturb your driving even if it remains permanently.

Quote from Rtsbasic :

Just to point out that my screenshot has been in no way edited or "photoshop'd". I think maybe it was a result of my graphics card being overclocked on a hot day, who knows. I was curious to see if anyone else has ever seen it..guess not.

Nah. It must be the fly you killed there the day before

Seriously... i've never seen a graphics card artifact like that. Usually several bright pixels etc. If it stays at the same spot no matter what program, it could be in monitor.

This is strange... i see something totally different hanging up there

Last edited by Aquilifer, Mon 21 Jan 2008, 21:24.

Swear...after my optical mouse has got one of those "fits"(*) and i've made a 90 degree turn, hit the wall, ruined my car, caused a huge crash and pissed off evertbody.

(*) By a 'fit' I mean a 'miss reading' in an my optical mouse when it thinks I move my mouse 1 meter left or right while i'm not actually moving it at all.

On one of those rare cases when my mouse does not get a fit...i play with my own made LFS car radio to change the track to something like "Eye of the tiger" which helps me to whip myself for a 1:33.xx lap time in BL1 with XFG

Cheers