LFSLib.NET 0.15b
(11 posts, started )
LFSLib.NET 0.15b
Cheers
Hey,
Much appreciation for your work here. I used LfsLib for my final project in uni - trying to automate car set up (on a restricted domain).
Omar
Much appreciation for your work here. I used LfsLib for my final project in uni - trying to automate car set up (on a restricted domain).
Omar
Possible problem in penalty handling
I think I may have identified a problem with either your library or LFS.
I'm writing an InSim application that gives out Stop-Go penalties to players when a certain event is triggered. In the event handler I send the stop go like this:
The player receives the Stop-Go correctly in LFS, however in the handler for RaceTrackPlayerPenalty, i.e.,
e.NewPenalty has the value of Enums.Penalty.StopGoValid instead of Enums.Penalty.StopGo. Is this correct? I thought that you'd get a Enums.Penalty.StopGo on receipt of a penalty and Enums.Penalty.StopGoValid when you complete it.
(When the user then completes their stop go e.NewPenalty has the value of Enums.Penalty.StopGoValid as is expected.)
I'm writing an InSim application that gives out Stop-Go penalties to players when a certain event is triggered. In the event handler I send the stop go like this:
handler.SendMessage("/p_sg " + PlayerName);The player receives the Stop-Go correctly in LFS, however in the handler for RaceTrackPlayerPenalty, i.e.,
void handler_RaceTrackPlayerPenalty(InSimHandler sender, RaceTrackPlayerPenalty e)e.NewPenalty has the value of Enums.Penalty.StopGoValid instead of Enums.Penalty.StopGo. Is this correct? I thought that you'd get a Enums.Penalty.StopGo on receipt of a penalty and Enums.Penalty.StopGoValid when you complete it.
(When the user then completes their stop go e.NewPenalty has the value of Enums.Penalty.StopGoValid as is expected.)
I'm not sure I understand what the valid vs. lacking valid versions of the penalty are, but I just looked at the packets coming in and that's what LFS is sending. So that's either what it's supposed to be or it's a bug in LFS.
I guess we need to hear from Scawen on this issue. I assumed that you'd get a StopGo packet when you receive a stop-go penalty and a StopGoValid packet when you complete one correctly.
That certainly sounds like the sensible order, so yes, it's a matter for Scawen to chime in with intent.
The following code in RaceTrackPlayer always returns zero because it is doing an integer divide, i.e. byte / integer = integer.
Change it to
resolves the issue.
public decimal HandicapIntakeRestriction
{
get { return packet.H_TRes / 100; }
}
Change it to
public decimal HandicapIntakeRestriction
{
get { return (decimal)packet.H_TRes / 100; }
}
resolves the issue.
Thanks for fix. 0.16b will be out as soon as the relay stuff goes official.
No problemo... was just a bit of a headscratcher for a few.
I was alerted to this by Victor as he saw this and was also confused by it. I don't think there's any LFS bug here.
The "valid" values are not set when the penalty is cleared, they are set when the penalty is ready to be cleared. That's to stop you getting a penalty and clearing it immediately on the same drive through the pits. So the "valid" value is set when you pass a split time point.
When the penalty is cleared the penalty status reverts to no penalty.
I think for most InSim programs you can assume that DT or DT_VALID are the same thing - the driver has a drive through penalty that must be cleared at some point.
The "valid" values are not set when the penalty is cleared, they are set when the penalty is ready to be cleared. That's to stop you getting a penalty and clearing it immediately on the same drive through the pits. So the "valid" value is set when you pass a split time point.
When the penalty is cleared the penalty status reverts to no penalty.
I think for most InSim programs you can assume that DT or DT_VALID are the same thing - the driver has a drive through penalty that must be cleared at some point.
LFSLib.NET 0.15b
(11 posts, started )
FGED GREDG RDFGDR GSFDG