Quote from JO53PHS :

Well, Im only sawing what he said

IIRC Scawen said that about patch W, X and Y. If you read the news archive you see that there weren't any multiplayer incompatible patches other than Patch X. Probably patch Z will be physics incompatible. But this is offtopic here.

Quote from _--NZ--_[HUN] :

IIRC Scawen said that about patch W, X and Y. If you read the news archive you see that there weren't any multiplayer incompatible patches other than Patch X. Probably patch Z will be physics incompatible. But this is offtopic here.

Quote from Scawen :

Anyway, Patch Z will be compatible so there will be no changes to damage or physics.

Well this is bringing the topic too far but, Patch Z will be compatible

Pitline is in car..

Quote from Dmt :

Pitline is in car..

it's a track bug, not patch y16 false

Well, they could fix that, you whiner..

Moved the skins not found discussion to website bugs forum :

http://www.lfsforum.net/showthread.php?t=41651

Move the off topic requests to... Off topic requests

http://www.lfsforum.net/showthread.php?t=9937

Quote from Scawen :

So the only mystery is why your unfocussed frame rate with cars in race sometimes goes down to 64.

I"m still not sure about how the no focus/64 FPS lock occurs but I've found a way to 'unlock' the FPS:

If I'm running another DirectX app such as the standalone Flash player or Media Player Classic or VLC, then the FPS are going back to normal (still when LFS doesn't have the focus, of course). It doesn't matter which other window has the focus.
As soon as I close the other DirectX app the FPS are locked to 64 again.

Thanks for the continuing hard work guys. Cnat wait for the next 'proper' patch.

I think it's not Y16 related but

after watching a replay (this one: http://www.lfsworld.net/get_spr.php?file=12257) at the end of the replay when LFS tried to close the replay and show the replays menu, I pushed the ESCape key... and it has "frozen", showing only the background of the main menu.... without any buttons... tried to close LFS but ALT+F4 didn't work... so I had to kill the process...

Could not load fonts error am useing vista 32 bit home premium.

I think that error would come up if you did not correctly install the patch. You must save it into your LFS folder and extract it right there.

Quote from Scawen :

I think that error would come up if you did not correctly install the patch. You must save it into your LFS folder and extract it right there.

Ok i done that now i get an error Could not open file:date/skins/HEL_DEFAULT.jpg

Glad when patch z comes then no more annoying errors.

Well that error is if you unzipped in the wrong place. There is nothing wrong with the patch. But that's all it is, a patch, so it must be extracted into an existing LFS folder.

Quote from Scawen :

Well that error is if you unzipped in the wrong place. There is nothing wrong with the patch. But that's all it is, a patch, so it must be extracted into an existing LFS folder.

it is extracted into a existing lfs folder.

Quote from faster111 :

it is extracted into a existing lfs folder.

Put this in your lfs/data/skins folder.

In the latest translation update the 3a_mode_dmo is now 1 character too short for the greek word for "demonstration".

Same for 3h_smal_dmo.

Quote from mcgas001 :

OK, Firstly i'll explain the bugs.

1. The first bug is a little issue with the InSim packet SMALL_SSG. Basically, As InSim.txt says: You have to give a uVal to SMALL_SSG. In this case, Its the port. If you set the uVal to 0. OutGauge will say its closed. If you set this to anything higher then 0, LFS will say "OutGauge : UDPPort was not specified".
   
2. The second bug is a issue with running InSim and OutGauge together. Basically, Setup OutGauge in cfg.txt as required. Then once in LFS, OutGauge data will be sent. If you try to inatilize InSim("/insim PORTNUM"). OutGauge will close instantly, And upon closing LFS. It will also adjust cfg.txt and set OutGauge mode = 0.

Thanks for the description.

1) Is not a bug at all, the number in the SSG packet is the rate, not the port. The UDPPort is specified in the IS_ISI packet.

2) I've now changed this so that if OutSim or OutGauge are set up in cfg.txt then InSim will not be allowed to affect it in any way.

Quote from xaotik :

In the latest translation update the 3a_mode_dmo is now 1 character too short for the greek word for "demonstration".

Same for 3h_smal_dmo.

OK, I've allowed up to 11 characters now and uploaded it to the translation system. I've made a note in the code not to reduce this in future.

Post from mcgas001 (sean):
"Scawen, That cant be right with number 1, The Udp port in the ISI is for the MCI and NLP"

It does work like that, but there seems to be a conflict when trying to run InSim and OutSim (initialised via InSim) at the same time, that's true. From my experiments it does work right now, but InSim is then not fully functional - or you'd at least need to write a handler that can handle both InSim and OutSim packets as both arrive at the same port.

Quote from G. Dierckx :

Post from mcgas001 (sean):
"Scawen, That cant be right with number 1, The Udp port in the ISI is for the MCI and NLP"

And also for the incoming OutGauge packet when you initialize it through the SSG packet.

Quote from AndroidXP :

It does work like that, but there seems to be a conflict when trying to run InSim and OutSim (initialised via InSim) at the same time, that's true. From my experiments it does work right now, but InSim is then not fully functional - or you'd at least need to write a handler that can handle both InSim and OutSim packets as both arrive at the same port.

Shouldn't be hard to do, but would be nice if the OutGuage packet had an identifier at byte 2 so that we could check it and sort it just like the InSim packets... But, there is always the test to see if it is NOT and InSim packet and then check the size.

Quote from blackbird04217 :

Shouldn't be hard to do, but would be nice if the OutGuage packet had an identifier at byte 2 so that we could check it and sort it just like the InSim packets... But, there is always the test to see if it is NOT and InSim packet and then check the size.

Yes, I agree that it would be nice if OutGauge and OutInSim packets had size and type inserted before the rest of their packet data, would make life a little easier checking the packets coming in on the UDP port. That said, there are workarounds for it, so a breaking change like that to InSim probably wouldn't be worth all the fuss it would cause really.

I was playing with my friend.
And evry time i joined i got this joobs - obj or something
Then i joined some times then suddently i got the backround we have in pit on the main and i couldn't push any.
Then i got error messenge.. Lol

If you wish to file a bug report, then please do so methodically, carefully stated what you did, how you did it, and what the result was, possibly with screenshots if it helps.

If you need to use the term 'Lol' in a bug report, then it won't be good enough.