The online racing simulator
InSim changes in new test patch
(236 posts, closed, started )
InSim changes in new test patch
Dear Programmers, as you probably know there is a new test patch coming.

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

Old InSim programs will still work with the new patch, but you can make use of some new functions.

1) Note the Track[6] fields will indicate the new configs like SO1X and FE3Y etc. Those two would indicate an open config using SO Classic Forward start grid / Fern Bay Gold Reversed grid.

2) New collision reporting. Please take a look at this packet specification and have a think about how you would use it, and if it needs any more info :

// CONTACT - reports contacts between two cars
// =======

struct CarContact // Info about one car in a contact - two of these in the IS_CON (below)
{
byte PLID;
byte Info; // like Info byte in CompCar (CCI_BLUE / CCI_YELLOW / CCI_LAG)
byte Sp2;
byte Speed; // m/s

byte Direction; // car's motion if Speed > 0 : 0 = world y direction, 128 = 180 deg
byte Heading; // direction of forward axis : 0 = world y direction, 128 = 180 deg
char AccelF; // m/s^2 longitudinal acceleration (forward positive)
char AccelR; // m/s^2 lateral acceleration (right positive)

short X; // position (1 metre = 16)
short Y; // position (1 metre = 16)
};

struct IS_CON // CONtact - between two cars (A and B are sorted by PLID)
{
byte Size; // 32
byte Type; // ISP_CON
byte ReqI; // 0
byte Zero;

byte Closing; // the closing speed of the collision in m/s (suggests severity)
byte Sp1;
byte Sp2;
byte Sp3;

CarContact A;
CarContact B;
};

3) IS_MTC now can have up to 128 characters (including a zero at the end) in a variable sized packet. You can also specify the sound effect of the message and send a message to all connections with a single call.

struct IS_MTC // Msg To Connection - hosts only - send to a connection / a player / all
{
byte Size; // 8 + TEXT_SIZE (TEXT_SIZE = 4, 8, 12... 128)
byte Type; // ISP_MTC
byte ReqI; // 0
byte Sound; // sound effect (see Message Sounds below)

byte UCID; // connection's unique id (0 = host / 255 = all)
byte PLID; // player's unique id (if zero, use UCID)
byte Sp2;
byte Sp3;

// char Text[TEXT_SIZE]; // up to 128 characters of text - last byte must be zero
};

4) I've had a look at EQ_Worry's suggestions in this post :

http://www.lfsforum.net/showthread.php?p=1337106#post1337106

Particularly suggestion (2) a traction control bit I'd like to include because that is something missing. And I'll have a look at (3). I have not studied them yet so I can't say for sure.

I really must keep any updates to the minimum, because I want to release the test patch as soon as possible so I can get back to the tyre physics. So if you have suggestions, please try to stick to very simple ones and think through how they would work.

Thanks
Fist of all, thanks, Scawen, for all these updates!

I'll need a bit more time to think about the collision packet and usability of the contained info, but at a first sight it looks really interesting! An algorithm reliably detecting the car causing the crash would not be easy to develop, but I think this addition just makes it possible. I'll try to think about it.

The longer messages are a blast! I would be most happy even with 96 bytes, but 128 is just great.

Moving the traction control bit would be good, just as having the car damage info available (points 3 and 4), but I do not see those two as some pressing matters. If they are easy to add, good. If not, maybe rather add some more usable things. And, as I see it, these would be, starting with the most pressing ones:

1) Not really an InSim feature, but what I miss most in the whole LFS is a (simple) admin command to cancel running kick/ban votes, something like /stopvote or whatever. It will not disable voting, it will just cancel the current vote. InSim apps can then apply various criteria, analyze who is voting against whom, and let the vote go or cancel it. BTW there's no InSim info about kick/ban votes, but the necessary data (what kind of vote it is, who votes, etc.) can be parsed from server messages, so it is not really needed.

2) Include into OutSim or maybe rather into OutGauge an additional bit indicating that Ctrl+Shift is pressed on the client. This is used to change some buttons in LFS (nicknames/usernames), it would be great if also local InSim applications could provide this functionality. All that is needed is this one bit.

These two above I'd love to see in addition to the already provided changes, they'd be extremely useful, especially the vote canceling command. Of course there can be a whole bunch of other improvements, currently I see one more as a useful option:

3) Report somewhere, I guess the standard CompCar used in MCI would be good, so that no new special packet is needed, that the car hit a wall or some other object, maybe even other car, in the elapsed period (since previous MCI). I do not know if this is possible though, if the server has such data actually available. But it would be good for detecting completely clean online laps, similar way HLVC does it for offline laps.

That's it from me. Thanks for considering the proposals. And big thanks for already implementing some of them.
One question that immediately jumps to mind:
How will the track nodes work in open configurations? They obviously can't be consecutive anymore when there are multiple routes possible.
There won't be any track nodes I'm afraid... so no yellow / blue flags, no wrong way detection.
It would be good if clutch control changes (axis<->button) were reported every time they changed, like how it is reported whether autoclutch is changed (yes<->no).

If you wish to setup a server prohibiting button clutch, currently anyone can join the track with axis clutch and then change it once they join the track.
Quote from Flame CZE :There won't be any track nodes I'm afraid... so no yellow / blue flags, no wrong way detection.

Are you sure? Scawen has only mentioned no flags/wrong way detection afaik, which doesn't imply there aren't any nodes or similar.

Of course the server itself couldn't have a hope of working out flags or direction, but if there were nodes of some description, an InSim application could potentially do it if it knows the route(s) of the layout.
The PTH files, which contain nodes, have also a direction info. And that's not easy to determine on the open configs.
I was mostly referring to the node values sent via InSim - I'm afraid I'm not too familiar with PTH files.

It would be impossible to work out the correct direction of travel, unless the order of the nodes (not necessarily consecutive or all ascending/in the same order) is given to the InSim application for every given layout/config.
These could probably be cobbled together if there is a choice of route using techniques similar to those mapping software uses to plan travel directions. Flags & direction info could then be calculated by the InSim application. It wouldn't necessarily be easy, but it's certainly doable.


(The above may have come out in a bit of a mess, I'm tired )


Edit: If there isn't a choice of route, it'd be as simple as a lookup table.
how open track works? is it new nodes or only using XY method? afraid to change everything but i like the new packet
Hhhmmm maybe it could be very useful to include the pedal status in CarContact. It's one of the first things people analyze during a crash replay with help of the 'show pedal' bars.

Determining pedal usage is not easy by just looking at pure acceleration (/deceleration) values. Actually I even think it's mandatory information, I can give an extended explanation if needed.

.
#11 - PoVo
Good work!
Quote from boothy :It would be good if clutch control changes (axis<->button) were reported every time they changed, like how it is reported whether autoclutch is changed (yes<->no).

If you wish to setup a server prohibiting button clutch, currently anyone can join the track with axis clutch and then change it once they join the track.

We have managed to block button clutch on our Gen PRO server, the only problem is that we had to force the use of the clutch to do that...so as it is, it is not possible to leave the choice between auto clutch and pedal clutch....So yeah it would be great if we could do both!!
Quote from Framaris :We have managed to block button clutch on our Gen PRO server, the only problem is that we had to force the use of the clutch to do that...so as it is, it is not possible to leave the choice between auto clutch and pedal clutch....So yeah it would be great if we could do both!!

Nah sorry but you haven't managed to block button clutch, just did a lap on your server with it
Tire temperatures in Outgauge would be nice.
Quote from Scawen :Dear Programmers, as you probably know there is a new test patch coming.

2) New collision reporting.

Wow, this, together with the barrier-liftoff-fix makes me want do some Sumo coding again. Now, if we could only get a way to detect when a car is upside down or on the side (angle relative to the track)

Quote from Scawen :Please take a look at this packet specification and have a think about how you would use it, and if it needs any more info

I assume multiple IS_CON packets are guaranteed to be received in correct order? If not, some sort of timestamp would be useful. Actually, when I think about it, that might be useful anyways.

Either way, excellent work. Nice to see our requests are being heard.
The only small suggestion I'd can think of right now is to add a leave reason to the PLL packet, that would inform you whether the player spectated of their own volition, were spectated by an admin, or if they were spectated by the game (e.g. took the wrong route, jumped the start etc..). However adding it to the PLL packet at this stage would be a breaking change, so it would probably have to be done with a new packet if done at all.

Just an aside, recently I noticed a small error in InSim.txt, in the comments for IS_REO. You mention a packet called IS_VTA, but this packet does not exist, it's actually a IS_SMALL with a SubT of SMALL_VTA. Not important but it made me scratch my head for a few seconds the other day.

I think this might be a throw-back to the old version of InSim.

// 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 [B]IS_VTA[/B]. LFS does its default grid reordering at the same time
// as it sends the [B]IS_VTA[/B] (VoTe Action) and you can override this by sending an IS_REO.

#17 - PoVo
Yeah the reason for spectating would be useful. I needed to find a reason for spectating a couple of months ago, but ended up not doing anything at all
Quote from PoVo :Yeah the reason for spectating would be useful. I needed to find a reason for spectating a couple of months ago, but ended up not doing anything at all

Yeah, it's something used a lot in cruise apps I think, as they give out fines to players spectated for various reasons, such as took the wrong route.
Thank you all for the comments. I've been making notes to have a look at what I can do. I don't have any questions yet. I'll let you know here when I make any InSim changes.

Quote from skywatcher122 :how open track works? is it new nodes or only using XY method? afraid to change everything but i like the new packet

There is no path and no nodes, so NLP and MCI packets will contain zero in the Node field.
ok thanks for the reply, can i request about the /msg <messsage> limit increase?
Quote from boothy :It would be good if clutch control changes (axis<->button) were reported every time they changed, like how it is reported whether autoclutch is changed (yes<->no).

If you wish to setup a server prohibiting button clutch, currently anyone can join the track with axis clutch and then change it once they join the track.

That seems to be a bug which I have now fixed. The player flags were not checked for changes when leaving the Controls screen.

I don't know if that affected any other PIF_ flags, but if it did, they should be fixed too.
Quote from skywatcher122 :ok thanks for the reply, can i request about the /msg <messsage> limit increase?

I can't do that very easily while retaining compatibility, because of the packets that are used within LFS.

But, do you really need it? I think the updated MTC packet does anything the /msg can... or not?
Quote from Scawen :I don't know if that affected any other PIF_ flags, but if it did, they should be fixed too.

Good to hear! Is there any chance to get a preview Z29 version for private testing of these things? Well, probably not, but had to ask anyway.
Quote from Scawen :There is no path and no nodes, so NLP and MCI packets will contain zero in the Node field.

So, if I'm using them, my mod won't work correctly on those tracks, yes? Since there will be no nodes.
I should rewrite my code to use X/Y to work correctly everywhere? Or someone has any ideas, maybe?
Quote from EQ Worry :
3) Report somewhere, I guess the standard CompCar used in MCI would be good, so that no new special packet is needed, that the car hit a wall or some other object, maybe even other car, in the elapsed period (since previous MCI). I do not know if this is possible though, if the server has such data actually available. But it would be good for detecting completely clean online laps, similar way HLVC does it for offline laps.

could it be that a new byte for object type would be added in the AXO packet ?
something like this :

// If an autocross object is hit (2 second time penalty) this packet is sent :

struct IS_AXO // AutoX Object
{
byte Size; // 4
byte Type; // ISP_AXO
byte ReqI; // 0
byte PLID; // player's unique id

byte ObjType; // collided object type

};

with an enum that could taken from the LYT file format
Objects indexes allowed by tracks.

* Autocross track :
TYRES (white) : 0
TYRES (red) : 1
post1 : 2
TYRES2 (white) : 3
TYRES2 (red) : 4
TYRES (white) : 19
bale1 : 23
AD_banner1 : 24
Banner_AD2 : 25
Banner_AD3 : 27
CONE red : 29
CONE red3 : 30
...etc

* Blackwood track :
cone1 : 0
cone2 : 1
bale : 3
tyre_white_s2 : 5
tyre_blue : 6
railing : 8

...etc

in case of non AXO object, maybe send an struct IS_CON with a null CarContact B.

Having info on type of object collided would allow insim to know whenever a clipping point (in a drift context) is touched, even if it is surrounded by other layout objects.
I guess some other ideas would pop in people's head.
This thread is closed

InSim changes in new test patch
(236 posts, closed, started )
FGED GREDG RDFGDR GSFDG