What we been needing for quite a while now is a programmer section moderator who can keep the place in order.

I didnt even know that was planned, but found strange as hell a well populated LRF server that didnt have the word 'drift' in it, so I had to try.

Hands full keeping the thing on track, but was fun

For lazy people who dont want to click in the link in my above post, this is what nikka wrote:

When a player is in pit (PLP), his MCI CompCar struct is set to 0, including Info byte.
So, if his CompCar is CCI_FIRST or CCI_LAST, this info is missing.

(yes, this one caused some brain twisting... )

Edit: Not entire struct is set to 0, PLID is still intact.

Quote from nikka, in another thread :

Just in case you didn't know, there is a bug in the compcar struct when a player is in pit, so you shouldnt rely on the compcar.Info alone..
http://www.lfsforum.net/showthread.php?t=28061

Spent a few hours scratching my head and just found this from nikka in another thread, just so everyone knows.

Last edited by BurnOut69, Tue 21 Aug 2007, 18:00.

Good luck Dan!

Is the InSim relay working atm? I can connect and I'm getting keepalive requests but no IR_HOS at all.

EDIT: ok it DOES work, I can see both LX and sdether's hosts

Last edited by BurnOut69, Tue 14 Aug 2007, 17:27. Reason : fixed the damn bug

Quote from ajp71 :

I sense this is going downhill... and it's not entirely other people's fault, as Vic said...

pwned

Well you wouldnt be able to know the state of the car if you jump in the middle of the replay.

Accelerating or braking are there yes, but you dont know from which value.

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

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