Quote from DANIEL-CRO :

Thanks
At the moment it is showing three players that aren't on your buddie list and you have spent most time online with. In future I plan to randomize it a bit, so players change on every load...

Another thing you might consider is to make it possible to ignore (delete from list) some of them

One more idea.

TINY_VTE (Vote Expand), which cancels vote action (SMALL_VTA) but preserves all those votes casted (unlike the TINY_VTC, which cancels the vote completely), therefore we can increase the required votes percentage to any amount we want.

Buddy suggestion is uber awesome thing, well done Daniel <3

Quote from Scawen :

I don't think that would be a trivial update, because of the complexity of it. The slipstream effect is calculated as a contribution of a varying air speed vector in a stretched oval behind the lead car(s) combined with the actual wind speed. It can vary from a tiny amount to a large amount depending on several factors.

It's possible it could be boiled down in some way, but that depends on what you want to use it for.

I am going to use it to filter laps to clean and non-clean categories in server stats.

By saying trivial, I meant just to send the packet whenever the drag gets to non-zero level. We could filter it up to 1..3% of the difference slipstream does to the car acceleration... There is also some need to exclude too short periods, like 10msecs or something like that.

Ok, it turned out not any trivial indeed.

Scawen, I can not avoid another request.

Could we get slipstream value into IS_HLV::HLVC? It would let developers throw the burden of calculating the slipstream themselves (which we implement just by common sence, since there is no precise data on how it actually works in LFS). Also it would save quite a lot of bandwidth.

I hope it is a trivial thing to do

Scawen, you should add debug print to dcon which prints actual content of that spare byte in IS_ISI, in case some of old insim programs have some uninitiated garbage there instead of 0

Quote from Degats :

Changed settings aren't applied to the car after it's joined the track. The car on track will have whatever the original setup contained before editing started (i.e. the same as if you clicked undo). Therefore the first NPL will be correct.

Maybe I messed up a bit, but I remember following thing with my setup enforcing system with k10:

(in lobby)
enter to pit
select proper setup
type /join => success
make set with restricted setting
press "OK" => denied

Quote from Scawen :

Yes. In conjunction with making it clear if he has joined the race, and avoiding the pointless extra join request, maybe this is the best solution. Allow the host to know if a certain connection is in the garage, even if he does not currently have a player in the race...

It is not pointless one! If he ends up editing setup after his car was already on the track, he will abuse the restrictions we want to enforce, so we need that extra final JRR

Quote from sicotange :

BUG REPORT:

Somehow with DCon 0.6K10 an IS_MTC with UCID 255 (=server message) does not work. It is displayed on the DCon console though. Could someone try to send an IS_MTC with UCID 255 and confirm it works normally so I know I'm paranoid or not?

I can confirm that.

Regarding the /ujoin, I think we could go the way we are... If the car is not ready (being in pits, changing settings) to join the track, from the insim you can tell it, and you can either ignore it (so he likely fails the start) or you can spectate him alltogether and alert him to join at the end of the grid.

EDIT:
I think, that making us able to see (from insim) if the car is joined being in pits (send IS_PLP), would be enough regarding the JRR stuff. So that if the car is not ready (being in pits, changing settings) to completely join the track, from the insim you can tell it, and you can either ignore it (so he likely fails the start) or you can spectate him alltogether and alert him to join at the end of the grid.

Last edited by vitaly_m, Sun 31 Jan 2016, 12:05.

I've just tested the JRR thing and it works fine for me.

Even with this "join from pit" thing Degats described, I see no problem with it so far.

By the way, it looks like the sequence goes like this:

/join
NPL join request packet sent
NPL regular packet sent
click OK button
NPL join request packet sent

Quote from Scawen :

About the enumeration of allowed cars, what about setting the allowed cars? I suppose now you use the /cars command? But maybe that is a bit clumsy / inconvenient? Do you think there should be something similar to IS_PLC but equivalent to the /cars command? Then the same packet could be used to report the cars allowed information.

The symmetry with set/query packets is a good thing indeed. Currently I have to pack the command like ALL-XFG-UF1 if I want to set more cars than admin command packet can contain

So, yes, better to have both set and query packets.

Quote from cargame.nl :

Apparently you like to do unfounded ranting, probably you was on too much Russian vodka when you wrote this or it's a general lack of diplomacy but I never heard anyone making an issue of the problem you described neither a possible solution or request to change. On the other hand "one car" public servers are quite rare to begin with for the last six years so your proposed InSim change is probably quite useless.

I can bring here 2 other people who encountered this problem in some way. 1 car servers are used quite often in leagues. Wouldn't it be much more convenient to just configure server /cars and /track and start everything up neither than having to keep in mind how to deal with your tracker of choice?

Quote from Flame CZE :

I meant that admins would be able to override the /canspectate command with the /spec username command.

Ah, I see, you just quoted too much maybe? :]

Quote from PeterN :

I don't use fixed ranges, my buttons are all dynamically allocated. Wouldn't need to be a dynamic array, could be bitmap of 30 bytes with a bit set indicating which buttons to remove.

Bitmap sounds flexible, although it will take atleast 32 bytes packet to suffice the whole possible range. With range based packet, you're enough with just 2 bytes. And, I guess, most of the time you still create and destroy buttons by some bunch amounts, which typically occupy consecutive ranges, so you could try to book keep them and use the range destroy packet.



Also, yet another request:
Can we have a packet enumerating allowed cars on the server? This will be really nice, because that way my app could automatically detect what car to show with !top command.

It was already annoying with Airio, when you came to some server and typed !top, seeing XFG top, while server has only BF1 enabled. There is workaround in Airio, but it requires server admin to take some actions (which they are lazy, or too busy to do), which ends up with lots of regular players experiencing this problem.

Quote from Flame CZE :

There is already a command for that - /spec username

He is talking about making Deco able to enforce "NO SHIFT+S"

Version 1.5.0 released. Download: Linux Windows

Changes:

Quote from vitaly_m :

In the end you can even have different Type byte

To make it clear, initially I thought that it would be possible to just send the IS_NPL and depending on response either put car on track or not. Then I saw we can't do it.

Also it will break compatibility with older insim programs -- say we run Airio and another program which does make use of this new feature.

So my current suggestion would be to have the new IS_RQJ packet being an exact full copy of the IS_NPL. This way old programs would just ignore RQJ and get only NPL, working as before.

Quote from Scawen :

Like for example the NumP could be 255 to indicate it's a join Request.

Also PLID could be 255, ReqI 255 or any other thing.

In the end you can even have different Type byte

Regarding the IS_RQJ

In the IS_RQJ we need everything from the IS_NPL, in order to decide if we let driver join (need to check all the flags, game config, ... -- button clutch, restrictions, traction control, abs...)

I think you rather should not introduce whole new packet and use the IS_NPL. So we send IS_RQR in answer to IS_NPL.


Yet another request
Also, have you looked into other changes requests?
https://www.lfs.net/forum/thread/88125 -- [RFC]TINY_AXM to request IS_AXM packets at any time -- this one will make LFSLazy splits prediction/comparison bar work on open config tracks.

Quote from cargame.nl :

Is it possible to make an option to move the entire lower section of the HUD up 40 pixels? I mean the virtual dash, susp and tire info, pedals, driverlist, netinfo?.

You can do it by scaling and moving the whole LFS buttons interface. Accessible through Display => Interface (right bottom corner)

Moving only those elements at the bottom might make it overlap with insim buttons with some specific insim programs, so it's not worth doing really.

Last edited by vitaly_m, Sun 24 Jan 2016, 01:22.

Sad that Sami Litmanen had disconnect, could be some fight in the top 3 spots

Quote from Flotch :

same here. There is not the "challenge" you may expect from a rocket car like this (even if 'just' driving a F1 is not necessarily "complex" ... being fast is another story )

Well, you can set FO8 to be lot easier than WR setups. So I hope that's the setup thing here. Will wait until they get car set up functionality back into the game, and then we can tell more.

Quote from Flotch :

not seduced ... handling is very strange ... I tried quickly I have to admit.
Graphics and sound are a bit ... not so nice

I felt some severe input lag when driving, but can't tell if it's due to my potato PC (running on processor graphics atm). But force feedback was really nice, that's the key point for me. Need much more testing until I can say if I like it better than AC for example

Recently found it on reddit http://onlineracingchampionship.com/page?id=1

They claim that they used old Formula 1 simulator as a base for physics.

What do you guys think about it?
I can't test it really well, since I don't have proper PC for it at the moment.

To try it out you need to register (providing your email) and download.

Quote from Whiskey :

I still dream of the day we can set handicap & restrictions through InSim

You can set engine restriction and weight via insim. Look for IS_HCP packet in docs/insim.txt.

By the way, my program does it. https://www.lfs.net/forum/thread/88468-LFSTop-tracker

Quote from Eclipsed :

Well,if this topic has already started - how about complete server side setup limitations? Where server admin could access menu,where he can select allowed range to all possible settings (including the same TC,air restriction,ballast weight and even max fuel amount). Probably a lot of work,but could be very useful.

That would be a bit less effort if we can have insim packets for this. The best is to have ability to send an insim packet, which has minimum and maximum setting for each value of car setup for each driver (say, we send it when driver connects). That would be the most flexible way possible: you can make special championships when people can choose what to improve in the car, and also we can have custom cars that way, etc. Also it would be nice to have sliders in insim

And basically it would be at least around 132 (setup file size) * 2 + 4 (header size) == 272 bytes size, which is already bigger than 256. That will require some (not too hard tbh) magic in insim format, since currently every packet has only 1 byte for size, so max size is 256.

Anyway, that does require a lot of work, and for those who really need such functionality, they could just RIP the set on the fly and spectate people if setup doesn't conform.