This is indeed funny as we faced a longtime ago at work (and even recently)on our industrial application for hmi, this particular issue of 49 days leading to a crash.
It took very long times to detect it, because there was never any cases in which the application or even the power supply have remained operational for more thn 49 days
Glad it is under control on your side !
The text entry updated for editors is included in LFS
There are some fixes in the IME for East Asian Languages
Finer force feedback adjustments in game (1% steps instead of 5%)
MPR fix (if entering a server that was in game for 24.8 days
Hi Scawen, thx very much for this update. I'm especially grateful for what you did with the FFB strength adjustment. Increments of +-1 by keys are more than welcome and capping it to 100% is pro.
If anyone wonders if the scaling of FFB strength is changed - the answer is no. You can keep your old FFB strength %, it is just that the max value is being capped to 100. Note that most cars will clip the FFB at 20% or sooner, so be careful with it and optimize for your driving style and car/track combo.
edit: For example, for normal smooth driving XFG+BL1 you can use up to 34% FFB strength with no clipping (if you hit wall or sausage curb it will clip)
The attached figures are showing an FFB real-time monitor that I made in GUI for my FFB wheel firmware for Arduino. It is simply passing the FFB value that the LFS is sending.
What have changed? Didn't notice obvious difference in Simplified Chinese as it working nicely as before.
However I found Japanese still have issue. By using Google Japanese IME it does not seems to work.
BTW.There are some special hotkeys only available on Japanese Keyboard. That maybe the reason you have difficulty. Among spacebar there are ENG/NUM on the left and KanaInput on the right.
I'm not sure what I am seeing in the first image. Is it that you expect the characters in the bottom left window, to match the ones displayed in the LFS dialog?
If that is the case, it seems like a code page issue. Maybe the "Language for non-Unicode Programs" is set wrong on your computer? Maybe that is set to Chinese, but should be set to Japanese?
It's a very unfriendly setting as it requires a restart if you change the setting. But maybe if you did then Japanese would work, and Chinese would go wrong instead.
EDIT: I forgot to answer this:
First I noticed a bug in Japanese, where it made a beep and displayed an error message every time I entered a character. So I fixed that but then noticed that the shortcut keys I used did not seem to notify LFS that the IME is switched on or off, in Japanese. And there was a crash on exiting LFS when an IME is active, though it seems this may only be in the debug version. I read up about the crash (with some difficulty, because there is very little documentation or discussion about IME on the internet) and found one article by Microsoft which advised not to call IME functions when processing a Windows message, as this could cause a crash. So I restructured the system to record IME notifications in the message loop but only act on them outside the message loop. I also removed a little code that had little function but looked as if it might cause a problem.
So with all these changes, sometimes things may be done in a different order and so I became concerned that I could have broken something without knowing about it. The idea is it should still work as before, you shouldn't notice the changes (except that error beep in Japanese).
But the funny thing is I didn't even really know if it was working well *before* these updates. I don't think many IME users actually write on our forum, so I don't get much feedback about it. I really have no idea how much the IME is used. For example, are there Chinese players online, talking to each other using the IME? I hope so, because it was a lot of work to support it all those years ago!
And do Japanese or Korean players use the IME? Or is the IME support clunky to use and so they find it easier to write English instead? It's really hard for me to know if it works well or if people actually use it, as I've never seen anyone using it and have hardly ever heard any feedback. But somehow I think it's important to support Chinese, Japanese and Korean as I think a lot of people around there might like LFS.
I don't know about different servers, but in TC they change the map every week, so it gets reset every ~7 days. That's why I haven't had a problem with this in TC
I've done an experiment today, to receive Unicode characters from Windows. So Windows doesn't think LFS is a non-unicode program.
It's much better as I can now use Korean, Japanese and Chinese IME to successfully enter characters without any system setting "Language for non-Unicode Programs". I can even switch between input languages while typing a single text string.
There are a couple more things to sort out. But I'm hoping to include it in the next test patch so text entry will be more versatile in LFS.
LFS is no longer a "non-unicode program" which helps a few things:
You can type into LFS with any input language supported in LFS
- Latin 1 / Central European / Turkish / Baltic / Cyrillic / Greek
- Japanese / Traditional Chinese / Simplified Chinese / Korean
You can change the input language at any time and continue typing
To paste text from elsewhere you must select correct input language
NOTE: code pages are still used internally - change is text entry
Please test, especially if you use more than one input language!
EDIT: I found two bugs.
1) Composition text disappears if you click on another window, reappears when you continue typing [fixed in my version]
2) Change to other language while composition text still exists, composition text is interpreted in the new language [fix tomorrow]
just tried it, and while the text selection works fine, no matter what kind of keyboard i select, every symbol is an ASCII Character, after I click on it on the virtual keyboard...
IDK if that's in any way intentional, but I didn't find any way to use other symbols now
Thanks! I did notice this today. By mistake, those code page button clicks were going through the "interpret unicode" function.
This afternoon I'll release a version with these fixes:
Text dialog can now get wider if long string typed with IME open
FIX: Characters from click in code page were wrongly interpreted
FIX: Composition string disappeared if you clicked another window
FIX: Composition interpreted in wrong language if language changed
FIX: Composition text could change language of characters after it
Since you are working on smaller issues, that are not related to Vehicle Mods:
I'd like to just mention an issue I've had for so many years in LFS.
Some context first, I am a mouse driver. I steer left/right with the mouse, accelerate on LMB and brake on RMB. Whenever i do a u-turn and accelerate - the mouse cursor is top right of the screen, around where the map is. The issue here is if the cursor is on another player and i accelerate (left click), I'll be spectating someone else.
Perhaps you could make an improvement? I have a couple of suggestions:
- Make an option so players can choose whether or not to have the players on the map clickable.
- Players on the map are no longer clickable.
- Players on the map are only clickable below a certain speed.
I'm used to just pressing HOME button (move view back to myself), but I'm sure other mouse drivers have this issue as well.
I agree! Also cursor will be hidden after some seconds if there is no namelist at bottom right, to keep cursor visible you have to turn on namelist, but in that case the namelist is very likely to click on it when driving. If considering map too, there will be 2 large area that not suitable for cursor to move around, which is quite annoying tbh.
I'm sorry, no. Maybe if it was more in the center, it would work to see where the mouse was positioned at. But that would just make it more in the way of other things.
I've personally looked for ways to get rid of that thing
To be fair, even I have that curvy bar hidden when mousedriving and have the cursor turned on instead.
I think the main reason is (at least for me), that I can keep the cursor in the middle of the screen at my eye level (wherever I'm looking at most of the time).
Using the bar suggested would force me to pay too much attention to the bottom of the screen instead of following the road ahead.
That bar is however very useful when watching replay, but not so much for live racing.
I drive with mouse in central view, and this bar is more than enough, as long as the bug color is in contrast with the bar color, so that it's perceivable by peripheral vision.
