Going really off-topic, but then licensed users would start to nag and mess around and no one can ban them. Believe me, there are tons of immature licensed users out there. Join couple of cruising servers and you'll see.
Going really off-topic, but then licensed users would start to nag and mess around and no one can ban them. Believe me, there are tons of immature licensed users out there. Join couple of cruising servers and you'll see.
OK, I've found how to reproduce this.
When watching that SPR I've clicked on output lap data to get the RAF file....
after replay finished I've been pressing ESCape a lot of times....
and there it is.... the background appears but no buttons, alt+f4 doesn't work too, only way is to kill the process...
INSIM: LFS Relax (with and without it too)
P.S. for me, replay doesn't loop in any case... it returns directly to the main screen(not the replay selection screen), is this right?.
I directed my comment at you, but it was meant for anyone who was confused or seemed worried that their online races would be ruined by demo drivers.
Well... how it is :
MPR - never loops
SPR - loops unless InSim is initialised (even if no InSim program is attached).
I might change this behaviour, instead I think the SPR should loop unless it was started by a /spr command (most probably by an external program). This would make more sense. This non-looping was originally done so an external program could run a series of replays. But with the new InSim, most InSim programs do not start replays so it doesn't make much sense any more.
Anyway I'll fix that bug - and in fixing that to allow the ESCAPE menu to not cause issues when a replay does not loop, I should be able to use the same fix to allow me to enable the ESCAPE menu when you are playing an MPR (which also does not loop and this is why there is no ESCAPE menu in an MPR). My first idea for the fix is that the replay should just freeze at the end if you are in an options screen, instead of exiting back to the entry screen.
And before anyone mentions replay controls again, that is on my list so please do not say it. Thanks!
Long list? 
hello Scawen,
thank you for the explanation, now I understand why there is no ESC menu in MPR. And of course I would like to see this implemented.
Nevertheless my TV Director should be able to run a list of replays (later, it is on my list). This is not to ask you you to stop implementing MPRs looping. But now I have to think about a convenient solution how to detect the end of the replay, and then issue the /end command. First idea is to check the values of SMALL_RTP packets. What do you think about it, maybe there are other (more) simple detection methods, without the need to flood LFS with TINY_GTH packets? Will an insim application still receive a TINY_REN, even if the MPR/SPR loops instead of returning to entry screen?
BTW: I was hoping that LFS can handle a list of replays on its own (maybe with a script). But there was no answer to my thread (http://www.lfsforum.net/showthread.php?t=41290), so I am afraid this is not possible. That's why I have to implement it in the TV Director to run the list.
with kind regards
Soeren
Well, I think the only way your program can start a replay is by using the /spr or /mpr command. And that is the one case where I would like to make sure the replays do not loop. I think you missed me saying that in my previous post... unless there's another way to start a replay I haven't thought of?
At the moment, there is only one way to run a list of replays, and that is through InSim. You detect when LFS is back in the entry screen then play the next replay - that's what LFS Show did I think.
At the moment, there is only one way to run a list of replays, and that is through InSim. You detect when LFS is back in the entry screen then play the next replay - that's what LFS Show did I think.
you are right, I missed this.
So finally all my questions regarding the replay list are answered, and I can start to implement this feature in my TV Director.
thx and regards
Soeren
I seem to have a problem with the AA (haven't checked the AF - not sure how). I installed a "test" instalation of patch Y18 and tried out these new settings, by putting them both up to max settings and the resulting screen shot can be seen in file named "Y18 - AA and AF"
Now when I set the same values of AA and AF using my normal install of patch Y by setting my video drivers to force the application instead, (using the global settings), I get the result as in the file named "Y - AA and AF(drivers)"
Looks to me like the AA at least isn't working when set "in game"
This is on a Vista Home Premium machine with a Nvidia 8600GT card with driver version 169.25
Now when I set the same values of AA and AF using my normal install of patch Y by setting my video drivers to force the application instead, (using the global settings), I get the result as in the file named "Y - AA and AF(drivers)"
Looks to me like the AA at least isn't working when set "in game"
This is on a Vista Home Premium machine with a Nvidia 8600GT card with driver version 169.25
@gezmoor:
As far as I've gathered that is a problem of the 169.x Forceware drivers, which don't seem to work correctly when AA/AF is set to application controlled. Try to up- or downgrade to a different driver version, at least the ingame AA should work then.
As far as I've gathered that is a problem of the 169.x Forceware drivers, which don't seem to work correctly when AA/AF is set to application controlled. Try to up- or downgrade to a different driver version, at least the ingame AA should work then.
sorry if this has been posted, i haven't read posts above.
I have huge lag or something when i use LFS in screen mode now.
Dunno how to describe it, but when i click to open something screen loads much slower, and i usually have about 60ms ping on servers list, and it's about 200ms now when i use screen mode.
edit: I've just noticed that it works normally when Mozilla Firefox is on.
edit2: It works fine only when firefox is maximized. When firefox is in window or minimize mod LFS is laggy again =/
edit3: LFS works fine in maximize screen mod, but i never use that anyway lol
I have huge lag or something when i use LFS in screen mode now.
Dunno how to describe it, but when i click to open something screen loads much slower, and i usually have about 60ms ping on servers list, and it's about 200ms now when i use screen mode.
edit: I've just noticed that it works normally when Mozilla Firefox is on.
edit2: It works fine only when firefox is maximized. When firefox is in window or minimize mod LFS is laggy again =/
edit3: LFS works fine in maximize screen mod, but i never use that anyway lol
Lmao, Yep, Same.
The problem you refer to relates to using the nvidia CP to set application specific graphics settings. I'm not using this setting, I'm using the global setting to force the AA and AF settings in LFS, (purely for this test), and as you can see from the attached image the settings work. My post is specifically relating to the fact that if I set the setting in the nvidia CP to "let application decide" in the main options page, (ie not even using the choice to allow different profiles for each application), and then set the AA and AF settings in the Patch Y18 version of the game, the AA does not work, (as can clearly be seen in the attached image).
So to reiterate. This is not that driver issue, I can set AA succesfuly through the driver settings. What I can't do is set it using the in game options in patch Y18, (while the drivers are set to defer to the application).
I hope that is clearer.
I can't see the difference here?
@gez, it's still the driver receiving the instruction from LFS to apply settings. The driver does not just interact with the control panel, it also interacts with the application. Or it doesn't, in the case of this particular faulty driver, according to AndroidXP.
Script bug:
The FXO GTR and XR GTR execute road.lfs instead of sequential.lfs
Evidently when these two cars were made sequential only (patch x or patch y or whenever it was), Scawen forgot to change what script the cars load.
The other sequential cars correctly load sequential.lfs
Surely this is a small bug that can be easily fixed before patch z is complete, G25 users such as myself who rely on these scripts would be very grateful.
The FXO GTR and XR GTR execute road.lfs instead of sequential.lfs
Evidently when these two cars were made sequential only (patch x or patch y or whenever it was), Scawen forgot to change what script the cars load.
The other sequential cars correctly load sequential.lfs
Surely this is a small bug that can be easily fixed before patch z is complete, G25 users such as myself who rely on these scripts would be very grateful.
Good point, thanks. I've added those fixed scripts to my patch folder.
Just to make sure you know, you can also fix it for yourself in two mins, just edit the scripts XRR.lfs and FXR.lfs so they say sequential instead of road.
Just to make sure you know, you can also fix it for yourself in two mins, just edit the scripts XRR.lfs and FXR.lfs so they say sequential instead of road.
The next thing to do is disable online demo playing on Patch X, kill those free drifters
Bad English BTW
Bad English BTW
2 FCS13: I couldn't agree more
Ok maybe there is some confusion here, (me included).
I know that there is a known fault with the current set of drivers from Nvidia which means that settings in the specific application profile in the nvidia CP are not applied to the application. I am aware of this as I have seen the issue myself with the current set of drivers that I'm using, ie a previous set allowed me to set AA and AF in the CP specifically for LFS and the current drivers don't work when attempting this.
However, I can set the AA and AF to work in LFS (patch Y) by setting the global settings, (ie not specific just to LFS) in the nvidia CP. So obviously the drivers are able to override the LFS application in order to set AA and AF settings.
However what I am stating is that using patch Y18 the application will not set the AA and AF settings, despite the drivers being globally set to "allow application to decide". I don't see this as related to the above driver issue. Why ? because if it were a driver issue then the AA and AF wouldn't work in any application on my pc when the drivers are set to "allow application to decide". Given that AA and AF are working fine in all the other 3D games that I have, I can only see that this is an issue with the application not the driver. Unless someone can explain to me why LFS might request AA and AF settings from the drivers, and the drivers not apply those settings only for LFS be a driver issue when they do apply the settings when other applications make the same requests?
ie
Drivers set to "let application decide" globally:
Other applications = AA and AF work
LFS (Patch Y18) = AA doesn't work
Drivers set to "force override application" globaly:
LFS (Patch Y) = AA works
and the known driver fault:
Drivers set to "force override application" in application specific profile:
LFS (Patch Y or Y18) = AA doesn't work.
See the difference??
gez, I've no idea what the intricate details are regarding the driver's behaviour and interaction with different applications are, although it seems to refer to unexpected or undesirable behaviour when setting/unsetting AA/AF. What I do know, though, is that there is no point in reporting LFS AA/AF bugs when knowingly using a faulty nV driver. If he were to "fudge" the LFS code so that it works with a borked nV driver, he'll have to recode LFS to "un-fudge" it later. That just doesn't make sense. Replace the faulty driver first, then bug report if the problem persists, surely?
Why are you arguing when there are 174.74's floating round the internet that are just as stable if not a little bit faster?
That's because it isn't. You're the one that brought that issue up. What you're experiencing is a separate issue in which LFS asks the driver "AA and AF please" and the driver goes "what was that?" and ignores those commands. This bug is LFS (or probably DX8) specific, meaning other games may still work, but that does not mean LFS itself is at fault.
With the complexity of drivers these days, and the amount of application detection they do, this kind of application specific problem is not witout precedent.
Y18 from DEMO user perspective
After some experimenting with Y18 I consider that patch a major improvement from demo users perspective.
On one hand it requires registration for online use, but this is ballanced by storing statistics on LFSW - every demo user would love this and removing that access (as is still considered, I think) would be a big step back.
Downloading skins is a very good feature as well. But this is to a large extent hampered by inability to upload skins to LFSW. It means that most demo users will still not see custom skins of other demo users. But consider that demo users have only three cars available - maybe they could be allowed one uploaded skin for each car (perhaps further limited to one update a week).
As a demo server admin I see many benefits in Y18 (and hopefully next versions).
My experiments show that banning (yes, crashers are quite some problem in demo) works now purely on registered name basis, if I'm not mistaken. But I'm afraid that for a dedicated crasher (and there are lots of those) there's no problem registering other user name in a minute or two (only different mail address is required). I think that using ban on user name and IP address as well (at it was before) would make lifes easier for demo admins. Of course this still isn't bulletproof, but it may help in many cases.
Off the topic, but I still miss: 1) manageable list of servers used in Join specific host screen, 2) a key for limiting throttle/brake by a specified percentage for keyboard and mouse players (demo people, mostly).
Thanks for reading, take care, keep up the fantastic work...
On one hand it requires registration for online use, but this is ballanced by storing statistics on LFSW - every demo user would love this and removing that access (as is still considered, I think) would be a big step back.
Downloading skins is a very good feature as well. But this is to a large extent hampered by inability to upload skins to LFSW. It means that most demo users will still not see custom skins of other demo users. But consider that demo users have only three cars available - maybe they could be allowed one uploaded skin for each car (perhaps further limited to one update a week).
As a demo server admin I see many benefits in Y18 (and hopefully next versions).
My experiments show that banning (yes, crashers are quite some problem in demo) works now purely on registered name basis, if I'm not mistaken. But I'm afraid that for a dedicated crasher (and there are lots of those) there's no problem registering other user name in a minute or two (only different mail address is required). I think that using ban on user name and IP address as well (at it was before) would make lifes easier for demo admins. Of course this still isn't bulletproof, but it may help in many cases.
Off the topic, but I still miss: 1) manageable list of servers used in Join specific host screen, 2) a key for limiting throttle/brake by a specified percentage for keyboard and mouse players (demo people, mostly).
Thanks for reading, take care, keep up the fantastic work...
The registration for online use is a good thing completely, it doesn't have any downsides other than a quick form and it gets rid of the lunactics that inhabit the Idiotic Republic of the Interwebs.
Demo is short for demonstration, and the skin downloading system is demonstrated when a licenced driver joins.
I'm not a demo server admin and I feel sure that there are considerable benefits due to the banning system.
Understatement of the year.
Tend to agree with you there, although there are ways around the whole IP banning business, which would make the whole thing pointless. Maybe not allow webmail and spamgourmet type accounts for initial registration ... although not everyone would have access to a ISP/place of employment/education/other non-webmail account. 'tis difficult.
This thread is closed
Test Patch Y18 - Licensed Demo System
(324 posts, closed, started )
FGED GREDG RDFGDR GSFDG