Quote from Scawen :

I don't think that would be a trivial update, because of the complexity of it. The slipstream effect is calculated as a contribution of a varying air speed vector in a stretched oval behind the lead car(s) combined with the actual wind speed. It can vary from a tiny amount to a large amount depending on several factors.

It's possible it could be boiled down in some way, but that depends on what you want to use it for.

EDIT: To me it sounds more like something that could be in the MCI packet. Something like "amount of slipstream" or "similarity to driving in a vacuum" though I haven't looked into how that could be calculated.

How do you calculate the amount of drag that is removed from each aero feature on the car? Shouldn't you be able to use the same calculation as the basis of scale?


We can then use this as a basis for any value of > 0.0 is a car that is receiving a draft and other programs that want to threshold this information could use anything above 0.20 as the basis for DSQing the lap.

--- Edit ---

Odd request perhaps. But once you start an InSim instance (by the command /insim=$port) could it send a ISP_ISI packet on loopback? Kinda like "Hey, I'm here." I leave my InSim instance running, in the background even when I disconnect and close LFS. If it could automatically reconnect once the LFS instance of InSim is ready that would be cool. Useful when debugging, I think.

Last edited by Dygear, Fri 5 Feb 2016, 08:44.

Should always use the wizard! Vic did a fantastic job on that part of PRISM.

I may "borrow" some of this code for the Timing&Scoring plugin.

Just submit a pull request with your changes. And Git will merge the rest.

Like Povo did here.

Last edited by Dygear, Fri 5 Feb 2016, 06:22.

Quote from cargame.nl :

Thanks Dygear but I am already a step further by changing MSO/III/ACR packets to var packets

Get a Github account and commit the code. No reason why we can't share.

Quote from cargame.nl :

I skipped the JRR section because I think it doesn't work. Or at least I don't know how to correctly send a packet in your setup. It seems the packing for ObjectInfo is missing.

Haha! You're right! I didn't include the pack function! Woops!

These two commits should bring you up to date with the current version of InSim.

Updated packets to 0.6K12 and INSIM_VERSION 7.
Added $JRR array for the JRRAction enum.

And it follows the standard set out by the other packets. No idea if it works, so please check it out.

I find it odd that the IS_BFN packet morphology changed from 'CSize/CType/CReqI/CSubT/CUCID/CClickID/CInst/CSp3' too 'CSize/CType/CReqI/CSubT/CUCID/CClickID/CClickMax/CInst'.

Inst was moved too the last byte, and ClickMax was moved to it's position. I would think there is going to be some BC breaks on that right? Or is it because Inst is exposed but not used that it doesn't matter.

Last edited by Dygear, Thu 4 Feb 2016, 11:11.

Quote from sicotange :

I have one complaint concerning IS_JRR. When you teleported a car (on a grid for example) the car is moving because the handbrake is not on. This is a problem. Cars spawned on a grid before a race shouldn't move at all.

Am I the only one bothered by this? Scawen, can it easily be turned on by default?

That's a fair point, actually.

Make sure you have a plugin that's handling those packets. You could be getting them but never using them.

The irony the it dies on an RIP packet.

It is very difficult ... But I'm awesome so there's that.

It would be something along the lines of Pull from here download this and run both. Then watch the set fault.

Awesome! Segmentation faults are fun! I'll submit the bug report to PHP as segfaults are not supposed to happen.

Is there an error that you can show? A screen shot of what you see when it crashes? Error logs that you can post?

What's the server you're running this on? OS, and where are you getting PHP from? Building from source, download from a website, apt-get, yum, or pac man?

You're looking for the point blocks Z value. If you don't know how to parse this information, I have a parser written in PHP.

Quote from Victor :

Looks like I will have to dust off the Flash IDE to fix this one.
Hopefully I'll have an update later today.

Oh god, please no more flash!

Quote from cargame.nl :

Now it works without hex hacks which I described in my earlier (now deleted) posts. The Vec3 structure is not the same as the packets produced by LFS but no clue how to fix this. For some reason LFS listen also to this structure.

* note that the l3 hack @function pack() still is needed!

Vec is 3 Ints, X, Y, Z. (12 Bytes)
Vector is 3 Floats, X, Y, Z. (12 Bytes)

While they are different things, they happen to be the same size in memory.

l3 within the function call is not a hack, it's really how it needs to be done. DarkTime's libaries handle this better then PRISM does, but it also does it with a little more overhead. It places a wrapper around the Vec structure. We could do the same thing within PRISM, the overhead it's self is negligible. The Pos function would accept $X, $Y, $Z as paramaters and pass them through to the Vec class on packing / unpacking.

You managed to crash PHP, that's impressive from user land.

I'll take a closer look at this tonight with PRISM running instead of making wild guesses.

Quote from Degats :

Would this work? (A guess based on what the php pack() funcion does)


<?php 
IS_CPP()->Pos(pack("l3",-39175822,11394484,1037662))->H(65117)->P(757)->R(0)->ViewPLID(0)->InGameCam(0)->FOV(24.60000038147)->Time(0)->Flags(0)->Send();
?>



edit: nm, it probably doesn't. I'll try to take a proper look into it later

Yep, that should work. As it's producing a datasize the same as the required input.

The key point being the `->Pos(pack('l3', $X, $Y, $Z))` in your code example.

Quote from Popughini :

Someone has created a system for the Dcon you can play music or radio for server users?

That's not possible.

Quote from dawesdust_12 :

Given LFS' current state, more marketing isn't always a good thing.

That's a very good point. But I still voted yes because "Moar money!" for the devs. Putting this on Steam AFTER S3 comes out would be a much better idea.

Although an electric power trained car in the game could be interesting.

Nice job on the Wiki. As far as the Mac side of things, I'm running the Beta of 10.11 now, and WineBottler works like a charm still. Homebrew and Ports complain and refuse to install on platforms they don't know. Because I'm on 10.11 El Captain Dev preview I can't even try to install brew or ports. WineBottler just works. Can't tell you about controller support as I use a mouse.

Ah ... Yeah. Sorry about that. I don't see an issue with it then.

LFS on MAC OSX 10.10 Yosemite using WINEBottler.

For MAC OSX.

Allow connections from 127.0.0.1 and ::1 without a password. What about linux servers running multiple hosts on a single machine? If I were on the same VHOST as another server wouldn't I be able to commandeer their server.