InSim changes in new test patch

[Scawen]

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 :)

[EQ Worry]

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. :thumb:

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. :nod:

[Degats]

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.

[Flame CZE]

There won't be any track nodes I'm afraid... so no yellow / blue flags, no wrong way detection.

[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.

[Degats]

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.

[Flame CZE]

The PTH files, which contain nodes, have also a direction info. And that's not easy to determine on the open configs.

[Degats]

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 :p )


Edit: If there isn't a choice of route, it'd be as simple as a lookup table.

[skywatcher122]

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

[cargame.nl]

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.

.

[PoVo]

Good work! :trampolin

[Framaris]

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!!:thumb:

[boothy]

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!!:thumb:

Nah sorry but you haven't managed to block button clutch, just did a lap on your server with it :tilt:

[tmehlinger]

Tire temperatures in Outgauge would be nice. :)

[nikka]

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) :)

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.

[DarkTimes]

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 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.

[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 :x

[DarkTimes]

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 :x

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.

[Scawen]

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.

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.

[skywatcher122]

ok thanks for the reply, can i request about the /msg <messsage> limit increase?

[Scawen]

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.

[Scawen]

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?

[EQ Worry]

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. :shy:

[matrxs]

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?

[fat-oil]

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 (http://en.lfsmanual.net/wiki/File_Formats)
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

...etcin 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.:)

[boothy]

Amp brought this up in here: http://www.lfsforum.net/showthread.php?t=62060

[EQ Worry]

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

I guess that could be handy. My concerns are that: 1) Reporting every contact with every object may sometimes generate high amount of packets/events. 2) Adding a byte to the existing packet creates incompatibilities. But of course, having info about objects touched, even in normal race, would be good.

[fat-oil]

Right.
Another option, instead of modifying AXO packet would be that in the case of object contact
the CarContact B struct could have 0 in its speed field, and the object type in another one.

Regarding number of packets sent, some car crashes will also generate many contacts. So maybe this could be filtered so lfs sends at max like 1 contact event per 1 second per object.

[EQ Worry]

Great ideas! Now I guess we need to see what will make it into Z29. :) As always, many seemingly simple ideas are very hard to convert into code, I'm sure.

[Tur8o]

great ideas! Now i guess we need to see what will make it into z29. :) as always, many seemingly simple ideas are very hard to convert into code, i'm sure.

z30 :)

[EQ Worry]

Right. :)

One minor thing considering InSim versioning. To make use of the new IS_MTC packet possibilities, InSim applications need to know to what kind of server they are connected. Such data are available in the IS_VER packet. But the InSim version contained there in two bytes is not unusable, if it stays at number 4. Would it be possible to increase the InSim version to 5 in this new patch? I know there are no substantial changes, but on the other hand there's no need to keep InSim versions low, is there? (Or maybe use the two bytes for major and minor versioning? But that creates incompatibility.) In any case, parsing the host version from e.g. 0.5Z30 is certainly possible, but not reliable for the future, so raising InSim version would be great... :)

[Scawen]

One question about collisions with objects... I'm not saying I will do it, but I'll look at the code and see if it can be done in under a few hours (it is much simpler than the car collisions because they required an "agreement" system between the two cars that collided).

But the question is, how much info would you really need in that? I wouldn't change the AXO because that is really related to autocross penalties. And I wouldn't use the IS_CON because it is too big and has too much information, specially if I'll be adding some more to it.

But do you need some of that info? For example the CarContact for the car and some more info. Or is the CarContact (12 bytes) already too much information?

struct IS_OBH // OBject Hit
{
byte Size; // 32
byte Type; // ISP_CON
byte ReqI; // 0
byte Zero;

byte ObjectType; // object type (varies between track)
byte ObjectCategory; // tyre / cone / object / segment
byte ObjectInfo; // movable / etc...
byte SurfaceType; // surface type (only segments)

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

CarContact A;
};

[EQ Worry]

Well, that is really a lot of info already. Personally, I would be happy even with something much simpler considering collisions with objects (including walls, that is important for me), just PLID and maybe type of the object. However, I see no problem having more data than necessary. :) I might just note that for the collision with another car the CarContact could really contain pedal info (throttle, brake), as Dave suggested earlier.

[BabyOnWheels]

Hi Scawen,
I know that you don't want to do a big changes, but I would to ask you for one (I hope small).

One year ago I wrote first plugin into CML. And it provides real rallycross.
I switched the start grid order per heat. But I had problems with "odd" (modulo 3) cars count. E.g. for 5 cars I need one free space on the start grid. I "hacked" it with AI-driver. But it has to be added by race admin manually and this is a bit .. uncomfortable.

So I would ask you for possibility to set (via InSIm) empty position on start grid. (E.g. send player ID 0 or 255).

Thanks
Jarda (Baby)
(http://www.lfsforum.net/member.php?u=43)

[EQ Worry]

So I would ask you for possibility to set (via InSIm) empty position on start grid. (E.g. send player ID 0 or 255).

If I understand correctly, then the IS_REO packet should recognize zero PLIDs as empty places on the grid. Then you could make e.g. positions 3 and 4 empty, while 1, 2, 5, 6 etc. are used by the submitted PLIDs... That would be a nice feature too, if possible. :)

PS: Awwww, my 1000th post, and I almost missed it...

[morpha]

OBH looks pretty good, although it might produce a lot of traffic in certain situations, such as a cone killing spree.
Would X and Y be the position the object was placed at? Or the position at the time the OBH is sent? Should be the former.
Some way to determine whether the object was moving (i.e. struck by another car, then propelled toward the current OBH-trigger) at the time of impact would also be nice.

I'd also like to raise something from EQ's InSim Bug Report / Update Request thread: Notification when objects are added, moved (by an admin, not a collision) or deleted; should contain an ObjectID, X/Y/Z coords, Rotation and the UCID of the user responsible for the change of state. Ability to add objects by specifying ObjectType, X/Y/Z and Rotation. If ReqI != 0, a response is sent containing the added object's ObjectID. Ability to move or remove objects using the ObjectID, providing new coordinates and rotation when moving. Ability to instantly reset an object that's been moved by a collision.
Instead of the unique ObjectID, the ObjectType with the X/Y could also work, i.e. to delete, you specify the ObjectType and coords and LFS will remove the object of the specified type closest to the specified coords.

[BabyOnWheels]

If I understand correctly, then the IS_REO packet should recognize zero PLIDs as empty places on the grid. Then you could make e.g. positions 3 and 4 empty, while 1, 2, 5, 6 etc. are used by the submitted PLIDs... That would be a nice feature too, if possible. :)


Yes, that is exactly what I wanted to say ... Thx :)

[cargame.nl]

Regarding number of packets sent, some car crashes will also generate many contacts. So maybe this could be filtered so lfs sends at max like 1 contact event per 1 second per object.
Hmm why?

I'd rather not miss a contact event. Might be an option to send that information by UDP instead of TCP to ease the pressure on the TCP stack but buffering/limiting will result in... Well... Limitations.

UDP can also result in missing information of course but most InSims communicate locally with the LFS server.

[fat-oil]

But do you need some of that info? For example the CarContact for the car and some more info. Or is the CarContact (12 bytes) already too much information?


This IS_OBH struct would be great for sure.
SurfaceType and ObjectInfo are the ones i can't think about being usefull right now.

A nice refinement would be to have this added, like in car contact struct :
byte Closing; // the closing speed of the collision in m/s (suggests severity)

Closing speed would not be car speed even when colliding a non moving object, as a 'fast' car can nudge a cone so it doesnt move much and car speed would be different than 'collision speed'.

edit:
Also, thinking about some precision, could the closing speed unit be changed to cm/s instead of m/s ?
with the current closing speed unit we would not be able to have values under 1m/s
this would limit max closing speed to 2.5 m/s but i would rather have precision downside than upside : with planes anything more than 2 m/s is a quite hard landing.

Lets hope this can be done easily : )

[denis-takumi]

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?

it would be nice if the open configuration to use another method of Nodes, as described by the squares or polygons

like this (bad c++ code)

struct Node
{
int PointCount;
int RoadX[PointCount];
int RoadY[PointCount];
}

struct Path
{
char LFSPTH[6]; // do not read file if no match
byte version; // 0 - do not read file if > 0
byte revision; // 0 - do not read file if > 0
int num_nodes; // number
struct Node Nodes[num_nodes];
};

[Dygear]

it would be nice if the open configuration to use another method of Nodes, as described by the squares or polygons

We already have that information, just parse the pth or smx files.

[PoVo]

Couldn't the Nodes still be used in open configs? Simply by still using them around the track, coverting every single road of the open track.

Even though it would be quite useless, it would save a lot of time for cruise servers, because using the X and Y coordinates, it would be a pain in the butt IMHO. :nod:

[EQ Worry]

Nodes are like little sectors, numbered as incremented integers in the direction of the race path, from start to finish. I have no idea how could you have nodes on an open site where there is no predefined race path at all.

[Degats]

We already have that information, just parse the pth or smx files.

Couldn't the Nodes still be used in open configs? Simply by still using them around the track, coverting every single road of the open track.

Even though it would be quite useless, it would save a lot of time for cruise servers, because using the X and Y coordinates, it would be a pain in the butt IMHO. :nod:

Getting the data from the .pth files and converting to the open configurations is easier said than done
- The nodes are in different places on the same bit of track in the different configurations, due both to the way they were created and the different speeds involved
- There'll be much overlapping/intersecting of nodes where different routes intersect, particularly if there's a choice of route. I assume these overlaps/intersections would cause problems.

Not impossible, but the junctions in particular would be tricky, especially if there's no graphical way of removing/shortening them.


Nodes are like little sectors, numbered as incremented integers in the direction of the race path, from start to finish. I have no idea how could you have nodes on an open site where there is no predefined race path at all.

As I mentioned in an earlier post, you'd have to feed information to the InSim program based on the chosen route and use something like a lookup table to convert the non-sequential nodes to sequential equivalents. The order of the non-sequential nodes would have to be different for each route of course.
Multiple choice routes would probably have to use a combination of the above and algorithms similar to route-finding software like google maps. The route junctions could still be tricky though.

[denis-takumi]

in my programm i use polygon system with funcrion for detect point in this polygon


int polySides = 14;
int polyX[polySides ] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0};
int polyY[polySides ] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0};


bool Check_Pos(int polySides,int polyX[],int polyY[],float x,float y)
{

int i, j=polySides-1 ;
bool oddNodes=false ;

for (i=0; i<polySides; i++)
{
if (polyY[i]<y && polyY[j]>=y
|| polyY[j]<y && polyY[i]>=y)
{
if (polyX[i]+(y-polyY[i])/(polyY[j]-polyY[i])*(polyX[j]-polyX[i])<x)
{
oddNodes=!oddNodes;
}
}
j=i;
}
return oddNodes;
}



to quickly create a polygon i use html+js(create line)+Track.jpg

[PoVo]

in my programm i use polygon system with funcrion for detect point in this polygon



Very good script! Thank you!

Just a question. How can I find the X/Y coordinates from the TIF track files? :shrug:

[Flame CZE]

Very good script! Thank you!

Just a question. How can I find the X/Y coordinates from the TIF track files? :shrug:I think that 1 pixel equals 1 metre.

[avetere]

Although this thread is originally for INSIM, I'd still like to know one thing:

Will this patch affect the current mpr-version (i.e. will other things than track config be altered?)

[hyntty]

collisions with objects...


Any chance to be able to completely remove objects (all of them)? Then you could remove an object that has just been run over instead of it respawning in it's original place.

[Framaris]

Nah sorry but you haven't managed to block button clutch, just did a lap on your server with it :tilt:

Yeah you're were right, I am hating you for the last two days now!:razz:

Let's hope this new patch will allow us to do that!

[Scawen]

Although this thread is originally for INSIM, I'd still like to know one thing:

Will this patch affect the current mpr-version (i.e. will other things than track config be altered?)The MPR should still be exactly the same, other than the config specification.

By the way, if there are any files where "R" would normally indicate "Reversed" then there could be an "X" or "Y" to indicate an open config (as you know already). If there are any files where the byte 1 (not character R) indicates Reversed, then the equivalent bytes for X and Y are 2 and 3.

Any chance to be able to completely remove objects (all of them)? Then you could remove an object that has just been run over instead of it respawning in it's original place.I don't know, yet, about adding and removing objects, though it's on my list to consider it. If I do that function, I think it would only remove objects that have been added, not original objects that are in the default track.

[avetere]

If there are any files where the byte 1 (not character R) indicates Reversed, then the equivalent bytes for X and Y are 2 and 3.

Ooh, nice to know that one, thanks :thumb:

[PoVo]

I think that 1 pixel equals 1 metre.

Can anyone confirm this please? :)

[codehound]

The perpendicular closing speed of the car with the object would be useful for a program idea that I have. We want to assign ballast penalties for out of control driving and this would help especially on the city tracks.

[DarkTimes]

Can anyone confirm this please? :)

Yes each pixel corresponds to one meter. The track environments are 2560 meters square, the same in pixels.

[denis-takumi]

Very good script! Thank you!

Just a question. How can I find the X/Y coordinates from the TIF track files? :shrug:


http://denisbatya.narod2.ru/ <== exsample for SO

i'll use it today to generate streets on cruise with polygons

look sourse code

[DarkKostas]

http://denisbatya.narod2.ru/ <== exsample for SO

i'll use it today to generate streets on cruise with polygons

look sourse code

This one gets Mouse position, so if you keep your mouse stable and scroll up/down/left/right coords will be still the same.

[denis-takumi]

This one gets Mouse position, so if you keep your mouse stable and scroll up/down/left/right coords will be still the same.

i write fats script for firefox and this work right.

if u want to work with it on IE or Safari fix it :tilt:

[DarkKostas]

i write fats script for firefox and this work right.

if u want to work with it on IE or Safari fix it :tilt:

hmm, it was working fine on firefox(bad boy chrome)

[denis-takumi]

i'm begin new thread for this tools.
http://www.lfsforum.net/showthread.php?p=1579556

[boothy]

There is no path and no nodes, so NLP and MCI packets will contain zero in the Node field.

Is this because it is essentially autocross, or because there is no path file to load? Could it not be done so that if for example, a FE4X.pth file exists, it attempts to load that? Just in case someone manages to make one in the future - could the .pth dependant functions (map, racing line, flags, positions, etc) be made to function only if there is a valid .pth file for the track?

[EQ Worry]

Interesting question! But I do not think there can be FE4X.pth covering all FE roads. I would say a PTH file must represent just one path without splits and joins, also with incremented node numbers. So I think there are two questions:

1) Is a PTH file all that the LFS engine needs to assess car positions in race?

2) Is it possible for LFS to load custom PTH files?

Well, overall, I think this is rather complicated, because the same PTH files must be guaranteed to be available on all clients, that is if race positions and flags are not handled only by the server. That would make things much easier, but I do not think that is the case.

[Whiskey]

It would be great if the PTH on open circuits could be downloaded from the host while connecting. Allowing us to do whatever layout we wan (as far as not using the same road twice).

[dj_hitas]

Scawen, would it be hard to report lap or car change via InSim? I mean when an admin changes that.

[sinanju]

.... the same PTH files must be guaranteed to be available on all clients....
Failing a standard PTH file, what about a standard SHIFT-U Layout file, with agreed start/finish line and checkpoint placement.

That way, if you jump from server to server, at least you'll be comparing like for like on lap and split/sector times.

Also, might be better if there was an additional checkpoint included as part of the layout choice, even at the expense of a barrier, tyre or line, as some of the tracks will be lot longer on average, and 4 splits may be better than 3.

[EQ Worry]

Well, the problem is the position of start/finish line + splits in a layout are reported using node numbers. And those X and Y tracks will have no nodes, so almost nothing would be available to InSim applications concerning the actually loaded layout.

There are ways to overcome that limitation, like using a CRC check or something on the layout file, as Dave of CG suggested, or maybe even parsing the LYT file and seeing the X,Y,Z placement of important things, but overall it is not really easy. At least I do not see an easy way.

All current tracks have 3 splits max plus start/finish. LFSW, AIRW and Airio, Lapper (plus maybe other tools) rely on this fact that there can be max. 4 sectors on any track. So again, adding a 4th (or higher) split could do a lot of damage concerning compatibility. :(

[morpha]

Scawen, would it be hard to report lap or car change via InSim? I mean when an admin changes that.

The number of laps is reported via IS_STA, but I don't think there's anything for the cars, aside from reading the hostXXXXXX.txt file. Could be done via a SMALL.

[T3charmy]

Well, the problem is the position of start/finish line + splits in a layout are reported using node numbers. And those X and Y tracks will have no nodes, so almost nothing would be available to InSim applications concerning the actually loaded layout.

There are ways to overcome that limitation, like using a CRC check or something on the layout file, as Dave of CG suggested, or maybe even parsing the LYT file and seeing the X,Y,Z placement of important things, but overall it is not really easy. At least I do not see an easy way.(
wouldnt it be quite simple? get the x,y of one part go over to other side or road, get another x,y.

[Scawen]

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.I'll add this to the CarContact structure. I guess they only need accuracy of 0 to 15 so I could squeeze both into a single byte.

I was considering a "hit point" as well, so you'd know roughly which part of the car took the impact (front, right, etc). Though I guess you can work this out from position and heading so maybe that's not needed. There isn't any space left anyway, if the accelerator / brake byte replaces the one spare byte (Sp2).

I guess the easiest thing would be to leave the CarContact just as it is now but include a single byte pedal status byte instead of Sp2. But that leaves no spare space at all (to add anything later in a compatible way). If we do need any more data in the CarContact, I'm wondering if the AccelF and AccelR are needed - are they actually going to be useful? I guess you can tell if a person was actually turning left on a left bend...

[E.Reiljans]

I'll add this to the CarContact structure. I guess they only need accuracy of 0 to 15 so I could squeeze both into a single byte.How about clutch? Throttle+brake at once heavily depends on clutch position.

[Scawen]

How about clutch? Throttle+brake at once heavily depends on clutch position.I've now added the ThrBrk byte and the CarContact structure is now full. Adding any more data per car will mean the IS_CON has to go up by 8 bytes (4 per CarContact) or we will need to delete something.

I don't know if a programmer can make use of the clutch status as well... or how important that could be when detecting whose fault a collision was. But this packet is nearly final so please do have a final think about that and tell me if I've missed something (I've been very busy this last week on other things so I might have forgotten a point). I'm still considering if a time stamp is needed. I'll have a look at that hit object packet now.

IS_CON as it stands :

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 ThrBrk; // highest 4 bits : throttle / lowest 4 bits : brake (0 to 15)
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;
};

[morpha]

You could add handbrake and clutch as flags in the Info byte, clutch would be disengaged, slipping (some friction, enough to cause heat/wear but not sufficient to move the vehicle / overcome the inertia), gripping (slipping but sufficient friction to move the vehicle) or fully engaged, handbrake could be 0%, 33%, 66% or 100%.

[Scawen]

I don't really want to do that, in case CCI bits are added to CompCar some time in the future.

But to understand why it is important, I'd like to know how someone would use clutch and handbrake information in a collision analysis.

I guess they could be put into one byte, if the lateral and longitudinal accelerations were also put into a single byte, though that would be a bit of a squeeze.

Or of course I could extend those structures by 4 bytes each, leaving a bit of space for the future. Maybe that is the best idea, just in case...

[morpha]

But to understand why it is important, I'd like to know how someone would use clutch and handbrake information in a collision analysis.Well I don't think it's important, but if your analysis takes driver input into consideration at all, it might as well take all available factors into account.

Or of course I could extend those structures by 4 bytes each, leaving a bit of space for the future. Maybe that is the best idea, just in case...Indeed, I'd go with that :thumb:

[Scawen]

OK, here it is, final unless anyone thinks of anything... now CarContact has steer, throttle, brake, clutch, handbrake, gear and IS_CON has a looping time stamp.

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; // spare
char Steer; // front wheel steer in degrees (right positive)

byte ThrBrk; // high 4 bits : throttle / low 4 bits : brake (0 to 15)
byte CluHan; // high 4 bits : clutch / low 4 bits : handbrake (0 to 15)
byte GearSp; // high 4 bits : gear (15=R) / low 4 bits : spare
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; // 40
byte Type; // ISP_CON
byte ReqI; // 0
byte Zero;

byte Closing; // the closing speed of the collision in m/s (suggests severity)
byte Sp1;
word Time; // looping time stamp (hundredths - time since reset - like TINY_GTH)

CarContact A;
CarContact B;
};


Maybe I'll add a switch just like ISF_MCI so connected programs don't receive contact reports unless they ask for them them. Then there isn't really a bandwidth problem.

[cargame.nl]

Looks great!

[fat-oil]

Closing speed could be more efficient use when its unit would be more precise.
With meter/second, we wont know more than :

closing = 1 for >0 - 1.49 m/s (how will it report closing speed if under 0.5m/s ? null ? idk)
closing = 2 for 1.5 - 2.49 m/s
closing = 3 for 2.5 - 3.49 m/s

etc... till 255 m/s, but do i rly need to know car X rammed Y at 255m/s ?

To me a "fast/slow" boolean would be as efficient.
As i consider anything above 2.5 m/s a too hard contact, and as i can have more clues about the intent of faulty car with throttle/brake info, i believe it would open more possibilities of using the closing speed value if it was labelled in a more precise unit like decimeters or centimeters /second, even if it has to be clipped for higher speeds.

[Scawen]

At the moment, if less than 0.5 m/s closing speed, the packet is not sent.

I think high closing speeds are important to know if you think about what wreckers do. But I agree : 255 is not needed.

How about if it would be "closing speed times 2" so values of that byte from 1 to 250 would indicate closing speeds from 0.5 to 125 m/s?

Online testing with Victor we thought that speeds below 2 m/s would probably be ignored, because they were such light touches.

EDIT : One reason for having it a bit coarse was that it naturally provided a cut off point (0.5 m/s) so cars that were just rubbing a bit down the straight wouldn't send several collision packets. To get more accuracy we could possibly use another byte... but I still think a cutoff point is needed because of the possible bandwidth problem, maybe the same old 0.5 m/s....?

[cargame.nl]

Best tested on KY1 I think, with bump drafting.

0.5 m/s sounds low enough to consider it a racing incident if something bad is going to be the result of the contact between the cars.

Most crashes on the licensed environment occur due to not having enough respect for each others speed and braking points. The trigger currently lies on the creation of a yellow flag but often the wrong car gets penalized as well pretty badly. Due to having a not so big active racer pool, multiclass systems are there which doesn't necessarily have to be negative but speed differences and braking points even become a bigger issue. (Some think that having single class will fix a lot of problems automatically, but I do not agree on that, looking at demo XFG/XRG races for example).

Crashes also often occur because of total disrespect of the yellow flag but that is sadly a completely different problem.

---
Wreckers are more a typical demo thing, a classic will be the; 'reverse on track, drive wrong way below 10 m/s (~ ?) to avoid being spectated and take out leader. Such behavior will be easy to detect with this system but the current ongoing race will still be ruined.

Biggest problem on the demo environment is the voteban system which is nice but too basic, not the wreckers. Demo racers are quite good in having an early detection of potential wreckers but vote banning someone off the server on time seems to be difficult. Or worse, a little group starts vote banning of people just to hijack the server. But EQ Worry can comment more about that, running six successful demo servers.

.

[KassadGLA]

I don't really want to do that, in case CCI bits are added to CompCar some time in the future.

But to understand why it is important, I'd like to know how someone would use clutch and handbrake information in a collision analysis.

I guess they could be put into one byte, if the lateral and longitudinal accelerations were also put into a single byte, though that would be a bit of a squeeze.

Or of course I could extend those structures by 4 bytes each, leaving a bit of space for the future. Maybe that is the best idea, just in case...

I think that one big point of recive packets with trottle, brake, clutch, handbrake, steerring,... is that a programmer can do easy a online telemetry program for monitorize a team partner with telemetry like in F1, GT,...
I'm trying to do one and i haven't a lot of info from the packets, maybe looking on the memory of my computer i can extract more data, but i don't know how to "memory hack" or use memory adresses in C# code :shrug:

[EQ Worry]

For me the new packet and structure looks great, but I really cannot say now if they prove to be usable for reliable crasher detection. Unfortunately, lags are always influencing many things. I guess we all know situations when you brake on time, but the car in front of you is obviously pushed and slides away though you never touched it. But you lagged a bit, the server saw you braking 0.5 s later than you really did, and processed the inexistent collision. Now it will send a collision packet with lots of precise data, that are not so precise in fact. And cascading effect is also possible, cars hitting each other as a result of the first small lag.

So, I think it is great to have the car collision packet with some data available. But only practice (months of testing/development) will show what data are actually usable and reliable for whatever crash-detection routines someone develops. Having some spare bytes both in the collision packet and the car structure looks like very good idea to me. Also, I consider the impact speed resolution of 1 m/s as sufficient. Car speed is updated only 2 or 3 times per second on server, so again, it will never be precise and highly reliable factor.

I hope the object collision packet will make it into InSim. That would be nice to have for clean laps detection. Also nice would be to have the InSim version raised to 5 (or whatever), so that InSim libraries can easily detect they can use the collision packets and longer messages etc. And I very very much hope a kind of /stopvote command, canceling the running kick/ban vote, will make it into patch Z30. It is the thing I miss most. And maybe that Ctrl+Shift pressed bit in OutGauge. Sorry for repeating myself and BIG thanks for all this development! :)

[Scawen]

For me the new packet and structure looks great, but I really cannot say now if they prove to be usable for reliable crasher detection. Unfortunately, lags are always influencing many things. I guess we all know situations when you brake on time, but the car in front of you is obviously pushed and slides away though you never touched it. But you lagged a bit, the server saw you braking 0.5 s later than you really did, and processed the inexistent collision. Now it will send a collision packet with lots of precise data, that are not so precise in fact. And cascading effect is also possible, cars hitting each other as a result of the first small lag.I think it is a little better than you imagine. The impact detection is not done on the host, but on the guests. If you crash with a local player (AI) then of course... no problem, the data is accurate, packet is sent to the host. If you crash with a remote player, that info packet is also sent to the host. Plus, the remote player sends a packet to the host. These two packets must be in reasonable agreement, and if so, then they are combined (with some straight copying and some averaging) then output to InSim (on guests and host).

So, most of the data in the packets is in fact quite accurate, having been calculated on the guests. And a crash due to lag that only appears on one computer will not be reported.

I hope the object collision packet will make it into InSim. That would be nice to have for clean laps detection. Also nice would be to have the InSim version raised to 5 (or whatever), so that InSim libraries can easily detect they can use the collision packets and longer messages etc. And I very very much hope a kind of /stopvote command, canceling the running kick/ban vote, will make it into patch Z30. It is the thing I miss most. Sorry for repeating myself and BIG thanks for all this development! :)I have implemented a /cv command for admins or hosts to quickly cancel any running vote. It applies to game votes (end / start / qualify) and system votes (kick / ban). I used a single short command for all types of vote so admins can use it without thinking too hard.

About the InSim version, I could increase it but I have only one concern. But maybe my concern is unfounded... I sometimes imagine that InSim programs will decide not to operate if the version number in increased. So the version number increase would indicate incompatibility. But maybe no-one used the version number in this way, and if so then it is fine to increase the number.

Object collisions I definitely want to do. It's possible that they won't be in the first test patch, as I am trying to release one without delay. But there are always more than one test patch and some things will be added after the first one.

[fat-oil]

At the moment, if less than 0.5 m/s closing speed, the packet is not sent.

I think high closing speeds are important to know if you think about what wreckers do. But I agree : 255 is not needed.

How about if it would be "closing speed times 2" so values of that byte from 1 to 250 would indicate closing speeds from 0.5 to 125 m/s?

Online testing with Victor we thought that speeds below 2 m/s would probably be ignored, because they were such light touches.

EDIT : One reason for having it a bit coarse was that it naturally provided a cut off point (0.5 m/s) so cars that were just rubbing a bit down the straight wouldn't send several collision packets. To get more accuracy we could possibly use another byte... but I still think a cutoff point is needed because of the possible bandwidth problem, maybe the same old 0.5 m/s....?

Nothing would be sent under 0.5m/s sounds weird to me.
An option to limit number of contact packets would be restrict events with some timer so 2 cars wouldnt trigger more than for example 1 event per second. However maybe this approach isnot so easy to implement, compared to a speed cutoff.
From my own insim programing experience, it seems the AXO packet has a nice cutoff system, never flooding the bandwidth, but still reports even the lightest contact. Idk how it works, but it looks efficient.

Sometimes, the cause of an accident can be a driver blocking the way on straights or at braking by changing lane when someone attempts overtake can result in blocking car being pushed by the other one even if the follower keeps his lane (kinda fish tail). I would like those contacts to be reported, but it seems to me most of them are under 2m/s and maybe even under the 0.5m/s cutoff threshold.

I am aware that small refinements are often those which eat much time. and I didnt test online so i wont discuss more over your inputs,
The "closing speed times 2" will still be better precision, and that contact packet still will be a major boost for racing spirit, am confident.

[GeForz]

You could increase the insim version to 4.1 and state, that the minor version may change if non-breaking changes are introduced ;)

[E.Reiljans]

You could increase the insim version to 4.1 and state, that the minor version may change if non-breaking changes are introduced ;)Insim version is a integer.

[EQ Worry]

I think it is a little better than you imagine ... two packets must be in reasonable agreement ... I have implemented a /cv command for admins or hosts ... About the InSim version, I could increase it.

Fantastic about the 2 collision packets sent by clients and combined! Indeed, that is much better than I imagined. Very nice. :)

Also BIG thanks for the /cv command! I can't wait to test it. My only concern is that e.g. ban vote can run together with restart vote, and /cv will cancel both. Quite often there are situations, when only one type of vote needs to be canceled (either ban vote or restart vote) and the other should run. Sometimes I need to cancel restart vote but kick/ban is allowed. Other times kick/ban needs to be canceled, but restart voting should continue.

Concerning InSim version, maybe that Zero byte (4th) in IS_VER could be used for sub-version as eg. InSimSubVer? It was always 0 up until now. It could be 1 for Z30, making this InSim version 4.1, an update of 4.0. But it is a "header" byte, so I'm not sure if that's possible.

Again, thanks for all these explanations. :thumb: The only thing that seems to be a problem to me now is the universal /cv command, which, if I understand it correctly, affects two different and not really related types of voting.

Nothing would be sent under 0.5m/s sounds weird to me.

Maybe the collision packet could still be sent, simply with 0 as the severity (speed)?

[Scawen]

I think I am right to say you can cancel a game vote (restart / end / qualify) with TINY_VTC.

That's what the documentation says, with one error : it says in the enum that it is "info". But the documentation (and apparently the code) say you can cancel a vote with TINY_VTC. So i've changed that "info" to "both ways".

So that means you only need another special command to stop a kick or ban vote. I think /cv is very good for typing, because an admin may want to stop a vote very quickly, without trying to remember one command or another.


EDIT : I've just added /ck to cancel kick. So /cv cancels any vote and /ck cancels a kick (or ban) vote.

[skywatcher122]

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?

[EQ Worry]

Yes, indeed, it is possible to cancel restart/end/qualify vote through InSim, though not immediately (after 1st vote), but only when the vote is really called by the server (more than half the people voted). But that's OK, no problem there. All that's needed, in my view, is the possibility to cancel kick/ban votes, and only those votes. If /ck does that and only that, I'm absolutely happy. :tilt:

[cargame.nl]

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?
:D

Would be insane to tackle the yellow flag ignorance problem but I'm afraid it's too much for now :schwitz:

[EQ Worry]

Having the gear available in MCI would be nice, as there are some cheats giving XFG/XRG a 6th gear. But again, it is best to release the patch as soon as possible and maybe add such suggestions later, if reasonably possible. Just my view though.

[Degats]

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?
Would be a really easy way to detect players using more gears than the car actually has as well ;)

[cargame.nl]

But again, it is best to release the patch as soon as possible
Hmm personally I'm BBQ'ing tonight with a fellow admin. So wouldn't be much of a problem if it's being delayed a bit more haha...

OK, thats a bit selfish :schwitz::smileypul

[Scawen]

...I've decided to use another 4 bits.

Now implemented like this :

word SpClose; // high 4 bits : reserved / low 12 bits : closing speed (10 = 1 m/s)

And they will be sent if the closing speed is above 0.25 m/s - we'll see how that goes.

[morpha]

So just to summarise / clarify, that makes itstruct 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;

word SpClose; // high 4 bits : reserved / low 12 bits : closing speed (10 = 1 m/s)
byte Sp2;
byte Sp3;

CarContact A;
CarContact B;
};

and (for example)inline float closingMs(const word &SpClose)
{
return (SpClose & 4095) / 10.0f;
}

would give us the closing speed as float in m/s.

Correct?

[Scawen]

Yes, that's right.

float closing_speed = (pack->SpClose & 0x0fff) * 0.1f;

You really must do that &0x0fff before multiplying by 0.1f so it's safe if I add some more bits in the future.

I've also increased INSIM_VERSION to 5.

[fat-oil]

Well, this looks ultimate. Bravo :nod:

[Dygear]

It would be nice if the button interface had a hot key mechanism, so you could bind an on screen button to a keyboard button. It would allow for things like a menu system to be used without having to stop playing (mainly for mousers like myself), al la Counter-Stirke.

Source: InGame Menu for Server Plugins (http://developer.valvesoftware.com/wiki/Ingame_menu_for_server_plugins_(CS:S_only)), VGUI Docs (http://developer.valvesoftware.com/wiki/VGUI_Documentation), and Alliedmodders: Menu API (http://wiki.alliedmods.net/Menu_API_(SourceMod))* (If you read nothing else, read the one in bold).

[Mango Juice]

I don't think Scawen is taking requests, you could post that in the improvements forum.

[Dygear]

I don't think Scawen is taking requests, you could post that in the improvements forum.

If you look back in the thread, it seems that he is as long as it's not to hard. I'll suggest it, and he will decide if it get's into the next version or not.

[wsinda]

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?
That would be also great for a project I'm working on.

(Not really relevant for the test patch, but I thought I'd chime in with this request.)

I modified LRA (http://www.lfsforum.net/showthread.php?t=20056), my replay analyser, so that it can grab lap data from InSim. The nice thing about this is that you can then also get laps from multiplayer races (live online races as well as MPR replays). And it saves he hassle of generating a RAF file first, so the drive -> analyse -> improve cycle is much shorter.

I've got it working, but for now it can only read the speed and position of each car. That's a bit thin for an analysis. To be really useful, the lap data should also include the pedals, steer position, and current gear.

[DarkTimes]

If anyone is interested here is a diff of InSim.txt showing all the changes.

@@ -13,18 +13,28 @@
// NOTE : This text file was written with a TAB size equal to 4 spaces.


-// INSIM VERSION NUMBER (updated for version 0.5X)
+// INSIM VERSION NUMBER (updated for version 0.5Z30)
// ====================

-const int INSIM_VERSION = 4;
+const int INSIM_VERSION = 5;


-// CHANGES in version 0.5Z (compatible so no change to INSIM_VERSION)
+// CHANGES
// =======

+// Version 0.5Z (compatible so no change to INSIM_VERSION)
+
// NLP / MCI packets are now output at regular intervals
// CCI_LAG bit added to the CompCar structure

+// Version 0.5Z30 (INSIM_VERSION increased to 5)
+
+// IS_CON (CONtact) reports contact between two cars (if ISF_CON is enabled)
+// IS_MTC (Msg To Connection) now has a variable length (up to 128 characters)
+// IS_MTC can be sent to all (UCID = 255) and sound effect can be specified
+// ISS_SHIFTU_HIGH is no longer used (no distinction between high and low view)
+// FIX : Clutch axis / button was not reported after a change in Controls screen
+

// TYPES : (all multi-byte types are PC style - lowest byte first)
// =====
@@ -108,6 +118,7 @@
#define ISF_MSO_COLS 8 // bit 3 : keep colours in MSO text
#define ISF_NLP 16 // bit 4 : receive NLP packets
#define ISF_MCI 32 // bit 5 : receive MCI packets
+#define ISF_CON 64 // bit 6 : receive CON packets

// In most cases you should not set both ISF_NLP and ISF_MCI flags
// because all IS_NLP information is included in the IS_MCI packet.
@@ -179,6 +190,7 @@
ISP_BTT, // 47 - info : sent after typing into a button
ISP_RIP, // 48 - both ways : replay information packet
ISP_SSH, // 49 - both ways : screenshot
+ ISP_CON, // 50 - info : contact (collision report)
};

enum // the fourth byte of an IS_TINY packet is one of these
@@ -188,7 +200,7 @@
TINY_CLOSE, // 2 - instruction : close insim
TINY_PING, // 3 - ping request : external progam requesting a reply
TINY_REPLY, // 4 - ping reply : reply to a ping request
- TINY_VTC, // 5 - info : vote cancelled
+ TINY_VTC, // 5 - both ways : game vote cancel (info or request)
TINY_SCP, // 6 - info request : send camera pos
TINY_SST, // 7 - info request : send state info
TINY_GTH, // 8 - info request : get time in hundredths (i.e. SMALL_RTP)
@@ -363,8 +375,8 @@
#define ISS_REPLAY 2 // in SPR
#define ISS_PAUSED 4 // paused
#define ISS_SHIFTU 8 // SHIFT+U mode
-#define ISS_SHIFTU_HIGH 16 // HIGH view
-#define ISS_SHIFTU_FOLLOW 32 // following car
+#define ISS_16 16 // UNUSED
+#define ISS_SHIFTU_FOLLOW 32 // FOLLOW view
#define ISS_SHIFTU_NO_OPT 64 // SHIFT+U buttons hidden
#define ISS_SHOW_2D 128 // showing 2d display
#define ISS_FRONT_END 256 // entry screen
@@ -384,7 +396,6 @@

// These states can be set by a special packet :

-// ISS_SHIFTU_FOLLOW - following car
// ISS_SHIFTU_NO_OPT - SHIFT+U buttons hidden
// ISS_SHOW_2D - showing 2d display
// ISS_MPSPEEDUP - multiplayer speedup option
@@ -516,19 +527,19 @@
char Msg[128]; // last byte must be zero
};

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

- byte UCID; // connection's unique id (0 = host)
+ 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 Msg[64]; // last byte must be zero
+// char Text[TEXT_SIZE]; // up to 128 characters of text - last byte must be zero
};

// Message Sounds (for Sound byte)
@@ -1013,8 +1024,8 @@
// 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.
+// AFTER you receive the SMALL_VTA (VoTe Action). LFS does its default grid reordering at
+// the same time as it sends the SMALL_VTA and you can override this by sending an IS_REO.

struct IS_REO // REOrder (when race restarts after qualifying)
{
@@ -1259,7 +1270,7 @@

// To receive IS_NLP or IS_MCI packets at a specified interval :

-// 1) Set the Interval field in the IS_ISI (InSimInit) packet (50, 60, 70... 8000 ms)
+// 1) Set the Interval field in the IS_ISI (InSimInit) packet (40, 50, 60... 8000 ms)
// 2) Set one of the flags ISF_NLP or ISF_MCI in the IS_ISI packet

// If ISF_NLP flag is set, one IS_NLP packet is sent...
@@ -1296,7 +1307,7 @@
int Y; // Y map (65536 = 1 metre)
int Z; // Z alt (65536 = 1 metre)
word Speed; // speed (32768 = 100 m/s)
- word Direction; // direction of car's motion : 0 = world y direction, 32768 = 180 deg
+ word Direction; // car's motion if Speed > 0 : 0 = world y direction, 32768 = 180 deg
word Heading; // direction of forward axis : 0 = world y direction, 32768 = 180 deg
short AngVel; // signed, rate of change of heading : (16384 = 360 deg/s)
};
@@ -1328,7 +1339,46 @@

// ReqI : 0
// SubT : SMALL_NLI (Node Lap Interval)
-// UVal : interval (0 means stop, otherwise time interval : 50, 60, 70... 8000 ms)
+// UVal : interval (0 means stop, otherwise time interval : 40, 50, 60... 8000 ms)
+
+
+// CONTACT - reports contacts between two cars if the closing speed is above 0.25 m/s
+// =======
+
+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; // spare
+ char Steer; // front wheel steer in degrees (right positive)
+
+ byte ThrBrk; // high 4 bits : throttle / low 4 bits : brake (0 to 15)
+ byte CluHan; // high 4 bits : clutch / low 4 bits : handbrake (0 to 15)
+ byte GearSp; // high 4 bits : gear (15=R) / low 4 bits : spare
+ 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; // 40
+ byte Type; // ISP_CON
+ byte ReqI; // 0
+ byte Zero;
+
+ word SpClose; // high 4 bits : reserved / low 12 bits : closing speed (10 = 1 m/s)
+ word Time; // looping time stamp (hundredths - time since reset - like TINY_GTH)
+
+ CarContact A;
+ CarContact B;
+};


// CAR POSITION PACKETS (Initialising OutSim from InSim - See "OutSim" below)
@@ -1387,7 +1437,7 @@
byte ReqI; // 0
byte Zero;

- byte ViewPLID; // UniqueID of player to view
+ byte ViewPLID; // Unique ID of player to view
byte InGameCam; // InGameCam (as reported in StatePack)
byte Sp2;
byte Sp3;
@@ -1421,22 +1471,19 @@

float FOV; // 4-byte float : FOV in degrees

- word Time; // Time to get there (0 means instant + reset)
+ word Time; // Time in ms to get there (0 means instant)
word Flags; // ISS state flags (see below)
};

// The ISS state flags that can be set are :

// ISS_SHIFTU - in SHIFT+U mode
-// ISS_SHIFTU_HIGH - HIGH view
-// ISS_SHIFTU_FOLLOW - following car
+// ISS_SHIFTU_FOLLOW - FOLLOW view
// ISS_VIEW_OVERRIDE - override user view

// On receiving this packet, LFS will set up the camera to match the values in the packet,
// including switching into or out of SHIFT+U mode depending on the ISS_SHIFTU flag.

-// If ISS_SHIFTU is not set, then ViewPLID and InGameCam will be used.
-
// If ISS_VIEW_OVERRIDE is set, the in-car view Heading Pitch and Roll will be taken
// from the values in this packet. Otherwise normal in game control will be used.

@@ -1695,7 +1742,7 @@
// Text in the IS_BTN packet. If the first character of IS_BTN's Text field is zero, LFS will read
// the caption up to the second zero. The visible button text then follows that second zero.

-// Text : 0-65-66-0 would display button text "AB" and no caption
+// Text : 65-66-67-0 would display button text "ABC" and no caption

// Text : 0-65-66-67-0-68-69-70-71-0-0-0 would display button text "DEFG" and caption "ABC"

[Scawen]

Thank you for the feedback so far. :thumbsup:

I'll look at the object / segment hit packet and other things in the next few days. I thought it was better to get that patch out and start the testing, even if another incompatible one may need to be released.

[DarkTimes]

Hi Scawen,

I noticed that the IS_CON packet does not appear to be sent when playing back multiplayer replays from previous versions of LFS. I'm wondering if this is a bug or just a limitation. They seem to be sent fine when running a replay from Z30, but not for replays from, say, Z13. I don't have any old singleplayer replays lying around to check those.

[Scawen]

That's correct. The MPR is just what a remote player would see. The collisions are detected on the guests - which were not sending any collision packets at the time, so there are none in the MPR to be processed.

[DarkTimes]

Ah OK, that's cool.

[Dygear]

That's correct. The MPR is just what a remote player would see. The collisions are detected on the guests - which were not sending any collision packets at the time, so there are none in the MPR to be processed.

So a MPR is basically as the server sees the game? Interesting.

[Scawen]

Moved CamLevel posts to a new thread in this section :
http://www.lfsforum.net/showthread.php?t=74066

[Dygear]

Scawen, can you give us an insim packet that will allow us to color a player's car on the map a certain color.

IS_CMI // Color Map Icon
{
byte Size;
byte Type = IS_CMI;
byte PLID;
byte Color; // RRGGBB, 00 = Off, 01 = Blink, 11 = On;
}
/* Color:
As 00 is off, as 11 is on, and 01 is blink.
000000 = Black
110000 = Red
001100 = Green
111100 = Yellow
000011 = Blue
110011 = Magenta
001111 = Cyan
111111 = White
If you blink 1 color, then it will cycle between the 2 states.
If you blink 2 colors, then it will cycle between the 4 states.
If you blink 3 colors, then it will cycle between the 8 states.
*/

[DarkTimes]

Hey Scawen, you might like to look at this issue with the BTN packet (http://www.lfsforum.net/showthread.php?p=1584607#post1584607).

Basically the BTN Text field does not need a trailing zero unless the TEXT_SIZE is exactly 240 characters. To clarify, if the TEXT_SIZE is a multiple of four but less than 240, say eight or 128, then no null terminator is needed. However if the TEXT_SIZE is exactly 240 characters and there is no trailing zero, then LFS fails to display the button and there is no error message or warning.

Just to note that the new MTC packet always needs a trailing zero, no matter what the TEXT_SIZE is (and warns you if you omit it), so it would seem there is a bug/inconsistency here.

I hope I've explained it clearly. :)

[Scawen]

Thanks for the report - it was definitely a bug. I've fixed the IS_BTN to accept 240 characters without a terminating zero.

http://www.lfsforum.net/showthread.php?p=1584951#post1584951

[NeOn_sp]

I think I have found a bug in SPX.

By definition, on Lap 1 in practise mode, STime and ETime must have 3600000 (1 hour) value.

When you play in a server for more than an hour ( or the game in that server started 1 hour ago), SPX sends instead of that 3600000, the time of the game started.

Replay #2: http://www.mediafire.com/file/cppk3iauf2zay0z/replay2.mpr
Replay #1: http://www.mediafire.com/file/dndo091rk5at7ni/BugInsim.mpr


I don´t know if I´m explaining myself correctly, that´s the replay, and is very easy to reproduce.

Edit: Add replay 2.. Cleaner than first..

[EQ Worry]

The InSim changes so far are great. Thanks! :) I do not have enough data to be sure every new thing works perfectly, but I believe it is OK. I wonder if two more InSim updates can make it into the official patch:

1) Would it be possible to have communication from server InSim to client(s) InSim? Currently, client InSim apps can send info to server InSim app using the /i command. Not ideal, but it works. But as far as I know, server InSim cannot communicate with client InSims. The idea would be to create a new packet type, just for inter-InSim communication, best working both ways, from client to server, and also from server to client, either a specific one (via ConnID), or to all clients. Alternatively, maybe the existing IS_MTC packet could be used, but when the text starts with a special char, it is not displayed on client(s), it can only be captured by client InSim tools.

2) I was mentioning this before already, but I'll try once more, sorry. A bit somewhere in OutGauge, indicating pressed Ctrl+Shift (on clients) would be nice to have for the option to create multi-purpose buttons (showing alternately e.g. nickname/username). Is it too hard/impossible to add this info to OutGauge? Inside the OutGauge packet OG_x seems to be very empty and there's a spare bit also in DL_x. Please, Scawen, I would really appreciate just a short comment on this addition, like will do / maybe / too complicated / useless / not a priority. Thanks. :)

[EQ Worry]

3) Any chance to receive somehow more infos about the currently loaded layout? New race positions while using layouts are great. The open sites with new tracks using layouts are also cool, so layouts are more important now than they used to be, still there is only minimum data reported by LFS about loaded layouts, basically just the number of objects and the layout name. Personally, I'd love to see reported the X/Y positions of the major race elements, specifically split and finish lines. But I realize this cannot be done in a compatible fashion, except by creating a new packet... eh... :(

Sorry about this additional thing, but it would make checking the correct layout so much easier.

[Scawen]

1) Would it be possible to have communication from server InSim to client(s) InSim? Currently, client InSim apps can send info to server InSim app using the /i command. Not ideal, but it works. But as far as I know, server InSim cannot communicate with client InSims. The idea would be to create a new packet type, just for inter-InSim communication, best working both ways, from client to server, and also from server to client, either a specific one (via ConnID), or to all clients. Alternatively, maybe the existing IS_MTC packet could be used, but when the text starts with a special char, it is not displayed on client(s), it can only be captured by client InSim tools.Can you tell me what ideas you have for this? I understand it is quite powerful but I have a couple of concerns.

a) To do anything with this, people must install a client side InSim program. I wouldn't like it if people would need to do that before joining a host, so I'd like to provide enough things on the host side that this is not needed.

b) Security concerns, if LFS's packet system is used for communication between two remote programs, I don't know what implications that might have.

2) I was mentioning this before already, but I'll try once more, sorry. A bit somewhere in OutGauge, indicating pressed Ctrl+Shift (on clients) would be nice to have for the option to create multi-purpose buttons (showing alternately e.g. nickname/username). Is it too hard/impossible to add this info to OutGauge? Inside the OutGauge packet OG_x seems to be very empty and there's a spare bit also in DL_x. Please, Scawen, I would really appreciate just a short comment on this addition, like will do / maybe / too complicated / useless / not a priority. Thanks. :)I don't know but it is on my list to look at it. There doesn't seem to be any space in the OutSimPack and actually that doesn't seem to be a good place for it. To put it in the Flags (OG_x) of OutGaugePack seems quite sensible, because that is partly about user preferences, whereas DL_x is all about dash lights, and CTRL+SHIFT is not a light! :D I guess that separate OG_CTRL and OG_SHIFT bits would be better than a combined one.

3) Any chance to receive somehow more infos about the currently loaded layout? New race positions while using layouts are great. The open sites with new tracks using layouts are also cool, so layouts are more important now than they used to be, still there is only minimum data reported by LFS about loaded layouts, basically just the number of objects and the layout name. Personally, I'd love to see reported the X/Y positions of the major race elements, specifically split and finish lines. But I realize this cannot be done in a compatible fashion, except by creating a new packet... eh... :((OT) I've just done something today that greatly increases the frame rate when there are a lot of autocross objects. Static vertex buffers are now used for them, like the other world objects, so big layouts just don't slow it down like in the current version.

Back on topic, I intend to add InSim packets that can add and remove autocross objects. Each added object would use the 8 byte OBJECT BLOCK from the LYT file : http://www.lfs.net/?page=LYT and I expect these can be put into a variable sized packet.

This seems easy to do because LFS uses that for internal communication anyway. Also you could enable object reporting so that added and deleted objects (and which connection did that) are sent out to InSim. Loaded layout files also uses the multiplayer system so I guess they would appear naturally.

[Whiskey]

@Scawen, I remember someone requested a way of tellig the user to change to another server, and a ok/cancel button.

This would be useful not only for multiclass servers, where they could send you to your allowed server, but also to leagues, if you need to go to a specific server to sing up before you can actually race.

[PoVo]

I have a suggestion for your Scawen.

Would it be possible to add an IP address variable in the IS_NCN packet?

Another goodie would be to add "/ban IP" and "/unban IP" commands. (which isn't that important IMO)

[morpha]

Can you tell me what ideas you have for this? I understand it is quite powerful but I have a couple of concerns.

a) To do anything with this, people must install a client side InSim program. I wouldn't like it if people would need to do that before joining a host, so I'd like to provide enough things on the host side that this is not needed.Valid concern, it could end up causing a lot of ... let's call it "perceived incompatibility". On the other hand, if anyone really wanted to exclude people who don't have a specific local InSim application running, they could already do so by (visibly, i.e. MTC) initiating a handshake, expecting a reply via /i.

b) Security concerns, if LFS's packet system is used for communication between two remote programs, I don't know what implications that might have.Ha! LFS suddenly becomes Live FileSharing :razz: Seriously though, I don't think there's much room for abuse if the packet for this carries a max payload of ~128 bytes and the client is asked whether or not to allow communication with the local InSim application(s).

Back on topic, I intend to add InSim packets that can add and remove autocross objects. Each added object would use the 8 byte OBJECT BLOCK from the LYT file : http://www.lfs.net/?page=LYT and I expect these can be put into a variable sized packet.

This seems easy to do because LFS uses that for internal communication anyway. Also you could enable object reporting so that added and deleted objects (and which connection did that) are sent out to InSim. Loaded layout files also uses the multiplayer system so I guess they would appear naturally.

:lovies3d:

[EQ Worry]

Can you tell me what ideas you have for this? I understand it is quite powerful but I have a couple of concerns.

Well, my idea was not to exclude people without a certain client InSim program, rather to supply information to such clients, if they're in use, that extend what LFS itself can provide. Specifically, I'm now working on a support for certain "half-official" layouts on the open tracks, creating PTH files with nodes that allow for path checks and also more precise (continuous) race position reporting. This is all done in an application connected to server (Airio) and I though that the results could be sent to client InSims (Aonio) saying like: It is this special track (A21 instead of AS2X_layout, K32 instead of KY3_layout) and the current positions are these (PID bytes). Finding car nodes and the resulting positions are relatively expensive operations, so sharing the results would be really advantageous. I am not sure if this could be misused, because it is like a message sent to clients (specific or all), just hidden.

I don't know but it is on my list to look at it. ... I guess that separate OG_CTRL and OG_SHIFT bits would be better than a combined one.

That sounds really great! I hope it is not too complicated. :)

... I intend to add InSim packets that can add and remove autocross objects. ... Loaded layout files also uses the multiplayer system so I guess they would appear naturally.

Does it mean that when a layout is loaded, all its objects will be reported? Uhmm, that could be quite a few packets. Supposing there can be 16 objects per packet it may mean 40 packets for extensive layouts... Of course, it would be great to have all this info! :)

[T3charmy]

I have a suggestion for your Scawen.

Would it be possible to add an IP address variable in the IS_NCN packet?

Another goodie would be to add "/ban IP" and "/unban IP" commands. (which isn't that important IMO)

i would have to agree, I personally, have been trying to code something like this for the longest time... but being i had no access i couldn't do anything :/


Scawen, can you give us an insim packet that will allow us to color a player's car on the map a certain color.

IS_CMI // Color Map Icon
{
byte Size;
byte Type = IS_CMI;
byte PLID;
byte Color; // RRGGBB, 00 = Off, 01 = Blink, 11 = On;
}
/* Color:
As 00 is off, as 11 is on, and 01 is blink.
000000 = Black
110000 = Red
001100 = Green
111100 = Yellow
000011 = Blue
110011 = Magenta
001111 = Cyan
111111 = White
If you blink 1 color, then it will cycle between the 2 states.
If you blink 2 colors, then it will cycle between the 4 states.
If you blink 3 colors, then it will cycle between the 8 states.
*/
That would be cool too, great for cruising :D

I can see it now, cops blink blue/red, robbers, black, citizens orange i guess?

[EQ Worry]

Would it be possible to add an IP address variable in the IS_NCN packet? Another goodie would be to add "/ban IP" and "/unban IP" commands. (which isn't that important IMO)

In my experience, banning by IP has all the negatives. 1) In many cases it hits completely innocent people that just happen to share a provider. 2) In as many cases it doesn't block the troublemaker, because he's able to use another IP.

So, having IP in NCP packet would be nice (currently I'm grabbing it from the server log file, which is not 100% reliable), but banning by IP is really dangerous.

[PoVo]

In my experience, banning by IP has all the negatives. 1) In many cases it hits completely innocent people that just happen to share a provider. 2) In as many cases it doesn't block the troublemaker, because he's able to use another IP.

So, having IP in NCP packet would be nice (currently I'm grabbing it from the server log file, which is not 100% reliable), but banning by IP is really dangerous.

How exactly do you get it from the server log? I've tried many times with no success :(

[cargame.nl]

Well dangerous is not the right word but it's completely unnecessary as far as I see for LFS. It takes way too much time even for a demo'er to keep registering accounts.

But having an IP address available is useful to do connection measurements and be able to determine country location.

Together with server redirection (suggested by someone else) it reaalllllyyyy gets interesting. People from AUS/US tend to connect to the busiest server which is all nice but in my case its based in Paris while I have another one in Los Angeles and Chicago but it's impossible to promote those without good IP address recognition and redirection.

Actually I'm almost sure it would boost global LFS usage a bit more if it's better balanced out because people from AUS and the West Coast of the US are causing for the biggest trouble without knowing it (very high lag) and get banned often without knowing why. Or they even think everyone is crashing them instead of the other way around.

Anyway, long story short... It are powerful tools, which, used in a good way, improve a lot.

[EQ Worry]

How exactly do you get it from the server log? I've tried many times with no success :(

The condition is the InSim app must be running locally to server, on the same machine. Then you can add a "watch" on the server log changes, being notified about updates of a certain file, the server log. And then you can parse the updates, looking for "Connect" and grabbing the following IP address, assigning it to the new connection. Well, it is complicated, the info is already available, but of course having it as 4 bytes in the new connection packet would be most handy. I use the IP info for DNS lookup of the domain name, often getting the country of origin.

[Rhama]

I once hosted a demo drift server for 2+ years.
I used IP ban several times, once even IP banned a whole provider 'IP mask' because of dynamic IPs.
Some people are not afraid of creating a new account everyday for monthes.

Anyway this is a demo related problem, so why care if only demoers get the benefit of it, and when it actually may impulse some people to buy s1 or s2 to keep away from the permanent offense wich plagues most demo servers. (offense happens at same rate in s2 servers, but there, banned people usually dont spend 30$ for a new license every day)



...
b) Security concerns, if LFS's packet system is used for communication between two remote programs, I don't know what implications that might have.
...

Regarding the server/client insim communication, a security issue popped in my mind as this would allow the account password info to be retrieved from client process memory (not even writing about other non LFS sensitive data), as it is : uncrypted, and sent back to host.

To me, the content of these packets shouldnt be modifiable by the client nor the server insim, they should be read only and their content generated by the lfs process. Sealed. edit: and then it may look quite a useless feature

Anyway, encrypting the account password may be a good move still.

[morpha]

Rhama, the situation you describe still requires the user to install a local InSim application. Now why would anyone with malicious intent bother to transmit the info via LFS when he can spread an application capable of doing virtually anything he desires?

There is no security issue with allowing bi-directional hidden communication, the issue is always the client-side InSim application itself.

[Rhama]

Sure I agree morpha, the intents can be wrong, not the tools,
Cient/server insim coms would just make things easier to me, everything is ready for coding, only have to know how read memory and send insim packets and voilà, and to me make sensitive data a little more stealth is as easy.
Well, maybe I get too much alarmed about it, idk.

[E.Reiljans]

Rhama, any data can be sent from client to server by using /i command even in current patch. What was suggested is server->client communication.

[Scawen]

Finding car nodes and the resulting positions are relatively expensive operationsThis shouldn't be too expensive, if you only do the full "search for node" on each car at the start of the race or when they leave the pits. Then each time you receive an MCI you only have to check each car's position against the direction and position of the next and previous nodes to see if their line has been crossed. All LFS guests and hosts do it with minimal CPU usage.

Something like this I guess.

int next_node_index = (car->current_node + 1) % num_nodes;
PathNode *next_node = Nodes + next_node_index;

Vector2d rel_pos = car->pos - next_node->pos;
if (dot_product(rel_pos, next_node->dir) > 0.0f) // crossed the next node
{
car->current_node = next_node_index;
}
else // didn't cross the next node - check previous node
{
PathNode *prev_node = Nodes + car->current_node;

rel_pos = car->pos - prev_node->pos;
if (dot_product(rel_pos, prev_node->dir) < 0.0f)
{
if (car->current_node)
{
car->current_node--;
}
else
{
car->current_node = num_nodes - 1;
}
}
}
One thing about LFS is you can just install the software and you can go and join any host you see in your list. It's a pity if you don't get the full experience without installing some extra software. We'll start to lose something if LFS isn't so easy to use and people need to figure out how to install InSim programs and find out how to connect them.

[NeOn_sp]

Scawen, anything about what I posted on #112 (http://www.lfsforum.net/showthread.php?p=1586018#post1586018)?

[Dygear]

Rhama, the situation you describe still requires the user to install a local InSim application. Now why would anyone with malicious intent bother to transmit the info via LFS when he can spread an application capable of doing virtually anything he desires?

There is no security issue with allowing bi-directional hidden communication, the issue is always the client-side InSim application itself.

It can happen to anyone (http://forums.alliedmods.net/showthread.php?t=66326) when you trust someone that you should not. It's also the nature of compiled languages, you just don't know what's running on your system.

[EQ Worry]

This shouldn't be too expensive, if you only do the full "search for node" on each car at the start of the race or when they leave the pits. Then each time you receive an MCI you only have to check each car's position against the direction and position of the next and previous nodes to see if their line has been crossed. All LFS guests and hosts do it with minimal CPU usage.

Indeed, I do it in a similar way, full node search done just once, then expecting the car to be in the same node, or one or two nodes ahead or one or two back. Only if all these fail, full search is done again.

But still, I would see a great advantage in doing all this node checks and position calculations at the server, sending only results to client InSims. If all clients were to do this, they would all have to include the current custom PTH files and all the code of these calculations, which seems an overkill to me.

Also, for users that would just complicate matters, because if new PTH files are available, they'd need to install them. Having a way to send race position PIDs to clients seems to me as a very nice shortcut. Most clients would ignore such data, some may process it in local InSims.

One thing about LFS is you can just install the software and you can go and join any host you see in your list. It's a pity if you don't get the full experience without installing some extra software. We'll start to lose something if LFS isn't so easy to use and people need to figure out how to install InSim programs and find out how to connect them.

I completely agree, I would never require the use of a certain client InSim, I know it can be too complicated for many to set it all up properly, even though it may take setting up just 2 or 3 parameters.

I remember that "unnamed" matter, people being kicked by Airio just because they had no nickname. I changed this long time ago, so that now unnamed people just cannot join the race (if admins choose so) and they see messages both in chat and using BIG buttons what should they do to rename.

On the other hand, there's the question of "full experience". For example Aonio, the client-side InSim I'm developing, offers a lot of additional data, like position list with live time differences and their tendencies on splits, car types, penalties, pit stops, correct race positions on multiclass servers, live time/speed comparison with a PB lap, min/max speeds in configurable sections, even a not-so-realistic-but-very-useful radar display showing car locations around/behind you, etc.

For me, full experience from LFS includes all such data, with customizable display and positions on screen, local PBs, remaining fuel laps estimate... Receiving additional data processed at the server (Airio) can make some things more precise. E.g. the race positions can be for Aonio users connected to Airio managed server more precise and updated say every second or two, not just at splits. Also, receiving info about the fact that this is a special half-official track (certain open site + specific layout) makes managing local PBs simple. New layouts are loaded at server, new tracks defined in Airio, clients just receive all the updated info.

Ouch, sorry for these lengthy explanations. :schwitz: In short, ability of client InSims to receive additional info from server InSims can have its uses, I think. I do not see security problems (though I may be short-sighted), as there are already ways to send infos both ways, just not invisibly from server to clients. On the other hand I perfectly understand your concerns. Airio is a large system and quite wide-spread now. It manages many servers in ways that maybe were not your intentions. But I would still hope it is overall perceived as a good thing, especially for the demo servers which are extremely hard/impossible to manage using standard LFS options alone.

[Scawen]

Just a quick note about a small change.

In Z32, which I am still aiming to release today, I have changed the meaning of the /cv command.

I realised that there was still no way of removing all game votes, until the vote was activated (majority reached).
So I've made that /cv remove all game votes even if not yet activated - but not affecting the kick / ban vote.

So the two are now separated :

/ck - no change - cancels kick / ban vote
/cv - remove any game votes (restart / end / qualify)

[EQ Worry]

Aaahh, very nice, thanks! :) Yes, indeed, even the vote canceling packet worked (works?) only after majority was reached, that means in the 3 seconds after restart/qualify/end countdown actually starts.

[Scawen]

Aaahh, very nice, thanks! :) Yes, indeed, even the vote canceling packet worked (works?) only after majority was reached, that means in the 3 seconds after restart/qualify/end countdown actually starts.Now you said that, I've made IS_VTC do the same thing now as well.

[Scawen]

One more small thing I might as well tell you in advance.

There's also one new "Timing" byte in the IS_RST packet :

struct IS_RST // Race STart
{
byte Size; // 28
byte Type; // ISP_RST
byte ReqI; // 0 unless this is a reply to an TINY_RST request
byte Zero;

byte RaceLaps; // 0 if qualifying
byte QualMins; // 0 if race
byte NumP; // number of players in race
byte Timing; // lap timing (see below)

char Track[6]; // short track name
byte Weather;
byte Wind;

word Flags; // race flags (must pit, can reset, etc - see below)
word NumNodes; // total number of nodes in the path
word Finish; // node index - finish line
word Split1; // node index - split 1
word Split2; // node index - split 2
word Split3; // node index - split 3
};

// Lap timing info (for Timing byte)

// bits 6 and 7 (Timing & 0xc0) :

// 0x40 : standard timing
// 0x80 : custom timing
// 0xc0 : no lap timing

// bits 0 and 1 (Timing & 0x03) : number of checkpoints if lap timing is enabled

I added this when I did a similar thing for the LFS World equivalent.

[EQ Worry]

Uhm, I'm not sure what these timing options mean. :shrug: Anyone please point me somewhere where I could learn more? (How to choose timing, what could it be used for...) Thanks! :)

[Scawen]

They aren't really options, it's just information sent when the race restarts.

standard timing : an official LFS track
custom timing : user placed checkpoints
no timing : car park / X / Y with no timing

I think it could be helpful for some InSim programs to know how many checkpoints there are and if lap timing is enabled.

[EQ Worry]

Understood now, thank you! Also thanks for some of the InSim changes, the OG_CTRL and OG_SHIFT bits. :)

[misiek08]

Can z33 have adding/moving/removing objects via InSim, please? That will be awesome and will give you some time to make new physics, Rockingham, Scirocoo while we will be making new type of cruise and drift servers.

[Dygear]

Understood now, thank you! Also thanks for some of the InSim changes, the OG_CTRL and OG_SHIFT bits. :)

Thank you for asking the question, I was thinking I was being some what dense yesterday when I read that and just did not understand it at all.

[kutu]

Can anyone explain to me, why lfs ignore FOV value in IS_CPP packet with inGameCam = VIEW_CUSTOM and flags = VIEW_OVERRIDE (worked only in SHIFTU mode), its a bug or feature?

If it normally, maybe add Note in InSim.txt

ps test in z28 version

[EQ Worry]

Anyone noticed that there are some LFSW messages in Z32 open tracks? It is really strange and confusing, because I make like 10 laps on some layout (say F11) and then suddenly I see "LFSW - this was your first lap...", next lap shows "LFSW - new PB by ...", but /w pb returns something like "LFSW - PBs are not stored for open tracks". What am I missing? Is that a LFSW bug or how/where can it store open track data? Any ideas?

I can see only one explanation: It is somehow (maybe unintentionally) storing lap times for e.g. FE1X+XFG, any layout. Then it reports all lap time improvements, again without distinguishing between layouts. If that's really the case, then I believe the LFSW messages should not be shown at all because they have zero value. Maybe if Scawen or Victor read this, can you please confirm my assumption? (I was already mentioning this in the main Z32 thread, without response.)

[Victor]

those pb's shouldn't be stored then, no. I'll have a look why apparently they are.

[EQ Worry]

:thumbsup:

[Scawen]

I think I have found a bug in SPX.

By definition, on Lap 1 in practise mode, STime and ETime must have 3600000 (1 hour) value.

When you play in a server for more than an hour ( or the game in that server started 1 hour ago), SPX sends instead of that 3600000, the time of the game started.

Replay #2: http://www.mediafire.com/file/cppk3iauf2zay0z/replay2.mpr
Replay #1: http://www.mediafire.com/file/dndo091rk5at7ni/BugInsim.mpr

...

Edit: Add replay 2.. Cleaner than first..OK, I see why this happens. If it's the first lap in practice or qualifying mode LFS just makes sure that split (or lap) times are one hour or more when it sends the packet. This indicates to the packet receive function not to display split times, lap time, or record a qualifying lap in this case, where the time is really invalid. It does allow the split or lap to be greater than one hour - I think the idea is so that it only makes the split or lap time longer than it really is, and never shorter.

It doesn't really seem to be a bug. Does it cause a problem? I guess it depends what you are trying to do. LFS just isn't really interested in split or lap times longer than an hour, so that's why it uses this method to indicate that it shouldn't do anything with this information.

Can anyone explain to me, why lfs ignore FOV value in IS_CPP packet with inGameCam = VIEW_CUSTOM and flags = VIEW_OVERRIDE (worked only in SHIFTU mode), its a bug or feature?

If it normally, maybe add Note in InSim.txt

ps test in z28 versionYes, this appears to be normal, the FOV is ignored in this case. The documentation only says that Heading Pitch and Roll will be taken from this packet (if ISS_VIEW_OVERRIDE is set). I've now added a note in InSim.txt to make it clear that the FOV will not be used.

[MadCatX]

I'm sorry for bringing this up this late, but could I make a small request regarding OutGauge? Would it be possible to use the last spare byte to send PLID of the car whose telemetry is contained in the packet? Recording live telemetry is kind of impossible if player switches view to another car.
I can't rely on ViewPLID in STA packets because there's no way to ensure they always arrive before OutGauge packets when player switches view.

[NeOn_sp]

OK, I see why this happens. If it's the first lap in practice or qualifying mode LFS just makes sure that split (or lap) times are one hour or more when it sends the packet. This indicates to the packet receive function not to display split times, lap time, or record a qualifying lap in this case, where the time is really invalid. It does allow the split or lap to be greater than one hour - I think the idea is so that it only makes the split or lap time longer than it really is, and never shorter.


The problem is that I though that I should be always 1 hour, exactly 1 hour.

So, in my League Qual InSim, I was comparing SPX with 1 hour to know if it´s in warm up lap, and don´t store splits then.

But no problem then, I have changed the comparation to >= 1 hour and ended.

Thanks for reply.

[EQ Worry]

Scawen, first, BIG thanks for all the already implemented new features! Marvelous stuff. :) Here I dare to mention three more things, maybe not exactly InSim matters, but closely related, I hope:

1) One thing that, well, annoys me quite a bit is that the char "1" is narrower than all the other numbers. This is very unusual, because most fonts keep all the numbers of the same width, for easy aligning. Now if there's a LFS button showing fast changing numbers, the numbers tend to jump around instead of keeping their places. Is there please any chance to make the char 1 the same width as the other numbers?

2) LFS clients support at least 2 more colors that cannot be used by InSim apps, dark gray (when someone disconnects), and light red (when someone is banned). Is there any chance to make these colors (plus possible additional ones) available? I think somebody already asked for this, but I'm not sure if there was any answer.

3) Below the race control message area on screen there seems to be a smaller (and not much used) space for additional info. It displays info e.g. at the race start when pit stop is required. Could this line become available for changes/display, probably using some new commands similar to the RCM ones?

Scawen, of course none of the above is anything major, but if they seem reasonable (especially point 1) and correction/addition is possible and simple, maybe they could be part of some patch.

And how about that server to client (and vice versa) hidden communication, is it still considered a security issue or do you plan to add this in the future? Just so that I know which way to go concerning Airio/Aonio information exchange. :) Thanks again for all the work and answers!

PS: There is also light blue color when someone is connecting and light orange when showing race results... :)

[Dygear]

I would love a whole patch update process for just InSim requests, I think what the 3rd party devs could add to the community could be huge.

[Scawen]

I'm sorry for bringing this up this late, but could I make a small request regarding OutGauge? Would it be possible to use the last spare byte to send PLID of the car whose telemetry is contained in the packet?OK, I have changed OutGauge SpareB to PLID.

1) One thing that, well, annoys me quite a bit is that the char "1" is narrower than all the other numbers. This is very unusual, because most fonts keep all the numbers of the same width, for easy aligning. Now if there's a LFS button showing fast changing numbers, the numbers tend to jump around instead of keeping their places. Is there please any chance to make the char 1 the same width as the other numbers?OK, I've done that now and it will be in the next test patch.

2) LFS clients support at least 2 more colors that cannot be used by InSim apps, dark gray (when someone disconnects), and light red (when someone is banned). Is there any chance to make these colors (plus possible additional ones) available? I think somebody already asked for this, but I'm not sure if there was any answer.

3) Below the race control message area on screen there seems to be a smaller (and not much used) space for additional info. It displays info e.g. at the race start when pit stop is required. Could this line become available for changes/display, probably using some new commands similar to the RCM ones?I don't know yet, I can't really think of these as a high priority at the moment with a lot of other things on my list.

And how about that server to client (and vice versa) hidden communication, is it still considered a security issue or do you plan to add this in the future? Just so that I know which way to go concerning Airio/Aonio information exchange. :) Thanks again for all the work and answers!I still don't have a very good feeling about this. I don't get excited about it and I do feel negative about it.

I think if I have to do this, then InSim has failed in its mission. The idea is that a user can install LFS, with no additional software, go online and join the hosts that are out there. They should be able to get the full experience, same as anyone else, without installing anything else. I do not want to make it harder for them.

I do want to provide the packets you need to do what you have to do from a host controller only. I realise that this takes time because I have to do a lot of other things.

I would prefer in each case to understand the problem you are having, the thing you are trying to implement, which cannot be done from the host side, then I can code a new packet to allow your planned feature and more.

[Scawen]

There was a problem with demo racers joining "demo" hosts which had previously allowed non-demo cars and then demo racers getting an OOS kick, unless of course they had cracked the game, in which case they did not get an OOS kick, so I had to make a change today. Now, when the allowed cars are changed with the /cars command, anyone who is driving a disallowed car will be instantly spectated.

I realised that could sometimes cause a problem, if for example a host only allowed formula cars but occasionally swtched temporarily to allow a safety car to join.

So I thought I'd better quickly implement an old request which is to be able to specify which cars an individual player can drive. So here's the new packet, in case you have any comments about it. This does not allow anyone to drive any cars that aren't actually allowed on the host, but it can limit their selection within the allowed cars.

// ALLOWED CARS
// ============

// You can send a packet to limit the cars that can be used by a given connection

struct IS_PLC // PLayer Cars
{
byte Size; // 12
byte Type; // ISP_PLC
byte ReqI; // 0
byte Zero;

byte UCID; // connection's unique id
byte Sp1;
byte Sp2;
byte Sp3;

unsigned Cars; // allowed cars - see below
};

// XF GTI - 1
// XR GT - 2
// XR GT TURBO - 4
// RB4 GT - 8
// FXO TURBO - 0x10
// LX4 - 0x20
// LX6 - 0x40
// MRT5 - 0x80
// UF 1000 - 0x100
// RACEABOUT - 0x200
// FZ50 - 0x400
// FORMULA XR - 0x800
// XF GTR - 0x1000
// UF GTR - 0x2000
// FORMULA V8 - 0x4000
// FXO GTR - 0x8000
// XR GTR - 0x10000
// FZ50 GTR - 0x20000
// BMW SAUBER F1.06 - 0x40000
// FORMULA BMW FB02 - 0x80000


P.S. Is there any way to specify TAB size in CODE blocks?

[Flame CZE]

I like the new packet, it can be very useful in leagues with safety cars, indeed. Thanks!

And by the way, I think there is no way how to adjust the tab size via HTML or CSS, the only solution I think of is to use spaces instead :shrug:

[Scawen]

I like the new packet, it can be very useful in leagues with safety cars, indeed. Thanks!What you would have to do is, with the /cars command, allow the cars that are allowed in the race, PLUS the safety car. Then send an IS_PLC with the allowed cars, excluding the safety car, to each of the racers. Once is enough, when they join the host.

[morpha]

Couldn't you just set /cars to the race cars and then use PLC to allow the safety car for just the safety car driver?

[boothy]

I doubt it would affect races with safety cars, normally you just do /cars=GTR+FZ5+RB4 and obviously racers use the GTRs and admins the other ones when needed. And anyway, you'd need to develop/update insim applications to make use of it.

Will be useful if you do some stuff on a public server with all cars enabled, someone joins in a bad choice of car and you can spec them easier. :p

[Scawen]

Couldn't you just set /cars to the race cars and then use PLC to allow the safety car for just the safety car driver?No, it doesn't work that way.

IS_PLC only allows players to use a subset of the actual allowed cars, it doesn't allow them to use cars which are not allowed on the host.

[morpha]

But to the players with just a subset allowed, only the ones they're actually allowed to drive would show up coloured in the car selection screen, right?

[EQ Worry]

OK, I've done that now and it will be in the next test patch.

This concerned char "1" width, thanks! :) Indeed, the other things (colors) are of low priority. I also accept that you do not have a good feeling about sending hidden info to clients, so I'll do what I can using the existing packets (well, sending visible info for now). The new packet of allowed cars per connection looks indeed promising. I guess it will be very handy for all the multiclass and cruising servers... Too bad it means more work for me and others. Hehe, well, thats when we require something and then we get it. :thumb: Thanks again.

[Scawen]

But to the players with just a subset allowed, only the ones they're actually allowed to drive would show up coloured in the car selection screen, right?Yes, that's right. It affects the car selection screen, the /car command and the check when you try to join a race.

I've seen racing hosts with a progression system and cruise servers where the host does know what you are allowed to drive (a subset of the actual cars that are allowed on the host). But the way it has always been enforced is by spectating you immediately after you join with a car you are not allowed. Now with this new InSim command it can work cleanly, appearing just like the "real" allowed cars system.

[Whiskey]

Actually if you are in a server and you do a take over with a driver driving a car you are not allowed to drive, the InSim won't spec you (probably because they don't want to).
With the new system will LFS spec you if you take a car you are prohibited to use?

[denis-takumi]

P.S. Is there any way to specify TAB size in CODE blocks?


Settings ==> Editor ==> General Settings ==> Tab options

[GeForz]

Yes, that's right. It affects the car selection screen, the /car command and the check when you try to join a race.

I've seen racing hosts with a progression system and cruise servers where the host does know what you are allowed to drive (a subset of the actual cars that are allowed on the host). But the way it has always been enforced is by spectating you immediately after you join with a car you are not allowed. Now with this new InSim command it can work cleanly, appearing just like the "real" allowed cars system.

Jeah thats really annoying in cargame.nl Server when you have no clue which car to drive and get specced always. Very nice addition although i don't see the reason why aa league which is organized enough to have a safety car would need to restrict the cars ;)

[Flame CZE]

Ah yes, you are right, it does not have to be necessary when using a safety car in leagues as long as it's administrated, therefore anyone who would take the safety car would be penalised (why would he even do that anyway), now I see it is more likely to be used in public multiclass racing, that's actually a good idea. I have seen many newcomers in those servers who took a car they are not allowed to drive and despite they saw the message, they disconnected. Now with the new packet system, it can attract (and keep) more players.

Let's see what our programmers can do :)

[Scawen]

Actually if you are in a server and you do a take over with a driver driving a car you are not allowed to drive, the InSim won't spec you (probably because they don't want to).
With the new system will LFS spec you if you take a car you are prohibited to use?No, it has no effect in that case. You can still take over a car that the IS_PLC has prevented you from selecting.

Settings ==> Editor ==> General Settings ==> Tab optionsThanks, but I was hoping to be able to specify it for an individual block of code so that everyone sees it correctly regardless of their general setting. Doesn't really matter anyway.

[EQ Worry]

Can the allowed cars packet also be used to disable all cars for a certain UCID? I would hope so, because it would be a useful functionality for special events etc... The question is what will then LFS do, if no car is available...

[cargame.nl]

Jeah thats really annoying in cargame.nl Server when you have no clue which car to drive and get specced always.
I've changed this behavior two months ago. (Visit more frequently, *grin* ;) )

I especially make use now of the ability to change allowed cars with the /cars command. Anyone who is in the current track rotate and driving GTR can still drive it and/or continue with an ongoing race. /cars changes dynamically with the amount of server connections. If you want to join the race while the lock is on you just cannot select GTR in the LFS car selection screen. There is no error message anymore or auto-spectating.

So I'm not so happy with this change. I'm afraid..

Let me understand this correctly;

What happens if a server on default allows ALL cars but this InSim packet limits for a certain UCID the selection to lets say XFG+XRG.

Does the user get the selection screen with only XFG+XRG or is there some kind of error message when this UCID select a car he/she is not allowed to drive due to InSim regulations?

Maybe its not that dramatic as I think it is ;)

..
edit;
Yes, that's right. It affects the car selection screen, the /car command and the check when you try to join a race.

Hhmm first read then ask... Question answered ;)

[GeForz]

Uhm okay, maybe it was more than 2 month ago when i was so confused with safety ratings etc. :)
But the statement still holds. If i can select a car I should be able to drive it and not be specced after join which is the current limitation by insim systems to enforce car usage.

[cargame.nl]

Well you can still be specced if you use the wrong setup, rally tires on road or vice versa. Or too many passengers on a race server, or using the wrong restriction.

UFB for example, newbies may drive UFR but only with 45% air intake restriction. Unrestricted GTR on our main server isn't even allowed at all. So this change doesn't cover all spec messages. But this sounds good. System gets more complicated from an admin point of view but will get over it :razz:

For the racer it indeed works much better :thumb:

..

[Dygear]

Thank you Scawen, I have just one request now.

I would like to be able to bind InSim buttons to keys on the keyboard. For example, should I show a menu on the screen, and allow the player to use a button on their keyboard to activate (click) that button.

http://wiki.alliedmods.net/images/Basic_menu_2_page1.PNG http://wiki.alliedmods.net/images/Basic_menu_2_page2.PNG http://wiki.alliedmods.net/images/Basic_menu_2_page3.PNG

Something along the lines of this, but as you would suspect with LFS Track names, or player names as needed.

[repeat83]

tips: In ArmA activating menu at pressing key BackSpace. You can select item (some items can have sub-items) pressing key 0 - 9

Becouse keys 0 - 9 now busy.

[Dygear]

The reason why I bring this up, is that right now, for people who use a mouse to steer have to use their mouse to also select these items. I would like to be able to race with my mouse and still interact with the InSim app without having to use my mouse. You can still click on these items if you wish, but having the option to use you keyboard I think makes it a more robust solution.

[T3charmy]

to be able to specify which cars an individual player can drive.

I LOVE YOU! I have always wanted this feature, as stated, it could be used for racing as well as cruising, I am really looking forward to this, take as much time as you need. :)

[Scawen]

Can the allowed cars packet also be used to disable all cars for a certain UCID? I would hope so, because it would be a useful functionality for special events etc... The question is what will then LFS do, if no car is available...You can, with a Cars value of zero. You can give a player access to all allowed cars with Cars = 0xffffffff and stop them selecting any car with Cars = 0.

If Cars is zero, or any set bits in Cars are not actually allowed on the host, then a player who tries to join is presented with a car selection screen full of greyed out cars. Whichever one they click, LFS informs them that the host does not allow them to drive that car.

That might be a bit crude but it's just what LFS did naturally. It's ok for now, doesn't need any translation strings, etc...

I especially make use now of the ability to change allowed cars with the /cars command. Anyone who is in the current track rotate and driving GTR can still drive it and/or continue with an ongoing race. /cars changes dynamically with the amount of server connections. If you want to join the race while the lock is on you just cannot select GTR in the LFS car selection screen.I'm not sure if I understood this correctly but please be warned - you will have to be very careful with the /cars command now, it can no longer be used as a "prevent join" command. Because any cars that are disallowed by the /cars command will be instantly spectated. I realised that /cars could be used in that way before but is now very "strong" and that's why I've done the IS_PLC.

Thank you Scawen, I have just one request now.

I would like to be able to bind InSim buttons to keys on the keyboard. For example, should I show a menu on the screen, and allow the player to use a button on their keyboard to activate (click) that button.

http://wiki.alliedmods.net/images/Basic_menu_2_page1.PNG http://wiki.alliedmods.net/images/Basic_menu_2_page2.PNG http://wiki.alliedmods.net/images/Basic_menu_2_page3.PNG

Something along the lines of this, but as you would suspect with LFS Track names, or player names as needed.I would like to just forget about this for now, the thought of it is a little confusing, and I don't want to occupy any more of my brain with anything tricky at the moment. This patch has taken longer than expected and I just want to get those last few things done and tested so we can release the official patch.

Soon :

In the next 1-3 days I'll be posting here to discuss some autocross object add / remove (instructions + notifications) and object hit by car notification packets.

[EQ Worry]

Thanks for the reply and explanation! :thumb: Indeed, there's already a lot of new features, it would be good to make them official.

[Dygear]

I would like to just forget about this for now, the thought of it is a little confusing, and I don't want to occupy any more of my brain with anything tricky at the moment. This patch has taken longer than expected and I just want to get those last few things done and tested so we can release the official patch.

Thanks for the reply. Sorry my example was confusing, I'll try to provide a more concise example using the LFS client with a plugin I'm making for PRISM as an example.

[Scawen]

Actually your example is not confusing. It looks good... it's the thought of how to implement InSim key binds that is confusing, when the keys are all used up and multiple InSim programs can be attached, when my head is filled with so many other things. :)

[Dygear]

Actually your example is not confusing. It looks good... it's the thought of how to implement InSim key binds that is confusing, when the keys are all used up and multiple InSim programs can be attached, when my head is filled with so many other things. :)

Good point! This is the same problem I'm having with the InSim Buttons myself right now. I don't know how to display a group of buttons that are meant to work as one, but when they display on top of another group. I though that I would use a push / pop kind of method, so that the last bunch of items to be put onto the screen are the first interfaced by the user. This way, the most 'current' information is placed up front for the user to deal with. Once they have handled that, they are then represented with the older button group so they can interact with that.

In essence the button bound key, would work just like a ClickID, but with a physical key to click. In the same way that if you use a ClickID twice, then the data is overwritten, the same could be true of this. It would be up to the InSim programmer to handle themselves. Of course this would become a problem with multiple InSim instances running at once, should they request the same key, but then I would think that the first in last out, push pop method could work there too.

[Degats]

I would like to be able to bind InSim buttons to keys on the keyboard. For example, should I show a menu on the screen, and allow the player to use a button on their keyboard to activate (click) that button.

http://wiki.alliedmods.net/images/Basic_menu_2_page1.PNG http://wiki.alliedmods.net/images/Basic_menu_2_page2.PNG http://wiki.alliedmods.net/images/Basic_menu_2_page3.PNG


A possible solution - not quite as quick to use, but should work with InSim as it is now:

The player would need to bind 3 commands to function keys (!up !down !select for example. "/o " instead of "!" for a local InSim program)

The 'active' button would have a different colour to the others. The player changes the active button using the up and down binds, and the select bind to effectively click the active button. The player would be able to navigate a menu system while still maintaining control.

[repeat83]

same keys that at F11 menu ;)

[EQ Worry]

Two, I hope reasonable, InSim suggestions:

1) Could there please be somewhere a bit (or bits) saying that tweaks on the server are allowed? Maybe a bit about the host being private would be useful as well. I'm not sure, maybe these two could go to the existing race flags...

2) Could the race flags be also sent as part of IS_STA, ideally including the private/tweak bits and updated on every change (of car reset, midrace join, must pit, etc.)? There seem to be two spare bytes...

Thanks for reading/considering. :)

[cargame.nl]

I'm not sure if I understood this correctly but please be warned - you will have to be very careful with the /cars command now, it can no longer be used as a "prevent join" command. Because any cars that are disallowed by the /cars command will be instantly spectated. I realised that /cars could be used in that way before but is now very "strong" and that's why I've done the IS_PLC.

Yes, it's relying on /cars right now.

But I misunderstood you the first time. I know understand how it's going to work and in the end I think it's great. It only need some InSim coding now but this solution is better. Some racers cannot handle cars like FZ5 for example, its very nice that it's possible to exclude those cars from person to person on the LFS car selection screen.

[cargame.nl]

I was thinking...

I wonder how the ingame filter and webfilter is going to react on this change.

What if a lot of race hosters decide to do a car ALL and let the InSim do permanent limiting? This change is making those filters pretty unreliable?

[Dygear]

This change is making those filters pretty unreliable?

Pretty much, yeah. But that's because it's only going to be able to filter whats in the /cars setup. It can't filter based on what it might not be able to give you as it just does not know that. That means it's up to us not to abuse it.

[Squelch]

Correct me if I'm wrong, but if cars is set ALL and then limited via InSim /cars, the ingame host list will also become misleading. This will mean drivers wishing to join an apparently open marque server, will find themselves frustrated by having no reliable information about the server type.

It is up to the server admin not to abuse the system, but history has shown that cannot always be relied on. I welcome the new addition, but it could cause further issues.

[Dygear]

With great power comes great responsibility. I think this is a step in the right direction, I think we should have much more power over the engine, I think we should have access to the the engine via a DLL interface that we can use to setup callbacks within our own programs. I want to be able to edit and change the game on the fly, I want tweak on the server side that will propagate to the client side automagicly. I want full control over the client's speed, I want to be able to setup hotkey functions onto their client that will allow for like a server slide KERS system, or DRS. I want images and sprites to be able to be displayed on screen. I want to be able to control the font I use to display information within the buttons. I want control over the engine and all of it's parts. But we are a long way away from that, and that's ok, because if we got all of this tomorrow none of us would know what to do with ourselves.

[EQ Worry]

I believe the individual car blocking is much better than forcing people to spec, as it is done now, so this feature is in every respect (for me) a major improvement. If properly used, it will substantially limit confusion and bad race joining spam happening now.

I hope, Scawen, that you still follow this thread, because I'd like to suggest a security improvement, also related to InSim. Just yesterday and today our servers were hacked in some way. I believe someone connected gained admin rights while being already online, or at least he/she was able to use all server admin commands. (I'm not sure, is that possible?)

The bad thing is that neither server nor any InSim tool (if I'm not mistaken) is able to log/see admin commands entered anywhere else than on host (and Remote, which is the host itself). All the / commands coming from a normal connection are "eaten", never reported. They are either refused or processed, but never logged.

Here I dare to suggest the following:

1) Whenever someone connects with server admin rights (or gets them somehow later, uhm?), record the event into server log, just one line with time, name, status.

2) Store all admin commands into server log, even when they come from normal connections and not just the host. This would be, I think, a major safety improvement allowing to backtrack currently hidden actions of rightful (and fake) admins. Of course I do not know how easy this is to implement, but I hope it can be done. Again, one line in server log, time, name, command, like it was a normal message.

3) If somehow possible, forward all such commands of all the connections also as standard messages to InSim clients, maybe using a new special type of message if necessary (I am not sure). IMO best would be to log/report all such commands, even if they're refused for insufficient rights. The idea is InSims can then spot all attempts at admin commands, and if they have a list of rightful admins, they can quickly recognize someone unauthorized is trying to subvert the server, with a protective action following (kick/ban).

I hope this makes sense, and thanks for considering. :)

[Dygear]

Yeah, that's another thing. We should really have access to what is going on with the server at any given moment. If there is a command going on, then the InSim application should be informed of it so it can update it's state to keep everything in sync.

[EQ Worry]

Well, sorry, one more suggestion, extending the server state info data and reporting as already mentioned here (http://www.lfsforum.net/showthread.php?p=1598110#post1598110): One more bit saying whether or not the server is in demo-compatible mode would be helpful.

I believe it is possible to use /demo=s2 in server config and still make it available to demo people, but that depends on track+cars+connections+layout and it is hard to gather all these data separately. So that one more bit as part of server state (ideally sent on every state change as suggested in the linked post) would be nice.

Thanks! :)

[Scawen]

Hello programmers,

I've now added this packet that can add or remove up to 30 autocross objects per packet. It can also be used to clear a layout and report any objects that are added by the host or admins, either when loading an entire layout or in the editor. Please can you read the documentation and see if it makes sense / if there are any problems you can see. The updated layout file format is attached, so you can understand the ObjectInfo structure.

// AUTOCROSS OBJECTS - reporting / adding / removing
// =================

// Set the ISF_AXM_LOAD flag in the IS_ISI for info about objects when a layout is loaded.
// Set the ISF_AXM_EDIT flag in the IS_ISI for info about objects edited by user or InSim.

// You can also add or remove objects by sending IS_AXM packets.
// Some care must be taken with these - please read the notes below.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
short X;
short Y;
char Zchar;
byte Flags;
byte Index;
byte Heading;
};

struct IS_AXM // AutoX Multiple objects - variable size
{
byte Size; // 8 + NumO * 8
byte Type; // ISP_AXM (53)
byte ReqI; // 0
byte NumO; // number of objects in this packet

byte UCID; // unique id of the connection that sent the packet
byte PMOAction; // see below
byte PMOFlags; // see below
byte Sp3;

ObjectInfo Info[30]; // info about each object, 0 to 30 of these
};

// Values for PMOAction byte

enum
{
PMO_LOADING_FILE, // 0 - sent by the layout loading system only
PMO_ADD_OBJECTS, // 1 - adding objects (from InSim or editor)
PMO_DEL_OBJECTS, // 2 - delete objects (from InSim or editor)
PMO_CLEAR_ALL, // 3 - clear all objects (NumO must be zero)
PMO_NUM
};

// Info about the PMOFlags byte (only bit 0 is currently used) :

// If PMOFlags bit 0 is set in a PMO_LOADING_FILE packet, LFS has reached the end of
// a layout file which it is loading. The added objects will then be optimised.

// Optimised in this case means that static vertex buffers will be created for all
// objects, to greatly improve the frame rate. The problem with this is that when
// there are many objects loaded, optimisation causes a significant glitch which can
// be long enough to cause a driver who is cornering to lose control and crash.

// PMOFlags bit 0 can also be set in a IS_AXM with PMOAction of PMO_ADD_OBJECTS.
// This causes the objects to be optimised. It is important not to set bit 0 in
// every packet you send to add objects or you will cause severe glitches on the
// clients computers. It is ok to have some objects on the track which are not
// optimised. So if you have a few objects that are being removed and added
// occasionally, the best advice is not to request optimisation at all. Only
// request optimisation (by setting bit 0) if you have added so many objects
// that it is needed to improve the frame rate.

// NOTE 1) LFS makes sure that all objects are optimised when the race restarts.
// NOTE 2) In the 'more' section of SHIFT+U there is info about optimised objects.

// If you are using InSim to send many packets of objects (for example loading an
// entire layout through InSim) then you must take care of the bandwidth and buffer
// overflows. You must not try to send all the objects at once. It's probably good
// to use LFS's method of doing this : send the first packet of objects then wait for
// the corresponding IS_AXM that will be output when the packet is processed. Then
// you can send the second packet and again wait for the IS_AXM and so on.

[GeForz]

New layout format looks good (Was already wondering why the spare byte was not 0 in z34 ;))

At which point will the PMO_LOADING_FILE be sent? Maybe there is need for an "send objects"-tiny-request i.e. when the insim tool connects to a already running server?

[Scawen]

Well, that is really a lot of info already. Personally, I would be happy even with something much simpler considering collisions with objects (including walls, that is important for me), just PLID and maybe type of the object.

The perpendicular closing speed of the car with the object would be useful for a program idea that I have. We want to assign ballast penalties for out of control driving and this would help especially on the city tracks.I'm working on the IS_OBH (object hit) packet now. It's easy enough with the movable objects and autocross objects. X, Y and object index is enough to identify the actual object if you need to. It will include the perpendicular closing speed just as it does with the cars. For those objects LFS uses the same collision system as collisions with other cars.

But for the segments, there are more questions to be asked. Really, we cannot output all segment collisions, every time there is a brush with a wall or one tiny part of the car touches the ground. But this turns out to be a similar problem to the HLVC detection for hotlaps. To invalidate HLVC, the impact must be significant enough for 3 points of the car to touch the wall and the closing speed must be at least 1.5 m/s.

I guess my question to you is... for the wall collision detection, would you be happy with the same check as HLVC? This is designed to detect bad driving so I'm guessing it is quite suitable for your purposes. It's easier for me to code as well, because the detection is already in place so it's just a matter of putting that info into a packet and sending it.

[GeForz]

"Colour - only used for chalk (0-3) and tyres (0-5)"
Can you add which number is which color so we don't have to try it out. (assuming you have the list ready to c&p ;))

[avetere]

Nice one ... I have one question, though:

Can you easily(!) tell us the dimensions of the ocjects (height, width, length)?
Might be helpful ...

[Scawen]

"Colour - only used for chalk (0-3) and tyres (0-5)"
Can you add which number is which color so we don't have to try it out. (assuming you have the list ready to c&p ;))
enum // tyre colours
{
TC_BLACK,
TC_WHITE,
TC_RED,
TC_BLUE,
TC_GREEN,
TC_YELLOW,
TC_NUM
};

enum // chalk colours
{
CC_WHITE,
CC_RED,
CC_BLUE,
CC_YELLOW,
CC_NUM
};

Nice one ... I have one question, though:

Can you easily(!) tell us the dimensions of the ocjects (height, width, length)?
Might be helpful ...Not easily, but maybe I could do some kind of export of that info.

[denis-takumi]

Scawen, what about add object_id (from 0 to 800)?
in "PMO_ADD_OBJECTS," action lfs search for this object_id. if it already exist then "move this object to the new point" else "add this object"
and add its id in shift+u mode (object info)

[Scawen]

An object is identified by (X, Y, Index).

To move an object, you send a PMO_DEL_OBJECTS followed by a PMO_ADD_OBJECTS.

[EDIT : I removed some other posts that were either spam or turned out to be off topic]

[EQ Worry]

I guess my question to you is... for the wall collision detection, would you be happy with the same check as HLVC? This is designed to detect bad driving so I'm guessing it is quite suitable for your purposes.

I guess using the same code HLVC uses is absolutely sufficient, as long as it reports substantial touches of walls, cones, etc., maybe also grass/ground if that is possible. Whatever seems simple enough. Thanks. :)

I do not want to delay official patch, but I hope you noticed some other proposals here concerning InSim and server log, specifically 1) logging/reporting all attempts at using admin commands from all connections, which I consider very important and actually a security hole now, and maybe 2) adding demo/tweak/private bits to server/race state info, sending it all also in the IS_STA packet on every change.

Sorry, I know I mentioned these 2 things twice before, but especially the silent admin commands are really not good and potentially dangerous. For example I know someone got admin rights on our servers without using the pass, very probably somehow after connecting, not during connect (here I have no idea if admin rights are checked by server or clients, if for example server processes all admin commands coming from "approved", possibly hacked clients), but I have no way to track the guy and the commands. Just logging them and reporting them to InSim apps makes major difference with swift action possible.

So again, sorry for repeating this, but... :shy:

PS: Oops, I almost forgot: Thanks for the object updates! It all looks very nice, but it would require time to incorporate all the changes and see if everything works smoothly.

[Squelch]

In regards to multiple objects in shift+U (editor mode), where will the origin of the multiple objects be, first selected object, or the geometric centre?

Will it be possible to inject sets of objects via InSim while in editor mode? ie add further objects with relative offsets/rotations/indices from the last editor added object detected via ISF_AXM_EDIT

Example: Bale garage
Place first bale in editor, then use an InSim app to build a garage based on the last placed object position and rotation.

Is it possible to have a new generic "InSim object" available from the editor control objects list?

This would simply be a token that can be detected and trigger an InSim app to send a pre prepared payload. In the example above, the "InSim object" is used instead of the first bale, and the first object in the payload is placed at the vertices. I suggest a control object so it is invisible under normal circumstances, but would enable bulk object addition via InSim.

I hope this isn't considered to be more noise.

[GeForz]

I assume:
Multiple objects will just be reported as seperate objects in the packet, each with own x,y coordinates.

And for the control object: The insim app could also remove the "control object", i.e. you configure the insim app like "!build garage" and then add a predefined object like a cone. The insim app then removes the cone and builds a garage relative to the coords of the cone.

[Dygear]

You could do the command `autox build garage` and it will wait for you to place an object. After you do place an AutoX object, InSim sends the IS_AXM with the details of the 1 object that was placed by you, the InSim application then goes on to use the AutoX object you just placed as the Geomertic center and adds the other AutoX objects around it, finally removing the object you placed at the end. I can see this working quite well, except for one thing.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
short X;
short Y;
char Zchar;
byte Flags;
byte Index;
byte Heading;
};

First is, why is Z called Zchar? Was that an error? Should it not just be Z.
Second is how did you manage to Index 800 objects with a value of 0 - 255?

Sorry to be pedantic but could you make the Index the structs first value, as it's the most significant bit of data we will have.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
byte Id;
byte Flags;
short X;
short Y;
char Z;
byte Heading;
};

[Squelch]

I edited several times to try and be concise.
I assume:
Multiple objects will just be reported as seperate objects in the packet, each with own x,y coordinates.
That's my assumption too from reading Scawens post and the new LYT.txt.

And for the control object: The insim app could also remove the "control object", i.e. you configure the insim app like "!build garage" and then add a predefined object like a cone. The insim app then removes the cone and builds a garage relative to the coords of the cone.You could do the command `autox build garage` and it will wait for you to place an object. After you do place an AutoX object, InSim sends the IS_AXM with the details of the 1 object that was placed by you, the InSim application then goes on to use the AutoX object you just placed as the Geomertic center and adds the other AutoX objects around it, finally removing the object you placed at the end. I can see this working quite well, except for one thing.
I was originally thinking the same, but realised that creating and deleting an object would fragment the static vertex list. Where there are many objects, my understanding of Scawens posts, is that the list is best optimised for better frame rate. If my interpretation is correct, an analogy can be made to file fragmentation on disk/memory, and the optimisation simply makes objects contiguous. I may be wrong and often am though.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
short X;
short Y;
char Zchar;
byte Flags;
byte Index;
byte Heading;
};First is, why is Z called Zchar? Was that an error? Should it not just be Z.
Second is how did you manage to Index 800 objects with a value of 0 - 255?Not sure about the Zchar, but you might be getting muddled between the index of the array of all available objects (see note 5 of new lyt.txt) and the total number of objects.

Sorry to be pedantic but could you make the Index the structs first value, as it's the most significant bit of data we will have.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
byte Id;
byte Flags;
short X;
short Y;
char Z;
byte Heading;
};No two objects can occupy the same space, so each unique object can be identified easily, thus
An object is identified by (X, Y, Index).


On that note, currently if an object intersects another while moving, it is dropped from selection and is effectively lost. What happens when objects in a multiple selection intersect with an existing object? I'm assuming we would need to avoid this via InSim too, but how to detect intersection? Would these objects be silently dropped too?

[Scawen]

I guess using the same code HLVC uses is absolutely sufficient, as long as it reports substantial touches of walls, cones, etc., maybe also grass/ground if that is possible. Whatever seems simple enough. Thanks. :)OK, and I also thought that that grass / ground thing would be good to look at. So hosts can run a check nearly the same as HLVC if they want to.

About the car info in the OBject Hit and 'HLVC' packets (maybe the same packet) I am thinking it really does not need all the CarContact info that you get in the IS_CON packet. I think X, Y, Direction, Heading, Speed should be enough for the car. And for the object : X, Y, Index and another byte of flags, for info like if the object was in its original position when hit. I'll post a proposed packet this morning.

I do not want to delay official patch, but I hope you noticed some other proposals here concerning InSim and server log, specifically 1) logging/reporting all attempts at using admin commands from all connections, which I consider very important and actually a security hole now, and maybe 2) adding demo/tweak/private bits to server/race state info, sending it all also in the IS_STA packet on every change.Don't worry, I will look at this.

In regards to multiple objects in shift+U (editor mode), where will the origin of the multiple objects be, first selected object, or the geometric centre?Each object has its own X and Y. A multiple object packet contains 0 to 30 complete 8-byte ObjectInfo structures.

Will it be possible to inject sets of objects via InSim while in editor mode? ie add further objects with relative offsets/rotations/indices from the last editor added object detected via ISF_AXM_EDITYes, the system is specifically designed to allow simultaneous editing by InSim or any number of admins. That's why objects are referred to only by X, Y, Index and never their number in a list. Index means one of the AXO_X object type numbers from the end of LYT.txtIs it possible to have a new generic "InSim object" available from the editor control objects list?I don't think it is easy to change the code to allow NULL objects.
I assume:
Multiple objects will just be reported as seperate objects in the packet, each with own x,y coordinates.Yes.
And for the control object: The insim app could also remove the "control object", i.e. you configure the insim app like "!build garage" and then add a predefined object like a cone. The insim app then removes the cone and builds a garage relative to the coords of the cone.Yes, as I probably can't support NULL objects easily, this is a good way to signal a position to an InSim program.
You could do the command `autox build garage` and it will wait for you to place an object. After you do place an AutoX object, InSim sends the IS_AXM with the details of the 1 object that was placed by you, the InSim application then goes on to use the AutoX object you just placed as the Geomertic center and adds the other AutoX objects around it, finally removing the object you placed at the end. I can see this working quite well, except for one thing.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
short X;
short Y;
char Zchar;
byte Flags;
byte Index;
byte Heading;
};

First is, why is Z called Zchar? Was that an error? Should it not just be Z.
Second is how did you manage to Index 800 objects with a value of 0 - 255?

Sorry to be pedantic but could you make the Index the structs first value, as it's the most significant bit of data we will have.The approximate altitude has always been called Zchar, so I never forget that it has a different accuracy level compared with X and Y. This is the actual structure that has always been used in LFS and layout files, layout file loading packets and so on, so it is not possible to rearrange it.

You have missed the meaning of Index though. It is not an identifier of an individual object. It is one of the AXO_X numbers from the end of the LYT.txt file. Objects are not identified by a unique id or an index in a list (which could keep changing). An object can be indentified uniquely by (X, Y, Index) which is what PMO_DEL_OBJECTS looks at to find objects you want to delete.

[GeForz]

Scawen did you read my initial response about the PMO_LOADING_FILE?

[Scawen]

I was originally thinking the same, but realised that creating and deleting an object would fragment the static vertex list.No, there is never any fragmentation, because the static vertex buffers for all added objects are created at the same time - that's why it can take a quarter of a second / maybe half a second depending on computer speed to generate the buffers if there are 800 objects on the track.

I can't emphasise enough, and this is why I took ages to write an essay about it in the ISPackets.txt : programmers will have to be careful with that bit in PMOFlags and you absolutely MUST NOT set it routinely in the PMO_ADD_OBJECTS packets. You set it once in the last packet of a long list of objects, at a time when you are happy for people to spin off if they are driving around a corner. Don't set it if you are adding / moving a small number of objects around - just leave the new ones unoptimised.

On that note, currently if an object intersects another while moving, it is dropped from selection and is effectively lost. What happens when objects in a multiple selection intersect with an existing object? I'm assuming we would need to avoid this via InSim too, but how to detect intersection? Would these objects be silently dropped too?That doesn't happen in the editor now, it does a thorough check before you move objects, and doesn't perform the operation if it would go wrong in any way. But there are no such checks in InSim. Intersecting objects would be deleted in that case.

Unfortunately, dedicated hosts cannot detect intersecting objects. If objects sent from a dedicated host have the exact same X, Y, Index they will not be added. But if they are slightly different and still intersecting, they will stay there. If the packet is sent from a client, the objects are instantly deleted if they intersect.

[Scawen]

At which point will the PMO_LOADING_FILE be sent? Maybe there is need for an "send objects"-tiny-request i.e. when the insim tool connects to a already running server?PMO_LOADING_FILE packets are sent when you load a layout using LFS's load layout button or /axload, or just open a track and LFS loads a layout. Any time LFS loads a layout using its own system, those are sent.

I'm not sure about the send objects tiny. It's becoming very difficult for me now, trying to finish the patch with the things I am already committed to, thinking about yet more things to add and test makes me very uncomfortable. So I don't want to do that if it's at all possible. Perhaps people should connect their InSim programs before loading a layout? Alternatively you could do /axsave temp and then read the output layout file.

[GeForz]

Okay that should work, too.

BTW: is it really possible to have 2 objects at the same x,y coordinates?
i.e. Do we really need to use x, y AND index to compare or is x and y enough?

[Squelch]

No, there is never any fragmentation, because the static vertex buffers for all added objects are created at the same time - that's why it can take a quarter of a second / maybe half a second depending on computer speed to generate the buffers if there are 800 objects on the track.

I can't emphasise enough, and this is why I took ages to write an essay about it in the ISPackets.txt : programmers will have to be careful with that bit in PMOFlags and you absolutely MUST NOT set it routinely in the PMO_ADD_OBJECTS packets. You set it once in the last packet of a long list of objects, at a time when you are happy for people to spin off if they are driving around a corner. Don't set it if you are adding / moving a small number of objects around - just leave the new ones unoptimised.Thanks for the clarification and emphasis. It was your ISPackets.txt warning that made me think of avoiding re-optimisation, but for the wrong reasons, and it's now clear.

That doesn't happen in the editor now, it does a thorough check before you move objects, and doesn't perform the operation if it would go wrong in any way. But there are no such checks in InSim. Intersecting objects would be deleted in that case.I was going to suggest flashing the selection/object while in editor mode.

Unfortunately, dedicated hosts cannot detect intersecting objects. If objects sent from a dedicated host have the exact same X, Y, Index they will not be added. But if they are slightly different and still intersecting, they will stay there. If the packet is sent from a client, the objects are instantly deleted if they intersect.Does this mean an InSim packet on the dedicated host will allow intersecting objects then? :confused: If abused, it could lead to some very interesting... erm... sculptures?

[E.Reiljans]

Does this mean an InSim packet on the dedicated host will allow intersecting objects then? :confused: If abused, it could lead to some very interesting... erm... sculptures?Couldn't you do intersecting objects for long time using third party editors already?

e.g. this one: http://www.lfsforum.net/showthread.php?t=16873

[Dygear]

The approximate altitude has always been called Zchar, so I never forget that it has a different accuracy level compared with X and Y.

You have missed the meaning of Index though. It is not an identifier of an individual object. It is one of the AXO_X numbers from the end of the LYT.txt file. Objects are not identified by a unique id or an index in a list (which could keep changing).

Thank you for clearing both items up for me.

Maybe there is need for an "send objects"-tiny-request i.e. when the insim tool connects to a already running server?

Agreed, an ISP_TINY packet for this is an important step.

[Scawen]

1) Whenever someone connects with server admin rights (or gets them somehow later, uhm?), record the event into server log, just one line with time, name, status.I have added a line, if logging is enabled and someone connects as an admin :

Jun 08 11:35:48 Admin : scawen

2) Store all admin commands into server log, even when they come from normal connections and not just the host. This would be, I think, a major safety improvement allowing to backtrack currently hidden actions of rightful (and fake) admins.I have added to the log, commands from remote connections, with a small difference if it is an admin or not. The admin version has a colon and the non-admin version has a minus.

Jun 08 11:43:13 scawen : /axlist

or if the user is not an admin...

Jun 08 11:43:58 scawen - /axlist

3) If somehow possible, forward all such commands of all the connections also as standard messages to InSim clients, maybe using a new special type of message if necessary (I am not sure).I'm not sure yet if I'll do this, but I've made a note.

[Scawen]

Agreed, an ISP_TINY packet for this is an important step.Actually this is a bit hard, I can't just send a flood of packets for 800 objects. And doing it in pieces is not guaranteed to be correct if someone is editing, and has bug potential that I can do without right now.

So I don't plan to do that. Anyway, I don't see it as that important, because you can use the command /axsave temp and read the file temp.lyt that will be created.

[EQ Worry]

I have added a line, if logging is enabled and someone connects as an admin ... I'm not sure yet if I'll do this, but I've made a note.

Great, thanks :), having it in server log will allow for later diagnosis, but it is not really easy to respond to server log items in real time (though not impossible, under certain circumstances). Having the admin commands, or attempts at them, forwarded to InSim would make things of course much easier. But I'm very happy with this 1st step, thank you. :) Maybe instead of colon a plus could be used, representing accepted command, while minus represents refused command? Well, whatever, it is not really important, it just seems to be more, uhm, intuitive... :D

[Squelch]

Great, thanks :), having it in server log will allow for later diagnosis, but it is not really easy to respond to server log items in real time (though not impossible, under certain circumstances). Having the admin commands, or attempts at them, forwarded to InSim would make things of course much easier. But I'm very happy with this 1st step, thank you.Isn't it possible to use tail and then forward messages to an InSim client? Combined with grep, even high priority messages can be filtered and dealt with, and in virtually real time too.

[EQ Worry]

I'm not sure about tail and grep, but I think it obviously is a kind of makeshift solution, while an InSim message packet (maybe message of special type, we already have about 4) is nice and clean. Also I would guess any "server log change listeners" can work only locally. And even if I'm mistaken in this point, still... :)

[T3charmy]

@Scawen Just curious, why 30 objects per packet... the current limit is 800? 800/30 = 26.667 wouldn't it just be simpler to make it 32 or did you pick 30 for a specific reason? or if you rather not explain, that is fine also :)

[Victor]

@Scawen Just curious, why 30 objects per packet... the current limit is 800? 800/30 = 26.667 wouldn't it just be simpler to make it 32 or did you pick 30 for a specific reason? or if you rather not explain, that is fine also :)

the packet size remains smaller than 256 bytes then. This is necessary because the packets' their sizebyte is only one byte. So packets may not be bigger than 255 bytes.

[T3charmy]

the packet size remains smaller than 256 bytes then. This is necessary because the packets' their sizebyte is only one byte. So packets may not be bigger than 255 bytes.

ohh, Ok, didn't think about it that way while posting. ;)

[Krammeh]

I would really like to know if a user has DEMO/S1/S2 on join

[EQ Worry]

I would really like to know if a user has DEMO/S1/S2 on join

+1

I guess though that this is more a LFSW matter, it would be great to have this as part of some existing info (personal data - where country, total distance, races, etc. are available).

[Squelch]

Just a quickie Scawen.

indeces -> indices

In the docs.

[cargame.nl]

+1

I guess though that this is more a LFSW matter
+2

I already suggested that to Victor last year but somehow he wasn't entirely convinced yet. While it's a bit detectable by car usage history. Though difficult :really:

[Krammeh]

+2

I already suggested that to Victor last year but somehow he wasn't entirely convinced yet. While it's a bit detectable by car usage history. Though difficult :really:

what if im a s2 user that only likes XFG :P... it can't be that hard to put in, and there is sp3 in NCN *sulks*

[Victor]

what would you use it for?
I'm just very hesitant when it comes to giving away people's license status. For example there's already enough demo bashing going on here on the forum from time to time. I don't want to see this expanded in online LFS. I just cannot think of something constructive that the information can be used for.
A racer uses a certain car online and that's really all you need to know. So what if someone is a demo racer on your host? Or you're running an S2 host and then the racers will be S2 licensed. I just don't see the point of knowing a racer's license.
Also you don't have to do license checks to see if a demo racer has joined a S2 host - I already do those checks and kick people who are on a host they don't belong.

[Krammeh]

I normally run both S2 and Demo, and their in-server stats are stored in the same server. and I would like to ensure that they are Demo/S2 (not a S2 joining a demo hosts for instance).

The career starting point would change depending on if they are demo/s2

[EQ Worry]

First, thanks for response! :) Of course Demo/Licensed status is of no use on licensed hosts, where demo people cannot connect. However, S1 or S2 info could be useful, if only just to see that you can move to an S2 combo without anyone losing connection. However, I would like to use it basically the other way, on demo servers to see who's got a license and can be e.g. invited to an event. Most of the people on demo servers are demoers, nobody's been raising an issue of this for years on our servers, I do not remember a single case when someone was "spitting" on demo people while racing on a demo server. Maybe here in this forum there are some rants occasionally, but I never witnessed problems online. One additional thing: The license status is already actually available, though not 100% exact. You just take a look at the guy's online stats and if more than 5 rows are returned, you know he's got a kind of license. I personally see no big deal in making this info available more readily. It is actually usable only on demo servers where nobody is making fun of demo people. The S1/S2/S3+ state would be handy from server management point of view. Well, and then people may always hide all of their data... PS: Airio is showing the derived status for a really long time already, and I don't think there ever was a problem with it. That Demo/S1/S2 info from LFSW would just make the info more precise and 100% exact.

[Scawen]

Just a quickie Scawen.

indeces -> indices

In the docs.Thanks - I've corrected that in LYT.txt.

I couldn't see it anywhere else, except in my code. :spin:

[Scawen]

The OBject Hit packet is now implemented. Please have a look and see if you think it is OK. This does not report wall contacts - only contacts with actual objects - like autocross objects or other polygon objects that are not available in layouts.

Wall hits will be reported with a simpler packet that will also be used to report illegal ground surfaces. Those reports will be triggered using the HLVC code.

struct CarContOBJ // 8 bytes : car in a contact with an object
{
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
byte Speed; // m/s
byte Sp3;

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

struct IS_OBH // OBject Hit - car hit an autocross object or an unknown object
{
byte Size; // 24
byte Type; // ISP_OBH
byte ReqI; // 0
byte PLID; // player's unique id

word SpClose; // high 4 bits : reserved / low 12 bits : closing speed (10 = 1 m/s)
word Time; // looping time stamp (hundredths - time since reset - like TINY_GTH)

CarContOBJ C;

short X; // as in ObjectInfo
short Y; // as in ObjectInfo

byte Sp0;
byte Sp1;
byte Index; // AXO_x as in ObjectInfo or zero if it is an unknown object
byte OBHFlags; // see below
};

// OBHFlags byte

#define OBH_LAYOUT 1 // an added object
#define OBH_CAN_MOVE 2 // a movable object
#define OBH_WAS_MOVING 4 // was moving before this hit
#define OBH_ON_SPOT 8 // object in original position

[Heiko1]

I would really like to know if a user has DEMO/S1/S2 on join

+1 :thumb:

@ Victor
its not just to make work for the devs...
its..
how to explain..

If we "InSim Devs" got running an Demo Racing server, we would be happy to be able to create such a Statistic list with Users on our server.

e.g:
X Registered users in your server are using 'Demo'
X Registered users in your server are using 'S1'
X Registered users in your server are using 'S2'

Registered users mean by Insim registered users what means the Database.

Would be realy cool if we are able to do that.

I think thats what u meant Krammeh right? :P

[misiek08]

Propably we have to query LFSW on every joining user.

[Dygear]

Propably we have to query LFSW on every joining user.

Only on new users. This bit of information should really be cached for S2 users, until S3 comes out. But then on each connection for someone with a Demo or S1 license. (I wonder what the break down is of Demo vs S1 vs S2 licenses is.)

[cargame.nl]

Exactly..

I do not see the problem of online dicussions between demo'ers and licensed people about that someone has 'more' rights because he is licensed or not. Might even motivate people to think about buying S2 when they actually see licensed people racing on the demo environment. These worlds really look separated right now for the demo people, apart from visible but not join-able servers in the listing, in the upcoming patch. But, personal opinion.

I used the information (based on car usage) for a league competition where I wanted to left out the S2 people because people could win a license every month. It's not updated anymore (http://www.cargame.nl/forum/lp.php) but actually a lot of licensed people race on the demo environment.

Anyway, it's not an InSim thing imo so a bit offtopic.

---
About the car object crash detection / reporting. Looks fine to me, don't know the practical use of it yet (maybe invalidating lap timings) but information is power :thumb:

[Scawen]

I've implemented the IS_HLV packet so you can detect a few things that would invalidate HLVC, even if you are not hotlapping. For example you could penalise racers who repeatedly bounce off the walls at South City or use certain short cuts.

// Set the ISP_HLV flag in the IS_ISI to receive reports of incidents that would violate HLVC

struct IS_HLV // Hot Lap Validity - illegal ground / hit wall / speeding in pit lane
{
byte Size; // 16
byte Type; // ISP_OBH
byte ReqI; // 0
byte PLID; // player's unique id

byte HLVC; // 0 : ground / 1 : wall / 4 : speeding
byte Sp1;
word Time; // looping time stamp (hundredths - time since reset - like TINY_GTH)

CarContOBJ C;
};

[misiek08]

byte Type; // ISP_OBH
Maybe ISP_HLV? C&P mistake :)

[Scawen]

Thanks, now fixed in code.

[Scawen]

Hi, here's the report of admin commands / attempted admin commands requested by EQ_Worry.

struct IS_ACR // Admin Command Report - any user typed an admin command
{
byte Size; // 72
byte Type; // ISP_ACR
byte ReqI; // 0
byte Zero;

byte UCID; // connection's unique id (0 = host)
byte Admin; // set if user is an admin
byte Result; // 1 - processed / 2 - rejected / 3 - unknown command
byte Sp3;

char Text[64];
};

[DarkKostas]

This packet (IS_ACR) looks very interested because i had something like that in my mind.


if Result == 3 then
{
if "FirstWord" == "/mycommand" then
{
//do my command things
break;
}
SendMessageToConnection(UCID, "Unknown command");
}
I always wanted commands using slash intested of exclamation mark!

[Scawen]

I forgot to put the updated InSim.txt in the patch file.

You can find them in this thread :
http://www.lfsforum.net/showthread.php?t=74717

I'll close this one now - let's move into the new thread. :)