Quote from cargame.nl :

I agree but well.. Adding NCN with IP/language info is nicest but would render all InSims useless.. New packet with user info and announcing that after a NCN or requesting it with a TINY request? It's a solution but there is some overhead involved and I believe Scawen is allergic to overhead

Yet another option would be to expand the IS_NCN as needed but send the appended data only when an InSim app asks for it in IS_ISI flags. That would maintain binary compatibility with older InSim apps and eliminate the need for a special packet. OutGauge already uses similar solution to send OutGauge ID.

Yeah well, no clue. Then ISI needs change

And;

Quote from Scawen :

I will not make all new packets optional.

This would then be an optional part of a packet. Hmm difficult.

Scawen, if you made the non queue connection, may then do an asynchronous skin downloading

800 kb skin == over 1k packets

before user connect to server game download skins


AND

when i set "download skins" to "none" game said "Can't download skin: CAR_blablabla"
i think that this message not need.
just do some notice "Skin downloading is disabled" as "Donloading: CAR_blablabla"

Quote from cargame.nl :

Excuse? Why didn't you have such a big mouth last week?

There are a LOT of InSims out there, some are very old but still in use, like TV director, Airio and who knows what. All relying on dll's. Its stupid to break compatibility for such a small thing.

thats something that could be added in the same patch as the new content. All big changes in one go.


Regarding this test patch, I'd say its pretty stable and good enough to release. Maybe making it an official patch now could attract enough old time players to make the next test patch phase (if it come soon enough) more effective.

Quote from cargame.nl :

I agree but well.. Adding NCN with IP/language info is nicest but would render all InSims useless.. New packet with user info and announcing that after a NCN or requesting it with a TINY request? It's a solution but there is some overhead involved and I believe Scawen is allergic to overhead

Apps marshalling the entire structure may run into problems. If you read the values sequentially it wouldn't break. The additional values would then imply be ignored.

However, the most compatible solution would simply be to send an additional packet. Call it NCX (x=extended). So LFS would send an NCN + an NCX packet upon a user-connect. Sure, a bit redundant, but 100% compatible.

Lets see what B12 brings.

I ended the test cycle of B11 yesterday on our main server. I think thats fine after a full week. Looked good so far.

Nilex posted one bug in Bugs-Websites
I don't know do Scawen follow Bugs-Websites forum so I thought it would be good to repost it here. Actually its not bug in LFSW, its bug in LFS.exe
LFS doesn't send spectate packet to master server in case explained in thread.

edit:
-adding AI driver on server will show on LFSW like you are drving

DEDI Improvement suggestions:
1. remove line

since its not possible to add AI's on host and this only confuse people

2. add line in setup.cfg equivalent to "Ply Name host" in cfg.txt
so we can easly set name displayed above all connections, or make that above all connections always appear server name

Moved all posts regarding S3 release to this thread.

Quote from DarkKostas :

Would it be hard so when a player connects the other players can still pit/spec(all that stuff) and all these packets get cached. After that when the connecting player, finally connects, he will be prompted to these cached packets.

That would be awesome as it would stop the other side of lag pitting(the first one was when any player was lagging, but due to the new way packets work[only between host and client], this disappeared). Also that would help with the Object Out of Sync(when host adds objects once a player connects).

This is in fact what I am working on at the moment.

So far, I've made the joining process much faster, so the time between "A new guest is connecting" and "xxx connected" is down to half a second or so, even with maximum autocross objects.

I'm hoping to reduce that to zero, so there will not be "A new guest is connecting" at all, only "xxx connected". So there would be no more "Can't XXX - a guest is connecting" messages and much less chance of JOOS. In fact JOOS would then indicate an LFS bug or a hacker (cheater). At the moment it's often just that the game state changed while the player was connecting.

Already the cached joining makes that much less likely but we'll see if I can eliminate it. This is worth a couple of days because it's nice to remove annoying things.

Hi Scawen:

Slightly off-topic, but useful:
Can there be a flag added to Outgauge indicating the car's state (on/off). There are the battery lights that get triggered if the vehicle stalls, but there's no way to actually detect if a car is turned off (by virtue of hitting the ignition button).

I don't know about the ramifications on compatibility (I am only just starting out on working with the (In|out)sim packets of LFS), so if this will break things.. that's fine. I just feel it is something that is missing from Outgauge.

Thanks!

First - I think 2 ping bars not needed. 1 will be enough ( I mean 'n' menu )

Second - when I download and start some replays - track start loading same track again. After closing I should load it again ( 0.6B bug, that left in test pathes ).

Examples of replays :

http://www.lfsworld.net/get_spr.php?file=70634

http://www.lfsworld.net/get_spr.php?file=70628

etc.

While testing my InSim application (on 0.6B11) I noticed that the netcode improvements affected the IS_AXM packet greatly. Objects seem to be added quicklier when an IS_AXM is sent.
Another interesting change is that you can now remain on top of a Ramp2 object while it is moving (except if the altitude of the object is changed upwards) without falling through it, something which was not possible with 0.6B.

On the other hand I still struggle to prevent new guests connecting from getting "OOS-OBJS" (due to objects being added/removed while someone is connecting). I assume this is not easy to fix but is there a rule of thumb/undocumented information to help preventing this from happening?

Quote from Frunze118 :

First - I think 2 ping bars not needed. 1 will be enough ( I mean 'n' menu )

I'm not sure what you mean about that. Are you saying that only the numbers are ok and you don't need the bars? I think the bars are quite good for a quick check that all's well, while the numbers in the N menu are useful for a more detailed look.

Quote from Frunze118 :

Second - when I download and start some replays - track start loading same track again. After closing I should load it again ( 0.6B bug, that left in test pathes ).

In fact that is not a bug. Some replays are from before the 0.6B physics / collision updates. Some of the updates resulted in small changes to some parts of tracks and specially the shared autocross objects are now loaded in a completely different way. So the track must be loaded in the old way when you load an old replay, to avoid the replay going OOS.

Quote from sicotange :

On the other hand I still struggle to prevent new guests connecting from getting "OOS-OBJS" (due to objects being added/removed while someone is connecting). I assume this is not easy to fix but is there a rule of thumb/undocumented information to help preventing this from happening?

I hope this problem will be fixed completely or at least minimised greatly by the change I am working on right now (see my previous post).

Glad to see LFS being worked on

Quote from avih :

Glad to see LFS being worked on

when was stopped

The "instant join" system seems to be working very well now. Of course it is not really instant but it appears like that to the other guests. There is no "A new guest is connecting", only "X connected (X)". The game state is sent all at once (cached and much faster than before) and any subsequent packets that would change the game state are added to that cache and sent to the new guest so it doesn't miss anything during those couple of seconds.

- No more "Please wait - a guest is connecting".
- No more "Can't X - a guest is connecting".
- JOOS should be very rare now. For example you can now join while a layout is being loaded or at the same time as nearly any changes in game state are happening.

I've been able to delete quite a bit of code which was only dealing with the situation of player joining, trying to avoid JOOS by avoiding game state changers while a guest was connecting - something that is no longer needed.

My plan now is to finish the loose ends of this task, then complete the other incompatible updates (cheat protection) then release a test patch later in the week. You may have heard that before... but this instant join system was a case of finishing the job of this patch and was a natural step to take after the new server packet system and the cached packets were already done.

Quote from Scawen :

- No more "Please wait - a guest is connecting".
- No more "Can't X - a guest is connecting".

Is this small bug I found something that could be fixed for the 0.6C patch release, or would it mean rewriting too much of the sound engine?

Quote from Matrixi :

Is this small bug I found something that could be fixed for the 0.6C patch release, or would it mean rewriting too much of the sound engine?

No, I wouldn't like to look into that at all now.

It's been a long test patching stage that started from that hacking problem we had. The improvements that resulted are really good and I just want to get that finished so we can move on.

I do have a list of a few things that are relevant and important that must still be done then release a test patch before next weekend.

Got it. I was guessing that might be the case considering the relatively long time the test patch stage has carried on now, just thought I'd mention it in case it was a small and quick fix.

Keep up the good work on the netcode, will be testing the next test patch a lot when it's ready.

As the next patch will be incompatible, I'll start a new thread for that when it is ready.

I will close the test patch forum for now, as there has been enough testing of the B11 version, for my purposes.

Thank you all very much for the testing and comments.

I'll leave this thread open but the forum will not be visible.

Link to the test patch forum : http://www.lfsforum.net/forumdisplay.php?f=66

Great news!

maybe its little bit late, but is way to fix jumping (lag jump) and fake suspension crash when other players drive over ramp?

Also, I forget to write about start bug, that left from 0.6b :

When cars start on custom layout ( custom start place ) - I get message like "Can't start - start is blocked", but sometimes 2 cars can start with same time ( I think it's lag ) and 1 car start driving - all cars start flying. Also 2 gentlemens yesterday was in same situation and started driving with same time. Cars was in the same place.

Thanks for attention !

Quote from Frunze118 :

Also, I forget to write about start bug, that left from 0.6b :

When cars start on custom layout ( custom start place ) - I get message like "Can't start - start is blocked", but sometimes 2 cars can start with same time ( I think it's lag ) and 1 car start driving - all cars start flying. Also 2 gentlemens yesterday was in same situation and started driving with same time. Cars was in the same place.

Thanks for attention !

We are all aware of this and its quite a pain. Perhaps, Scawen you could think of adding the option of creating multiple start points next to eachother which could enable a mini pitlane in an autocross area or where ever.

Just keep the suggestions/bug reports for test-patch related stuff only, I don’t think Scawen will do any of this in this set of patches anyway.