How is it related to that? A real automatic doesn't magically know which direction you intend to go in, you have to tell it by either pressing the appropriate button or moving the lever to the correct position.
Perhaps you're thinking of a method commonly found in games, where the brake pedal acts as a reverse gas pedal. This is not the case with any real road car I know of, for fairly obvious reasons.
Not at all, that (solid!) hook can cause severe injury at much lower speeds than that area of the (flexible!) bumper would cause otherwise. Think about the area the blow will be distributed over compared to the essentially pointy end of the hook.
Again, that's not possible the way LFS Record runs the replay. It doesn't matter whether you actually use LFS Record to dump the still frames or Fraps. LFS Record pauses the replay and advances it frame by frame, setting the camera to the exact parameters it has calculated. Real time playback would mean a loss of precision, eliminating one of LFS Record's biggest advantages; Pixel perfect reproduction (with the exception of wind I mentioned before).
LFS Record does nothing of what you describe, it instructs LFS to make a screenshot. LFS Record would have to request the screenshot (write to disk), load the bmp into memory again (read from disk), do whatever processing it's set up to do and stream it to disk again.
I meant LFS Record crashed, but that was in an early version and I don't know how to reproduce it, so no worries.
Could it be related to the orientation of the camera? I had crashes when I keyframed the orientation on a LookCamera around 360°/0°.
No, as I wrote before, LFS doesn't render the sound at all because the replay is paused and advanced frame by frame. The only way to circumvent that would be to let the replay run and push camera positions on the go, but that would leave easing and interpolation to LFS, it only permits a "time to get there".
The laws of physics don't toggle on / off at certain speeds, they're permanently on. That spoiler is effective, whether the effect is desirable or not is a different question.
Last edited by morpha, .
Reason : splitter -> spoiler
File > Scripts > Run Script File
That's assuming perfectly sequential large block writes ops, doesn't apply here.
Quite simple: LFS doesn't render sound the way LFS Record plays the replay. It couldn't really, the replay is paused and simply advanced frame by frame.
LFS Record will push your HDD pretty heavily, 6mb per Full-HD 32bit frame. Doesn't take many of those to exhaust the buffer, and once that happens, you'll bog down to actual disk write speeds, which is what causes the stuttering.
Because LFS Record captures single frames frame by frame, recording sound simply isn't possible. The upside is that it ensures (almost) pixel-perfectly identical frames every single pass you run. "Almost" because there is one inconsistency: Wind. LFS uses a new random seed every time it is started, so if you want to record multiple passes, you mustn't restart LFS between passes or the flags and any other objects affected by wind will almost certainly be different, including particles (dust, grass, smoke).
Yes it was.
Strange, now I'm also experiencing the frame drop issue, 50% in fact. On my RAID 0 array it skipped odd numbers, on my VelociRaptor it skipped even ones 
In LFS I can hold down CTRL + S for minutes and it won't drop any, so there's no disk write issue of any kind.
Only difference, apart from the load on the disks, is that this project is set to 75fps, the one that worked flawlessly was at 100fps. Resolution is the same, 1920x1080.
In LFS I can hold down CTRL + S for minutes and it won't drop any, so there's no disk write issue of any kind.
Only difference, apart from the load on the disks, is that this project is set to 75fps, the one that worked flawlessly was at 100fps. Resolution is the same, 1920x1080.
Works fine for me with DE-AT and EN-UK keyboard layouts, it's somewhat cumbersome with the EN-UK layout because "." (full stop) and "," (comma) shift to ">" (greater than) and "<" (less than) instead of ":" (colon) and ";" (semicolon) respectively.
Doh! Yeah, that makes a hell of a lot more sense
That'll be difficult, replacing the characters won't help because they apparently cause some corruption during the saving process, adding additional bytes where none belong. And since they're not visible in LFS Record you don't get to know what to look for in the file
Those tail plates are awesome!
Same problem and I think I've narrowed it down to the layer name. It only occurs when I attempt to save/load a layer with certain characters in its name, specifically square brackets. My AIs are named ^7morpha ^2[^700^2] through ^7morpha ^2[^719^2], extracting their Car Data and saving without renaming the resulting layers will corrupt the file, or at least make it unreadable to LFS Record. If I rename the layers to Car #1 through 20 it works just fine.
Attached you'll find a screeny showing some characters that shouldn't be there
Attached you'll find a screeny showing some characters that shouldn't be there
I captured 1740 frames (10 gigs) and it didn't skip any
Gills, the car example you provide seems to assume the car is travelling at constant speed, the chair/elevator, however, keeps on falling = accelerating. A direct comparison is difficult because the car example describes movement along an axis not affected by gravity or any other constant force.
To make this easier, let's assume the vehicle isn't a passenger car but a flatbed truck. Let's say it's travelling at a constant 40kph and you're standing on it. Jump now and you might move back just a tiny bit because of the air resistance, but other than that your inertia will pull you along. However if the truck accelerates at, let's say, 0.2g (1.962m/s²) a 1 second jump will already displace you by that much and that's ignoring any resistance! Obviously when you land you'll still be doing almost 40kph so even though you jumped off the truck just fine, you'll have trouble staying on your feet once you land.
The elevator/chair situation is different though since gravity will still affect you even after detaching yourself from the elevator/chair.
To make this easier, let's assume the vehicle isn't a passenger car but a flatbed truck. Let's say it's travelling at a constant 40kph and you're standing on it. Jump now and you might move back just a tiny bit because of the air resistance, but other than that your inertia will pull you along. However if the truck accelerates at, let's say, 0.2g (1.962m/s²) a 1 second jump will already displace you by that much and that's ignoring any resistance! Obviously when you land you'll still be doing almost 40kph so even though you jumped off the truck just fine, you'll have trouble staying on your feet once you land.
The elevator/chair situation is different though since gravity will still affect you even after detaching yourself from the elevator/chair.
Well you don't really need Mythbusters for this, do you? Gravity pushes you down 9.81 metres per second per second, how many metres per second per second can you jump?
Even if you could somehow produce the required energy, the jump necessary to avoid injury would make you jump through the elevator cabin
Besides if you really jumped just prior to impact, the jump would cause the same damage.
Even if you could somehow produce the required energy, the jump necessary to avoid injury would make you jump through the elevator cabin
Besides if you really jumped just prior to impact, the jump would cause the same damage.
FGED GREDG RDFGDR GSFDG