a packet: if a car has pitlimiter on or off
It would be nice if we could be able to know what cars are under yellow. Right now its possible to know which car is causing it, but not which are under.
Would be useful to enforce 'no passing under yellow' rules, among other things.
EDIT:
- Add session start time to IS_STA, as datetime (8 bytes), or new requestable packet (IS_SSN, session info), though a lot of info would be already included in IS_STA.
Would be useful to enforce 'no passing under yellow' rules, among other things.
EDIT:
- Add session start time to IS_STA, as datetime (8 bytes), or new requestable packet (IS_SSN, session info), though a lot of info would be already included in IS_STA.
But it's possible with racetracking.
You just need to track which car is at which node and you are almost done.
You just need to track which car is at which node and you are almost done.
Why are you assuming 'causing yellow' means 'causing yellow for node X'?
Maybe I've missed something but I dont recall having read that anywhere
Maybe I've missed something but I dont recall having read that anywhere
It means causing yellow for car C.
But if you track the cars through NLP packets you can store for each car at which node it is at the moment. -> Flag Y for Car C + Node N for Car C => Flag Y for Node N
But if you track the cars through NLP packets you can store for each car at which node it is at the moment. -> Flag Y for Car C + Node N for Car C => Flag Y for Node N
Again, you are assuming that if a car is causing yellow, it is causing yellow for the node that car is in, have you confirmed this or you're guessing?
Requesting a change to the InSim packet, MTC to make use of the Sp2 variable to define where on the screen the message shows up and the use of Sp3 variable to say how long it should stay on screen (in seconds) or in the case of zero, stay on screen for the default amount of time the chat message would stay on screen.
enum
{
MTC_CHAT,
MTC_RaceControl,
MTC_SubRaceControl,
}
<?php
# Display to Chat for 2 seconds.
$MTC = new MTC;
$MTC->PLID = $plid;
$MTC->Msg = "There's a limit of 64 chars here.";
$MTC->Sp2 = 0;
$MTC->Sp3 = 2;
$MTC->send();
# Display as Race Control Message for 5 seconds.
$MTC = new MTC;
$MTC->PLID = $plid;
$MTC->Msg = "There's a limit of 64 chars here.";
$MTC->Sp2 = 1;
$MTC->Sp3 = 5;
$MTC->send();
# Display as Sub Race Control Message for default chat time.
$MTC = new MTC;
$MTC->PLID = $plid;
$MTC->Msg = "There's a limit of 64 chars here.";
$MTC->Sp2 = 2;
$MTC->Sp3 = 0;
$MTC->send();
?>
Sorry to drag up old ground but could an iVibe packet be created? I am not sure what that would mean exactly but I understand they have made a specific request in detail previously.
I sort of get the impression form the various threads about ivibe support that 90% of what they need is available by mix and match from the other packets and they are being a bit lazy not even creating 90% support. However, while new packet are being created could this be considered? Maybe then add the surface under each wheel info which seems to be the one thing they can't get. I am not sure if they use that info for canned effects which goes against how LFS deals with things but letting someone else respond that way wouldn't be considered selling out would it?
Maxim
I sort of get the impression form the various threads about ivibe support that 90% of what they need is available by mix and match from the other packets and they are being a bit lazy not even creating 90% support. However, while new packet are being created could this be considered? Maybe then add the surface under each wheel info which seems to be the one thing they can't get. I am not sure if they use that info for canned effects which goes against how LFS deals with things but letting someone else respond that way wouldn't be considered selling out would it?
Maxim
Why don't you use buttons for that purpose ? You can do your own chat box with them (with scrollbars if you wish :nod
.MTC is just for console text and is probably a problem to make it behave any different that other text.
Not to be completely useless post
, someone mentioned packet to indicate closure of InSim. I also think that would be good packet to add.RCM's would be under (or over) the button. It would look stupid.
O you mean rcm messages not mtc ? Yeah they are annoying. I wish they could be turned off from insim...
Sure it can be done with buttons, but that's not the point! The proposed change would make a packet that could send a message to connection that can take any form. It could be a chat message if you needed it, It could be Race Control Message if you needed it, or if you what something in between like a Sub Race Control Message.
What I what is an MTC packet that could also be sent as an RCM message, or an chat message, or even a Sub RCM message.
Having a packet for RCM's would be nice, as would being able to send "sub"-RCM's.
Yeah, RCM packet would be nice. Having an RCM command that would be able to wave the yellow or blue flag would be nice to.
But to me, having the ability to read the speed and position in the IS_LAP and IS_SPX would be a great addition as it would reduce the need for sampling the MCI packets if you don't need the information provided in them, which in turn reduces bandwidth usage. Also, adding the Lap to the IS_SPX would be a boon too, for sanity sakes.
Ideally, I would love to see the CompCar structure included in both the IS_LAP and IS_SPX packet.
Shouldn't be too much of a strain on the network. If you have 32 cars at Blackwood, and run the tracking at 100ms interval, that's 600 MCI packets containing 32 CompCar structures over one lap or 19200 CompCar structures . Split and lap packets (2 splits and 1 lap packet) would send out 96 CompCar structures over one lap. Even if you run at 500ms interval (which doesn't do a lot of good when you are trying to capture each node's information and are running at 5+ nodes per second) you still end up with 120 MCI packets, or 3840 CompCar structures having been sent.
But to me, having the ability to read the speed and position in the IS_LAP and IS_SPX would be a great addition as it would reduce the need for sampling the MCI packets if you don't need the information provided in them, which in turn reduces bandwidth usage. Also, adding the Lap to the IS_SPX would be a boon too, for sanity sakes.
Ideally, I would love to see the CompCar structure included in both the IS_LAP and IS_SPX packet.
Shouldn't be too much of a strain on the network. If you have 32 cars at Blackwood, and run the tracking at 100ms interval, that's 600 MCI packets containing 32 CompCar structures over one lap or 19200 CompCar structures . Split and lap packets (2 splits and 1 lap packet) would send out 96 CompCar structures over one lap. Even if you run at 500ms interval (which doesn't do a lot of good when you are trying to capture each node's information and are running at 5+ nodes per second) you still end up with 120 MCI packets, or 3840 CompCar structures having been sent.
Is it possible to add the distance (or 'track ruler measurement') to the IS_NLP or IS_MCI packet?
I'd like to extend LRA with a possibility to capture laps as they're driven (or replayed). I know the packets contain the node and the car coordinates, but for a good comparison with laps from RAF files I need the distance.
I'd like to extend LRA with a possibility to capture laps as they're driven (or replayed). I know the packets contain the node and the car coordinates, but for a good comparison with laps from RAF files I need the distance.
on the Lap Packet, $UserLaps++; From there you can also test to see if the laps match the amount your program said he has.
The point wasn't to track the # of laps, but rather to make sure you know which split belongs to which lap in case things get out of sync. Very similiarly to how the CarInfo contains the lap number. You could infer the lap number of a given CarInfo packet based on the last IS_LAP packet received, but you'd have to make assumptions. With the IS_LAP packet you *are* assuming that it applies to the the last IS_LAP packet.
Don't quote me on this one, and I'd like to be told I'm wrong if I am, but the TCP connection should not allow for that exception. All packets are ordered.
Sure TCP is guarenteed order of delivery, however since both TCP and UDP protocols are supported, it does matter.
Fair point.
just was posting about the /pitlane bug.. a little late to the party.
Any urgent InSim requests?
(71 posts, started )
FGED GREDG RDFGDR GSFDG