A crash bug fix that can be implemented on host side forces me to release a dedicated host X2 very soon.
I've decided to implement one InSim request from Becky Rose (packets to report autocross layout) which you may wish to check out and see if it returns the required info.
And I thought I'd just make a new thead in case you have come up with any other issues since patch X was released and if you need any quick InSim requests which I might be able to do quickly for X2.
Having spent most of the weekend trying to marshal Lfs encoding into Unicode and back, there are a couple of encoding related things I'd like to request:
1) As wabz mentioned, it would be nice if LFS could strip out extraneous encoding markers:
2) A couple of things about encoding that I noticed that could be classified either as bugs or as unexpected behavior. I hope the following makes sense. It's a bit hard to write off. It's basically stuff about extra control encodings, difference between color and no color and unobvious TextStart placement
In the following, I use | as a marker where TextStart is located, C0 means ISF_MSO_COLS is off and C1 means ISF_MSO_COLS is on
Mixed encoding username, latin-1 text C0: ^JDsd^LÆther : ^L|d C1: ^7^JD^1sd^L^7Æ^4ther ^7: ^8|d
What's weird?
- CO has an extraneous ^L before the message, C1 does not
- The text color in C1 or the ^L in C1 is before TextStart
Stripped out the high Latin-1 char from username C0: ^JDsdether : ^L|d C1: ^7^JD^1sd^7e^4ther ^7: ^8|d
What's weird?
- CO has an un-needed ^L before the message, C1 does not
- The text color in C1 and the ^L in C1 are before TextStart
Made Text Japanese C0: ^JDsdether : ^L|^JD C1: ^7^JD^1sd^7e^4ther ^7: ^8|^JD
What's weird?
- CO has an un-needed ^L before the message, then requires an immediate ^J
- C1 has an extraneous ^J
So these are the problems this causes me:
The extraneous or unneeded encoding markers hark back to wabz comment. I.e. once you convert it to Unicode, you can never get back the exact string
Different strings between color and no color just compound the first
And this one is the real issue for me and contradicts my complaints in about the first two in a way I'd like to have all the necessary encoding explict in the Text section. I.e. currently, in order to expose playername and Text, I can split the byte array on TextStart. But if I then decode the byteArray of just the text, I've lost the context of encoding (and color) that was set up by parsing the player. But if I decode first and then split, TextStart is no longer accurate, since the encoding markers have been stripped. So this means, I can't use a generic decoder function, but have to decode and split in a state machine specific to MSO that can keep track of the current encoding and color state and put them into the respective playername and text strings. I would really prefer not to do that.
Here's the way I think would make life easier (yeah, i know it's selfish):
Prefix text with both the appropriate color and encoding sequence and have TextStart point at the first control sequence
Other than the above case, strip any extra encoding markers (this is internally consistent, since the only time 1-to-1 conversion is really important is for echoing a message exactly.. the player prefix isn't likely to be echo'ed
Of the two, the first is more important to me.. The second can be handled by just using the raw bytes when you have to echo things. Since this is something that can be handled on the client, it probably gets trumped by requests that can only be handled in LFS, but i thought I'd put it on the list.
If you mean detection of people who are not using proper race suite models, then I would like to implement that. If not in insim then in a host file option.
Not an urgent request, just something I noticed about ^codes and remembered now reading sdether's post... In chat messages received in MSO, back to default color code is ^9 instead of expected ^8. So far I thought ^9 is undefined?
+1 for that, I'd love to print of the source code of LFS player hacker and wipe my butt with it, I just hate that annoyance. If it isn't in InSim, make it a host option or even just delete the models once and for all ...
I don't really want to crack open the rights/wrongs of the player model's existence, but I do think that it should be something serverops have the option to control in races on their servers.
I'm struggling to follow your problem on ^codes sdether. I have no problem with them at the moment. For player names I maintain 4 strings:
player.username: LFS World Name
player.urlname: HTML friendly version
player.playername: In game display name
player.cleanname: ^code stripped display name
This does me fine for all purposes. I accept I may be missing the point because i'm struggling to understand your problem sdether, but would this not solve your matching problem?
I've added the player model number to the NPL packet. You'll need to research the valid model numbers if you want to exclude some.
Wow that is confusing. I can't find wabz's original post but he says it would be nice if LFS would strip extraneous colour codes as they were entered. In fact it does, player names etc are made with the minimum changes to codepage etc. But people can edit the actual file name or create player names or host names, etc, by other means than the LFS entry system.
I think your post is really too confusing for me at this time of day. All I can say is that sometimes LFS adds a ^L or whatever just when it adds some text, when there is no real need to read the existing string and find out what codepage it is currently in, so that it really knows if the extra ^L is needed or not. And for example several translation lines have ^8 after a player name, so that we always go back to the original code page of the message, regardless of the code pages in a player's name. So yes, there are some ways that LFS can appear to add extra code page characters in a line of text. A simple example is there is no need to have ^8 after a plain text Latin-1 name if the display is in a Latin-1 language. But this is the first time I've heard of it being a problem.
Maybe for comparisons you should always use the unicode encoded version? Would that solve the problem?
The TextStart is at the point where the characters typed by a user start, excluding the codepage, intentionally, so that an external program can easily see if a user typed something.
One thing I'd better mention is I was asking for anything that might be quick. To change text display systems would probably be a really massive change. Though maybe I am totally missing the point - it is a bit late for me now as I'm stopping for the day.
^9 means : return to original colour
^8 means : return to original colour and code page
^: means : return to original colour and Latin-1
You are probably on a track where the path does not define the route - e.g. a car park. On real tracks with a route, the splits must be filled in properly.
Sorry to report Scawen, i'm using standard tracks with no layout for the split1/2/3 issue - I do accept it could be an error on my part but I can't see it if that's the case.
Perhaps I missunderstand the /pitlane command - it appears that drivers are back in game in a spectated format, they seem half spectated, they dont appear to be 'rejoining' other than being put back on the track. I am sure in patch W I could pitlane somebody and they could then rejoin the action but that does not appear to be the case: They are on track, but seem to not take part in the race.
I think I worked myself into a corner of over-complication and have withdrawn the request. But I just wanted to make sure I am reading this right. The ^L or ^8 before the TextStart are just resetting things, because anything after textstart can always be assumed to be default color and Latin-1 and if it's not the color and codepage wil be explicit after TextStart.
I send an ISI Packet to LFS and set a UDP Port as Reply Port (i.e. 9063) and an Application Name (i.e. PocketLFS).
LFS Displays that Insim was initialized for PocketLFS with UDP Port 9063.
After that I send a IS_Small to start Outgauge.
LFS says that Outgauge is Enabled and my App receives Outgauge Data.
I send a IS_Tiny to close Insim.
In my App I change the UDP Port to i.e. 6070.
I send a ISI Packet to LFS (this Time with UDP Port 6070) and my Application Name (PocketLFS).
LFS Displays that Insim was initialized for PocketLFS with UDP Port 6070.
After that I send a IS_Small to start Outgauge.
I get not Packages. When I look with Wireshark I can see that LFS still sends to 9063.
So, maybe I am doing something completely wrong or there is a Bug
This "Bug" seems to only occur if LFS is forced to send Outgauge Packets. If I play through this Scenario while in the Main Menu and after Step 7 go into a Replay I receive the Outgauge Packets. But when I am watching a Replay and doing the above thing I only get Packages in the 1st try and not after I changed the UDP Port and reinitialized Insim.
Edit: It was my Bug. I did not close Outgauge before closing Insim. So LFS seems to "remember" the Outgauge Settings even if Outgauge is opened again. So it isn´t a Bug, but maybe a Feature as with the cfg.txt (if you set Outgauge there the Insim Parameters are ignored). If this is how it should be I will shut up now :-)
well outgauge should be "closed" if the insim program which requested outgauge disconnects (this is a lfs flaw). and perhaps lfs should send both apps outgauge packets. but that would probably need a outgauge-sending-system rewrite and isn't very good on a "dedicated patch X2" (or are we going to get x2 client version, too with the inism changes?)
Ahh.. had that earlier, and I was baffled. I rolled (like I always do, of course, with significant style and poise) and was sitting upside down in the car for 20 or so seconds, then the InSim software put me back in the pit garage, as if I'd just joined the session. I then raced 3 of 4 laps, crossed the finish line immediately after the winner, but for the entire race after I'd been sent to the garage, there was no lap counting or anything.. basically as if I were a ghost on the track.. there, visible, but not a part of it all.
Perhaps I have missed something, but as far as I am aware there is no way to tell when LFS is about to terminate the InSim connection. Can we get LFS to send a "I'm closing" packet when the InSim connection is about to be terminated (e.g., user quits LFS)?
Actually there is one thing which I thought would be useful to have. Urgent? Probably not. Anyway... OutGauge packets in normal InSim way. Maybe with somewhat different contents. Basically I'd like to have fuel consumption info without messing with UDP, but would be useful in other ways also I guess.
I'd like to have all the necessary encoding explict in the Text section. I.e. currently, in order to expose playername and Text, I can split the byte array on TextStart. But if I then decode the byteArray of just the text, I've lost the context of encoding (and color) that was set up by parsing the player. But if I decode first and then split, TextStart is no longer accurate, since the encoding markers have been stripped. So this means, I can't use a generic decoder function, but have to decode and split in a state machine specific to MSO that can keep track of the current encoding and color state and put them into the respective playername and text strings. I would really prefer not to do that.
