Generally I would say it is a good suggestion

Quote from bobloblaw :

Accepting bitcoin has become pretty easy latley

Can you provide further info? Because as far as I know developers have to pay taxes and everything. So how easy would it be to incorporate bitcoins into tax payment in Great Britain?

I have no idea on how exactly things work there, but afaik devs even did have some problems to sort with taxation in late 2015

If I want to race an open wheel car, FBM@BL1 community is the only thing that I can jump in almost any time (sometimes even that combo gets empty all around the server browser).

I've been Demo for a long time, and I had a lot of friends there. And I can say that almost everyone I played a lot with, wanted to buy an S2 (back then), but had no possibility to do it. Some of them do not have credit card, some of them can not even dare to ask their parents, etc.

Ofcourse there is big part (I would say around 50%) of those who do not want to buy license, again, most of them just aren't ready to spend their money.

I don't get the idea on why would liced users would want that anyway. It won't add as much liced users to community, as it would wipe demo world. And also it would require a lot of work to implement all the limiting stuff. Also, once people have something for free, they will be raged if someone takes that from him, provoking even bigger pirate activity.

Another release candidate with bug fixes. From now on, database will be saved every minute if someone did new laps or new WRs were merged into it.

This time it is supplied with debugging symbols and no optimisations, so in case there is some bug, I can (probably) get meaningful reports from users.

Download: Linux Windows

Server have been set up by Oliver Feistkorn to try the nonclean feature out.

LFSTOP%20TRACKER%20TRY-OUT]LFSTOP TRACKER TRY-OUT
Shut down since no interest

Last edited by vitaly_m, Tue 1 Nov 2016, 15:10.

Release candidate (which is more like Tech Preview) of Version 2.0.0 released.

Download: Linux Windows

With this version, LFSTop database does make distinction between clean and nonclean laptimes. Make sure to do complete backup of the whole lfstop folder before updating to this version!

What does it change for users?
Clean laps are treated basically the same as before. Nonclean laps do not cause chat notifications.

In the query window (!top, !tbs, !tb, !avg) you can switch between clean or all ("all" includes both clean and nonclean laps) laptimes. Currently your preference of clean/all display gets reset to "clean" every time you connect the server. Will be fixed at some point if I find that people need it.

What does it change for server administrators?
As far as I know, some people switched some hlvc off globally. Now you don't really want to do it blindly. The only thing that should be used generally is all-object_hit for custom layouts.

If you really need to save bandwidth so much, then you might also disable draft checks.

Linux admins, make sure you always have correct rights after you install the lfstop. (you need to be able to read everything and write into databases/*, Users.dat and WRs.dat). As always, don't run it with root permissions.

Changes:

Last edited by vitaly_m, Tue 9 Feb 2016, 15:50.

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