Player name was never the problem, it was just an example, to hopefully demonstrate the correct encoding.
In my copy of Notepad, there is a menu in "Format" "Font..." and in there is a drop-down "Script" where you can select the code page represented by the characters in the file. I think you may need to select the correct "Script" for the language you are typing in there.
It seems likely you are not using the code page correctly, but it's not for me to describe. It's an old Microsoft system, which you can look up if you want.
LFS can help a bit though. You can try writing a player name using the word you want, then exit from the player options, now have a look in data\misc - I think the new .ply file name will have the correct character encoding.
I think it may be the high rise buildings with hundreds of windows, in those cases Eric doesn't want to model them in an 'expensive' way with light emitting surfaces behind a glass layer, as he has done with various buildings around Kyoto (and also South City) but not the high rise ones. Although it's not something we have discussed recently, I guess the priority isn't that high yet.
EDIT:
How the lights are modelled in LFS, each object with self-lit surfaces has a lighting value that can be set (per object or object type). There are 3 different values (always on, night white and night yellow). These values are inserted in the vertex structure when the editor model is built as a game-ready mesh (on load). When drawing the triangles in game, the special values (3 mentioned above) are multiplied by the current state of that light (always on is... always on [pit garages etc] and night white / night yellow are on between sunrise and sunset). Some lights also use a "night mid" and they get half of night white and half of night yellow, to allow a bit more variation in the light colours.
These resulting light colours are used both to render those lights every frame and also in the lighting baking render which is done over several hours, getting light values from every point.
But I fear I may get more questions now that I started talking about technical things. Please forgive me if I don't answer!
It's possible that the Chinese firewall can cause problems, and that may vary. There are two ways to download a mod.
1) Click a mod in-game (on the mods screen). From China (and other Asian regions, and of course America) I think you are redirected to the USA downloads. You can disable the USA redirect with:
Options... Misc... Allow regional downloads: [no]
Maybe that can help.
2) If you were clicking a mod like on the website and it failed, we would need to know the exact message, maybe you can set LFS to English and report the message. This depends on LFS being installed with associations enabled, so that web links can be used to start LFS.
I think it would help to know if it worked for you before, and it has recently stopped working?
I've started one of these requests on a test account, to have another look after 7 days. I've tested thoroughly before several times on a short time frame test while developing it and it was working fine, and I'm sure I've seen it on the full week test as well. There isn't a way for it to be affected by failed emails or expired domains, etc. It's not an active process, it just sets a time in the database and that is affected when you visit the page after some time.
After the first 7 days, you should be able to set a new email address without receiving one on the old email address.
After a further 7 days, if you don't set a new address, then it returns back to the original state. That is 14 days after you first clicked.
Hi, that is unfortunate timing. You wait 7 days and then, for the second 7 days, you are able to change your email address without receiving an email on the old address. On the 14th day it expires and you are back to the start.
I wonder if there may be a way to reproduce the issue, maybe some pattern to it?
As we know, it seems to work at first, checking every minute, then apparently it can go wrong at some point.
If I understand the pattern it might help direct me how to figure it out (remembering this is all Victor's code and it's better if I don't bother him unless it's an important issue).
I'm busy on other things but maybe if you detect a pattern, let me know and it might me some time when I do look into it.
By the way, we don't store any credit card details. Our site doesn't even see them during the payment process. And we have to run regular PCI DSS checks to comply with the security standards.
Some other companies store your credit card details for use in future purchases. We don't.
You could sell a car with some nice improvements and also a leaking fuel tank, some holes in the bodywork, faulty electrics and an uncomfortable seat. Or you could fix the known issues and release it at that point instead. Which is better?
This is an entirely new version. There is no compatibility between tracks in the old and new versions. The old version cannot possibly load the new tracks, and the new version looks terrible with the old tracks. Good news though, they have all been updated, as you can see by reading the previous progress reports I linked to above.
The new version is not a patch for old LFS. It has to be released all at once, and it will be released with flaws, in as a test version. But there is absolutely no point releasing it when it is not ready for testing and we are working full time trying to fix all the issues we already know about.
There is a point to release it before it is perfect (and will never be perfect anyway) but we aren't at that point yet.
EDIT: As mentioned, some important things are simply not done yet. Also, at some point I need to build a public version, actually exporting everything from the development version into a publicly releasable folder. Even that will take me a few days, probably a week by the time I've added some code support to help me build a clean version a few times during the testing stages. To move from a development version to release isn't simply a matter of declaring it ready. It's a careful process of exporting and encrypting the necessary files, possibly stored a bit differently from the current public version. It's not a big deal, I'm just trying to illustrate that there isn't a version to release yet, even if it was ready which it isn't.
OK, we get that in Edge too. In Firefox it goes where it's supposed to. So I don't think this test tells us much so far. My son got that result and he is not a moderator.
My hypothesis at the moment is that redirect is browser related and doesn't shed any light on Zero7's mod download issue.
Sorry, I know there are other questions but I can't answer them all as I'm still busy working long days every day.
In our system, I call the following ambient lighting:
1) Lighting from the sky
2) Lighting from nearby objects
3) Lighting from artificial lights (excluding headlights which are obviously dynamic)
These are linked together in our system, values baked into vertex lighting and they are in operation at all times, with a varying effect depending on the lighting situation. Some artificial lights are on at all times (e.g. pit garages) and some come on only at night (street lights).
That ambient lighting, including from the artificial lights, is baked and vertex based. Where there is an issue like the one you spotted, Eric can improve it by manually increasing the geometry in those areas.
EDIT: To be clear, in the older versions of LFS, we had automatic geometry splitting to try to allow more detailed shadows (that were also for sun shadows). It worked OK in some places, but sometimes it creates long shards of undesirable lighting. In the new version of LFS, direct lighting shadows are done using shadow maps. Vertex lighting is now only for the ambient lighting (including sky lighting and street lights). Automatic splitting then seemed to cause more problems than it could solve, so we decided that it would be better if Eric has full control of the geometry instead of leaving anything to a flawed algorithm.
The design compromise of storing lighting in vertices has pros and cons, it's very efficient and helps LFS keep running on less powerful GPUs that is important for many of our customers. In my opinion it usually works quite well but there can be problems in some places, e.g. sometimes near street lights or occasionally there are excessive ambient shadows. I think it's not worth trying to make it too perfect but it can be improved a bit in some places where it might be seen a lot or has obvious issues.
Anyway in the SHIFT+A editor I think I got a better result by reducing the "Collector MIX" and turning up "Header MIX" and I think maybe "Unevenness" isn't needed for this engine?
Last edited by Scawen, .
Reason : removed off-topic