There is a small request that is easy to do and wouldn't break anything.
Can we have it so that traction control wouldn't be possible to enable if it is disabled in the car setup?
This way we can run a non-TC BF1 and FZ5 events (using special insim app), which are impossible to do now.
Also, it will actualy justify the existence of SETF_TC_ENABLE which is useless so far.
Can we have it so that traction control wouldn't be possible to enable if it is disabled in the car setup?
This way we can run a non-TC BF1 and FZ5 events (using special insim app), which are impossible to do now.
Also, it will actualy justify the existence of SETF_TC_ENABLE which is useless so far.
Thanks guys. Will do my best to match your pace some day 
Yes, it would be best to simply conform to the format used in the insim. To use special file for ID-to-TrackName sounds not really good, since we would bring more burden to end users (and sometimes the users are not only server admins, but can be just regular players).
And obviously you need to increase the version for it.
This is fair point, not saying that the data can be damaged (no checksum or whatsoever here). Thanks.
Anyway, you will definitely need to come up with something really hacky if you want just to continue to work on top of current system. So I think it is time to move to simple RO11 stuff.
In this case in the code I have 0.25 per second, while I rather wanted 4 per second.
The clutch problem has pretty easy solution.
Autoclutch works with the specific speed which is say 0.25 seconds to travel from 0 to 1.
When you calculate user input you just have to compare current input with previous value and if it traveled by more than this speed allows, you damp it back to the maximum possible value that the fixed speed allows.
The code would look like:
Autoclutch works with the specific speed which is say 0.25 seconds to travel from 0 to 1.
When you calculate user input you just have to compare current input with previous value and if it traveled by more than this speed allows, you damp it back to the maximum possible value that the fixed speed allows.
The code would look like:
// assuming we run on 100Hz
// variables description
const float clutch_max_speed = 0.25 / 100;
float clutch; // the value you will put in the physics calculation
float user_input_clutch; // the value you get from your input system every frame
// now follows the code you run every frame
{
float delta = user_input_clutch - clutch;
if (abs(delta) > clutch_max_speed) {
clutch += sign(delta) * clutch_max_speed;
} else {
clutch = user_input_clutch;
}
}
Version 1.4.0 released. Download: Linux Windows
Thanks to Oliver Feistkorn for German translation.
Changes:
Thanks to Oliver Feistkorn for German translation.
Changes:
1.4.0
+ Translation mechanism implemented (see docs/Translating.txt)
+ Translation to russian
+ Translation to german
+ Can use NONE for hlvc_checks
- Fixed help window displaying !top and !recent info in a wrong way
- Fixed corrupted sections/splits switch messing the table pretty much
- Fixed printing excessive info on new laps (now will only print one
of the TOP TBS or TB laps, since TOP means also new TB and TBS, and
TBS means also TB)
- Removed !stb command, since we have all the data in the !stint
Yes, the current format scales even worse than I thought!
Please have a look at the pubstat <track> format design
When Rockingham was released I had to make another release for my tracker insim in order for it to work.
Here is the actual info I want you to consider: https://www.lfs.net/forum/post/1899880#post1899880
Because if another track gets released I will have to do this (dive into code, run virtual machines to produce linux and windows binaries, upload new versions, make post on forum...) again in order to be able to show people world record in the !top table for that new track.
Here is the actual info I want you to consider: https://www.lfs.net/forum/post/1899880#post1899880
Because if another track gets released I will have to do this (dive into code, run virtual machines to produce linux and windows binaries, upload new versions, make post on forum...) again in order to be able to show people world record in the !top table for that new track.
Yes/49/vitaly_m
49/vitaly_m/Vitalii Minnakhmetov/Corse Motorsports
?action=WR has something to improve.
The use of numbers instead of track names seams unreasoned. What will happen when we get 11 tracks in the game?
With commonly used BL1[R] system this problem goes away (atleast we can have 4294967296 tracks instead of just 10
). The drawback is that it will make the response 619 bytes bigger (but with time, as new tracks get released, the letter-system will actually become smaller, if you have to add another digit for other tracks for the old system).
But the most important gain is that clients wouldn't have to dive into their applications' implementations whenever there is new track out there. This is pretty big.
The use of numbers instead of track names seams unreasoned. What will happen when we get 11 tracks in the game?
With commonly used BL1[R] system this problem goes away (atleast we can have 4294967296 tracks instead of just 10
). The drawback is that it will make the response 619 bytes bigger (but with time, as new tracks get released, the letter-system will actually become smaller, if you have to add another digit for other tracks for the old system). But the most important gain is that clients wouldn't have to dive into their applications' implementations whenever there is new track out there. This is pretty big.
Last edited by vitaly_m, .
With this version I get a problem under Linux/Winewhen I try to scale window sometimes (picture 1)
The problem happens if I start LFS in windowed mode and then try to increase the size.
If I start fullscreen then I can go to windowed mode and have any size I want.
Not a critical bug, but I thought it's worth mention here.
Another note: can we have this new shader on the Car's dashboard part and probably even on the steering wheel? Will make it even fancier (Y)
The problem happens if I start LFS in windowed mode and then try to increase the size.
If I start fullscreen then I can go to windowed mode and have any size I want.
Not a critical bug, but I thought it's worth mention here.
Another note: can we have this new shader on the Car's dashboard part and probably even on the steering wheel? Will make it even fancier (Y)
No idea how exactly Insim.Net api works(and I have never wrote any code on C#), but generally you need to specify PLID when you send the message.
So that it might look like this:
So that it might look like this:
IS_MTC message;
message.PLID = CON.B.PLID;
message.Msg = "I am sorry " + players[CON.B.PLID].PName;
insim.Send(message);
Nice. Don't hesitate to write me a PM through the forum, because I don't get email notification with every message in the thread, only for the first unread message.
Thanks for testing. Somehow I failed to build it properly for windows. I wonder why no one reported that earlier
Try this https://bitbucket.org/restlessmonkey/lfstop/downloads/lfstop-1.3.1-windows-bundled_libs-i686.zip
I have also updated the links in first post and latest version post.
Wild guess: maybe try to run installer as administrator?
Version 1.3.0 released. Download: Linux Windows
Changes:
Changes:
+ Configurable !log command added: option to restrict to admins, max
messages limit. Long messages are split to 2 strings
+ Split/sections preference is now saved to database, so you can
switch it once and it will always appear the same after reconnect
+ Use SystemSemaphore instead of running.pid file. No longer need to
remove running.pid file if program crashes
+ !ver command shows memory usage
+ Added Clang compiler build flags
- Fixed options window which showed all laptime updates options "On"
until you change them
- Will not run importer if lfstop is running in the directory
- Database query window optimised (!top, !tb, !tbs and !avg printed up
to 20 times faster)
- A lot of minor fixes, refactoring, code formatting :)
Ok, hopefully I can get the /laps crash backtrace tommorow so I can fix it. So far I have no clue why could this happen. And now some sleep...
Are these both logs related to the "!" issue? That one I can reproduce and the fix is trivial...
I can't see /laps command report in any of those...
I can't reproduce it on my pc, but obviously this is a bug...
Do you have gdb installed on that machine? It would be great if you could provide me backtrace.
1. Enter the directory as you normally do
cd lfstop
2. Start gdb session recording output to a log file
gdb ./lfstop | tee debug_output.log
3. When gdb shell opens, run the program
run
4. Execute the /laps command on the server to cause the segmentation fault.
5. Ask gdb to print backtrace:
bt
Then type enter until you see the whole backtrace (in case it gets long) and type ctrl+d or quit to finish debgging session.
After you done this post me the content of that debug_output.log file.
Been waiting for this for some time, nice guide, hopefully no one will take anything of this personally and rather learn from that 
FGED GREDG RDFGDR GSFDG