Speaking of missed (or ignored) posts; a couple of weeks ago I created this post asking for client latency information in the MCI packet.

Initially it seemed like I was the only one who would appreciate such info, and I can fully understand why Scawen would not want to spend time on a feature only one single person would find useful. But I've learned that there in fact are other programmers out there who agree with me (more or less).

If you guys (or girls) would step forward maybe it would be easier for Scawen to find the time to implement such information somewhere. (I have learned that it does not necessarily have to be the MCI packet, for example).

Latency information is on my list to consider it at some time. But it's impossible for me to give it any thought with such a long list of very important and extremely urgent things in front of me. It's not just a case of making a new packet, it's a case of seriously considering some means of analyzing the data available, what data actually makes sense and smoothing it and presenting it in some kind of usable form that won't lead to incorrect conclusions and so on. Loads of people saying "+1" or similar won't make it any easier for me, they'd just bug me really and make it less likely that I'll look at it. All I can do is leave it on my list and look at it at some point. I feel it's quite unlikely that it would be in patch X because it's down at the bottom of a long list.

Please, let's not start to think that just because I was later than necessary replying to t1ger's post, that everyone should now repeat their previous posts. It's very, very rare that I miss a post on one of my own threads and don't get it on my list. It can take between one minute and a few years before things get done, but that doesn't mean anything is ignored.

Ok.

Though I was not expecting "+1"s or "-1"s. I was expecting constructive, detailed descriptions of how and why the information could be used. Just like the usual insim discussions. But I simply did not realize that what I was asking for was so much work!

And by the way: Someone just pointed out to me that the debug mode (shift-f8) displays latency information if display names are turned on. I had completely overlooked that feature. It will suffice for now.

Quote from felplacerad :

But I simply did not realize that what I was asking for was so much work!

Thanks for your post.

It's not that it's so much work, I have no idea without thinking about it. But just to be clear - the point I was trying to make is that I can't discuss it, comment on it or whatever, I really have about 100 things on my sheet to do very quickly, and I'm deep in confusing SPR things at the moment. I'm just trying to express that it gets quite hard for me to stay very calm when I am reminded about things that are already on my list, when already up to my neck in other things - I'm a very busy guy working at my limit on the final push before a full version release!

I do have a list, and it's long, and I'll get to each thing in the end. I just hope that in here in the programmer forum, people will understand that not every post gets an answer quickly - and being programmers, they'll know why.

And also I want to reassure everyone, I do read every post and make a note about every post, so no need to repeat things to me. It's totally impossible to keep control in the test patch threads, even though I make notes there, the amount of duplicate posts there is quite bad, but then there are so many duplicate posts, that it's impossible for people to read the whole thread, so they end up making more duplicate posts. and so it becomes an endless cycle of duplicate information. I've learned to deal with it over time, I've come to expect to have to skim through, skipping out the duplicated without getting annoyed, trying trying to see if they added any new information. It's a great thing the test patch threads, because of all the bugs they do find! Though, it is really quite uncontrollable...

If we avoid duplicates in here then we can run on a less crazy level and stay calm, so I don't have to take a deep breath before coming in here to read the updates - I don't want this to be like the test patch threads, so that's why I seemed to react quite strongly.

Ok, two of the requests are now done in W25.

Admins can now use the IS_REO (race reorder) packet
New packet IS_MSX - allows typing of longer messages
New packet IS_MSL - output a message on local computer

http://www.lfsforum.net/showthread.php?t=24341

All message packets could be variable length? Some savings in bandwidth.

Quote from Scawen :

Admins can now use the IS_REO (race reorder) packet

I know this is spam, but I couldn't let this go with out expressing my deepest thanks, could I!

Thank you.

Tim

Small problem. If I start my InSim prog (which is ATM console program and doesn't create window itself) with /exec command in autoexec.lfs, LFS loses focus. Tried to use "/exec start /MIN prog.exe" to start it minimized, but then I get "Parameter is not valid".

Perhaps would make sense for /exec command to run programs in such way that LFS doesn't lose focus?

Hello programmers.

I just wanted to alert you to this new button interface specification which I hope to implement quite quickly.

http://www.lfsforum.net/showthread.php?t=24690

Is there any way to make the LFS window stay on top, even when it doesnt have focus?

Maybe some kind of command line parameter so an option doesnt need to be added in any menu.

If its not asking too much, it would make testing much easier for me.

Quote from BurnOut69 :

LFS window stay on top

I use hoekey to make certain windows stay on top.

http://www.bcheck.net/apps/hoe.htm

When it's running the default key is Win-4, but you might want to edit the config and comment the part of the command which makes the window transparent.

Hello,

Small mistake noted in the InSim.txt file:


byte Type should have ISP_RES not ISP_PFL as the comment.

Nothing major, but worth noting.

Thanks
Tim

Thanks fel, that will surely do the trick

I have another question: if several players can be bound to one connection (when adding AI), what would be the UCID of these AI drivers if the connection that created them leaves?

Quote from BurnOut69 :

Thanks fel, that will surely do the trick

I have another question: if several players can be bound to one connection (when adding AI), what would be the UCID of these AI drivers if the connection that created them leaves?

AI dont have UCIDs so when the the connection that created them leaves, I would expect the AI to leave also. I can not confirm this at this moment, but I am fairly sure this will happen.

Tim

Messages in MSO have colour codes stripped. If this is intentional, then why?

Hi, me again...

Tried to make use of ViewPlayer in STA packet, but to my surprise it's not player's unique id. That "Player index of viewed car" is kinda useless, as seems like it doesn't relate directly to any other data received from LFS. Also this number can change, while viewed car itself doesn't. Quite confusing.

So, any particular reason why this isn't PLID?

Quote from t1ger :


struct IS_RES // RESult (qualify or confirmed finish)
{
byte Size; // 84
byte Type; // [COLOR=red]ISP_PFL[/COLOR]
byte ReqI; // 0
byte PLID; // player's unique id (0 = player left before result was sent)


byte Type should have ISP_RES not ISP_PFL as the comment.

Nothing major, but worth noting.

Thank you, I've just fixed it in my version here (not in the W27 exe I've just posted though).

Quote from t1ger :

AI dont have UCIDs so when the the connection that created them leaves, I would expect the AI to leave also. I can not confirm this at this moment, but I am fairly sure this will happen.

Yes, AI leave if their connection disconnects.

Quote from hackerx :

Messages in MSO have colour codes stripped. If this is intentional, then why?

I think someone wanted it stripped, some time in the past, to make the text more easily readable. I don't really know if that's the best thing for it now or not.

Quote from hackerx :

Hi, me again...

Tried to make use of ViewPlayer in STA packet, but to my surprise it's not player's unique id. That "Player index of viewed car" is kinda useless, as seems like it doesn't relate directly to any other data received from LFS. Also this number can change, while viewed car itself doesn't. Quite confusing.

So, any particular reason why this isn't PLID?

No, that is just something that has passed through the net, Something I didn't spot during the upgrade when I got rid of all "PlyNum" references. I've made a note to fix that - unfortunately that will be another incompatible change, but only for those programs that used "ViewPlayer". Anyway now is going to be better than later...

I just wanted to make sure you have all noticed the new InSim button system over on this thread :

http://www.lfsforum.net/showthread.php?t=24783

Aha. There's few more of those "PlyNum" thingies I think, in camera control packets. And as for colour codes, I guess better is to put them back. For example, one of possibilities with buttons is full message history, but that wouldn't look right without colours.

OK, I go to test the buttons now.

Hi,

I think I may have found a bug in InSim. I have a program which can talk to InSim and the first thing it does with received packets is check the amount of bytes received against byte 0 and byte 1 (using a lookup table) to ensure it has received enough or not.

This works fine everywhere apart from one place - when I start a multiplayer replay. I haven't tried it with a single player replay yet as I have been scratching my head hard to make sure I am not missing anything obvious (apologies again, if I have )

When I start a multiplayer replay I get a packet which is 40 bytes long (0 to 39) and the first two bytes are as follows:

byte(0) = 40
byte(1) = 10

The rest of the bytes from 2 to 39 are all = 0.

Now, this packet seems to be an ISP_ISM, but this should be 8 bytes in size, so I expect byte(0) to be 8 not 40. I can't see any LFS packets that are 40 bytes and there is nothing in the rest of the packet which gives me any clue as to what it is.

Can anyone else confirm this before Scawen takes a look? I am using W29.

Thanks in advance.

Tim

Quote from t1ger :

...Now, this packet seems to be an ISP_ISM, but this should be 8 bytes in size, so I expect byte(0) to be 8 not 40...

The size of 8 is an error in the insim documentation.
It's 4 bytes general header, the "Host" byte, 3 spare bytes and then 32 bytes containing the hostname. That's 40 bytes.

Oh dear, my bad!

I spot one mistake just like it and then I miss one altogether! How bizarre.

Thanks GeForz.

Tim

Quote from GeForz :

The size of 8 is an error in the insim documentation.
It's 4 bytes general header, the "Host" byte, 3 spare bytes and then 32 bytes containing the hostname. That's 40 bytes.

Thanks... fixed.

Can PLID be zero? According for example to this in STA packet...

...seems it should not be. But sometimes in single player it's 0 (seems only when starting LFS, if you are already in grid - bug?).

Also something I haven't figured out yet, when using InSim locally in multiplayer mode, how do I know which is "my own car"?

Quote from hackerx :

Can PLID be zero? According for example to this in STA packet...

byte ViewPLID; // Unique ID of viewed player (0 = none)

...seems it should not be. But sometimes in single player it's 0 (seems only when starting LFS, if you are already in grid - bug?).

Yes, bug, now fixed.

Also in that case (entering single player with cars already in race) LFS will now send IS_NPL packets for each player.

Quote from hackerx :

Also something I haven't figured out yet, when using InSim locally in multiplayer mode, how do I know which is "my own car"?

Good point, I've now added a remote flag (bit 2) to the PType member of IS_NPL.