There's a really cool feature I had an idea for - but it seems the dedicated host does not support running an AI so I cant do it - if the AI bits can be #included into the dedicated host that would be cool for what I have in mind... It's really cool btw - did I mention that?

If it's not possible then so be it, no point loosing sleep over, but it would be really cool .

Really cool.

Quote from Becky Rose :

There's a really cool feature I had an idea for - but it seems the dedicated host does not support running an AI so I cant do it - if the AI bits can be #included into the dedicated host that would be cool for what I have in mind... It's really cool btw - did I mention that?

If it's not possible then so be it, no point loosing sleep over, but it would be really cool .

Really cool.

AI driven Safety Car? ;D

DEDI can never run AI... that's why it's *dedicated* because it's dedicated to hosting only. As it would have to run full physics to handle AI cars.

The tracks supplied with the dedi don't even have any track info, they just have the minimum amount of info like start grids and pit starts to stay in sync with the guests.

But you could always run a full host instead of a dedi, if needed, but then it won't be so fast and clean as a dedi.

ok fair enough Scawen, perfectly logical. Never mind.

Quote from Becky Rose :

RST packet:
Finishline, split1, split2, split3 - possibly bugged, returning 65535 for me.

Yes I can confirm this now having tested with a dedicated host. The dedicated host doesn't know where the checkpoints are - this problem arises because of its lack of knowledge about the track surfaces which are used to mark some path nodes as being check points. I see this is also a problem with the race positions. Race positions are not set at all, so position bytes in NLP and MCI are always zero instead of containing useful info.

I've made a note to consider these problems. They only affect InSim and nothing in LFS depended on this info being known to the dedicated host.

Quote from sdether :

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.

Yes that does appear to be the case. Wrote something in Cyrillic and there was an extraneous ^L before the TextStart (as you described) and a ^C after the text start.

So it does appear that at TextStart you can assume you are in Latin-1.

Thanks for the confirmation Scawen, I can work around it. Sincere thanks also for the heads up on the position data as I was about to use it - i'll work around.

Quote from Scawen :

I've made a note to consider these problems. They only affect InSim and nothing in LFS depended on this info being known to the dedicated host.

Great! And I still thought something was wrong with my code http://www.lfsforum.net/showthread.php?t=25572

I have a very small suggestion: could you decrease the minimum car info interval? It seems fairly artificial at the current 100ms, and I need more precision for my purposes (measuring the time gap between cars in real time)

Thank you for all the hard work (specifically InSim ), Scawen!

How about a order packet? Were you can order players via InSim?

like IS_REO?

Quote from Scawen :

like IS_REO?

Word, I need to read the documentation closer.

Quote from InSim.txt :

// IS_REO : REOrder - this packet can be sent in either direction

// LFS sends one at the start of every race or qualifying session, listing the start order

// You can send one to LFS before a race start, to specify the starting order.
// It may be a good idea to avoid conflict by using /start=fixed (LFS setting).
// Alternatively, you can leave the LFS setting, but make sure you send your IS_REO
// AFTER you receive the IS_VTA. LFS does its default grid reordering at the same time
// as it sends the IS_VTA (VoTe Action) and you can override this by sending an IS_REO.

Quote from Becky Rose :

Bug: /pitlane <username> clears the drivers lap count from screen and they appear to no longer register SPX and LAP packets.

I'm just going to have to mark this down as a bug, I can't fix it in this version because it really needs to be fixed on guest side, so that would have to be an official patch.

So for now as you described /pitlane does put them in their pit box but they do not start lap timing again, they are effectively out of the race.

Quote from joshdifabio :

http://www.lfsforum.net/showthread.php?p=443831#post443831

That would be great if it's possible

I've now added handicaps / start position / user name to the MPR header.

Quote from hackerx :

Aha... I wonder if all this is documented somewhere? Maybe I could find some other interesting things in that place also.

I don't think those are documented anywhere, and I don't think there is any documentation other than what you know about, the LFS docs folder and the programmer files at www.lfs.net

Quote from Dygear :

I'm sure I could come up with something that FOM is doing that InSim can't. But I'll wait untill patch Y or Z.

What is FOM ?

What I intend to release tomorrow :

InSim :

Driver model byte added to IS_NPL packet
Added autocross layout information packets
FIX : Dedicated host did not report race positions
FIX : Dedicated host could not fill in Split nodes info

Multiplayer :

Added handicaps / start position / user name to MPR header
FIX : It was possible for any guest to cause a host to crash

Quote from Scawen :

I've now added handicaps / start position / user name to the MPR header.

I love you.

Quote from Scawen :

What I intend to release tomorrow :

InSim :

Driver model byte added to IS_NPL packet
Added autocross layout information packets
FIX : Dedicated host did not report race positions
FIX : Dedicated host could not fill in Split nodes info

Multiplayer :

Added handicaps / start position / user name to MPR header
FIX : It was possible for any guest to cause a host to crash

Thanks a lot Scawen, those additions to the MPR header are great for us .

any idea as of when this is going to be released?

Quote from Scawen :

Posted Yesterday: What I intend to release tomorrow

Quote from Krammeh :

any idea as of when this is going to be released?

Today, most likely.

Yes I plan to release this at about 5 pm BST.
If I've missed something urgent please tell me.

InSim :

Driver model byte added to IS_NPL packet
Minimum MCI / NLP time interval reduced to 50 ms
New packet IS_AXO sent when an autocross object is hit
New packets IS_AXI and IS_AXC report layout information
FIX : Dedicated host could not fill in Split nodes info
FIX : Dedicated host did not report race positions

Multiplayer :

Added handicaps / start position / user name to MPR header
FIX : It was possible for any guest to cause a host to crash

I assume the Model byte in IS_NPL going to take up one of the spares? If not, can we rev the InSim number? Just want to make sure that if packets are incompatible, we can adjust on the fly.

thanks

It's ok, as all the new info uses either spare bytes or new packets, so I'll leave the InSim number the same.

TIP : InSim programs should ignore new packets they don't know about and any spare bytes - that way updates will always be compatible, if not I'll raise the version number.

Quote from Scawen :

It's ok, as all the new info uses either spare bytes or new packets, so I'll leave the InSim number the same.

TIP : InSim programs should ignore new packets they don't know about and any spare bytes - that way updates will always be compatible, if not I'll raise the version number.

Cool. that's what i was hoping. I already deserialize the struct as defined, so all i have to do is expose the spare as an actual value and I ignore (log warnings) about all unknown packets. Thanks!

OK - the update is available in the test patch forum!

http://www.lfsforum.net/showth ... ?goto=newpost&t=26561

Hello Scaven,

I ran into an issue while doing an insim tool I called LFS fast forward.
It uses time step requests to forward a replay to a specified time.

To get to the problem, I quickly explain, how it works:
1. I stop LFS with a time stop request
2. I forward with a time step request
LFS doesn't tell me, when time step is finished, but luckily LFS only queues any further requests until time step is finished (or jinsim does the queueing - not sure). So I can immediately do the following:
3. I send a singlecharacter request with key P to pause the game
4. And I send a time stop request to unfreeze the replay.

Works fine, because 3 and 4 are done after 2 is completed, so the replay is waiting in pause for the user to watch at the correct time stamp.

But if the time step request execution lasts longer than the 70 second time out, there is a problem. Because immediately after time step is finished, LFS kills the connection with the reason time out. So my connection is lost and the user get's a frozen replay, because the steps 3 and 4 are also not processed.

I tested it with Patch W and Patch X, no X test patches yet. But I haven't seen any update notes, which indicate a fix to that problem.

It's not an urgent issue for me (did a workaround) - just wanted you to know.

Thanks & kr
Martin

If LFS is killing the conn, are you sure you are responding to the keep-alive while your program is busy? Or maybe I've misunderstood...

Quote from DarkTimes :

If LFS is killing the conn, are you sure you are responding to the keep-alive while your program is busy? Or maybe I've misunderstood...

Not my prorgram is busy, LFS is. And while it is, it is not reacting to anything I send: neither to responses to keep alive packets (Tiny NONE) nor does it answer my keep alive packets (Tiny PING).