Finally I have included withdrawals on the notification thread.

I don't plan to work on this any more today but will do so if you have any problems.

One more small change as I noticed the Race Green rally signup has included "Country" as a field.

I've now made "Include user's country in CSV export" an option. As you wanted that, you should switch on that option (in Edit season, just above the signup thread option).

I thought of this in the night and had to add this feature to try to solve the remaining problem with not using forum signups.

In "Edit season" you can now add an optional sign-up thread.

So in your case you would add https://www.lfs.net/forum/thread/110364 (or just the thread id 110364) and then you will see a notification of new signups.

I could add a similar notification for withdrawn/deleted signups which would obviously be easy to add now that the system is in place.

Last edited by Scawen, Wed 29 Jan 2025, 09:53. Reason : removed example notification thread

I used to smoke roll-ups but restarted each time I tried to stop.

My fitness had declined due to a mainly sedentary lifestyle (and I guess smoking didn't help either).

Eventually when I took up running and cycling to get outside and become fit again, I wanted to be faster and it was embarrassing to smoke in the car park at mountain bike events (hiding behind my car) so then I finally stopped at the end of a packet. It is possible to just stop, best to plan it ahead, reduce the amount a bit and then stop on a target day. But you have to understand that you will never smoke again, not a single puff. If you can't honestly make that commitment then I guess there's no point even trying.

Physically for me it was a feeling like being thirsty for a couple of days, then for the following year or so I could think of a cigarette at any time when I would have had one in the past. But that connection gradually disappears as you do those things and don't smoke.

Now, approaching 13 years later it is very rare for me to have a thought of a cigarette and it's very easily dismissed, just seems a bit odd that it still pops into my head on rare occasions.

Duplicate numbers are now shown in red:
https://www.lfs.net/leagues/22/season/1219/signup/view

Note - this is if the field name is Number


EDIT: So apparently the only remaining thing at the moment is for admins to be able to edit entries directly. I think I can do that but not today and maybe better not do that one for a few days, and maybe you'll come up with something else more urgent.

Last edited by Scawen, Mon 27 Jan 2025, 21:36.

There is now a manual temporary signup closure.

You can see how it looks on one of my test seasons: https://www.lfs.net/leagues/22/season/1218

(it says "Signup temporarily closed" and you can still click to see the signed up racers)

The option is activated on "Edit season" page as seen in the screenshot.

I've realised duplicate number detection is a bit complicated as it needs to retrieve quite a bit of info and search through it and present error messages to the user, preventing them submitting their updates. It's more complicated than you might expect because of the fully customisable entry fields. I might try something simpler like highlighting duplicate numbers in red, just when the page is displayed. Something to make it easier for admins without doing the full job. It might even be better that way, in case a new user selected a number that is really reserved for someone else like last year's winner, etc.

Current status, referring to Jonathon's original requests.
CONSIDER means I intend to look today.


1. CSV agree Nationality would be nice there.
DONE

2. CSV also headers for columns would be a nice to have.
DONE

3. Ability for admins to edit a entry manually.
CONSIDER

4. & 5. Notification to admins of any changes a drivers makes to their entry after it has been approved. Plus the ability to approve a change would be awesome!
DONE for leagues that require approval of entries
(notification sent to admins if there is a new entry or an already approved entry is edited - requires approval again)

6. Ability to temporarily close signups a certain time before a round and x time after a round completion. This may need to be a time stamp after event maybe?
[edit: DONE option to manually close and open again]

7. Ability for car number to be tracked and not used more than once
[edit: DONE duplicate numbers are shown in red, if field name is "Number"]

8. Ability to reject a signup with a reason, giving the driver a chance to correct the details rather than going through the whole signup again.
SUGGEST use signup PM system
(the signup PM works for signed up drivers even if they don't allow forum PM)

Last edited by Scawen, Mon 27 Jan 2025, 21:33.

OK CSV improved as requested.

If you click Get CSV on my test page you will see:

1) First row is column titles (as specified by admin)
2) The column after user name is Country

Admin should not add "Country" when setting up the signup required fields. It automatically appears in the CSV after the user name.

Right, first thing I had to do this morning was some essential maintenance (gutter clearing). The rain and hail brought more moss down.

I've had a bit of a fight with some php code but now the season signups are updated so admins of a league that is set to require approval of entries get a new email if:

1) There is a new entry
2) An entry that has been approved, is now edited

In case (2) the entry is no longer marked as 'approved'.

I've made it clearer to see on the admin pages if an entry requires approval.

I'll continue to look at more things now.


I know Viperakecske and some others will be frustrated that I'm not working on Tyre physics this afternoon but I'd really appreciate if they can keep out while I do a few more things this afternoon to make the league entry system good enough to be used for a high quality league. The idea will be to get on with the tyres in the morning. So please leave me in peace.

Well thank you very much and I hope I haven't been too annoying pressurising you to do it. I will look at some this morning and will keep supporting it as you go. For anyone concerned, this will not stop me working on the tyre physics this afternoon.

I understand it's an experiment and I thank you for making that experiment real.

EDIT: I'll do the country export of CSV as one of the first things and look at user-editing removing approved status, and sending an email to all admins when a change is made. Maybe, to avoid email spam, an email like that is only made, when an "approved" entry is edited and becomes no longer approved?

Last edited by Scawen, Mon 27 Jan 2025, 11:10.

Sorry, I wrote previous post without knowing you had posted!

I'll have a look this morning. I think they mostly look like quite small things and could be quickly done.

To be clear, I could look at some today and get them sorted, if it would actually go into use for the E-challenge.

I've heard a couple of times that people say the forum thread itself can make the event seem alive. It seems like you could get the same effect with a sort of news thread and do a daily post each time more people have signed up, linking to the signup page. Or maybe there are better ideas.

It does seem like just falling back to the forum-based signup at this point would be quite sad, rejecting the new system without even giving it a try, when I am quite willing to add a few features, on the same day you request them.

1) You can set country as a field for people to enter (of course, you can add any named field). But if you don't want people to type in their country, I guess I could add a separate CSV export option that includes country as listed on the forum.

2) How would that be done? is there a special format for that or is it like the first line of the CSV is just column headers?

3) Makes sense, though you could use the PM system to tell the person.

4) Do you mean simply an email to admins if someone edits their entry?

5) Starting to get too complicated now, the need to store in database the version before and after the change? Or do you mean more simply the entry loses its "APPROVED" status if they edit it?

6) I was thinking a manual close and open might be a better option.

7) You can use the PM system (although a number check on a a specifically named field could be possible).

8) You can use the PM system.


I find it a bit extreme that some of these are preventing you from using the system. 1, 2, 3, 5, 7, 8, don't really seem like reasons not to use the system as forum signups don't do that either.

To my mind that only leaves 4 and 6 as remaining advantages of the forum system that you have listed.

I could probably add some of these and would do so before the E-challenge if you would use it. But I did a big push recently as you know and it seems like you've left it a bit late to respond. Also it seems like something else might be preventing you from wanting to use it, because you haven't really listed much that should prevent you using it (if I added 4 and 6, for instance). EDIT: And maybe (5) if you just mean that editing an entry means it loses its "approved" status. I'd also look at some of the other ones.

Last edited by Scawen, Mon 27 Jan 2025, 10:45.

These quick weekend updates are all I can really do at this time. Improvements that are harder to implement will have to wait for the future.

I'll be doing another push on the Retro tyre model at the start of the working week, moving towards the big release.

Of course, this test patch can be easily updated at any time if simple updates / bug fixes / documentation corrections are needed.

OK, I've added the repeating AII option, it's a special Input value CS_REPEAT_AI_INFO.
The special input values now have defines instead of 253, 254 etc.
You can also use CS_SEND_AI_INFO to send a single AII (like SMALL_AII).


Updated section in docs/InSim.txt


Download:

https://www.lfs.net/file_lfs.php?name=LFS_PATCH_7F_TO_7F5.zip

That's great to hear, thanks!

Usually if a few lines are added for a new teat patch I send a notification from our admin system to all the translators.

Quote from iamproplayer7 :

- auto gear box sometimes gear up to high or too low, with message GEAR_DOWN avoided or similar

I'm not sure what this means. Auto shift doesn't work well?

Quote from iamproplayer7 :

multiple PLIDs because local InSim gets a bit spammed when you want to control 30 or more AI vehicles.
30 vehicles every 50ms = 600 packets every second. 600 * 8 bytes = 4800 bytes every second.

Maybe a better solution would be if I would add a packet to request regular updates.

Maybe something like


I think it should be easy enough though I haven't checked thoroughly yet.

Last edited by Scawen, Sun 26 Jan 2025, 10:10.

Quote from iamproplayer7 :

First of all, yes - there is problem in my own script/framework and i'm very sorry that i made you waste so much valuable time...

No problem at all, I only wrote a few sentences and briefly looked at the output in my InSim test program.

Good to hear you identified the issue.

Quote from iamproplayer7 :

- add direction to IS_AII like CompCar struct has.

At least this one should be easy if you have an atan2 function.

Direction = atan2f(-Vel.x, Vel.y); // in radians

Thanks for the thanks but you don't need to buy an account just to thank me.

Quote from iamproplayer7 :

Now i have this issue, using 7F4 (also tried 7F3) as client and InSim Version 9 in my InSim, i rechecked my framework and it works very well and intended as it should. I'm not getting ISP_PLL packet consistely (player spectates), only first time after insim connects and sometime after randomly.

From my point of view it's most likely there could be a bug in your packet reader. For example two packets arriving at once but you only read the first one.

This is a quite fundamental packet so I doubt that it is broken, though I could check tomorrow.

EDIT: I've checked now and I'm getting IS_PLL as expected. I think you should check how many bytes arrived in your TCP read and compare that with the packets you processed. In case a packet is going missing. Packets may arrive more than one in a single read or even be split across multiple reads, which really does happen!

Quote from Bokujishin :

I just noticed an issue, it seems like CS_CHUP, CS_CHDN and CS_FLASH get "stuck", they only work once and never go back to zero, so I can't change gears anymore, and the high beam flash stays on indefinitely.

That behaviour, for these inputs that you can hold indefinitely, is documented above but maybe it's not clear enough.

Mentions in the InSim.txt:

// If the Time value is set, that input will return to default after that time.
// This is probably most useful for CS_CHUP / CS_CHDN / CS_FLASH / CS_HORN inputs.
// If you don't use Time then you should send another packet to zero the input.

// CS_CHUP 3 - shift up (set to 1 for a short time then set back to 0)
// CS_CHDN 4 - shift down

I suggest you could use a time like 10 (which is 0.1s). Otherwise (if you use 0 for the Time value) you are just telling it to hold the lever on full time.

EDIT: Tested again and it's still working as expected. Maybe I'll add a bit clearer description in InSim.txt about the need to zero or use the Time value, for those specific controls.

Last edited by Scawen, Sat 25 Jan 2025, 21:27.

Wow, thanks!
I see it hadn't been updated for a long time.
I've uploaded it to the online system.
https://www.lfs.net/lfs_translate/public_translation_viewer.php

I'm not sure if you would like to do any more of it, but in case you do, I've added your access to the online editing system. I can easily remove your user name from the list if you don't want it there.

Translation page: https://www.lfs.net/lfs_translate/translate.php
You can either click the disc beside each edited line, or edit several lines and click "save whole translation".

EDIT: There is a new update below: https://www.lfs.net/forum/post/2114897#post2114897


Here is another update, F4. It's easier to use as you can set PIF_AUTOGEARS and you can set switches and ignition directly instead of toggling them.

Changes from F3 to F4:

The following inputs can now accept values 1:toggle / 2:off / 3:on
CS_IGNITION / CS_EXTRALIGHT / CS_PITSPEED / CS_TCDISABLE / CS_FOGREAR / CS_FOGFRONT

New special value for input 253 sets help flags.
Values that can set set are any combination of the following "Player flags" bits:
PIF_AUTOGEARS // 8 - auto shift
PIF_HELP_B // 64 - brake help
PIF_AUTOCLUTCH // 512 - auto clutch
The default value for an AI is PIF_AUTOCLUTCH only
If you set PIF_AUTOGEARS you don't need to set PIF_AUTOCLUTCH as it is implied

Zero is now an invalid value for CS_MSX
Valid CS_MSX values are 32768 plus or minus 32767 that results in a valid range 1 to 65535
The only possible word value not included is zero and it's better to report as invalid
In this way, an error will be reported if there is any completely zero AIInputVal

Updated section in docs/InSim.txt


Download:

[ link removed - new update available ]

Last edited by Scawen, Sun 26 Jan 2025, 17:15.

I've moved spam and a resolved issue to a cleanup thread.

I request that people who can't understand the benefit of this system should avoid posting here.

Quote from Bokujishin :

Also, could you please confirm that extra light and fog lights only accept 0 (no change) and non-zero (toggle)? If possible, being able to specifically turn them on or off, in addition to toggling, would make it easier to use.

I think this can be simply done. I'll probably add an off and on value for the fog and extra light.


EDIT: I think it may be possible to add some help options too:

#define PIF_AUTOGEARS 8
#define PIF_HELP_B 64
#define PIF_AUTOCLUTCH 512

By default an AI has PIF_AUTOCLUTCH set. It may be possible to add an input to set these 3 values optionally.


EDIT2: I did the toggle update this morning and it will be in F4.
The following inputs can now accept values 1:toggle / 2:off / 3:on
CS_IGNITION
CS_EXTRALIGHT
CS_PITSPEED
CS_TCDISABLE
CS_FOGREAR
CS_FOGFRONT


EDIT3: Now I've added the ability to set help flags.
New special value for input 253 sets help flags.
Values that can set set are any combination of the following "Player flags" bits:
PIF_AUTOGEARS // 8 - auto shift
PIF_HELP_B // 64 - brake help
PIF_AUTOCLUTCH // 512 - auto clutch
The default value for an AI is PIF_AUTOCLUTCH only
If you set PIF_AUTOGEARS you don't need to set PIF_AUTOCLUTCH as it is implied


EDIT4: Finally for today, I've made zero an invalid value for CS_MSX
Valid CS_MSX values are 32768 plus or minus 32767 that results in a valid range 1 to 65535
The only possible word value not included is zero and it's better to report as invalid
In this way, an error will be reported if there is any completely zero AIInputVal


I'll update documentation and release F4.

Last edited by Scawen, Sat 25 Jan 2025, 18:55.

I guess the AIInputVal structures you unintentionally submitted as zero were interpreted as:

Input = 0 : CS_MSX (steer)
Time = 0 : stay on
Value = 0 : full left

Quote from Bokujishin :

I will check again on my end, just found it strange that only steering is not behaving properly, even though it's in the middle of other inputs (see screenshots for test program bit - apart from extra light and fog lights which do not work on this car, everything other than steering is fine with this packet containing all inputs). Just FYI, my hold times are given in seconds as floats, input values are given raw as per your documentation.

No floats, the hold times are bytes representing hundredths of a second.

I don't know how that language works but you'd better make sure the byte and word values are combined correctly, resulting in the correct size packet.

Quote from Bokujishin :

Edit: Also, could you please confirm that extra light and fog lights only accept 0 (no change) and non-zero (toggle)? If possible, being able to specifically turn them on or off, in addition to toggling, would make it easier to use.

That is true.