I tried to describe why things take a long time, for Eric and me. I wouldn't be able to go into much more detail without listing every detail of our personal lives.
Some people do understand and some will not. There is also life outside of LFS, we have families and so on. Things happen, it's not just a constant uninterrupted 50 hours per week on LFS.
But just to clear up one myth: Eric and I do not have any other jobs. I'm not sure why people sometimes get that idea. As you can see, we are working hard on Live for Speed and there has been a lot of progress these last few years. But it's not always plain sailing. There is life outside LFS, and within LFS there is experimentation, research, trying and testing, following unexpected avenues, backtracking, trying again, and so on.
I do say occasionally, if our aim was to make the most money possible, we should have chosen another job or way of working. But that's not the aim here. The aim is to develop something we like, working in the way we like, get paid for it and enjoy life as well. It's a great thing to be able to have some time to spend with the people you love. Some people do miss out on that part of life through working too hard, and I'm really happy that we have avoided that mistake. You don't have a second life to come back and do all the things you forgot to do in your first life. So you need to make sure you have time to do the things you like to do.
I don't suppose it does any harm to let you know where we are with the tracks, as I think you can work it out anyway. The South City and Fern Bay are not yet done. Kyoto has taken longer than expected because Eric is working to a high level of detail, and the track covers a vast area. He wanted to create interesting buildings as part of the job because as an artist he wants to create good looking work.
It's similar on my side, things have taken longer than expected and one thing leads to another, so I end up working on things that were not planned in the first place. Maybe if we had a project manager they could keep us to timescales and limit our work accordingly. But I think it's a good thing that we can experiment by going down unexpected paths of development, although it does take longer, the end result can be more interesting.
I know people may say "if you don't release it quickly it will become irrelevant and obsolete" and so on but I don't really mind about those kind of opinions. We're trying to create a nice game that we are happy with, and I know a lot of people will be happy to have a go when it's ready.
That is because there is no code to deal with wind strength. They don't adjust their style to deal with wind. For example if there was a strong tailwind down a straight, they might not brake in time for the corner.
I'm not sure what you mean. The code is really intended to solve the problem of real switches oscillating a bit as they turn on or off. But it sounds like you want to have high settings to prevent yourself doing multiple gearchanges by mistake?
Gearshift debounce setting now applies to all controller buttons
Reduced maximum value of gearshift debounce to 100 ms (default 20)
FIX: Memory leak related to threads (most often for skin download)
More translations updated - thank you translators!
I could see where it crashed in the code but it's a bit mysterious because it is at the point where LFS loads the objects when you load a track.
So that shouldn't happen unless:
1) The file is corrupted. In this case, the bug would come up every time you try to load that track. Do you know which track it was? Are you able to load each track on that server?
2) The computer's RAM is corrupted. This is very rare and would probably be repeatable or cause other random faults.
3) Overclocked computer. The most common reason for memory errors. I'm guessing this is not the case here.
4) It could also happen if a memory allocation failed - LFS isn't checking for that case. It should only normally happen if there is a significant memory leak and the program has been running for a very long time. I have discovered a small memory leak recently but this seems unlikely as we aren't seeing regular crashes from DCon. Unless maybe yours was heavily used for several days?
5) A memory corruption error somewhere else in the program.
At this point I can't think of anything else, as the crash is in code that is used every time a track is loaded. So all I can ask is for you to check if all tracks can be loaded on that instance of DCon.
As many of you know from the forum and Twitter, Eric has been working on Kyoto and I have been working on a new lighting system. In this month's progress report we would like to show you some of the work in progress and talk a bit about the lighting.
I'm really busy working on the lighting so I've left the test patch for a while. There are a couple of small things on my list to add for this test patch but I'm trying to get other things done at the moment.
Sure it's easy to fake, and if unknown users come here and start posting images that might be fake, then I won't act on what they say. But there is very little chance that a long term user like lucaf will come here and start posting false information.
I really can't imagine it would get far up the priority list for the Rio police when I think about the other things they are dealing with over there.
Other people in the chain just tell you it's not their responsibility unless they receive the legal documents, and they suggest talking to the other people, who obviously don't care either. They are just happy to continue receiving money for their hosting service and won't stop that because some guy on the internet sends them an email.
I have extremely little appetite for going to expensive lawyers about this sad lying criminal who abuses his own customers. I'm sure he will unravel in the end. I've got too much work to do.
It's good that we are getting more sales to Brazilian users these days. Maybe after some time they get tired of being pushed around by the lying criminal who hosts them and even charges them to be unbanned.
I think that is when the layout objects are updated. It would depend on which server you were on, if the layout was being changed that could come up. There could be a split second hang while that message is displayed (when the meshes are sent to the graphics card).
If the server InSim has been coded correctly, that should only come up when the updating is finished, not every frame.
I don't think anything has changed since version T so you would still get that message. I think it depends on the server you are connected to rather than your version.
Unfortunately it's not so simple because some things in SM2 don't work in SM3. For example the fog must be done differently. And I have a vague memory about some issue with the 2D interface shaders too. And it needs some special handling for certain types of error (so the whole program doesn't become unusable each time there is an error in a shader). I know this because I changed to SM3 and dealt with the issues in the development version. I'm not keen to spend time working on the old shaders at the moment.