Amp brought this up in here: http://www.lfsforum.net/showthread.php?t=62060
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.
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.
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.
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.
As always, many seemingly simple ideas are very hard to convert into code, I'm sure.z30
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...
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...
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?
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;
};
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.
I might just note that for the collision with another car the CarContact could really contain pedal info (throttle, brake), as Dave suggested earlier.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)
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)
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...
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:
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.
Yes, that is exactly what I wanted to say ... Thx
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.
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 : )
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];
};
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.
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.
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.
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.
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.
in my programm i use polygon system with funcrion for detect point in this polygon
to quickly create a polygon i use html+js(create line)+Track.jpg
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
Very good script! Thank you!
Just a question. How can I find the X/Y coordinates from the TIF track files?
I think that 1 pixel equals 1 metre.
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?)
Will this patch affect the current mpr-version (i.e. will other things than track config be altered?)
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.
Yeah you're were right, I am hating you for the last two days now!
Let's hope this new patch will allow us to do that!
This thread is closed
InSim changes in new test patch
(236 posts, closed, started )
FGED GREDG RDFGDR GSFDG