I can't deal with faulty anti virus software, of course. I don't know what could have gone wrong when you clicked Go. Do you get better results if you install a fresh version?
Thanks for the info. Just at the moment you are the only one to report a crash and we didn't get one in any of the recent test patches (other than one in early test patches that happened at startup and I believe we found the cause and fixed it). So I'm wondering if your computer could possibly be overheating as it is so hot. It could cause the CPU or memory to do something funny, so maybe you could open it and check for dust?
We haven't sent one. I'm not sure if we will or not, actually haven't discussed it with Victor yet.
Ive cleaned it out but ive just realised it only occurs on the TC Drving servers im guessing it could be the amount of connections but my pc is fairly cool, CPU is at 50 Degrees Celcius, and the GC at 60 even my motherboard is at 45. its been running for about an hour after i thought a restart cwould fix it. thank you for the fast reply though really appreciate it.
EDIT: - about 15 minutes since i replied i went straight to TC Driving one, no lag or anything everything is perfect then BOOM it just vanished with no error or warning. could it be that im running triple screen?
1) You are driving.
2) A certain car joins and you haven't seen that car since joining the server.
Then it uses the "use blank textures to reduce pit-out glitch" code and that is the only time the function where the crash occurred is ever called.
To cause the crash in that case:
3) The car that joined has a texture without a name.
4) The material being created is of a type that we haven't used in any of our car models.
I've loaded the 20 LFS cars to check and in theory this situation cannot come up. So that makes me wonder if you have installed one of those 'safe' VOB mods that is purely visual and doesn't create any advantage or out-of-sync in multiplayer.
Obviously I don't hold it against you for using such a mod - it's not cheating in any way, but it would be great if you could confirm if you do have any VOB mods in your data\veh folder. In that case it would explain why most people aren't getting the crash and if you replace the official .vob files problem would then go away.
Updated to 0.6T. Someone above already asked this but it was not answered properly. How to remove the lfs.net logo/watermark from the top left of the screen while in game?
Before the update it wasn't there. I had my FPS showing on that side but now I can only set my FPS to be shown on the top right.
And also any idea when Pro tweaker will be updated to work with 0.6T? It's hard to drift nicely with the stock XRG...
The idea of the demo is to try out Live for Speed, and if you like it we hope you'll buy a license which we think is great value as you get all future updates with no extra charge. If people buy a license then we can buy food, clothes, pay our taxes and so on, to allow us to continue developing LFS. We think it is a good idea to show demo racers the website address to remind them in case they forget!
Good job on the update I'm waiting patiently for more information on what's to come next. All of the things mentioned: tire physics updates, track updates, graphics engine updates sounds amazing on their own.
I don't actually think VOB mods affect other people, because the mod is only on their computer, not yours. On your computer you just see the unmodified car - loading happens in the same way as usual. So if the mod is constructed in such a way that is has the same physics bounding box, then it passes the OOS check and all is well and collisions take place as normal.
We don't support such mods in any way. They are only 'wrong' in the sense that all cars of that type look different on the modded computer. But I don't believe they are harming other players.
Wizard, I have one idea for you to try. I wonder if your computer could be slowed down when people join by massively full skins_x or skins_y folders. Then Windows could take a seemingly long time (fraction of a second) to search the list of files.
So a possible solution to try is to temporarily rename those folders to something else (before you start LFS). Then LFS will create an empty folder when you start it and Windows won't be searching through hundreds of files to see if a skin is available each time someone joins. Of course, this is quite irrelevant if there aren't many files in those folders.
i know it sucks for me to say this, but if you like the game support the devs by buying a licence.
its not that expencive, and you will get more content as time goes on.
That's the result of the special code which reduces the pit-out glitch. It deliberately avoids loading the textures of the car of a player who joins while you are driving, because doing so can cause a glitch. Then when you stop your car or the race restarts, those textures are loaded.
Scawen, have you considered adding hashing of the skins directories to work around the slow directory access issue?
The texture issue above is not that it hasn't loaded the user's skin, it hasn't loaded the car's base textures either. If that also glitches, maybe they can be pre-loaded as there are less of them than user skins.
The Insim connection (through LFS World > Racers & Hosts online > Insim Relay) to my dedicated server still failed. But if I try a tool outside it reports that my Insim port is open. Perhaps an issue on LFS World side?
Hm yeah, the problem is that we've locked down the server the relay ran on. Port 47474 is open for the outside to connect to, but the relay is not allowed to make outgoing connections to random ports (the hosts). This is due to us locking traffic down upstream, on a switch and not a firewall. And the switch isn't stateful, so it's not capable of discerning between incoming and outgoing connections / traffic.
Because of that, I've moved the relay to another server with some more networking freedom. The relay is now connecting to all hosts again and you can use it if you connect [your app] to isrelay.lfs.net .
BUT this brings another problem ... the LFS Remote apparently was coded to connect to "lfs.net" and not "isrelay.lfs.net". So now it's trying to connect to the wrong thing. On top of that I seem to have displaced the source code for the LFS Remote ... so now there is no way of fixing it.
Sooooo ... I guess the need for a HTML5 remote is really there now.
Unfortunately that's not a quick solution, but one that can be realised if I can find some free time (or maybe it can be a community effort? I've no problems making it an open source project ... it'll be javascript anyway, so it's open by default )