Quote from the_angry_angel :

...Naturally pretty simple to implement with TCP InSim.. slightly trickier with UDP since it's stateless, but it could be faked by sending an ISI followed by an IS_VER request and then listening for the corresponding IS_VER reply, then setting the connected member?

Or even better: set a request id in the ini and wait for the Version response to the ini packet
ReqI //If non-zero LFS will send an IS_VER packet

Ok first testing results

• If you don't close outgauge on disconnect it keeps sending data to port A and if you connect with an other port B and enable outgauge it keeps sending to the port A of the first connection instead to port B.
  
• race tracking with value of "100" equals a SMALL_SSG value of 10...
  compare: // OutGauge Delay 1 :minimum delay between packets (100ths of a sec)
  with: // Time in ms between NLP or MCI (0 = none)
  => confusing!
  
• The source port of the OG packets is not the same as the port of the other packets -> my udp socket was connected to that port and didn't listen to packets coming from other ports -> no og ^^
  

Works now

OutGauge Mode 0
OutGauge Delay 100
OutGauge IP 127.0.0.1
OutGauge Port 1968
OutGauge ID 0


mh okay if it works i have to find my error ^^

I'll try with wireshark later

Oh wait that should be
UDP ->: 08 04 22 02 64 00 00 00, not?

Hm doesn't matter. Wont work

Quote from Vain :

I tested it. Outgauge works fine in patch X, without modifying any cfg-file.

Do you await OGpackets on the in the IS_ISI specified UDP-port?
Is it possible that your code only seldomly gets executed because of some blocking calls (I know several libraries where the TCP-receive call is a blocking call).

As written; Testing with udp only and with tcp returns the same result...

I'm sending the following to lfs.
Connected with local port: 1831
UDP ->: 2c 01 22 00 27 07 10 00 00 00 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00
ISI with the local port set and lfs displays the port in brackets ingame.
UDP ->: 08 04 22 02 00 00 00 64
The ISI small of type SSG and delay of 100ms and LFs displays "Outgauge: enabled"

But I only receive the isp ver and the race tracking packets.
UDP <-: 14 02 22 00 30 2e 35 58 00 00 00 00 53 32 00 00 00 00 04 00

Quote :

But beside that: Does anyone know why sizeof(OutGaugePacket) yields a size of 96 bytes, but the actual OGP is only 92 bytes long?

Vain

The optional ID at the end is not send if you initialize it through insim iirc.

Nope, as it's not even working if I "only" use udp for insim. And if you use only udp the outgauge packets should arrive on the same port as all other packets. Or if you use TCP and set a UDP port they should arrive on that port like the race tracking NLP/MCI do.

edit: above is resonse to angel.

Did anyone else tested this or did succeed in receiving out* without modifying the config?

Why?

I mean it just sucks when you connect to a server, load 30 high res skins to find out that you are not allowed to drive...

I mean just add some info which says "you can only drive if you have a pb better than 1:40" when connectiong to CD2

Nah, but I can attach the restart in .zip format wich windows can open natively ^^

But please add an info to the connection message

you should have told scawen before X ;p

it's probably simply ignoring the insim ports when activated through insim
"// The OutGauge packets will be sent to the UDP port specified in the InSimInit packet." Only getting NLP and MCI over that port (or all using udp only)

Can someone confirm that Outgauge/Outsim work in patch X when initialized?

I get "outGauge : enabled" and "OutSim : enabled" in LFS but I don't receive any packets

Well... 0 "some"times or once is not necesarily an error ^^
It's just LFS doesn't know as stated in the doc.

But Knu says it's always 0

Also my RST is working:
ISP_RST: 1c 11 22 00 0d 00 01 00 4b 59 32 00 00 00 00 01 00 00 52 02 fe 01 68 00 44 01 ff ff

I'm not sure either ^^

All I can say is that i receive positions:
3-driver NLP: 18 25 00 03 ' ca 00 03 00 02 01 ' c1 00 03 00 03 02 ' 9a 00 03 00 04 03 ' 00 00

I don't know at which point there is an error but. Perhaps start with showing your INI packet.

I'm getting correct positions in NLP.

Perhaps show your code

Quote from Peptis :

It would be useful if some of the other fields were updated along with the Text field when W and H are zero. This would enable us to move buttons (changing L & T fields) or change their styling (BStyle field) without having to delete the original button and create a new one.

Furthermore, if the above change was made, an invisible button style would also be useful as it could simplify the control logic of our InSim programs.

If you just send a button with the same id the old one is deleted. So ... just store the position somewhere

Quote from RocksGt :

It will be available for automatic update from inside the game?
I suppose it will . The point is: It will be possible to do NOT update and play multiplayer with old version?
We have our monday race at LFS-Spain and we don't know if we'll have all servers updated to patch X on Monday evening, so maybe we need to not update in order to be able to play

Sorry if this is already commented but didn't find anything about it

The "real" patch should be available in the automatic system. That's what it is for...

sure.

And if your car has a pit limiter you have to disable it once manually if you leave the pits

Hmm yeah probably

But that's a problem which cannot be solved throug scripting as you have no conditions and such in the system.

You could however write an insim app with outgauge and... :chairfall

Well...
X is the button on your pad with which you want to enable the pit limiter and open F12.
DPAD_'s are the button numbers of your d-pad.

Replace them through the correct numbers lfs displays in the controller settings when you press the button.

Then put the following scripts in the scripts folder and change the "what you want" parts to what you want ^^

autoexec.lfs:

Quote :

/ctrlf 8 /run openF12
/button X ctrl_f8

now the openF12.lfs:

Quote :

/button DPAD_U ctrl_f12
/ctrlf 12 /press up
/button DPAD_D ctrl_f11
/ctrlf 11 /press down
/button DPAD_L ctrl_f10
/ctrlf 10 /press left
/button DPAD_R ctrl_f9
/ctrlf 9 /press right
/press F12
/press l
/ctrlf 8 /run closeF12
/button X ctrl_f8

and the closeF12.lfs:

Quote :

/press F12
/press l
/button DPAD_U "what you want"
/button DPAD_D "what you want"
/button DPAD_L "what you want"
/button DPAD_R "what you want"
/ctrlf 8 /run openF12
/button X ctrl_f8

Quote from Scawen :

FIX : Start lights delay did not vary each race if wind was disabled

There is still a problem with the "random delay". If you start counting as soon as you see the lights (NOT the first red, but the grey box) it's always the same time until the green light goes on.

Example: (5 or 6 seconds depending how fast you count ^^)

The time between showing the first box and the green light is 6 seconds.

Now the red lights take ~2 seconds.

Makes 4 seconds which are randomly split into the timespan between showing the box and the first red light, and between the last red light and the green one.

You could ask the fragmasters admins how they do it on their oval server.

I don't know who their admin is but you can porbably ask someone on the team
http://www.lfsworld.net/?win=r ... mp;whichTab=teams&c=F

I am definately for this change as MCI produces a lot of overhead if you just want positions and don't need the rest

What about making everyone spectate and then making a 30 Secs cooldown in which you can join the race again?