I'm an edge case, sure, but I see the things you see between starting LFS and choosing 'multiplayer' about once a month (only when a restart of LFS or the computer is needed).
It would need to be in with the server-list, I would think, in order to be visible most often. Perhaps it could be in both places, or functional in one place with a live preview in the other place. Plenty of options to play with if Scawen likes the general idea, anyway
Sorry, I'd forgotten how this bit worked... it's been a while
You get the player flags in the NPL packet when a player joins the track, and in the PFL packet if those flags change while you're already on track. The format is the same in both places.
If you watch both packets, you should be good
You get the player flags in the NPL packet when a player joins the track, and in the PFL packet if those flags change while you're already on track. The format is the same in both places.
If you watch both packets, you should be good
1601 is 1+64+512+1024, so PIF_SWAPSIDE (1), PIF_HELP_B (64), PIF_AUTOCLUTCH (512) and PIF_MOUSE (1024).
If it's not catching the autoclutch flag from a flags value of 1601, I can only think that you forgot to copy all those defines you listed into your code? (1601 & 512) will be evaluated as true, but (anything & 0) will be false... and an undefined constant will end up being 0.
Yes, that's them. Lots of things to play with
What I'm doing with the '&' is checking to see if that bit is set. So, 'Flags & 8' will be true if the autogears bit is set for that player, and false otherwise.
If your code above is working, then you can replace the message line with this to check:
What I'm doing with the '&' is checking to see if that bit is set. So, 'Flags & 8' will be true if the autogears bit is set for that player, and false otherwise.
If your code above is working, then you can replace the message line with this to check:
<?php
$gears = $clutch = 'No';
if ($C->Flags & PIF_AUTOGEARS)
$gears = 'Yes';
if ($C->Flags & PIF_AUTOCLUTCH)
$clutch = 'Yes';
$this->MessageToAll("Autogears: ".$gears.", Autoclutch: ".$clutch);
?>
If you know how to get at the $Flags variable then it's just the code below, but I'm afraid I'm not familiar with PRISM if you need help getting at it.
$autogears = $Flags & 8;
$autoclutch = $Flags & 512;
Drone-cam drift
Send an '/end', pause for it to end the race (5 or so seconds), then send the '/track X'.
You'll also need to wait a while for the track to load if you want to start the race/qual automatically (or watch for the message 'Track loaded (X)').
If you're loading a layout, you've got an extra layer of waiting (or watching for the same message) between the layout and the race start.
You'll also need to wait a while for the track to load if you want to start the race/qual automatically (or watch for the message 'Track loaded (X)').
If you're loading a layout, you've got an extra layer of waiting (or watching for the same message) between the layout and the race start.
From what I've read about how it works, I would have thought FFB would be better in LFS than others. Myself, I've not been surprised by anything the FFB does in any situation in LFS and I can't say the same for any other sim despite very minimal usage. Too quick to judge soundly, no doubt, and there's nothing specific I can put my finger on, but first impressions and all that
One thing I do miss from a previous, crappy wheel I had was rumble. This was some thrustmaster/ferrari thing with no FFB (bungee cords for an always-on centering force, yay), but had a rumble motor. Made a world of difference when feeling for an apex when you're looking past the exit.
Perhaps there is the possibility of an option to exaggerate the force of FFB when it is changing rapidly, like a force multiplier based on a very short history of change rate. I would guess that would effectively make a rumble-like effect on curbs, but who knows if it would really work like that, or what else it might screw up. Just thinking aloud
Blackrabbi: Have you tried fiddling with the castor angle of your set? You can dial FFB force in and out with setups, but especially castor angle. Higher force might help you feel the bumps.
One thing I do miss from a previous, crappy wheel I had was rumble. This was some thrustmaster/ferrari thing with no FFB (bungee cords for an always-on centering force, yay), but had a rumble motor. Made a world of difference when feeling for an apex when you're looking past the exit.
Perhaps there is the possibility of an option to exaggerate the force of FFB when it is changing rapidly, like a force multiplier based on a very short history of change rate. I would guess that would effectively make a rumble-like effect on curbs, but who knows if it would really work like that, or what else it might screw up. Just thinking aloud
Blackrabbi: Have you tried fiddling with the castor angle of your set? You can dial FFB force in and out with setups, but especially castor angle. Higher force might help you feel the bumps.
Bish: At least 2-wide is in the definition of a racetrack, surely? 
PS to all: I tend to forget people can't see wry grins through the internet... I just mean Oulton seems incredibly narrow compared to other tracks. That's not to say it's not worth having - I appreciate that limitations in racing are a personal preference, and variety is always good - just that there are plenty of RL tracks without this baked-in restriction which, IMHO, would serve us better. And at a push, we can narrow tracks with AX objects, but can't usually widen them nicely due to the granularity of the angles available in AX concrete.
PS to all: I tend to forget people can't see wry grins through the internet... I just mean Oulton seems incredibly narrow compared to other tracks. That's not to say it's not worth having - I appreciate that limitations in racing are a personal preference, and variety is always good - just that there are plenty of RL tracks without this baked-in restriction which, IMHO, would serve us better. And at a push, we can narrow tracks with AX objects, but can't usually widen them nicely due to the granularity of the angles available in AX concrete.
If Oulton Park had walled edges instead of grass for runoff, you'd have to fold your wing mirrors in to pass another car...
Much appreciated, thank you
I have a flakey microswitch on my downshift, it fires on and off constantly when held down. Despite much effort at training myself, it takes me a conscious effort to do a 'fast click' (click and release in under 100ms) rather than a 'lazy click' (however long I take when I'm not thinking about it, somewhere between 150 and 200ms). As soon as the racing gets frantic, I slip back to lazy click.
I used 100ms when you first changed the debounce code and that worked perfectly in testing, but as soon as the next banger meet came up I'd double-downshifted by mistake once or twice in each of the first three races. I upped it to 150ms and for the rest of the night I only did it again a few times in ten or so more races. I upped the limit again to 200ms after that and now it's rare for it to happen at all, even when the racing's frantic.
If it was upshift I wouldn't mind, but double-downshift by mistake in a banger oval and your engine is damaged, even if you manage to avoid ending up backwards or getting tagged by the car behind.
I appreciate it's not exactly what the debounce is for, but one unintended repeat signal is as good as any other, no?
I used 100ms when you first changed the debounce code and that worked perfectly in testing, but as soon as the next banger meet came up I'd double-downshifted by mistake once or twice in each of the first three races. I upped it to 150ms and for the rest of the night I only did it again a few times in ten or so more races. I upped the limit again to 200ms after that and now it's rare for it to happen at all, even when the racing's frantic.
If it was upshift I wouldn't mind, but double-downshift by mistake in a banger oval and your engine is damaged, even if you manage to avoid ending up backwards or getting tagged by the car behind.
I appreciate it's not exactly what the debounce is for, but one unintended repeat signal is as good as any other, no?
I'm using it set to 200ms currently. 100ms is fine usually, but in a frantic situation such as banger racing it still catches me out quite a bit.
I'll leave it up while the tracks for the other rounds are on RG
edit: without wind
Last edited by Racon, .
Scawen has said that there won't be any new cars until after the new tyre physics is released (They would need work for the new physics, and he doesn't want to take time out of getting to the physics to do a job that would need to be redone).
When you say 'no FFB' and 'linear resistance', do you mean that there is something going on, but not as much as you expected? Or does it feel the same as if you've removed the power? (ie, I can unplug the mains from my wheel (DFGT) and it still works as a controller, just with no FFB or lights. There's a tiny bit of mechanical resistance left, which is linear).
Remember also that the castor you have in your setup has an effect on the force being supplied to the wheel. Put it up as far as it will go and drive in tight circles to get LFS supplying the wheel with a big value for the FFB. Or drive straight and fast with no hands on the wheel to see if it starts a shimmy.
Remember also that the castor you have in your setup has an effect on the force being supplied to the wheel. Put it up as far as it will go and drive in tight circles to get LFS supplying the wheel with a big value for the FFB. Or drive straight and fast with no hands on the wheel to see if it starts a shimmy.
If you're set to use 2048 res skins instead of 1024 it'll want credit to download them... but then it should skip that part with the skins in the folder, no?
Done a race restart too? (If you change a skin, it's shown as blank white on other clients until next optimise at race start, etc.
Done a race restart too? (If you change a skin, it's shown as blank white on other clients until next optimise at race start, etc.
We can rebind keys with scripts - there is an example for setting up using one button to cycle through the f9-f12 info in the docs here.
If I'm understanding it correctly, Scawen is saying you need to control the lights yourself if you want to know when they're green. The actual moment the standard lights change to green is hidden from insim (I think for foiling scripted launches) when it happens. You can work out the exact start time as soon as the first car hits the first split, but not until then.
The insim-controlled lights do lag the control packet being sent a little though, so you wouldn't have an exact time doing it through insim.
You could use an insim checkpoint on the start line to get a reference, but it wouldn't quite be on green, it'd be green + reaction time + inertia.
Maybe use both methods and tune a ratio between them
The insim-controlled lights do lag the control packet being sent a little though, so you wouldn't have an exact time doing it through insim.
You could use an insim checkpoint on the start line to get a reference, but it wouldn't quite be on green, it'd be green + reaction time + inertia.
Maybe use both methods and tune a ratio between them
In the meantime I could knock you up a webpage where you upload a PNG skin with transparency, play with a colour selector to get the colour you want, and click a button to download a coloured JPG version.
I've been meaning to do it for a while, but it's been one of too-many things I want to get to
Right, so, I made a simpler layout with 3 checkpoints and a finish, with an insim split over each one. I've added the replay and the layout if it's needed. I did two laps, and the log is below.
The good news is that the gap looks consistent That was my big worry from earlier in the thread.
(The first UCO time is the time it takes from /restart to green lights + reactions + inertia)
The good news is that the gap looks consistent
That was my big worry from earlier in the thread.(The first UCO time is the time it takes from /restart to green lights + reactions + inertia)
UCO: Time = 9.31
UCO: Time = 12.10
SPX: STime = 04.11, ETime = 04.11
UCO: Time = 15.14
SPX: STime = 07.15, ETime = 07.15
SPX: STime = 10.56, ETime = 10.56
UCO: Time = 18.56
LAP: LTime = 13.27, ETime = 13.27
UCO: Time = 21.27
SPX: STime = 02.38, ETime = 15.65
UCO: Time = 23.65
UCO: Time = 26.95
SPX: STime = 05.69, ETime = 18.96
SPX: STime = 08.49, ETime = 21.76
UCO: Time = 29.76
LAP: LTime = 11.06, ETime = 24.33
UCO: Time = 32.33
Sorry, 'raw' is just a dump of the whole packet by byte. SPX is a split, LAP is the finsih, and UCO is an insim checkpoint. The lines directly below the raw are the timing information extracted from each packet.
I'm a bit confused as to what's supposed to happening where with that track, so I just dumped the lot in case you could figure it out just from the timings
I'll try on a simple test track later on to get my head around it
I'm a bit confused as to what's supposed to happening where with that track, so I just dumped the lot in case you could figure it out just from the timings
I'll try on a simple test track later on to get my head around it
I did a straight 2 lap race with a log for UCO, SPX and LAP if that's any help
UCO Raw: 28 59 0 1 0 2 0 0 154 3 0 0 255 255 9 1 35 2 196 205 28 2 196 205 0 40 252 128
UCO: Time = 9.22
UCO Raw: 28 59 0 1 0 2 0 0 137 12 0 0 0 2 25 1 196 253 160 205 56 254 160 205 0 41 252 128
UCO: Time = 32.09
UCO Raw: 28 59 0 1 0 2 0 0 53 19 0 0 122 119 36 1 136 3 194 205 90 3 200 205 0 42 252 0
UCO: Time = 49.17
SPX Raw: 16 25 0 1 144 241 0 0 144 241 0 0 1 0 0 0
SPX: STime = 01:01.84, ETime = 01:01.84
UCO Raw: 28 59 0 1 0 2 0 0 73 27 0 0 129 128 21 1 161 3 66 197 90 3 68 197 0 43 252 0
UCO: Time = 69.85
SPX Raw: 16 25 0 1 30 49 1 0 30 49 1 0 2 0 0 0
SPX: STime = 01:18.11, ETime = 01:18.11
UCO Raw: 28 59 0 1 0 2 0 0 163 33 0 0 249 250 37 1 53 2 196 205 28 2 196 205 0 40 252 128
UCO: Time = 86.11
SPX Raw: 16 25 0 1 144 130 1 0 144 130 1 0 3 0 0 0
SPX: STime = 01:38.96, ETime = 01:38.96
UCO Raw: 28 59 0 1 0 2 0 0 201 41 0 0 0 0 23 1 195 253 161 205 56 254 160 205 0 41 252 128
UCO: Time = 106.97
LAP Raw: 20 24 0 1 210 199 1 0 210 199 1 0 1 0 0 2 0 0 0 0
LAP: LTime = 01:56.69, ETime = 01:56.69
UCO Raw: 28 59 0 1 0 2 0 0 182 48 0 0 122 119 37 1 146 3 196 205 90 3 200 205 0 42 252 0
UCO: Time = 124.70
SPX Raw: 16 25 0 1 86 79 0 0 40 23 2 0 1 0 0 0
SPX: STime = 20.31, ETime = 02:17.00
UCO Raw: 28 59 0 1 0 2 0 0 165 56 0 0 131 130 22 1 162 3 65 197 90 3 68 197 0 43 252 0
UCO: Time = 145.01
SPX Raw: 16 25 0 1 210 145 0 0 164 89 2 0 2 0 0 0
SPX: STime = 37.33, ETime = 02:34.02
UCO Raw: 28 59 0 1 0 2 0 0 74 63 0 0 249 251 37 1 71 2 199 205 28 2 196 205 0 40 252 128
UCO: Time = 162.02
SPX Raw: 16 25 0 1 96 224 0 0 50 168 2 0 3 0 0 0
SPX: STime = 57.44, ETime = 02:54.13
UCO Raw: 28 59 0 1 0 2 0 0 38 71 0 0 1 1 23 1 212 253 163 205 56 254 160 205 0 41 252 128
UCO: Time = 182.14
LAP Raw: 20 24 0 1 236 38 1 0 190 238 2 0 2 0 0 2 0 0 0 0
LAP: LTime = 01:15.50, ETime = 03:12.19
UCO Raw: 28 59 0 1 0 2 0 0 51 78 0 0 121 118 36 1 141 3 198 205 90 3 200 205 0 42 252 0
UCO: Time = 200.19Cheap sums it up perfectly, Niko. I thought the new owners might be better at seeing the bigger picture, but alas they're solving aero-related passing problems by adding... more aero. Genius. F1 is one step away from having drivers deviating from the normal line in order to collect virtual items for powerups. *weeps*.
But at least BTCC starts tomorrow
But at least BTCC starts tomorrow
I appreciate that this is both "far future" and only "don't see why not", but racing trucks has been on my wishlist since before I even found LFS... it's made my day that your response to his question is anything other than "no chance"
I've always imagined the extra wheels could cause you some programmatic grief, but then, you've had the bike hidden in there for a while and the LXs' tracks are different front-to-back, so maybe it's not as big an issue as I fear
You get to decide the minimum acceptable quality of your releases...
FGED GREDG RDFGDR GSFDG