You probably need to include the \filename.cfg too.
Specs aren't really guides / tutorials, are they?
Using 9.01 build 8542, just as fast and brilliant as ever.
Which, in my opinion, is a whole lot better then alot of people not knowing which commands are available.
And when they can't see people typing !help either, a lot of users still won't understand.
There's no point in having public commands and extras available if the majority of people can't use them, both of you are basically pointing out that alot of people notice new stuff by seeing others use it, which is a good thing, in my opinion.
Your connection, obviously related to LFS since multiplayer needs a reasonably stable/good connection to work properly.
If this was something new caused by LFS i'm sure the forum would be quite flooded with similar threads, which it isn't. I've seen a few posts about start lag being increased, which i've also felt myself, but nothing like "everyone see me as lag".
Also a good idea to include which version you're playing, in these times of 20 compatible patches/versions being around.
What bal00 is saying is, ping and lag are not directly related to your amount of bandwidth (speed), latency (ping, lag) depends on how fast a bit of information can travel from your computer to its destination, it doesn't matter if your connection can push 100kb or 1000kb thru the wires per second, what matters is how fast 0.001 kb can move from point A to point B disregarding the total amount of information you're sending.
About replays being laggy, LFS in multiplayer mode has a maximum rate of 6 position updates per second, and most servers run at an even lower rate to save bandwidth. This means a multiplayer game can basically never be as smooth as an offline game, provided cars move fast enough so their movements cannot be covered by these 6 updates per second. UF1's tend to jerk around less, BF1's tend to jerk around more.
As for movies being smoother then your mpr's, this can be the result of picking out scenes which doesn't lag too much, or a bit of frame blending or blurring to cover up tiny amounts of lag. Movies also run at a lower frame rate then the game which could also cover up small amounts of lag.
About replays being laggy, LFS in multiplayer mode has a maximum rate of 6 position updates per second, and most servers run at an even lower rate to save bandwidth. This means a multiplayer game can basically never be as smooth as an offline game, provided cars move fast enough so their movements cannot be covered by these 6 updates per second. UF1's tend to jerk around less, BF1's tend to jerk around more.
As for movies being smoother then your mpr's, this can be the result of picking out scenes which doesn't lag too much, or a bit of frame blending or blurring to cover up tiny amounts of lag. Movies also run at a lower frame rate then the game which could also cover up small amounts of lag.
You'll also have a whole lot of users not knowing/finding out what commands are available, and a whole lot of "type !this to do that".
Probably not, the insim docs specify word as a 2-byte unsigned integer, i unpack words in PHP using the S format, which looks similar to the H format on that python manual page.
unsigned short (always 16 bit, machine byte order)
http://en.wikipedia.org/wiki/Word_(computer_science)
Tried the demo to see what the BMW was like, but i can't really tell. rFactor gives me massive steering lag, if i turn the wheel fast enough from side to side, the in-game steering wheel is basically at the other end at all times. FFB doesn't tell me a thing about, well, anything. It all feels a bit like driving LFS with the keyboard.
Steering lag would make sense if i had 1 or 2 fps, but i've got well over 60.
Tried to slide around a bit in the road car too, which didn't really work. The sound still reminds me of the washing machine hall in an apartment building where i used to live.
Steering lag would make sense if i had 1 or 2 fps, but i've got well over 60.
Tried to slide around a bit in the road car too, which didn't really work. The sound still reminds me of the washing machine hall in an apartment building where i used to live.
Just poke the HDD holding the files every now and then, if this is the main problem.
I'd say it really doesn't, Windows can't figure out which things should preferrably be kept in RAM and which things could work just as good in virtual memory, having all your radio sounds in memory might create a situation where an SQL query on my PC ends up being handled in virtual memory, something i'd really notice.
Only clients and a server hosted in-game can add AI's, the dedicated server cannot.
A format like XRT_backfire (x).ext has been successfully applied elsewhere i believe.
The thought behind this suggestion was basically to let people not only customize, but also remove stuff they don't want without creating empty placeholders.
Argument would be that the performance loss of streaming from harddisk would probably never be noticed, while as your program is currently designed it uses over 40mb of RAM where 90% or so results in a performance gain nobody will probably ever need.
While arguing that using memory if it's there is kind of a good point, arguing to not use memory when you don't need to is even better.
This is all pretty neat, but i've got a few suggestions nonetheless.
Don't hardcode the loading of backfire sounds, let your program load either any sound files in the backfire directory, or any files matching "backfire (x).ext".
Don't load the radio sounds into RAM, even if you switch to a compressed sound format it's really alot of unecessary memory usage. Just stream from disk once you've picked a sound to play. Needing a bit of performance for backfires makes sense, but you'd probably never notice a radio sound playing 50ms too late.
Don't hardcode the loading of backfire sounds, let your program load either any sound files in the backfire directory, or any files matching "backfire (x).ext".
Don't load the radio sounds into RAM, even if you switch to a compressed sound format it's really alot of unecessary memory usage. Just stream from disk once you've picked a sound to play. Needing a bit of performance for backfires makes sense, but you'd probably never notice a radio sound playing 50ms too late.
Get a copy of Process Explorer, let it run while you race until you get one of these performance drops. You should be able to figure out which process is stealing precious CPU cycles from either hovering the mouse over the graph, or from the column CPU History (may need to enable the column from View -> Select Columns -> Process Performance).
Make sure the admin password is actually specified in the servers setup.cfg, lines with two leading slashes "//" are treated as comments, not used as commands / settings.
//admin=password should be /admin=password to not be treated as a comment.
//admin=password should be /admin=password to not be treated as a comment.
Wow, i typed in the URL without the referral part (:razz and after 5 or 6 redirects i ended up at a page telling me i've won the lottery. All they needed were some personal details and an email adress, to which they'd send not only lottery news, but sponsored advertising as well.
and after 5 or 6 redirects i ended up at a page telling me i've won the lottery. All they needed were some personal details and an email adress, to which they'd send not only lottery news, but sponsored advertising as well.FF is realistic, just like driving in cockpit view is realistic since you're "sitting in the car". FF is also unrealistic, just like the missing peripheral vision which makes cockpit view unrealistic.
ie. FF lets you feel certain things, feels like the steering wheel is "connected" just like in a real car, but it's not perfect, just like everything else.
ie. FF lets you feel certain things, feels like the steering wheel is "connected" just like in a real car, but it's not perfect, just like everything else.
Compatible ideas:
Instead of letting the sound engine update on each frame in a replay running in slowmotion, sample one frame of realtime sound and convert the sample rate to match whichever speed you're running the replay at. This would allow capturing replays at say 0.25x speed with sound which you could just speed up later, instead of recording the sound separately or using time-stretching which doesn't really produce good results. Optional perhaps.
Also, hitting ESC while loading a replay asks me if i want to shut down LFS, i'd like it to cancel loading the replay instead.
Instead of letting the sound engine update on each frame in a replay running in slowmotion, sample one frame of realtime sound and convert the sample rate to match whichever speed you're running the replay at. This would allow capturing replays at say 0.25x speed with sound which you could just speed up later, instead of recording the sound separately or using time-stretching which doesn't really produce good results. Optional perhaps.
Also, hitting ESC while loading a replay asks me if i want to shut down LFS, i'd like it to cancel loading the replay instead.
For anyone with codec troubles, get yer hands on Mplayer or VLC and you'll (probably) not be needing to download or install any codecs for a few years.
Captured in .25x speed at 18 fps with LFS locked to 18 fps. Clip set to 400% speed in Premiere with project set to 30 fps, frame blending on, rendered to uncompressed avi. Final stop in VirtualDub adding a field bob smooth filter, a chroma smoothing filter, and compressing with the xvid details already posted by dawesdust_12.
Fraps does exactly what it's supposed to do, there's no other / better way. It's even completely unbloated, which is really rare.
Because you switch the load of processing/saving the frames to another system.
Why not go for the best of both, LFS at half resolution, fraps at 'Full size'.
And this is somehow different from the current system?
FGED GREDG RDFGDR GSFDG