On the other hand I must admit still not getting this "move this existing car to this position" packet. How I understand it:
1) Player X is on track with car Y
2) Send packet with new position
3) Car spawns at new position
If I understand this right would it then be possible to send several of these packets in a few seconds time resulting in a custom grid? It would make it possible to organize races with InSim without being bound to the LFS grids or is that a bridge too far?
It's just a little messy because you would wait for the restart, everyone would be on the grid and a second later they would all teleport somewhere else. I think you could send all the packets at once.
So the solution would be a proper custom start grid but I don't really want to get into designing that now.
It would certainly not be an example of elegance but it would do the trick. If it is possible to teleport a full start grid in under 5 seconds with this packet that would be neat. Either way, I welcome this new packet with open arms
Been playing with anaglyph mode. One thing I have noticed (other than my brain trying to detach my eyeballs) is that when using a 3D mode, the mouse becomes constrained to the virtual display area. In 2D mode the mouse can move over all screens.
But the cursor isn't just constrained, it's scaled down resulting in odd cursor control when using a triple or double screen setup, as I need to move the mouse three times as far horizontally as vertically. Can you use a sliding constraint (there's probably a proper term for this but it's all I can think of at the moment) instead of unequal scaling?
I bought a licence pure fir the rift...
The get the option for 3d and the rift i get , but i never get the popup menu that asks about starting in the rift the next start.
When i select 3d in the rift my screen directly turns into rift display , without tracking.
And then the game never starts again till i delete the cfg file... :S
I see on oculus site more guys have this issue.
i got R9 290 with 3 screens and rift connected. i tried disabling 2 screens but no luck ..
Thanks for your answers with sicotange, as he said i was thinking exactly the same, by having a custom grid so we would also have more slots into the track by using a starting position.
About the 1st one. Once you load a layout and the InSim gets this packet, LName is empty, unless you load the layout as the host(either hosting through game, or using /axload into a dedi-server), so what i am suggesting is to "Enable" LName for remote(non-host) players as well.
Just a point Scawen.
I don't own a Rift but... how would it work if you play LFS on a simulation chair with your Rift?
I mean... if the chair pitch when you throttle, the rift will think you are looking up.
You should mount the tracking camera on the chair itself, that way you will still look forward (from Rift's point of view). Only head movements relative to the chair will be tracked.
Not true because "down", as detected by the Rift, is related to the direction of gravity, detected by an accelerometer. Not down relative to the angle of the camera.
So... I don't know the answer to josemspain's question. I guess you must avoid too much seat pitching. Anyway, leaning back a lot doesn't make your your brain tell you that you are accelerating, it just tells you that you are leaning back.
EDIT: Thinking further, I guess there is still a problem when the seat pitch simply matches the uphill gradient of the car, as output by LFS, without trying to add any acceleration effects by false tilting. There is a problem with the Rift even in this case, I think. I suppose that maybe there should be a setting for LFS to use the head's real world rotation for pitch and roll, and not add the in-game car's pitch and roll. Not thought through properly but that's just what I thought of now. It would be interesting to hear what perisoft has to say about this.
There's no good solutions for this yet. What would be the easiest (to my logic at least) is to have a second IMU (identical to what the Rift has) attached to the moving platform. Then the Oculus SDK would know how the platform is oriented and could adjust the "down" vector accordingly. The camera could be either on the platform or not, wouldn't matter as long as it's implemented that way.
I think with the complete removal of external reference points, the motion chairs could be very convincingly giving you some sense of longitudinal and lateral G-force.
Could the rift (or LFS) subtract the information which is sent to the chair? So if the chair was one of those high motion Force Dynamics type chairs, and under hard braking it was instructed to pitch forwards 20 degrees, would you be able to simultaneously subtract 20 degrees from the pitch information sent by the rift headset?
As far as I know it should be the Oculus SDK that does that, figuring out the platform orientation.
If LFS fixed the head orientation from the platform info I suspect it would lead to very jittery movements because the Oculus positional tracking uses the IMU too. When accelerating you lean backwards in such a platform and in-game you should stay still, but the Rift IMU will sense the backward acceleration and think it is being moved and thus it will be seen in the screen. The SDK should need to know how the platform is moving so it could take the additional movement into consideration in the sensor fusion. If the camera sees the headset staying in place (camera on the platform) but the IMU senses movement it will lead to a conflict and I have no idea how it would handle it. If the positional tracking was done only with the camera this would be a lot easier problem.
lfs was working well for about a week with 0.6F8 patch but for some random reason. I booted it up again after not playing lfs for a couple of days and the game is now hard locked to face the camera.
My dk2 camera is off to the side for spacing reasons and resetting the position no matter what I try will force the camera to be the front of the car.
_____________________________
4770k
8 GB RAM
gtx 780
1 other monitor
Windows 8
_____________________________
Just a note that LFS is working with my DK2. First thing I've got running other than the standard demo.
My favorite so far is going wheel-to-wheel in an MRT5 race
With 0.6F8, the camera does have to be in front of you. The change was related to the "Save position" option. But it's on my list as one of the thing to do - allow the camera to be to the side again. You can freely go back to 0.6F7 to allow the position to be reset with camera at the side.
As a user of a motion chair I maybe missing something here but lfs works really well with it. As long as the in game head movements are set to zero and the chair is toned down a bit it seems to work as good as it could. Why would you need to tell the rift to subtract movement data?
As in real life when I'm using the chair and I go over a bump the chair jerks my body which in turn moves my head (like it would in real life) which then makes the view in the rift move but as long as I keep focusing forward with my eyes then that is again the same as to what would happen in real life.
Only when a game adds movements effects does it ruin the experience with a motion chair. The seating position in the car needs to be stationary and just let the chair movement move the viewpoint in the rift which lfs does perfectly now.
The limitation of motion sims is the inability to maintain g force. In a quick chicane my chair is brilliant but on a long sweeper the chair is just 20 degrees tilted over to one side with no g-force. There are chairs which can move right over onto it's side which are great for replicating g-force in long sweepers but not quick enough to respond in a quick flip flop chicane. Maybe if something could be added to the chair which pushed your rib cage from side to side could replicate g-force in a long corner? Or maybe it would bruise you up?! I guess sim racing is exactly that, not quite as good as the real thing but getting closer as technology improves.