Your in-game name: [TC-R] Elmo
Protested driver's in-game name: M@CI3K
Session: Race
Lap: 6
Timecode of the incident: 00:08:23
A brief explanation about the incident:
I was hit from behind when pulling into the first pit stall, which caused be to spin and lose just over 4 seconds. This cost me 2 places (I would have crossed the pit-exit SC line right behind Jeff, based on time loss).
M@CI3K didn't brake at all and only lifted off throttle briefly as contact was made.
I still haven't got around to customising the button range for TCLights, however there shouldn't be any buttons drawn except when the menu is open (unless you have the HUD enabled).
It's possible that Lazy is trying to update the lights status text of a button which TCLights has deleted (ie when closing the menu)?
If you have the TCLights HUD on, try turning it off.
If TCLights HUD is off, does it still happen if you haven't opened a TCLights menu since last starting Lazy & LFS?
Edit: Looks like I was ninja'd. May still be useful for others to troubleshoot though.
Those tents won't show up in open config, so won't be a problem for layouts. There are already some tents, trucks etc that only exist in some standard configs and not open.
0.6T ("before") shots are all done in open config, so there are some missing objects. Might go through and update with the right track configs if I get time later.
Impossible to do on a server, it's a client side app I wrote that uses InSim/OutGauge data, no LFSLazy style memory hacking
It's quite old and a bit buggy, It can get confused and crash in certain circumstances - I know what the problem is, but I haven't got around to fixing it up yet.
Yeah, it's probably something to do with either the font, or maybe how Windows is reporting something, because it started happening in Windows 10 IIRC.
You definitely need to have a font installed for those characters to render as anything other than squares - this was a problem for a while where LFS was looking for a font that didn't exist or something.
Long story short, LFS is using the wrong width for a lot of the characters, so some get cut off (LFS thinks it's narrower than it is, like the gif) and some show the left edge of the character next to it in the bitmap as well as the correct one (LFS thinks it's wider than it really is). The top couple of lines of the Japanese extended page 87 are a good example of the latter.
Did you get a chance to look at the font width/alignment bug (attached) while you were digging around?
I can't find the bug report, but I know it was mentioned before - maybe buried in the hidden test patch section.
Scawen, are the /CP values correct for the second image?
The camera seems to be in the right place, but pointing in the wrong direction. The other ones of that area seem to line up properly, but that one looks way off.
I'm trying to work out whether the shine on the wet grip area is supposed to be water or shiny rubber.
I'm going to regret saying this, because it's another shader rabbit hole to go down (sorry if this delays the release ), but for "overexposed" shine like this, it could probably do with a subtle amount of bloom.
First, a thread is not a process. A process is what you would see in the Windows Task Manager. One of the hidden-by-default columns in Task Manager is the number of threads that a process is using.
It is very possible to have multi-core support by using multiple threads working in parallel, however just having multiple threads doesn't mean that you would get any benefit by running them across multiple cores. They must be able to perform tasks in parallel, somewhat independently.
One of the easiest ways of doing this for games is to split different tasks that do not depend on eachother (in the current tick at any rate) - splitting off AI, graphics and physics into their own threads is probably a good example, though there are some complications.
Alternatively, having a thread per car (or a small number of cars) would be another way to relieve the single-core burden of physics and AI, as - apart from car to car collision detection - the different cars are independent from eachother, which allows the different threads to easily work in parallel.
Depending on how the different threads are used and interact, there will be various limits on how many CPU cores can be effectively utilised.
Contrary to what many web browser developers would have you believe, you do not need multiple processes to have multi-core support. In fact, having multiple processes is usually less efficient than multiple threads in a single process.
I believe Scawen has said that multi-core support is already on the list of things to do, but I can't find the quote. I did find this one:
Hmm, blank for me as well in a private window - works fine if I've already been to the site though.
I've been told it works eventually if you refresh a few times.
Never used that site before, so no idea what's going on.
This is a guess, but it makes sense to me, so here goes:
When you open a file in Firefox without saving it first, it stores the file in a temp folder. This file (theoretically) will eventually be automatically deleted.
By setting the Read Only flag, Firefox is forcing programs to load a Save As dialog if you make changes to the file that you later want to keep.
If it didn't do this, people would accidentally permanently lose their changes after the temporary (now modified) file is deleted.