Nice!

Quote from Crady :

This one should have been fixed:

FIX : OutGauge and OutSim are no longer closed by starting InSim

But when starting InSim OutGauge Mode 1 is set back to OutGauge Mode 0...

or a complete Configuration for an OutGauge Mode 1 is deleted from cfg.txt... (When having Mode0 and Mode1 Config)...

Ok, when you have finished editing your cfg.txt, write - protect ist and start LFS with "/insim=xxxxx" parameter... so it works for me!

(xxxxx is the port)

Quote from mcgas001 :

I have also just seen a weird bug in the hosts list. See pic, Theres 2 of one server, I clicked the "?" and both of them lit up.

[STC] Kyoto Cruise

i had this too, strangly it was my server that showed up twice

With patch Y18 you cannot see DEMO host`s why not?
I read that as S2 user you can see and join DEMO,S1 and S2 hosts.
Even there is no button in multiplayer menu to switch to demo user.
Can some one tell me why?

The demo servers are right in the mix in the list. The servers are not differentiated like that anymore. All servers are the same now. If your license meets the car/track/slot requirement of the server you can join.

But i cannot see the demo servers i joined before.There are 2-3 of them.

Because they probably on Y instead of Y18.

I see thank you Guy`s for the reply.!!

I always get dropped to desktop when returning from multiplayer to main menu, and LFS says 'Closing 1 connect...'

Is it LFS related?

We had a strange bug tonight. I started a host that meets the requirements of a demo host. There were 3 of us on the server: baralaca(demo,Y18), SirKacsa(S2,Y), _--NZ--_[HUN](S2,Y18). After a practice session I've set five laps with /laps=5 then pressed shift-r. The race started and I didn't see the others at all, baralaca and Sirkacsa didn't see each other but they did see me in the race. This happened two times. Here are the replays from the second "race". I only have my own replay from the first race, I've attached it too (y18_bug_0.mpr).

Looks like a very laggy server

Quote from aroX123 :

Looks like a very laggy server

It didn't look like lag and we were on Ventrilo at that time and talked to each other continously so we should have noticed any major lag. If it was lag then we should have at least seen lag meters at the last known location of the cars. Correct me if I'm wrong.

Quote from detail :

A bug: wrong codepage in tracks list (cyrillic shown as ISO codepage)

I'm not sure how to fix this...

I assume to reproduce this, you load a music track with a cyrillic filename - is that right?

In that case this explains the problem, LFS doesn't know if a filename is Cyrillic or Latin (because it is not prefixed with ^C as for example an LFS player name would be). I'm not sure, maybe there is a way to find out from Windows...

Scawen, no, it's not a file, it's an empty slot in a new blank channel. it's just "track 1" that links to no file yet.

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

We had a strange bug tonight. I started a host that meets the requirements of a demo host. There were 3 of us on the server: baralaca(demo,Y18), SirKacsa(S2,Y), _--NZ--_[HUN](S2,Y18). After a practice session I've set five laps with /laps=5 then pressed shift-r. The race started and I didn't see the others at all, baralaca and Sirkacsa didn't see each other but they did see me in the race. This happened two times. Here are the replays from the second "race". I only have my own replay from the first race, I've attached it too (y18_bug_0.mpr).

It sounds like your host was not receiving UDP packets from the guests. Your host was successfully sending UDP position packets to the guests so they could see you, but it was not receiving them so you could not see the guests and they could not see each other.

Possibly the router was not set to forward UDP packets to your host computer?

Quote from detail :

Scawen, no, it's not a file, it's an empty slot in a new blank channel. it's just "track 1" that links to no file yet.

OK, thanks, reproduced it now - I don't know why I couldn't before.

Now fixed so it says Track in Cyrillic - looks a bit like "TP3K"

Quote from Crady :

This one should have been fixed:

FIX : OutGauge and OutSim are no longer closed by starting InSim

But when starting InSim OutGauge Mode 1 is set back to OutGauge Mode 0...

or a complete Configuration for an OutGauge Mode 1 is deleted from cfg.txt... (When having Mode0 and Mode1 Config)...

I can't reproduce this.

The code looks quite simple too - I can't see how it could go wrong.

If OutGauge Mode is 1 or 2 then InSim will refuse to change it in any way. It should just give a message :

"OutGuage : already enabled by cfg.txt"

Quote from Scawen :

It sounds like your host was not receiving UDP packets from the guests. Your host was successfully sending UDP position packets to the guests so they could see you, but it was not receiving them so you could not see the guests and they could not see each other.

Possibly the router was not set to forward UDP packets to your host computer?

I don't have a router ATM, only a software firewall but we played without any problems earlier that day so I don't think it was an error on my side.

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

I don't have a router ATM, only a software firewall but we played without any problems earlier that day so I don't think it was an error on my side.

Is this a WINE-based (Linux) server by any chance? I've seen something very similar happen due to a problem with WINE.

Well I have to say I am more than 99% certain that is a problem with the firewall, not LFS.

That is just the kind of thing that can sometimes happen with UDP packets, due to routers or firewalls, and it's not LFS's fault when suddenly UDP packets do not arrive.

For example, if you exited LFS and restarted it, it might still not have worked, but then if you restarted the computer everything would probably work again.

@wien: I started the host from LFS multiplayer mode.
It would be pretty strange from the firewall to allow the packets normally for an hour or so and then suddenly block them. I had the firewall on a relatively low security mode yesterday anyway and it never blocked LFS traffic for 3 or more years now.

I remembered incorrectly, we had a race after the practice session and after the restart the problem occured two times.
Edit: Is there a way to see what caused the error from the replays?

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

It would be pretty strange from the firewall to allow the packets normally for an hour or so and then suddenly block them.

Strange yes - but routers and firewalls do strange things.

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

Edit: Is there a way to see what caused the error from the replays?

From LFS's viewpoint it's simple. UDP packets arrived and then they did not arrive. Other than that I don't think you can judge anything from the replay. I won't give this any attention or consider this an LFS bug because it is so rare, and there are hundreds of servers running for months without this happening, and we have heard of this kind of thing happening due to windows emulators, routers and firewalls.

Quote from Scawen :

Strange yes - but routers and firewalls do strange things.

From LFS's viewpoint it's simple. UDP packets arrived and then they did not arrive. Other than that I don't think you can judge anything from the replay. I won't give this any attention or consider this an LFS bug because it is so rare, and there are hundreds of servers running for months without this happening, and we have heard of this kind of thing happening due to windows emulators, routers and firewalls.

OK, thank you for your time, I'll report back if I find any easily reproducable errors.
(edit: if you have a little free time you could try my sound pack)

New test patch Y19.
Various fixes and improvements.
New replay controls.

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

Thanks for the testing!