the source of the script

Quote :

/track as1
/axclear
/qual 15
/laps 25

After the I am run this of the script, the objects on the track are not cleaned.
I'm sorry for off top.

Quote from [Audi TT] :

the source of the script


After the I am run this of the script, the objects on the track are not cleaned.
I'm sorry for off top.

I see what you mean. The problem is those commands are all executed at once, they do not wait for the track to be loaded. It's a good point but I do not want to work on that now, only want to fix major bugs now, as we want to release this full version to continue with our substantial updates.

Quote from Scawen :

I see what you mean. The problem is those commands are all executed at once, they do not wait for the track to be loaded. It's a good point but I do not want to work on that now, only want to fix major bugs now, as we want to release this full version to continue with our substantial updates.

Ok. In this matter, Daniel there is master of his craft
Thanks you.

Quote from Scawen :

...to continue with our substantial updates...

To all: next time you try to report some bug, think about it! Don't make Scawen losing his time, there are substantial updates coming ^^

On the subject of the DCon, ever since we switched to the DCon on our servers (or possibly the new network code, I can't remember), we've been noticing a *lot* of "UDP ERROR (20) : WOULDBLOCK" messages in the log (number varies usually 20-30) - so many that we can get more WOULDBLOCK messages than anything else when the server is busy or the CPU is running something else as well.

We've tried all sorts of things to solve the issue, including tweaking kernel buffer sizes, but it seems like some other buffer somewhere is somehow getting full for a tiny fraction of a second - it's next to impossible to catch the system buffer with more than a handful of bytes in it because it gets cleared very quickly. Because the buffer seems to be cleared out so fast, there doesn't seem to be any noticeable ill affects other than an almost constant flood of messages in the log.

The cause could be LFS, WINE or something crazy in the custom version of the linux kernel that our host uses, but we gave up trying to solve it ages ago. I'm pretty sure that turning InSim off didn't make a significant difference.


Would it be possible to have an option to remove these messages from the debug log? As I understand it, UDP WOULDBLOCK isn't actually an error anyway and there don't seem to be any problems caused other than the error messages themselves.



As a side note, has anyone else had this issue, or is it just something funky with our server/setup?


(Running 0.6E DCon on Ubuntu 12.04.4 via WINE 1.4, haven't tried this latest DCon version yet, will do later)

From what i tested, weather on track only randomizes if track environment is changed, not the track layout (without using weather parameter!). For example: loading AS1 in entry screen from BL1 changes the weather but loading different AS layouts after AS1 wont change the weather - it will stay how it was when Aston was first loaded and only change when another track environment loads.
I kinda got the feeling you wanted max diversity

Quote from Degats :

As a side note, has anyone else had this issue, or is it just something funky with our server/setup?

(Running 0.6E DCon on Ubuntu 12.04.4 via WINE 1.4, haven't tried this latest DCon version yet, will do later)

I think I've seen those errors on my servers as well.
Have been running them on Windows XP and recently changed to server 2008.
Will check tomorrow and report back.

Quote from Degats :

e else had this issue, or is it just something funky with our server/setup?

I haven't tried the latest DCON ver yet, either. I haven't added the weather parameter to our scripts yet so the weather will be random. I'd need to check this with our race admin first.

Anyway. On a host that been running since march, with moderate activity I wc -l'd 110 instances of WOULDBLOCK. I'm also seeing a lot of:
... But the host appears to run OK, still.

It's a VPS with a custom kernel (OpenVZ I guess?). Don't flame for not having updated anything in a while.

Quote from Nilex :

From what i tested, weather on track only randomizes if track environment is changed, not the track layout (without using weather parameter!). For example: loading AS1 in entry screen from BL1 changes the weather but loading different AS layouts after AS1 wont change the weather - it will stay how it was when Aston was first loaded and only change when another track environment loads.
I kinda got the feeling you wanted max diversity

That is intentional because changing config is very quick, while changing lighting takes a few seconds. I did this change today to provide more variety while avoiding any negatives like slower loading.

Found a bug with the latest DCon:

If the config file has for example "/track=KY3X", KY3 will load instead of KY3X.
Typing "/track KY3X" or "/track=KY3X" in game works fine.

Something I noticed with the previous test patch E17:
I was on my own server with 2 IA drivers, then I quit the race and change circuit to autocross.

The 2 IA drivers are still selected and ready to race, but i can't start because "AI drivers cannot race in this configuration".

I know I can delete them, but couldn't it be cleaner to automatically remove them in that circuit selection screen?

Quote from Degats :

Found a bug with the latest DCon:

If the config file has for example "/track=KY3X", KY3 will load instead of KY3X.
Typing "/track KY3X" or "/track=KY3X" in game works fine.

Thanks for that good find.

I have uploaded new version E19 now. Hopefully no bugs now.

Quote from Ripley :

Something I noticed with the previous test patch E17:
I was on my own server with 2 IA drivers, then I quit the race and change circuit to autocross.

The 2 IA drivers are still selected and ready to race, but i can't start because "AI drivers cannot race in this configuration".

I know I can delete them, but couldn't it be cleaner to automatically remove them in that circuit selection screen?

Well this is not new. I know what you mean, and I'm not sure about the answer.
Sometimes you might not want them all removed, for example if you switched on wind.
Anyway I don't think I will think about this now.

Yep, that seems to have fixed it

After playing around with 0.6E19 a bit, I noticed that my FPS is virtually cut in half, from over 100 in most situations, to under 60 in most. After running some of the recent test patches, all the way back to the release version of 0.6E, it's still the same case. The weirdest part is I haven't noticed it until now.

I'm unsure if it's related to LFS, or an issue on my end. But I do know that running in windowed mode sends my FPS back to where it was before, well over 100, which I really find odd.

I'll look into all I can, but I just wanted to put this out there, maybe see if anyone else has this happen.

Quote from Degats :

As a side note, has anyone else had this issue, or is it just something funky with our server/setup?

I think it is...

Fiddled a lot with different kernel configurations to get a reliable network setup concerning LFS/Wine 1.4 (1.6 now but that doesnt make any difference as far as I could see).

I suggest not to remove those messages from the log, because it indicates there ìs something not working correctly. I don't get any or it is at least very rare but its also depending on the InSim and the rate of buttons/sec, other info send to (multiple) users by InSim etcetc. You said it doesn't matter if the InSim is on or off, if thats really the case then there is definitely something not right concerning the server setup. Number one reason why I stick with 2.6.32-431 (2.6.39.4-xxxx-std-ipv6-64 install/setup) but I used a custom kernel anyway. Luckily its quite easy to switch kernels if you get the hang of it.

So basically yes, I had those problems you described ages ago but killed those by testing out different kernels. And I have some other reasons not to go to a newer kernel but I leave it with this info. Oh, and changing kernel parms like buffers / memory (sysctl.conf) etcetc is no success indeed.

Quote from Scawen :

The idea of this is to avoid the problem that the first weather was nearly always used, so this just provides a little graphical variety as originally intended.

Excellent, updated. (seems to work as intended also)

Quote from Scawen :

FIX : Dedicated server would not start up in refersed or open configs

Normally I'm not the one about spelling mistakes but this one looks a bit mêh

.

Quote from Mr. Kninja :

After playing around with 0.6E19 a bit, I noticed that my FPS is virtually cut in half, from over 100 in most situations, to under 60 in most. After running some of the recent test patches, all the way back to the release version of 0.6E, it's still the same case. The weirdest part is I haven't noticed it until now.

I'm unsure if it's related to LFS, or an issue on my end. But I do know that running in windowed mode sends my FPS back to where it was before, well over 100, which I really find odd.

That sounds like Full screen vertical sync (Misc Options). But if that was on it would never go above 60. Have you tested again by running the original 0.6E exe and checking the same views? Another thing to check is Mirror antialiasing (Graphics Options) but I don't remember any reports about that causing much slowdown.

Quote from cargame.nl :

Normally I'm not the one about spelling mistakes but this one looks a bit mêh

Thanks... it was late!

Quote from Scawen :

...Anyway I don't think I will think about this now.

Ok, no problem

z buffer option has completly gone (16 and 24 are disabled) and the result is textures are a bit "funny"
lfs havent crash i have the latest directx everything is up to date
tried to force lfs from profiling it in amd cc nothing

reinstall it without the update everything is going nice so far trying to find the source of the problem

Quote from giannhsgr1 :

z buffer option has completly gone (16 and 24 are disabled) and the result is textures are a bit "funny"
lfs havent crash i have the latest directx everything is up to date
tried to force lfs from profiling it in amd cc nothing

That is the first time I have ever heard of that! If 16 and 24 are disabled, which option is selected? 15 or 32? Or nothing...? Maybe a screenshot of Graphics Options screen and one of how it looks in game could help?

Quote from giannhsgr1 :

reinstall it without the update everything is going nice so far trying to find the source of the problem

Just so you know, all the files are compatible, so to test the new one you only need to change the LFS.exe and you can test one after the other with no problems. Also you can rename LFS.exe and it still works, so you can have more than one version in your folder.

z buffer came back(after i reinstalled and patched it again ) on but the graphics remains the same
http://i.imgur.com/a5p5GWu.jpg
http://i.imgur.com/ZWJNMb9.jpg
its way to pixelated from what it was and im playing with forced aa af from the amd cc panel (dont know if that has anything to do with it)

I think maybe it's your Mip bias settings (Options - Graphics).

With Anisotropic filtering enabled, you should set Mip bias settings to zero or near zero.

I don't know why you need to force on the AA / AF settings, when they are available in game. But anyway, I hope the Mip bias settings will help.

I assume you are using adaptive or SS AA, when you are forcing it in CCC.
In new patch graphic option AA in LFS is enabled by default, and that makes forced AA not work propertly.

BTW Scawen, purpose of "low res" textures inside LFS?
I think every PC has more than 64 MB graphics RAM, which is enough to play default hi res.
Had some problems with that option, it increases track load times a lot! Like 90s compared to <5s I unintentionally set it to low and couldn't find source of problem for my bad load times

Quote from DANIEL-CRO :

I assume you are using adaptive or SS AA, when you are forcing it in CCC.
In new patch graphic option AA in LFS is enabled by default, and that makes forced AA not work propertly.

Do you (anyone) think it is a bad idea to enable AA by default?

It's very easy to switch that off as it was before by just changing one number to a zero. I could switch Full-scene AA off by default but leave AA on the mirrors by default, which is a different thing that doesn't seem to have caused any problems.

Quote from DANIEL-CRO :

BTW Scawen, purpose of "low res" textures inside LFS?
I think every PC has more than 64 MB graphics RAM, which is enough to play default hi res.

Maybe this option isn't needed any more, but later tracks have higher resolution textures so I'm not sure about removing this without some more research.

It's not only about memory usage, also accessing smaller textures can result in a higher frame rate, though I agree this is probably not noticeable on modern cards.

The trouble I had with AA is over. Wine 1.4 was to blame. Updated to Wine 1.7 and AA enabled does still impact FPS but only a little (just like it did on Windows). This is on an ultrabook with an IGP.

Quote from Scawen :

Do you (anyone) think it is a bad idea to enable AA by default?

I have no problem with it, infact maybe its even better for people who don't play much with settings. Still not sure if thats giannhsgr1's problem