I'm not sure if this helps but I guess you will now have to manually edit their names or delete them in your data\misc folder.
If there is a guaranteed set of steps to reproduce this bug then I could have a look at it but I think it is too rare for me to look into it at this point. It looks like something to do with code pages.
The mods screen in game isn't different for reviewers (we don't see private mods unless we have permission).
So for everyone, on the mods screen you will only see a padlock if it is your own private mod or someone else's private mod and you have permission to use it.
OK, I've done a fix for the replay slider + MCI disconnect issue in Test Patch E8.
Now, when clicking on replay slider or using IS_RIP to do the same thing, NLP/MCI packets will not be sent. I hope this works because I haven't actually tested it, but it was just a line of code.
In the case when using IS_RIP with option RIPOPT_FULL_PHYS the NLP/MCI packets are still sent. My hope is that because it is taking the time to do the physics, the rate of MCI output may be manageable. But I haven't tested this at all so I can't really confirm.
About the similar issue when joining a server, I couldn't think of a quick way to safely avoid sending the packets until LFS catches up with the server. I want to consider this a bit longer.
Updates to support approved mods in Test Patch E8. Please give thoughtful ratings to unapproved mods, or make comments on their threads to help them reach approved status.
Support for approved mods:
Tick (aka check mark) is shown in mods screen for approved mods
- also TW is shown for tweak mods and padlock for private mods
An 'external link icon' is visible when two columns are displayed
Rating stars pulsate in garage if you have not yet rated the mod
InSim:
NLP/MCI packets are no longer sent after clicking replay slider
- also not sent after IS_RIP unless RIPOPT_FULL_PHYS is set
The default is supposed to work for hosts you just start up and are unmanaged, so 4 minutes is not suitable for that. 8 seconds has been fine for 20 years or so, so to change to 4 minutes would be way too extreme. It seems like you are only thinking of the downside of this code, without considering the problem it solves. I was thinking maybe around 12 seconds, which could be boring enough when you finish a race but another racer who is blocking your result has gone AFK. With long times, there is a risk that the race restarts before you even get your result. The idea is that long stationary times, such as minutes, would be available for managed hosts, for hosters who know what they are doing.
I've had a look now and my reply is slightly complicated because there is a bug in the code that might sometimes come into action, but even without the bug, the problem is likely to come up.
By the way, I couldn't see anything different for custom configs and I think this could happen in any race.
What is supposed to happen (and does usually happen):
If a result can't be confirmed, because another car that might beat that result is still on track, then if that other car is stationary for 8 seconds, the game decides they will never finish and the result would never be confirmed, so it spectates that player.
So even without the bug I'll also describe, this can cause the problem.
E.g.
A wins the race with 4 laps
B has completed 2 laps but is not moving
C finishes with 2 laps
Problem:
Cannot confirm C's result as B could still beat C. Host spectates B if stationary for 8 seconds.
Separately, the bug (not sure how often this comes up):
1) Suppose the situation is as above except that B only has completed 1 lap. It cannot beat C and is therefore not blocking C's result. It is possible sometimes for the game to spectate B anyway.
2) Suppose the situation is as above except that B has completed 3 laps. Actually in the current system it does block C's result from being confirmed and 'should' be spectated but will not be.
What to do:
For a start, I'll fix the bug, but we are still left with the game spectating cars that are not moving in order to confirm results. What do we need to fix this problem? How about a host option to change that 8 seconds to something else, maybe up to 4 minutes? The easiest way to do this is by a text command after the host is started, and not available on the website. Maybe the default time should be a bit longer than 8 seconds too?
That's a known issue when a mod is unpublished, but actually the ratings are not lost, they reappear when a new rating is made, as I have now done on your mod.
EDIT: This should now be fixed, though this is a difficult fix to verify, as I would have to catch a mod, that had visible ratings before being unpublished, that has been unpublished, then fixed by its author, and catch it to see that it still has visible ratings before anyone updates the ratings again. So for this one I'm just assuming the fix should work.
We have made an adjustment to the mod system to try to make the system sustainable for a longer time and to be more beneficial to community members. In short, there is now a limit to the number of unapproved mods that each user can submit. High quality mods that reach approved status are not counted in this limit. It is also possible to purchase extra slots if necessary.
Thanks for the replies. Yes, by fast forwarding I meant when clicking on the slider. I think this is what CRAAACH means by the "no_gpu_rendering" feature?
Interestingly I think you are both suggesting equally valid but completely different options.
CRAAACH: do send MCI/NLP on clicking slider (or maybe only when sending IS_RIP?) but slow down LFS sufficiently not to flood the buffer.
Racon: avoid sending MCI/NLP on clicking slider.
Although I haven't studied in detail yet, Racon's solution seems easier to implement, is a very good option to have and doesn't really lose anything at this point. So then CRAAACH's solution could be done as a separate option at some point, maybe as a RIPOPT option.
I've had a quick look so far and thought I should ask what behaviour we really want from this, in those two situations.
For example one option would be to disable NLP and MCI when fast forwarding. Is there a reason to receive NLP / MCI packets when fast forwarding a replay?
And when joining a host, I guess it could be disabled until LFS has caught up with real time.
Or a different type of solution, I think it might also be possible for a send buffer (held by LFS internally) to expand massively if the input is so much faster than the output but it seems there should be some kind of limit to this.
I'd be interested to hear your thoughts on that. One thing you might try for a quick solution is using UDP packets for MCI / NLP. But of course I don't know how easy it is to change your program to receive UDP packets instead, or if they are suitable for your purposes.
I think from your location you are redirected to USA server. If that is the case, there is a yellow "Redirect" message one time in the message text.
Maybe for some reason the redirect isn't working for you. In that case it may work if you switch off "Allow regional downloads" in Misc Options. Then it will download from our main server.
Yes, I confirm the ratings are updated again when clicked. So they are not lost and the only problem is the processed ratings not appearing when the mod is republished after unpublishing.
Thank you for trying to help but I can't really take on translation duties. Even though I quickly fixed a typo in the German translation, I can't be responsible for translation updates.
Thanks, I agree this shouldn't have happened but I have a hunch why it did. I've made sure this can't happen again right now and I also have a longer term solution to implement today.
My main concern in this case is the loss of ratings but I'll have a look at that too to try and understand it.
As I'm aiming for an incompatible version very soon, I've made a note to look at this, probably tomorrow. I can't comment more until I understand how it works in the code.
I'm trying to release 0.7F in a short time with all the updates and it should be incompatible to make sure everyone gets on the new version.
Your request really would set "number of stops" that player has done. I don't see a difficulty adding a packet to set this, in an incompatible version.
I can't see any other thing that is similar, that I should code at the same time. We can set number of laps and a penalty, so I guess the number of pit stops done is the one missing thing.
I will disconnect from this thread now to focus on work.
I'd like to thank Chris again for his well written post which I said I would read again later.
I hope it's OK to say a few parting words. I know TC provides a lot of entertainment within LFS, which is a good part of why I've always done a few things here and there to support cruise servers. I don't believe TC or I can eliminate license sharing but we can be aware of it and reduce it. At least some of us learned a few things in this thread that we were not aware of before.
No doubt I have expressed some things too strongly and interpreted other people's words wrongly as it got too heated in this thread. I hoped after Chris's post that we were moving on, and I still hope that.