The online racing simulator
Damage report as insim package...
(15 posts, started )
#1 - bluejudas
Damage report as insim package...
Hi,

It would be nice if all damage is reported through insim. This is a fine way to force clean driving. Then I can make an insim application that give you a "repair time" when you have damage. If you are under damage you can't join new races. I have made a rallyx insim application(its on the 'LFS Norge RX' server) and of course we have problems with drivers wrecking and drivers being too aggressive. This will make at least the last category a bit more careful and force more clean driving. A ten minute cooling period for mayor damage is a good incentive for clean racing. Drivers having high damage rate could be given more and more "repair time". This will force them to be even more careful!

I hope a insim damage package is implemented soon

~b
#2 - BurnOut69
Cant see this happening as you could check how damaged other cars are, which can be seen as sensitive info in league races.
#3 - bluejudas
Quote from BurnOut69 :Cant see this happening as you could check how damaged other cars are, which can be seen as sensitive info in league races.

Even if that could be a problem, you still need to make an insim app and connect to the server insim port and the port is password protected. Btw you can already see damage when spectating cars.

~b
#4 - broken
I suggested something like this, but it seems like noone had what to say. Here: http://www.lfsforum.net/showthread.php?t=53419

So +6548465421635484(this number was achieved from very complicated calculations, involving much variables and very complicated formulas) from me.
#5 - Dygear
What would you like to see in the packet? What would it's structure be?
Also, I would like to congratulate you for using the Programmer Forum Correctly.
#6 - bluejudas
Quote from Dygear :
Also, I would like to congratulate you for using the Programmer Forum Correctly.

yrw...

Quote from Dygear :What would you like to see in the packet? What would it's structure be?

I am not sure this is correct, but maybe something like this....

struct IS_DMG // Damage
{
byte Size; // 8
byte Type; // ISP_DMG
byte ReqI; //
byte PLID; // player's unique id

byte DamageFactor; // Total damage in % 0-100 % (total for car)
byte DamageType; // Id of damage (00 = right suspension, 01 = left suspension, etc..)
byte DamageValue; // Size of damage DamageType (some meaningful value for the type of damage)
byte Spare1; //


};

Or maybe just make it simple??

struct IS_DMG // Damage
{
byte Size; // 8
byte Type; // ISP_DMG
byte ReqI; //
byte PLID; // player's unique id

byte DamageFactor; // Total damage in % 0-100 % (total for car)
byte Spare1; //
byte Spare2; //
byte Spare3; //

};
#7 - Dygear
struct IS_DMG {
byte Size; // 10
byte Type; // ISP_DMG
byte ReqI; // 0
byte PLID; // player's unique id

byte FR_DAM; // Value from 0 - 100 shown in %;
byte LE_FR_DAM; // Value from 0 - 100 shown in %;
byte RI_FR_DAM; // Value from 0 - 100 shown in %;
byte RE_DAM; // Value from 0 - 100 shown in %;
byte LE_RE_DAM; // Value from 0 - 100 shown in %;
byte RI_RE_DAM; // Value from 0 - 100 shown in %;
}

The reason I went for a packet structure like is is because one incident can case multiple problems with a car, and there might be many cars involved in the accident, that might issue a packet flood. I might want to further strut this out in fact to something that looks like this:

struct Damage {
byte PLID; // player's unique id
byte FR_DAM; // Value from 0 - 100 shown in %;
byte LE_FR_DAM; // Value from 0 - 100 shown in %;
byte RI_FR_DAM; // Value from 0 - 100 shown in %;
byte RE_DAM; // Value from 0 - 100 shown in %;
byte LE_RE_DAM; // Value from 0 - 100 shown in %;
byte RI_RE_DAM; // Value from 0 - 100 shown in %;
}

struct IS_DMG {
byte Size; // Header = 4 Bytes, Damage Struct is 7 Bytes, times by number of damaged cars in this packet.
byte Type; // ISP_DMG
byte ReqI; // 0
byte NumD; // Number of Cars Damaged (Ammout of Damage Structs found In Packet)

Damage[NumD]; // See Damage Struct for Data!
}

I would also recommend a ISP_TINY_DMG packet that will allow InSim connections to request the new IS_DMG packet containing all clients damage information.

TINY_DMG, // 22 - info request : send an IS_DMG

#8 - bluejudas
Yes flooding could be a problem....
#9 - bluejudas
Something like this should really be implemented. We really need a tool to punish aggressive driving. But I guess my sorry little request cant compete to the exciting news of physics update, Rockingham and Scirocco
I guess the only way to increase the possibility to get insim damage report is to wine about it... its seems to be the style of a lot of people on this forum. Well not only this forum but all forums on the net
#10 - Dygear
I forget what dev handles the game engine, but I'm sure this has not gone unnoticed. A comment from a dev would be nice, but unlikely.
#11 - bluejudas
Quote from Dygear :I forget what dev handles the game engine, but I'm sure this has not gone unnoticed. A comment from a dev would be nice, but unlikely.

I sure hope so.. yes and I don't expect a public confirmation If they did that we would for sure have a million winers complaining about that their suggestion is delayed... lets just hope that it is implemented at some point. My guess is that its not to difficult to implement. Flooding could be a problem, but it could be solved by accumulating damage reports and send it at a certain point, when the race ends or when the driver disconnects/spectate.
#12 - Dygear
Quote from bluejudas :I sure hope so.. yes and I don't expect a public confirmation If they did that we would for sure have a million winers complaining about that their suggestion is delayed... lets just hope that it is implemented at some point. My guess is that its not to difficult to implement. Flooding could be a problem, but it could be solved by accumulating damage reports and send it at a certain point, when the race ends or when the driver disconnects/spectate.

The idea remains that InSim is meant to be real time, so I don't expect to get that information at the end of the race. And I think the packet flow would be like getting a bunch of extra MCI packets.
#13 - DarkTimes
A solution would be to make damage bit flags in the MCI packet. You could use similar flags to the ones used for pitstop damage.

struct CompCar // Car info in 28 bytes - there is an array of these in the MCI (below)
{
word Node; // current path node
word Lap; // current lap
byte PLID; // player's unique id
byte Position; // current race position : 0 = unknown, 1 = leader, etc...
byte Info; // flags and other info - see below
byte Sp0;
int X; // X map (65536 = 1 metre)
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 Heading; // direction of forward axis : 0 = world y direction, 32768 = 180 deg
short AngVel; // signed, rate of change of heading : (16384 = 360 deg/s)
[b]unsigned DmgFlags;[/b]
};

enum
{
DMG_FR_DAM, // bit 1
DMG_FR_WHL, // bit 2
DMG_LE_FR_DAM, // bit 4 etc..
DMG_LE_FR_WHL,
DMG_RI_FR_DAM,
DMG_RI_FR_WHL,
DMG_RE_DAM,
DMG_RE_WHL,
DMG_LE_RE_DAM,
DMG_LE_RE_WHL,
DMG_RI_RE_DAM,
DMG_RI_RE_WHL,
DMG_BODY_MINOR,
DMG_BODY_MAJOR,
};

This would mean you wouldn't have percentages, but it would be reusing stuff already in InSim and would not create more flooding.
#14 - Dygear
Quote from DarkTimes :This would mean you wouldn't have percentages, but it would be reusing stuff already in InSim and would not create more flooding.

I wonder how much more of a drain on resources an extra set of MCI packets would cause. I really don't think it would be that much at all. MCI packets by themselves are not that bad, even when being parsed by a relativity slow PHP parser (compared to a C / C++ parser). Not seeing the number myself in a while I hesitate to speculate, I don't see it being more then 1% utilization on a 1.6GHz CPU (Based on past experience.). I stand by my recommendation of the specification as being the most complete offering, whether it gets implemented or not is another matter.
#15 - bluejudas
>DarkTimes
Your suggestion is fine if we do not get full support for damage reporting. It would be nice to have percentage because then we can make a smarter insim application. But I would settle for your suggestion if its to much job to do the "full implementation". I can see no reason not to implement your suggestion first and then implement some version of the other suggestion discussed in this thread after that. But not having percentage would not give full flexibility.

And some whining We need damage reporting so we can force people to drive with less risk Please please please implement it Scawen
Whining off...

Nice weather today, just -3 C deg

~b

Damage report as insim package...
(15 posts, started )
FGED GREDG RDFGDR GSFDG