You're pretty much right, but you can't really compare multi-sampled instruments to car engines since, for example, a piano sample bank will contain samples of every single key, probably even multiple times over for different strength and techniques, whereas a sampled car engine currently contains about 10 samples, where of course all sounds the engine produces are mixed together. Sort of like a piano bank with 10 prerecorded chords suitable for progressing from one to the next.
The quality and useability of sampled instrument banks comes from sampling an enormous amount of source, "standard" multi-sampled car engine banks is nowhere near this sort of thing.
Note: i'm not saying LFS' internal sound engine sounds more like real engines.
I've managed this many times, there's no relation to hardware, it's as simple as ...
I usually alt-tab twice and hit shift-f4 hoping for LFS to go into windowed mode, if it doesn't, repeat. It's not really an LFS bug, although it would be really nice if two sanity checks related to this could be added:
If LFS does not receive any input for x amount of time while being at the entry screen just after launch, go to windowed mode.
If LFS at launch detects another instance running (Warning - another instance of LFS is running .. ), go to windowed mode.
I've actually managed to start a second instance of LFS with the first one being in fullscreen, this loosing-focus annoyance occured and getting things back to normal became twice as tricky.
If a broadcasters LFS does not write to the temporary mpr for some time, no data can be sent to clients until it does (unless you manage to grab mpr data from memory / internal buffer). LFS still buffers and plays the replay at the same speed, meaning that if there was no data sent for some time, a replay can reach 'the end'.
Setting a bitrate wouldn't solve this, but the relay could broadcast a pause / unpause for clients to send thru insim, pausing playback if data flow is too low.
Maybe you (Scawen) could try getting in touch with some DirectX/DirectSound software synthesizer developer, the general approach to buffers etc while working with realtime generated sound can't really be a secret.
U22, I can get some very slight crackling in the BF1 at south city but I need to turn the volume up so much it's hard to tell if it's caused by LFS or if it's just distorsion. In a replay with ~17 GTR's on the grid i got some cracks/pops. Still hear steps in engine sound, they're smaller but still very audible, specially in the XFG. Don't know if steps is the right word for it so i made examples, these are very exaggerated, LFS sound isn't this bad.
All U22 tests with sound blocks at 1, there's no lag or delay, just these steps in sound. Delay/lag at 5 blocks is extreme. I run U20 with sound lag at 0.15s.
Works great , feature request would be some options for button combinations, i'd like to 'lock' the view in its current position by pressing both buttons, then return to center on release.
You would probably use a mix of the command line parameters (docs/Commands.txt), basically write batch files or create a new lfs://-protocol handling application with support for the password being part of the link.
The zero is a password flag, 1 flags the server as passworded and makes join2lfs display the text 'caution: server is password-protected', while 0 does not.
U21, audible steps and/or odd interpolated steps in engine sound, U20 brings back normal (better) sound. Seems completely unrelated to hardware / DirectX sound acceleration. Latest drivers made no difference.
3 GHz, Windows XP, Realtek AC97/WDM (VIA).
(horns work. )
Samples are stretched to twice their original length.
You're probably running php 4, which fails at declaring variables as private (php5+). This code doesn't really need php 5 and i think Dygear will remove the php 5 specifics.
The point is probably that if this little renderer would support textures, you could render small team car pictures on your linux box without a desktop environment, without going outside php and even without writing any files if you wanted to. There are probably much better ways of accomplishing this, but i don't think launching a full-featured 3d modeling / rendering application would be an option for the kind of thing Dygear has in mind.
I think the suspension damage would be enough to gradually remove that advantage throughout the rest of the lap, and i very much doubt anyone would attempt to recreate that stunt while going for a new wr.
Handling of car positions in multiplayer is much harder then handling them locally, currently you'd need to guesstimate contact by comparing distance, heading, etc, there is no packet for "contact". Even with a very good formula, the maximum settings of 6 pps as i understand it means the remote cars are in their correct positions during only 6% of physics updates, meaning there are 94 updates where positions are interpolated more or less accurately. Add lag issues and it's not a very tempting project.