When testing the new /grid command, I felt a bit uneasy that I didn't get a reply from the host confirming the update. I changed it to report back what I typed as a confirmation.
I'm not sure if this is needed or desirable. If so then I guess the same behaviour should be implemented for:
OK, some slight changes after feedback and testing.
I have been able to do more than expected without an incompatible version.
About a suggested option to allow AI / real / any players:
That is a good suggestion but is actually a different topic that doesn't require shared logic. I have to keep this simple to make it reliable. So let's leave that out for now.
About keeping object mods in the first grid slots and not moving them in an automatic reorder, vs a suggested idea to be able to individually lock any players (e.g. safety cars etc):
As noted, there are no gaps in the grid, so it's not really possible at the moment to lock arbitrary racers in position. I think the easiest option (for a quick and safe implementation) is to allow the admin to specify a number of static grid positions. Those static positions could include object mods and safety cars, if they are all at the start of the grid.
e.g. /static 3 ... keep the first 3 slots in place when auto-arranging grid on race restart.
About preventing people adding / removing / moving players around the grid:
I propose 3 options for a /grid command: open / self / lock
/grid open self lock JOIN RACE Y Y N REMOVE SELF Y Y N REMOVE OTHERS Y N N MOVE PLAYERS Y N N
Hi, the problem you are experiencing is not related to the LFS update. No changes were made in the code to download mods.
It has happened quite often that someone gets an internet issue around the same time as an update comes out, then they think it's because of the update.
I am sure, if you still have that problem and you revert LFS to the previous version, you will still have the problem, proving that it's not related to the update.
There may be a problem with your ISP or your firewall or something on the internet between your LFS instance and our server, but I'm sorry to say there's nothing we can do about it. If there's any way you can try a different internet connection, that could be a good test.
Related to a couple of issues that came up in this event, I have some simple solutions to ask you about before implementing them.
1) Temporarily lock the grid so people cannot join
2) Make object mods stay in their front of grid positions (avoid auto rearranging due to qualifying or result)
Tuttu The Dog reported a few issues related to the race restart and lobby screen when running a popular event. In some cases I think I can make a small change and would like your feedback if you notice any issues.
1) People were able to remove others from the grid or move people around on the grid. Obviously that is the behaviour of a trouble maker, not the normal thing. Unfortunately I can't do much about this right now because of the way it is written, that would require an incompatible version.
2) People can join at inconvenient times after being asked not to join. Not necessarily trouble makers but anyone could miss a message like "DO NOT JOIN GRID" and simply be trying to join the race. Join requests go through the host so I think I can provide a simple option to lock the grid.
How about: /grid lock - players cannot join in the lobby /grid open - back to normal
3) Object mods sometimes need to stay in the same grid slot. In this event the track mods needed to occupy the first 3 grid slots. This was a problem on race restarts due to the automatic reordering.
Proposed solution:
Grid rearrangement is worked out on the host so does not require an incompatible version. What if the host counts the number of "object" mods in the first few player slots, and then makes sure that those objects do not change in position due to their qualifying result [NONE] or race finish result [DNF]. Instead, any object mods that are in the list before any vehicles, would retain their front grid slots.
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.