Quote from wien :

Try turning down the FFB strength inside LFS. This usually happens if you use too high FFB strength.

thank you for the hint, i think i left the default value (80% i think)
i'll try it.

i tried a logitech force 3d joystick with lfs and with any car (the more powerful the worse is the problem) the ffb makes the joystick oscillating so violently that i'm afraid it will broke.
as the speed increase the problem decrease, with the car stopped the vibration is the worse, i tried setting the "smooth" value of lfs and it does help a bit... but i don't know what to do to fix it!

i searched the forum but i didn't find any similar issue, but i remember there was a guy with the same problem some years ago...

anyone have any idea? thanks!

i have the same issue with any control associated with shift up/down, i used to use keyboard, but i borrowed a joystick and even if less evident it happens even with joystick.
to me happens with all cars, but much more frequently with the new formula bmw.
if i set the button control rate to maximum, life is a bit easier, but the problem remains.
maybe it is an intended behaviour, but to me having any car (even road cars) shift like the fbmw is unrealistic: i'm not aware of any road car that prevents you from changing gear when you engage the clutch unless you cut the throttle...

anyway the funny thing is that you can workaround this by using the autogears (i know, it's no fun!), because autogears can shift with throttle applied...honestly i can't understand that...

maybe you can try to use "Autohotkey" to cut throttle while shifting, but i don't believe it will work, because to me lfs simply misses keystrokes (or buttons)...it's not a matter of doing things perfectly or slowly

Quote from tristancliffe :

"We're glad LFS is harder and more realistic now"

actually i don't agree! to me is way much easier and this thanks to huge step toward realism , because now cars are much more "predictable"...i mean they behave like you expect from a real car...much more than before
i guess much of the improvement is due to the engine moment inertia tuning

Quote from Shotglass :

you must be doing something wrong then ive had no issues whatsoever with the mouse so far
does your keyboard maybe have a few issues with the number of keys you press at the same time?



actually thats sort of how youre supposed to shift in the fbm

mah, i never had any isues like that, moreover only gear change are missed, other keys work fine even contemporarly, as i said for other car than FBMW is negligible, but it's there, my guess is that scawen implemented a filter class on top of controller handling to implement the absence of autoclutch on fbmw and this class introduce some problem.

btw, it's not aproblem for me because in the last year i lost interest in lfs and i don't play it anymore, i only wanted to try the new phisics wich is very realistic now.

Quote from Scawen :

This is not a bug, it's just that there is no autoclutch on gearchange for the FBM. You must pull on the gear lever and while still pulling, momentarily lift the throttle for a near instant clutchless gearchange. Same thing in real life.

as i reported before in this thread upshifts and downshifts are missed on ALL CARS even with no throttle at all for 2 seconds, FBMW is too evident and unplayable, but is there for other cars too but is "negligible" the only workaround i found is:
while pushing throttle (on keyboard in my case), push upshift very early and keep pushed it, at the time the gear change is needed, lift the throttle and keep pressed the upshift key...same thing for downshifts.
i hope to have explained well.

of course this isn't playable and the only solution is autogears...which i hate and it cuts all the fun

i have a problem with controller too, but it's a little different:
i use mouse to steer and keyboard for anything else, both usb.
most of the shifts up and shifts down are missed if button control rate is set to maximum the problem is less evident, with button control rate to minimum, it's almost impossible to change gear especially if any other key is pressed, the strange thing is that with the new car, this problem is really evident while with other cars much less.

at first i tought it was a new "feature" of realism, where autoclutch was removed and throttle must be released to change gear, but this obviously not the case.

PS thanks for this new update, the new engine moment of inertia greatly improved realism of cars!!!

i'm just curious to know if you fixed your problem and to know how you solved (maybe useful for other people too in the future )

let me dare to say: it's better this way (to have no packet loss)

another things to try:

- download full lfs version V and make a new installation (i know how silly looks this hint, but surprisingly many times it works (thanks microsoft!) simply because sometimes a file copy or an unzip may fail for various reasons and not telling you)

- disable w-lan from your router and any other not needed features (logging, etc.) that may slow down your router

- after you have joined to an lfs server press ctrl+T, you should see a message like "asking for tcp connection for position updates"

- check your security software that may slow down lfs with the process of transmitting and receiving packets (firewall, process guard, etc.) and eventually find alternatives or a way to circumvent the side effect

- patch your tcpip.sys for unlimited connections (lvllord.de), i know it may not seem so, but a not patched tcpip.sys may prevent even a simple program with a single connection to work with the network

Quote from Criamos :

If tried to reboot the Router, checked if the firmware of my netgear wpn824 is the newest version: yup, it is.
I have absolutely no clue what it could be, but as more ppl are on a server, it seems like the period of time after which i get disconnected is much shorter than on a lower populated server (e.g.: If I drive with 4 other people, i can play between 5 and 10 minutes until i get disconnected - and if i play with 16 ppl (just like today) i get disconnected after 30secs to 4-5 minutes).
This problem occurs on every server i connect to, it seems that only on servers with no other ppl playing i don't get disconnected (and hell, that's no fun at all ^^).

i have your problem too! in my case, it's my ISP fault i have about 30% packet loss, i made precise tests and disconnects occur exactly when too many packets in a row are dropped, the solution is to open a trouble ticket to your ISP and they must fix it!!! usual isp don't have more than 1% packet loss (actually much less).

i found that U and U20 servers seem more robust and keep connection longer and also less populated servers, maybe this could help while your isp fixes your connection.

if you want to see a rough estimate of your packet loss do a "ping -t google.com" from a command console and see how many replies are lost.

hope it helps

Quote from Davo :

The new pack 0.5.1 seems lighter than the first dark one. Is there a way yto make it darker? I like the tarmac really dark but I can't edit the files because they won't open in photoshop some error comes up. yes I have the dds plugin installed, something is wrong with the actual gwroad files, astpit opens fine. If I could get the 0.5.1 fixed alpha psd files then I could make my own, but only the old oens are up. Any chance of that happening?

long time has passed and i may not remember all correctly, but original PSDs are about 300 MB each...the uploaded "sources" have many layers merged, but they should (IIRC) be fine for reproducing 0.5.1 too.
Unfortunately (or "fortunately"), i have too many huge projects to handle at work and i'm rarely at home (just to sleep, or sorta of)...i am really sorry i cannot assist you, but i guess that if you play a bit with uploaded sources, you can find if they really are suitable for 0.5.1 or they are obsolete.
btw, if your problem is only to make them darker, you can use xnview (www.xnview.org) to convert dds to bitmap, edit them and then convert back to dds...WARNING! use only the "scawen's method" for maximum compatibility, in other words: save in raw format from photoshop, then delete corresponding dds from lfs, and put raw into pic folder (find details about this procedure in this thread and also whithin scawen's posts)

Quote from Thorvertonian :

In case you were still wondering about my light triangle problem, after upgrading my PC I can't find it, must have been an issue with my Ati gfx card

i had this feeling, good for you it's ok now

Quote from z3r0c00l :

thank you!

i'm glad you and many other people apreciated those textures...oh my gosh! more than 2000 downloads :eye-poppi

Quote from Boris Lozac :

Honey, any plans for working on Westhill, or South city tarmac?

as i said above, time is really missing now...i don't even remember my last lfs race...

Quote from Shotglass :

she planned to but i guess the project is pretty much dead atm

i'm afraid you're quite right...however i hope the sources i uploaded can help someone other to continue this work...i hope to find the way to upload more material to help with that, but only if someone is really intentioned to seriosly continue it.

PS
i take this post also to say a big HI to everyone

i'm glad to hear you solved your problem.
about the center area, try to play with "steer center reduction" (i'd suggest 0.60) and "wheel turn compensation" (i'd suggest 1.0).

imo you should try lower values for smooth compensation, but that depends a lot on your taste and wheel...the reason i suggest low values is because high values introduce a delay in wheel response (it's math, not an lfs or wheel issue).

i'm sorry guys but i don't agree! i remember that prepatch there were always some regular servers for tbo (mostly fern green) and xfg (mostly blackwood).
whenever i talk about this argument online many people agree with me, after patch only lrf servers were sometimes populated, but this was a particual case for people seeking for big challenges (and actually i remeber very good battles with rac at bl), maybe it was not the only cause, but i am convinced that it played a big role in the road car less popularity

this is my suggestion by priorities:

1) very good expensive wheel (dfp, whatever...)
2) cheap laser mouse + keyboard (i strongly suggest the Trust MI6200 laser mouse: is very cheap and very, very precise and robust)
3) good analog joystick
4) bad wheel (microsoft sidewinder, etc.)
5) keyboard
6) gamepads

so, yes try your wheel more, compare it to mouse to see if it is a good or bad wheel, use an easy car like xfg, fox, fxr...i'd suggest fox because it is rwd like most lfs cars, but it is the easiest one, if you feel it is too easy then try fo8 or fzr

Last edited by Honey, Sun, 10 Sep 2006 11:51.

Quote from Gimpster :

Just this morning I took a freeway interchange at a fast enough speed to make the tires growl through all 270 degreed of the uphill positive camber interchange. The back end steped out at about 5 degrees and the rear tires in their optimal slip angle. When i got to work i took a good look at the tires. The new wear was half way between the edge of the tread where is rolls down toward the sidewall and the point where the tread blends in to the side wall, so still squarly on the tread of the tire.

I am running 205/50R15 Yokohama tires rated to 150mph, inflated to 35psi and about -2 degrees of camber. If i set the GTT or GT up this way I would roll the tires right over on the sidewalls and loose grip, have slugish handeling and be slow around the track. Somthing is just not right there.

indeed, lfs road tyres deform too much and also, as i discussed in the past, they deform in an unrealistic way, on the other hand slick tyres seem to behave realistically (according to videos, photos, etc.) and the handling too is not weird like it is now on road tyres i don't know if the problem is that devs used the same tyre physics for both slick and road tyres, or if the set road tyres deformation just to achieve the wanted lateral grip value...neverthless both situations are very wrong and this is why with the new patch almost nobody drives road-tyres-car anymore (except cops and robbers and drifters)...me included...

Quote from Dumpy :

The way I understand it, hotlapping is a test of setting up your car and driving a clean lap as fast as you can, and I believe that a rolling start with warm tires would provide the best conditions and the most efficient means for a driver to do so.

exactly! i spend 60% of my time in hotlapping for developing setup purposes, what i need is to see by split times if a change is improving certain split or not...having to drive a whole lap before i can test it is a pure waste of time!
of course since i am playing lfs from some years, now i can measure/predict the split times most of the times with an accuracy of 0.05 sec, so i learned to see even in the last sector where hotlaps start, if a change of setup is improving or not, of course i test setups at default temp, warm/optimal temp and overheated temp to see if the setup is behaving how i want in all conditions or if it needs some tweak...what i don't understand is: in real life racers have the thing that bring tyres on temperature...why having it in lfs would be unrealistic? ...some people like to do useless laps and do averything by themself? let it be an option!

having hotlaps start from last sector with preheated tyres is NO advantage! only avoids a time waste!
so if purists want to do everything, let them drive from home to the circuit, wear their racing suit, the helmet, tell the pitcrew how to setup the car, wait the needed time for the pitcrew to make the setup changes, mount the tyres, wait for the "thermal thing" to heat up tyres, then enter the cockpit, lock the safety belts, turn up engine, exit from pits, make a useless lap and then start the hotlap that will end at T1!!!! then walk (30 minutes? more? ...who cares) to the pits, wait for the car to be repaired (if possible), then start all over again!

Quote from Hyperactive :

So there is more than one way how the bug appears? As far as I have heard from it, usually the invisible one and the others can't tough each others at all. Not even in that way that the invisible gets hit by others, while others "don't touch anything at the same time"?

At least by looking at the spr I uploaded, Honey doesn't seem to be moving (from my replay) when I drive my car right in to same place where her car is - at least his car isn't moving in my replay suggesting that there is no contact in any way.

But let's hope the big has vanished for now

actually, the invisible user is frequently rammed by others, ideed everytime i had guessed by noticing cars take racing line careless of the fact i am there, so i get rammed but right after the crash the other car continue smoothly on the racing line as nothing would have happened, in fact the other guy by HIS point of view is never able to hit the invisible one (actually there is a probability of 1/(65536-1024) that the invisible guy can become visible again each time he do spectate/join actions).

thanks Shoe Maker and schofei, with those replays i think scawen will have a full idea of what happens and hopefully it may help in fixing it with the solution he is already implementing. thanks guys and gals

good work scawen!

this is the replay of myself invisible, i connected to redline server which has lfslapper, i stayed idle so lfslapper put me to spectate, after a while i rejoined and i asked other people if they could see me amd no they couldn't. i saved the replay and asked for some holy sould to do the same and post here, let's hope...

btw i think there is no doubt about the reason, however i promised this replay, so here it is...

Quote from Scawen :

No. Because the guest does not actually know the ephemeral port. I wouldn't know how to access it. Maybe that's possible within the local OS but even so, it's still useless because the hardware *router* can change the ephemeral port. That is to allow two computers on the same network to use the same ephemeral port (one computer doesn't cooperate with another to find unused ephemeral ports). The router stores a look up table and repairs the reply packets before routing them to their destination. The result is that the ephemeral port that the server will see, is not necessarily seen by your client.

I'm happy enough with my "deduction" solution and it's 100% compatible so I will implement it anyway.

of course you knwo better than anyone your code and we know your solutions are always at state of the art, i'm just happy you found the cause
btw accessing/quering ephemeral port depends on the framework/api you use, but it's not a too hidden info...at least a netstat call would give you the answer, themost common name for ephemeral ports is "local endpoint", i remember winsocks to have it, for sure .net gives that info (but we don't care about .net), iirc in winsocks was quite hidden how to retrive it.

Quote :

Well it's a bit of a guess. Your evidence is also suggesting it's at the server end, because your own replays are saved correctly, and you report that the UDP packets are sent correctly.

One further piece of evidence that would strengthen this theory, is if spectating and joining does not help in any way, and the ONLY way to become visible again is to leave the host and rejoin.

exactly

Quote from Aquilifer :

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?

maybe coincidence, maybe since insim apps are quite "verbose" that could make the client os fall in the conditions to change the ephemeral port more easily...that does not surprises me so much even thou it's not completely clear why.

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.

i understand, you use the ephemeral port as sorta of "client id" so to save pospackets size small and have efficent bandwidth usage, surely there are robust solutions, but the first that come to my mind right now, could be to send via the tcp connection from client to server the ephemeral port change...i make myself clear: the client periodically check (i.e. each 5 seconds) its ephemeral port, if it has changed it sends a "ephemeral port changed" event trhought the tcp connection to the server...dunno if that may be useful.

...so a t this point maybe we have to hope that the cause is really (as it seems to be) the ephemeral port change, i guess this would be less time consuming than any other possible cause

good work!
thanks!

Quote from Scawen :

Important question : Is that only on the OTHER players MPR, or even in the replay you save on your own computer? Is the replay in your second post recorded on your own computer or someone else's?

when happened to me, on mprs i saved i could see myself, unfortunately i think i recently purged my mpr folder when i installed last patch, i'll promise to provide you an mpr tonight or tomorrow

Quote from Scawen :

Which UDP packets arrive at which instance of LFS? I don't know what you have verified - you have verified that UDP packets arrive at the guest? Or you have verified with 100% certainty that the PosPackets from the invisible guest are arriving at the host?

I am working on this question at the moment, that's why I've asked GAS-Hugo about the MPR in my previous post. If the player whose car becomes invisible to the other players, saves a MPR on his own computer, and even in that locally recorded replay, he can't see his own car, that means his computer is not even trying to send PosPackets! However, if he CAN see his car in the MPR saved on hos local machine, that means the PosPackets are being prepared but either they are failing to be sent or the host is not receiving them or not forwarding them.

when i enable the lfs network debug feature, it shows me the "ping/lag" of myself i assumed (by logic) that this means server has acknowledged my udp pospackets...so to be clear, it seems to me that udp pospackets arrive correctly from my client to the server, they surely are sent as my firewall log the rules that checks the lfs udp output (in the log there is the server at which i am connected as endpoint), of course i cannot see the content of the packets but i assume that are pospackets because the flux of bits transmitted is continous.
by means of windows ping and tracert commands i ensured there was no packet drop between me (client) and server host.

so if lfs ntework debug actually acknowledges pospackets, then the situation is the following:
the client affected by "invisible car issue" correctly sends pospackets (let's call this client1), server receives pospackets from it BUT don't "relay" pospackets of client1 to any other client...it just keep them for itself...
so the problem seem to be in the "server code". the only possibility that the problem is in the client is that possibly for some reason the client sends malformed pospackets and server rejects them mfrom processing after the acknowledge code.

i promise asap a couple of mpr from both views: invisible client, other client

@Hyperactive
unfortunately i don't have it it would have been a good thing to have both, but tonight or tomorrow, i'll try to arrange that with someone's collaboration when it will happen again

Quote from Aquilifer :

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.

i don't have any access to lfs code i'm just guessing using my intuition and experience with the hope that maybe the ideas that come out of this thread could be somewhat pointing in the right direction...let's just remember that until we find a way to make this problem quite reproduceable, scawen cannot do a miracle, this is obviously one of the most subtle bugs and hard to investigate

Quote :

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.

yeah i noticed that too and that is the thing that made the thing about semaphores come to my mind.

i don't know if it would be too time consuming for devs but i think that if could be possible for scawen to compile a debug version of server in "verbose mode" to be used for autox compo test i put myself at disposal to make stress tests on such server...hopefully with verbose logs, investigation may be a bit easier.

Quote from sinbad :

None of this is about any "unfair advantage". Whatever the system, it has always been the same for every one of us. I totally beg to differ on the realism subject though. It's like me asking for another shift-r key, like shift-*-R which allows me to begin a hotlap which I messed up from the point just before I messed it up, because it can assume that since I drove the lap up till that point, I can do it again. That'll save me time.

this is different, because doing the outlap is a simple thing to do that requires no skills, whilst of course the hotlap is a thing on the edge and repeating the first part of it after you did a mistake is a thing very hard to do and this is the competition that hotlaps bring...the outlap do not bring anything to the hotlap competition.

so we all agree (as you just said) it is not an unfair advantage, so, following your logic, an option for hardcore gamers to start from pits would solve this, am i correct?

Quote from NotAnIllusion :

Option (2) for me. I might want to bust a couple of extra moves before the start/finish line so a flying start is out for me.

*Oh yeah, and (5), start from 0 kph/mph beginning of last split.

flying start from last sector, not finish line...actually iwouldnt bother, but it adds the realism some people are looking for...