Working great so far, and I'm glad that this bug "Last key pressed in text box could activate its function" is fixed, no more gear changing surprises.

i just miss the cool text size from P4
now its the old size again :/

bug or strange behaviour: In the controls screen it's written: "3 - load replay", but this key doesn't work.

Quote from detail :

bug or strange behaviour: In the controls screen it's written: "3 - load replay", but this key doesn't work.

Hmm, it did for a long time, but it's not like that in any recent version, is it?

How's the codepage switching? Does it detect when you change your windows keyboard? It should show a small grey silent message at the top left, if it successfully finds the appropriate codepage when you change keyboard. In fact, it changes the "def : X" (default codepage) which is the codepage that any text box will start in, if you press T.

I'm a bit concerned about how that works though... for example :

Let's say you have English and Russian friends online in one host. You currently have Latin keyboard selected, and now you want to type in Russian, but you forgot or didn't think about which keyboard is currently selected. So you press T and start typing, and English characters appear by mistake, so you switch keyboard to Cyrillic. Problem now is that high-value Latin characters (mainly accented vowels) will now appear, because the Text box thinks it is in Latin mode (because it was when you first pressed T). You would then need to press escape and press T again, to be in Cyrillic mode. Is that confusing?

Am i right about this scenario? I can't really test it, i can only imagine it. Maybe it would be better if any windows keyboard changes, would automatically change the codepage of the current text box? Or maybe only if there are no characters typed yet. But there are some problems with that and some alternatives as well, so it gets a bit confusing. I won't write it all down now because i'm still thinking about this. But anyway your views on that would be useful - in what ways is the current keyboard detection good or bad?

Of course, the aim is for it to work intuitively without needing explanations of codepages. Slight complication only arises for people who change keyboard frequently.

Anybody else notice a decrease in longitudinal G force when the tires are locked that wasn't there before?

Quote from jtw62074 :

Anybody else notice a decrease in longitudinal G force when the tires are locked that wasn't there before?

No!

The slightest change in physics would throw all the hotlap replays out of sync, so i hope there aren't any!

Quote from Scawen :

How's the codepage switching? Does it detect when you change your windows keyboard? It should show a small grey silent message at the top left, if it successfully finds the apprpriate codepage when you change keyboard.

If I have it set to English language:

I start a message and type in latin chars, then I switch to Greek.
LFS says "keyboard: Greek" but in the msg box it says "Latin 1" and it keeps on typing in high range latin chars.

If I have it set to Greek language:

I start a message in Greek, then I switch to Latin.
LFS says "keyboard: Latin 1" but in the msg box it says "Greek" and it does type in latin characters, switching back to greek and I can keep on typing greek.

EDIT:
I think I should mention that this problem did not exist in P8. In P8 I could start a message with whatever codepage of the two mentioned and switch as I typed with no problem. But I suppose what you are trying to do with P9 is make it support all possible codepages at once in a message?

Quote from xaotik :

EDIT:
I think I should mention that this problem did not exist in P8. In P8 I could start a message with whatever codepage and switch as I typed with no problem.

Hmm, yes. That's because your system's ANSI codepage was Greek. So your LFS would stay in Greek the whole time (same as starting a message in Greek codepage - which contains English characters). P9 does allow you to type accented latin vowels without manually selecting a codepage, unlike P8. But it does expect one codepage per line of text, and that is the problem.

Thanks for explaining the scenario. I can understand that easily in terms of codepages, but it looks like it would be confusing for a user. LFS doesn't handle codepage mixing in a single text box very well at all. I guess i will have to make it "intelligent", store which codepage each typed character came from then insert things like ^G, ^C and ^L into the text, for output..........

Quote from Scawen :

I can understand that easily in terms of codepages, but it looks like it would be confusing for a user.

Well, the way it worked in P8 (from the end-user's point of view) is the customary way multilingual input works in a windows program. Ofcourse it requires that someone has installed the appropriate language input locales on his computer - which again, is the normal way of doing it (want to type Russian? then install the russian input locale on your machine via the appropriate windows settings).

hey scawen...
here my lang-switch results:

pic 1:
using GER as layout before pressing T

pic2:
switched to ENG when chat was opened

pic3:
switched to RUS when chat was opened

pic4:
ESC from chat type T and wrote something in RUS

pic5:
switched back to GER when chat was opened

hope u understand what i was doing...
in the first 3 pix i switched language (layout) and leave the chat "window" opend.

in pic 4 i closed chat, leave layout to RUS and opend chat window by typing T.
in pic 5 i leave chat open and swicthed back to GER...


/EDIT:
for me it's not confusing, why switching doesn't really work when a chat window is opend...
don't think thats a problem

Quote from Scawen :

I can't see reproduce the bad text bug.

Anyone who sees text that is worse than before, please say :

- which text looks bad
- what screen resolution you are using (and if antialiased)
- ideally before and after screen shots (P8 exe and P9 exe)

- It's mainly the tire temperature text where the change became apparent
- I'm using 1024x768x32 Bit in LFS and Windows as well. As I mentioned, I do not use any anti-aliasing because my GF4Ti4200 can't really cope with it
- I've attached some screenshots (P7 and P9) showing some different modes I've tested

I've noticed that since P9, there seems to be a slight 1-pixel difference in the text sizes between the left and right tires. It's probably just an anti-aliasing issue, but the readability of the left tire temparatures is slightly higher than that of the right ones.
Anti Aliasing does solve the issue but absolutely kills my frame rates

One more thing: may I suggest to put another 1-2 pixels of margin/padding around the text so it doesn't "merge" with the tire contact patch bars above and the colored tire surface model below?

While I'm at it, let me mention that your attention to little details is always appreciated, Scawen. It's those little things being perfected that make LFS as awesome as it is now

Quote from Scawen :

Hmm, it did for a long time, but it's not like that in any recent version, is it?

No, not only in this version. How is it supposed to work? Speaking about single player, when 1 is pressed, the replay is saved automatically and loaded immediately. "2" opens a dialong "filename to save the replay", and when I click "OK", it instantly loads the replay. Where is the "3" key used?

Quote from Scawen :

How's the codepage switching? Does it detect when you change your windows keyboard? It should show a small grey silent message at the top left, if it successfully finds the appropriate codepage when you change keyboard. In fact, it changes the "def : X" (default codepage) which is the codepage that any text box will start in, if you press T.

I'm a bit concerned about how that works though... for example :

Let's say you have English and Russian friends online in one host. You currently have Latin keyboard selected, and now you want to type in Russian, but you forgot or didn't think about which keyboard is currently selected. So you press T and start typing, and English characters appear by mistake, so you switch keyboard to Cyrillic. Problem now is that high-value Latin characters (mainly accented vowels) will now appear, because the Text box thinks it is in Latin mode (because it was when you first pressed T). You would then need to press escape and press T again, to be in Cyrillic mode. Is that confusing?

Am i right about this scenario? I can't really test it, i can only imagine it. Maybe it would be better if any windows keyboard changes, would automatically change the codepage of the current text box? Or maybe only if there are no characters typed yet. But there are some problems with that and some alternatives as well, so it gets a bit confusing. I won't write it all down now because i'm still thinking about this. But anyway your views on that would be useful - in what ways is the current keyboard detection good or bad?

Of course, the aim is for it to work intuitively without needing explanations of codepages. Slight complication only arises for people who change keyboard frequently.

Yes, it works as you've described, the sign of the keyboard is shown. (Maybe add translation string to keyboard layouts?) But such a behaviour, when you switch to Russian in the dialog box, is really confusing. In any other program since MS DOS we just switched layouts when needed and continued typing in Russian. But in LFS we would rather suppose that it is a bug in program.

Quote from biggie :

- It's mainly the tire temperature text where the change became apparent...

Thanks for the descriptions. I'll be checking this and all other posts since the P9 release post, to see what i can improve.

Quote from detail :

Where is the "3" key used?

It's never used, since an early version of LFS - so i've removed that text a few patches ago. It just doesn't occur in the LFS source code at all, so i can't understand how you can see it, in P9. Even the Russian translation in the patch doesn't seem to have it there. Are you are using one of your older tranlations?

Quote from detail :

In any other program since MS DOS we just switched layouts when needed and continued typing in Russian. But in LFS we would rather suppose that it is a bug in program.

Yes, i'll need to look at the "intelligent" version which can support multiple codepages in one line of text, without the user having to add any ^X codes. At least it seems the only remaining issues now are with the actual text input system / switching keyboards.

Quote from xaotik :

Well, the way it worked in P8 (from the end-user's point of view) is the customary way multilingual input works in a windows program.

Well... not really. For you, P8 worked ok, because you only wanted to type Greek or English (no accented characters) so, coincidentally, P8 did exactly the right thing for you - because the unchanging Greek codepage covers Greek and English. But P8 fell down for anyone who wanted to use the high characters in another code page. For example, just try running P8, and try typing some French accented characters. You would have to manually select the Latin-1 code page (even if you have French keyboard installed - because your system just says "Greek" to Patch P8 regardless of the selected keyboard). Some people need to switch between Eastern European characters, and Cyrillic, all in one session of LFS (and even in one line of text, apparently). So that's where the "intelligent" system is going to help - and for you it will be just as good as P8.

Quote from Scawen :

It's never used, since an early version of LFS - so i've removed that text a few patches ago. It just doesn't occur in the LFS source code at all, so i can't understand how you can see it, in P9. Even the Russian translation in the patch doesn't seem to have it there. Are you are using one of your older tranlations?

Ah, okay. I didn't even check, one guy reminded me, said : "what the hell, it doesn't work for ages, tell Scawen about this, please!" Sorry for disturbing.

Quote from Scawen :

Yes, i'll need to look at the "intelligent" version which can support multiple codepages in one line of text, without the user having to add any ^X codes. At least it seems the only remaining issues now are with the actual text input system / switching keyboards.

Right now I can suggest that if a user had called chat box and typing the line has ever switches to Russian/Greek/Japanese keyboard, the ^X would be written in the begining of the string. In other words, if I've type any Cyrillic letter, let all the line be in the 1251 codepage. Of course, this line won't be able to contain French/Italian, not to say about Greek or Japanese. But for chat this can be a compromise.

Quote from Scawen :

Well... not really. For you, P8 worked ok, because you only wanted to type Greek or English (no accented characters) so, coincidentally, P8 did exactly the right thing for you - because the unchanging Greek codepage covers Greek and English. But P8 fell down for anyone who wanted to use the high characters in another code page.

Yeah, I thought that was the case - but I was just speaking fron the end-user pov in regards of functionality since you said "it would be confusing for a user". Anyhow, glad you know how to fix it so we can turn LFS into a fully functional racing tower of Babel.

This is kinda old bug, maybe from patch 0.2xx :

Button "3" doesn't work how it must (load replay)... Earlier while in-game you was able to push it and load replay. Now its only error sound...

Quote from ekze :

This is kinda old bug, maybe from patch 0.2xx :

Button "3" doesn't work how it must (load replay)... Earlier while in-game you was able to push it and load replay. Now its only error sound...

Look above, I've already asked this question, and there is an answer.

Quote from [RCG]Boosted :

i just miss the cool text size from P4
now its the old size again :/

It's not clear to me what you mean by this. You would need to give me more info.

1) which text are you talking about (there are several minor changes to different text. most are a little smaller than P/P2 but some are the same).

2) is it width or height you are concerned about with those characters?

3) are you having problems reading the new text or is it just general looks?

4) what screen resolution are you using (text width varies slightly with screen ratio).


Note : As a programmer, and the same code is used in so many different conditions, i need very precise descriptions of things, or i don't really know what's going on! Ask a professional tester at a game company - they soon learn to write very detailed bug reports.

just wondering..... when will this patch be official?

Quote from YUGO45 :

just wondering..... when will this patch be official?

Well, i'll just take a look into my crystal ball and look into the future... oh wait! I don't have a crystal ball!



Just kidding... there should be an official patch when it works very well for the people who want to change codepages quite often while they are typing, and when there are no real problems remaining in the test patch. Hopefully sooner rather than later, as i do have physics work to be getting on with, but i want this very nice official patch already out there while i'm at it (best and least buggy LFS ever). It's impossible to predict exactly when all the bugs will be ironed out. Because if i knew the answers already then there wouldn't be any bugs in the first place.

Great, thx for the info

Coincidently, I first tested the keyboard switching in the meeting room which is basically a kind of a text box that is always open, so codepage switching doesn't work there, as is already described. One would have to exit, change keyboard, then come back every time. Actually, change does take effect but only after pressing enter and it is ok for the next message typed there. But that means that every message before the change would be written in strange characters. I hope I make sense here. Same behaviour is in normal message boxes, change is effecive for all the next ones, either by exiting the current one with esc or enter.

So, I'm liking that it stays default for everything after the change but the "intelligent" thing would be nice: change of keyboard would insert the appropriate code (^C, ^E, ^L...) in front of the next typed character in the message as well as change the default one as it is now.

Scawen - a bug.
in training mode, when pressing any key while driving it appears a sound. dunno for what that sound is normally, but i remember in P2 it wasnt there, and its a bit annoying that every time when i change the gear that this sound comes (im using mouse & keyboard to drive)
happend on all keys that i pressed.

Two comments:

- I liked the P8 font more, I think in P9 the font is a bit stretched vertically.

- I noticed that the in-game on-screen font gets blurred when I use a mip bias of 0.00 (ATI Radeon 9600, Catalyst 4.12, max quality settings).

Scawen - have just been asking in the Stats! thread about making it record lapped players correctly at race finish. At the moment, if a person laps people, and retires on the final lap, the people he lapped may not be able to overtake because the race ends for them.

Stats! wants to record the LFS results accurately, so I thought I'd ask you about it. Is it something that can be done? I expect it won't be until a non-compatible patch cos it would throw out previous results in replays, but I might be wrong.

Also, depending on what exactly changes in future versions, can you make LFS remember the physics that a replay used? This would mean that all future LFS versions can enter a backwards-compatability mode, and allow old replays (the ones done in this version) to be played on newer versions of LFS, say patch Q?

I'm not saying DO THIS, I'm just asking for your learned opinion on it.