Thats a great idea sd! Even though I find more fun to write my own library, I'm sure loads of people will make good use of those examples.

Keep up the great work!

Obviously Eric wants everyone to appreciate his upcoming awesome interiors

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?

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

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.

Last edited by BurnOut69, Wed, 4 Jul 2007 12:29. Reason : Added session start info suggestion

Some people may be forgetting than even if it is true that the small GTRs provide a true new class to racing, they are still FWD, and some (most I think) people dont enjoy driving them as much as RWD cars. Yeah it looks very cool in the stream seeing new cars, but it is really worth it? Driver's enjoyment should be above the spectators IMO.

If there was an N-GT class with less powered RWD cars I'd go for it as GT2, but since we got nothing like that, my vote goes for restricted GTRs.

Latest insim uses TCP, if you have it enabled in your dedi, there you go

funny how talking in pseudo-spanish seems to be the trend lately :P

On topic, nice to see we all agree that fly2mars is a serious bug and it would be nice if it was fixed soon, so +1

Quote from qoncept :

+1 for this. I think its almost inexcusable to not have a favorites list, and it'd be very easy to add.

Oh yes, it would be very easy to add, and I guess you make this assumption based on your total ignorance of LFS internal structure and/or programming?

Every time I see someone saying "add this I bet it takes 5 minutes" I find it 'funny', only Scawen knows what it takes and if it was very easy or it would take 5 minutes it would be already in, dont you think?

EDIT: On topic, +1 for the idea of a list of favourite servers.

I tried parsing the same replay with the same insim engine but in an app without UI and it seems to work properly, so I think the problem is definitely in my side, and that the bottleneck happens when the UI updater cant keep with the amount of packets received.

I'll keep testing and post here if I discover something wrong.

Thanks for your reply, re-reading my msg I wasnt very informative: it is LFS who is showing that message in big red letters, not my program, so theres not much I can do AFAIK.

Process is:

- Start my program (C#)
- Start LFS and open the insim port
- Go to replay/mpr/select a replay with lots of action (27 drivers)
- Everything seems to be working for about 45 seconds
- LFS shows INSIM ERROR: WOULD BLOCK
- My app times out and LFS frame rate drops to 5, I have to restart both LFS and my program.

I assume Scawen is showing the exception message as last resort in the case of unexpected socket exceptions, but I'd love to know if its my program who is causing it and why

Anybody knows what this means? Im getting it when playing a MPR with my InSim app connected. Right after getting this error my app times out.

Bienvenido a LFS!!

Tu habitación mola

Quote from danowat :

Oh shit...............

lol!

Too bad I wont be home for the first and I'll probably miss the start of the 2nd race but GO GO Dan!! *\o/*

OK, I understand it now: you want to track the position of every car at any given moment, so the standings dancing at the end of the race in the scenario you described would mess up your positions chart.

How about this: Even if you get MCIs before RES, you have the MCI.node in which the car is, so you can check if the current node is after the finish line. In that case you would just ignore that position info.

Quote from Aquilifer :

One suggestion was that you lock the position yourself if you get RES. It's just that I wouldn't trust, especially with UDP, that the RES is the first packet you get after the car crosses the finnish line. You could get a time line like this (I think)...

Right, I wouldnt rely on that either, specially with UDP. But keep in mind that I was talking about locking the position with the ResultNum of the IS_RES packet, thats the guaranteed confirmed position of the car, so there shouldnt be a problem locking position with that value

+1, I was using MCI because NLP didnt have this byte.

Well, to keep getting MCIs every X milliseconds only to be discarded seem like a waste of bandwidth and CPU for me. Yes, its no big deal to solve the problem, but even better than solving a problem is not having it

Quote from Aquilifer :

I tested it too (W39). However i found one interesting 'feature' in it. Not sure if this is intentional...

The positions change even when the race is over. I tryed with few AIs and after the race I moved my car ahead and behind the AI cars and my and AI positions changed respectively.

That is confirmed, MCI packets keep arriving even after all cars have finished, which mess up positions and IMO doesnt make sense since from the point the race is over, tracking should be over too. It can be dealt with by 'locking' the position of each car after their corresponding IS_RES arrives, but a better solution would be that LFS stopped sending MCIs after all cars have finished.

Last edited by BurnOut69, Mon, 4 Jun 2007 07:24.

Hap-pie birthday!

W37 tested, positions byte works like a charm

For future patches (Y?), however, it might be a good idea to add this byte as well to the NodeLap struct as someone already pointed out.

Quote from Scawen :

OK, There were spare bytes in the CompCar structures so I've put the race position in there. That will be in W37.

Thats awesome Scawen, thanks a lot.

One suggestion: would it be possible to include the race position of the car in the NLP/MCI packets?

http://www.lfsforum.net/showthread.php?t=25126

Right now we are able to know at any given moment in which lap any car is and in which node. Adding some stuff it is possible to get the standings of a race playing with those values.

But wouldnt it be MUCH easier if we got the value for the position of each car in every race tracking packet? Yeah it can be calculated but it would make things much simpler if 5 bits of the NLP or MCI packet were for the position of the car.

Unless I'm missing a better way of getting standings than comparing laps and nodes each cycle...which isnt even accurate when more than one car is in the same node.

Typo: IS_BTT size is 68 according to documentation but it should be 104 (4 bytes header + 4 bytes properties + 96 chars of text).