Yes, CS_MSX is steering, from left to right.
I've been trying to get that car info sorted. What I've got so far is this:
// AI CONTROL
// ----------
struct IS_AIC // AI Control
{
byte Size; // 8
byte Type; // ISP_AIC
byte ReqI; // 0
byte Zero;
byte PLID; // Unique ID of AI player to control
byte Input; // Select input value to set
word Value; // Value to set
};
// Values for Input
// CS_MSX 0 - steering : 32768 is centre
// CS_THROTTLE 1 - 0 to 65535
// CS_BRAKE 2 - 0 to 65535
// CS_CHUP 3 - shift up (set to 1 for a short time then set back to 0)
// CS_CHDN 4 - shift down
// CS_IGNITION 5 - set to 1 (auto switch off)
// CS_EXTRALIGHT 6
// CS_HEADLIGHTS 7 - 1: off / 2: side / 3: low / 4: high
// CS_SIREN 8
// CS_HORN 9
// CS_FLASH 10
// CS_CLUTCH 11 - 0 to 65535
// CS_HANDBRAKE 12 - 0 to 65535
// CS_INDICATORS 13 - 1: cancel / 2: left / 3: right / 4: hazard
// CS_GEAR 14 - for shifter (leave at 255 for sequential control)
// CS_LOOK 15 - 0: none / 4: left / 5: left+ / 6: right / 7: right+
// CS_PITSPEED 16
// CS_TCDISABLE 17
// CS_FOGREAR 18
// CS_FOGFRONT 19
// CS_NUM 20 - number of values above
// Special values for Input
// 254 - reset all
// 255 - stop control
// Send an SMALL_AII with UVal set to PLID to receive current information about a car
struct IS_AII // AI Info
{
byte Size; // 64
byte Type; // ISP_MCI
byte ReqI; // ReqI from the SMALL_AII request packet
byte Zero;
CompCar Info; // As in the MCI packet
// as in outgauge
byte Flags; // AIFLAGS_xelelow
byte Gear; // Reverse:0, Neutral:1, First:2...
byte Sp2;
byte Sp3;
float Spare;
float RPM; // RPM
unsigned ShowLights; // Dash lights (see DL_x in OutGauge section below)
unsigned SPU0;
unsigned SPU1;
unsigned SPU2;
unsigned SPU3;
};
#define AIFLAGS_IGNITION 1 // detect if engine running
//
#define AIFLAGS_CHDN 4 // downshift lever currently held
#define AIFLAGS_CHUP 8 // upshift lever currently held
I've been trying to get that car info sorted. What I've got so far is this:
// AI CONTROL
// ----------
struct IS_AIC // AI Control
{
byte Size; // 8
byte Type; // ISP_AIC
byte ReqI; // 0
byte Zero;
byte PLID; // Unique ID of AI player to control
byte Input; // Select input value to set
word Value; // Value to set
};
// Values for Input
// CS_MSX 0 - steering : 32768 is centre
// CS_THROTTLE 1 - 0 to 65535
// CS_BRAKE 2 - 0 to 65535
// CS_CHUP 3 - shift up (set to 1 for a short time then set back to 0)
// CS_CHDN 4 - shift down
// CS_IGNITION 5 - set to 1 (auto switch off)
// CS_EXTRALIGHT 6
// CS_HEADLIGHTS 7 - 1: off / 2: side / 3: low / 4: high
// CS_SIREN 8
// CS_HORN 9
// CS_FLASH 10
// CS_CLUTCH 11 - 0 to 65535
// CS_HANDBRAKE 12 - 0 to 65535
// CS_INDICATORS 13 - 1: cancel / 2: left / 3: right / 4: hazard
// CS_GEAR 14 - for shifter (leave at 255 for sequential control)
// CS_LOOK 15 - 0: none / 4: left / 5: left+ / 6: right / 7: right+
// CS_PITSPEED 16
// CS_TCDISABLE 17
// CS_FOGREAR 18
// CS_FOGFRONT 19
// CS_NUM 20 - number of values above
// Special values for Input
// 254 - reset all
// 255 - stop control
// Send an SMALL_AII with UVal set to PLID to receive current information about a car
struct IS_AII // AI Info
{
byte Size; // 64
byte Type; // ISP_MCI
byte ReqI; // ReqI from the SMALL_AII request packet
byte Zero;
CompCar Info; // As in the MCI packet
// as in outgauge
byte Flags; // AIFLAGS_xelelow
byte Gear; // Reverse:0, Neutral:1, First:2...
byte Sp2;
byte Sp3;
float Spare;
float RPM; // RPM
unsigned ShowLights; // Dash lights (see DL_x in OutGauge section below)
unsigned SPU0;
unsigned SPU1;
unsigned SPU2;
unsigned SPU3;
};
#define AIFLAGS_IGNITION 1 // detect if engine running
//
#define AIFLAGS_CHDN 4 // downshift lever currently held
#define AIFLAGS_CHUP 8 // upshift lever currently held
I should emphasise that this quick thing will not be good enough for racing. You don't receive detailed or fast enough information for control of a car near the limit. This can only be used for driving cars well within their limits. It's more of a thing for cruise or lessons.
Simple control of AI car
EDIT: A first test is now available below: https://www.lfs.net/forum/post/2114646#post2114646
Hello programmers.
There is a mod waiting for publishing, for the purpose of being "driven" by AI, but all it would actually do is drive along uncontrolled. But I don't really want to support such a bodge mod that bypasses all realism purely so it pulls away all by itself.
But I don't want to prevent something that could be fun so I've come up with a simple idea for just a few hours of work, to allow InSim to control a local car, in a very crude way. I've done a proof of concept and can now drive an AI car from an external program. Actually it disables the AI completely and you just set values, like Steer, throttle, brake, shift, etc.
EDIT: This is only for local AI. It would be far more complicated to do it from the server - that would require new multiplayer packets and I'm not getting into that.
EDIT2: To be clear, it can work for AI that are online, but the InSim must be connected to a local computer that has its own AI on it, and those are the only AI that can be controlled by this new simple packet.
I want to confirm if this could be useful.
It's just like this:
struct IS_AIC // AI Control
{
byte Size; // 8
byte Type; // ISP_AIC
byte ReqI; // 0
byte Zero;
byte PLID; // Unique ID of AI player to control
byte Input; // Select input value to set
word Value; // Value to set
};
// Input values from from CS_NUM in Inputs.h
// Special values
// 254 - reset all
// 255 - stop control
enum
{
CS_MSX,
CS_THROTTLE,
CS_BRAKE,
CS_CHUP,
CS_CHDN,
CS_IGNITION,
CS_EXTRALIGHT,
CS_HEADLIGHTS,
CS_SIREN,
CS_HORN,
CS_FLASH,
CS_CLUTCH,
CS_HANDBRAKE,
CS_INDICATORS,
CS_GEAR,
CS_LOOK,
CS_PITSPEED,
CS_TCDISABLE,
CS_FOGREAR,
CS_FOGFRONT,
CS_NUM
};
I think you might need some minimal feedback from the car, via a request info packet, and it could tell you some things like the lights and ignition status. I suppose you can get speed / position, etc from other packets like MCI? Or maybe you need something like an MCI for one car, which you can receive on request for a local AI, and maybe it has a little more date in it?
I want to keep it simple as I don't want this to go on more than this afternoon as I have other things that I am working on.
Hello programmers.
There is a mod waiting for publishing, for the purpose of being "driven" by AI, but all it would actually do is drive along uncontrolled. But I don't really want to support such a bodge mod that bypasses all realism purely so it pulls away all by itself.
But I don't want to prevent something that could be fun so I've come up with a simple idea for just a few hours of work, to allow InSim to control a local car, in a very crude way. I've done a proof of concept and can now drive an AI car from an external program. Actually it disables the AI completely and you just set values, like Steer, throttle, brake, shift, etc.
EDIT: This is only for local AI. It would be far more complicated to do it from the server - that would require new multiplayer packets and I'm not getting into that.
EDIT2: To be clear, it can work for AI that are online, but the InSim must be connected to a local computer that has its own AI on it, and those are the only AI that can be controlled by this new simple packet.
I want to confirm if this could be useful.
It's just like this:
struct IS_AIC // AI Control
{
byte Size; // 8
byte Type; // ISP_AIC
byte ReqI; // 0
byte Zero;
byte PLID; // Unique ID of AI player to control
byte Input; // Select input value to set
word Value; // Value to set
};
// Input values from from CS_NUM in Inputs.h
// Special values
// 254 - reset all
// 255 - stop control
enum
{
CS_MSX,
CS_THROTTLE,
CS_BRAKE,
CS_CHUP,
CS_CHDN,
CS_IGNITION,
CS_EXTRALIGHT,
CS_HEADLIGHTS,
CS_SIREN,
CS_HORN,
CS_FLASH,
CS_CLUTCH,
CS_HANDBRAKE,
CS_INDICATORS,
CS_GEAR,
CS_LOOK,
CS_PITSPEED,
CS_TCDISABLE,
CS_FOGREAR,
CS_FOGFRONT,
CS_NUM
};
I think you might need some minimal feedback from the car, via a request info packet, and it could tell you some things like the lights and ignition status. I suppose you can get speed / position, etc from other packets like MCI? Or maybe you need something like an MCI for one car, which you can receive on request for a local AI, and maybe it has a little more date in it?
I want to keep it simple as I don't want this to go on more than this afternoon as I have other things that I am working on.
Last edited by Scawen, .
I have done some research today. Based on income data I was able to move Argentina and Chile from the middle price band into the lower price band.
As I understand it both of these South American countries have had some economic turmoil in the past 8 years that have affected the average income.
As I understand it both of these South American countries have had some economic turmoil in the past 8 years that have affected the average income.
Maybe you can post on that thread that Sobis linked to?
Hopefully a server admin will reply to you there.
Hopefully a server admin will reply to you there.
I should add that this can be done more cleanly (no spectating of players that have already joined). Instead, an InSim program can allow them to spawn or not depending on their selected car.
- Enable join request with ISF_REQ_JOIN
- Use the IS_SLC packet to detect which car has been selected
- Respond to join requests with IS_JRR packets (JRR_REJECT or JRR_SPAWN)
See InSim.txt
- Enable join request with ISF_REQ_JOIN
- Use the IS_SLC packet to detect which car has been selected
- Respond to join requests with IS_JRR packets (JRR_REJECT or JRR_SPAWN)
See InSim.txt
That's because...
1) The flawed model is simple to code
2) It is actually 'logical' (although not physical)
I'm interested to try this, even the 'fake' version (making throttle response more realistic without doing a full engine simulation).
My understanding of the physical reason for this is that the diameter of the fully open butterfly valve is chosen to allow sufficient airflow at the engine's maximum power rpm. At low rpm the engine draws in air at a much slower rate so there isn't much resistance and so at low rpm it makes barely any difference whether the butterfly valves are fully open or half open. At low rpm when air flow is low, what makes the difference is whether the valves are a tiny bit open or slightly more open.
These days I'm sure it is more complicated as there is throttle mapping. So there is not a linear mapping between pedal and rotation of the butterfly valves. I don't know yet how the throttle mapping might be varied at different rpm. I'd be interested in that (but it doesn't affect the ability to try a test).
Also to note, not exactly the subject of this thread but even in a traditional engine without throttle mapping, and even at max power rpm, our model is also wrong, because the throttle response is linear, but that doesn't match the characteristic of butterfly valves which produce an S-shaped flow-vs-resistance characteristic. I'm sure that S-shape would be straightened by the throttle mapping (but just to repeat, I know that is not really the topic of this thread).
I do have higher priorities at the moment though, like trying to get to a state where we can do that release. This post is more to acknowledge that I'm interested in this subject, for those who didn't know that already.
I'm working on other things now but please do tell me whenever you think of any more features that could help, or anything good about forum-based signups that still isn't covered by the updated system.
I've allowed public access to the "Get CSV" function as well so people can see how that works without needing to set up a test league.
I've allowed public access to the "Get CSV" function as well so people can see how that works without needing to set up a test league.
The signup system now has support for skins.
If the administrator includes a field named "Skin" and a racer enters the name of a skin that has been uploaded, the skin is displayed on the signup page. A skin pack zip of all the skins can also be downloaded.
Signups test page: https://www.lfs.net/leagues/22/season/1219/signup/view
Forum thread: https://www.lfs.net/forum/post/2114364#post2114364
If the administrator includes a field named "Skin" and a racer enters the name of a skin that has been uploaded, the skin is displayed on the signup page. A skin pack zip of all the skins can also be downloaded.
Signups test page: https://www.lfs.net/leagues/22/season/1219/signup/view
Forum thread: https://www.lfs.net/forum/post/2114364#post2114364
Skin packs are now available. I think maybe it should only be for administrators but I have enabled it on the public page for now so you can see and test it. https://www.lfs.net/leagues/22/season/1219/signup/view
I wonder what the situation is in Argentina now, I think it may have had some economic turmoil since 8 years ago when we set the country bands, and Argentina was set in the middle band of three.
It's quite a long time ago now and maybe it is time for us to re-evaluate the high, medium and low income countries. I can't just set it though, it's a thing in our database and we would have to get the results and study it a bit and make sure we do the correct and fair thing. I think I will ask Victor about it.
It's quite a long time ago now and maybe it is time for us to re-evaluate the high, medium and low income countries. I can't just set it though, it's a thing in our database and we would have to get the results and study it a bit and make sure we do the correct and fair thing. I think I will ask Victor about it.
That command only removes mods from a list of allowed mods you have created.
It doesn't ban those mods if you have all mods allowed.
So there are two approaches you can take:
1) Create a list of allowed mods and adjust it over time.
2) Create an InSim program that detects people joining and forces them to spectate if they use a disallowed mod.
Also you might wish to report disruptive mods if they have unrealistic characteristics and should be removed from our system. Users have sometimes changed performance after publishing and this is not allowed if it is unrealistic or disruptive.
It doesn't ban those mods if you have all mods allowed.
So there are two approaches you can take:
1) Create a list of allowed mods and adjust it over time.
2) Create an InSim program that detects people joining and forces them to spectate if they use a disallowed mod.
Also you might wish to report disruptive mods if they have unrealistic characteristics and should be removed from our system. Users have sometimes changed performance after publishing and this is not allowed if it is unrealistic or disruptive.
I'll have a look around for examples where Victor has done something similar and see if I can collect and zip up the skins and send them as a single download.
I've now added an essay to try to explain the fields below and what they are and what is meant by the Team details.
I've attached an image of the text here. Please let me know if anything is unclear, incomplete or wrong.
Do you think this does the job for skins?
https://www.lfs.net/leagues/22/season/1219/signup/view
I can easily copy that over to round signups and the signup administration page. I'll also handle team skin (if a 'Skin' field is found in Team details instead of player details, which would be a good idea if all team members are sharing a car).
EDIT: Just fixed it, now it does a download with the correct filename, instead of just presenting an image with the wrong name. If there's a better way to do the http download, do let me know. This is done with a php file specific to this task and it can set whatever http headers are required.
EDIT2: Changed to view the skin in the browser but now with the correct filename in case if you decide to save it.
https://www.lfs.net/leagues/22/season/1219/signup/view
I can easily copy that over to round signups and the signup administration page. I'll also handle team skin (if a 'Skin' field is found in Team details instead of player details, which would be a good idea if all team members are sharing a car).
EDIT: Just fixed it, now it does a download with the correct filename, instead of just presenting an image with the wrong name. If there's a better way to do the http download, do let me know. This is done with a php file specific to this task and it can set whatever http headers are required.
EDIT2: Changed to view the skin in the browser but now with the correct filename in case if you decide to save it.
Last edited by Scawen, .
Thanks for the suggestion.
I think it may be possible to detect if the administrator has entered a field named 'Skin' which could then could be used as a special case to provide a download link for the skin and hopefully some info about which res is available.
I've added "Skin" field to my test season and maybe tomorrow I can try to make use of it.
I think it may be possible to detect if the administrator has entered a field named 'Skin' which could then could be used as a special case to provide a download link for the skin and hopefully some info about which res is available.
I've added "Skin" field to my test season and maybe tomorrow I can try to make use of it.
Screenshots in first post updated to show page updates including avatars, flags and info links.
For now, you can visit the signups page of my test league: https://www.lfs.net/leagues/22/season/1219/signup/view
For now, you can visit the signups page of my test league: https://www.lfs.net/leagues/22/season/1219/signup/view
Last edited by Scawen, .
Nice bug finding again. 
About the important one:
First time I've seen this code, but what happened: it stored the servers in the correct order but extracted from the database in a basically random order. At the same time, passwords were extracted preserving their order, so in fact if you had more than one host with different passwords, the passwords could be assigned to the wrong host.
I've changed the code to reassemble the list of servers in the order they were stored, so this should fix the problem. I recreated your test in my Round signup season and the bug appears fixed. Also my fake passwords have remained with the correct hosts, if I look in Edit Season.
About the important one:
First time I've seen this code, but what happened: it stored the servers in the correct order but extracted from the database in a basically random order. At the same time, passwords were extracted preserving their order, so in fact if you had more than one host with different passwords, the passwords could be assigned to the wrong host.
I've changed the code to reassemble the list of servers in the order they were stored, so this should fix the problem. I recreated your test in my Round signup season and the bug appears fixed. Also my fake passwords have remained with the correct hosts, if I look in Edit Season.
You are right, it needed to be made clear if a league is inactive (which basically means hidden). I also was wondering about a separate switch to make each season hidden or not, but I decided not to do that in a hurry, as it's not really necessary for now.
Anyway, along with that I found a few more presentation issues and did a few more updates today. Don't worry everyone, I'm aware that this has dragged on a few more days than hoped, but I've been thinking about the next updates to get the Retro model ready for release.
Minor updates:
Added avatars to the signup administration pages
The text (inactive) is displayed beside the name of inactive leagues
Links to league, season, forum, website on signup info pages (as on round or season pages)
FIX: Confusion around first event and number of events on round signup pages
FIX: After editing a round it went back to season page instead of round page
Anyway, along with that I found a few more presentation issues and did a few more updates today. Don't worry everyone, I'm aware that this has dragged on a few more days than hoped, but I've been thinking about the next updates to get the Retro model ready for release.
Minor updates:
Added avatars to the signup administration pages
The text (inactive) is displayed beside the name of inactive leagues
Links to league, season, forum, website on signup info pages (as on round or season pages)
FIX: Confusion around first event and number of events on round signup pages
FIX: After editing a round it went back to season page instead of round page
That is because my whole league is marked as "inactive" which I have set so it doesn't appear in the calendar.
For ordinary leagues, you would see your signups there.
I have just changed it so you can see signups in inactive leagues too, so now you can see your signup to my league, in My Signups section.
I'm not sure if that is a bad idea or not.
Great to have all these entries! I couldn't help but do a little more work and now your avatars are visible there!
https://www.lfs.net/leagues/22/season/1219/signup/view
https://www.lfs.net/leagues/22/season/1219/signup/view
You can see in season details!
https://www.lfs.net/leagues/22/season/1219
Maybe not the best of events as it consists of a 5 minute practice and nothing else.
No prizes for this one!
https://www.lfs.net/leagues/22/season/1219
Maybe not the best of events as it consists of a 5 minute practice and nothing else.
No prizes for this one!
Thank you all for the feedback. I've finished this work for now, other than minor updates that may be needed.
I've written a new thread in the Leagues & Events section, talking a bit about the updates and reasons for them, listing features and including a few example screenshots. https://www.lfs.net/forum/thread/110231
I've written a new thread in the Leagues & Events section, talking a bit about the updates and reasons for them, listing features and including a few example screenshots. https://www.lfs.net/forum/thread/110231
Updated on-site event entry system
Hello League Administrators,
For a long time we have had a race entry system that can be enabled to allow people to sign up for league seasons or individual rounds. Although it has many features and could be useful, it has not been used very often, partly because of certain flaws and missing features.
Organisers who require participants to sign up would be more likely to use a forum thread or something on another website. The trouble with a forum thread is the need to copy and paste details for each participant. Until now, this was not helped by the on-site system, but now we have a CSV export to easily extract the entries into a spreadsheet. One of the benefits of a forum thread is that it seemed easier to contact the users about any errors in their entries. The on-site system didn't help with that either but now there is a simple button to send a personal message to any or all participants who have signed up to your league.
There were other issues too, for example the in-game sign-up link would take people directly to the sign-up page, without presenting them with any information to read. Now the link takes them to the round information page which has been improved and information and links are readily available. Navigation around the leagues section has been improved so visitors should be able to find all the info they need and links to forum threads and other websites if needed.
The entry form can be customised to include as many fields as you need (e.g. race number, real name, country, team, etc... whatever you want). These can be for individuals, or team entries are also supported, e.g. for endurance races, so for example you could allow 40 teams of up to 4 people each.
The entry data of anyone who has signed up are visible with a single click from the season or round pages (depending on whether you selected entry per season or per round) and the link can be posted anywhere.
List of sign-up features:
Additional administrators can be specified by the owner of the league
Set up a customised race entry format, for individual or team entries
Entries can be set to be for the whole season or for individual rounds
Round or season entries can be seen by anyone who visits the round or season page
Any number of required fields may be set, per team or per racer (e.g. name, country, number, etc)
For team-based entries, a minimum and maximum number of racers per team can be set
An opening and closing time for entries can be specified
There is an option for entries to require approval by an admin
Entries can be deleted by an admin (or the person who signed up)
The person who signed up can edit their entry at any time or remove or add team members
Admins can download a CSV file containing the info of all entrants, to paste into a spreadsheet
Admins can now send a message to any or all participants from the signup administration page
The attached images show an example of a single-entry (not team) per season (not per round) setup.
Further development:
I am working on other things now, but if there are simple features that are still missing for your purposes, or any more issues I should consider, I would like to hear about it. Maybe you need another type of data export, maybe there should be another link or option, or you have an idea to improve presentation.
Thank you for your support!
For a long time we have had a race entry system that can be enabled to allow people to sign up for league seasons or individual rounds. Although it has many features and could be useful, it has not been used very often, partly because of certain flaws and missing features.
Organisers who require participants to sign up would be more likely to use a forum thread or something on another website. The trouble with a forum thread is the need to copy and paste details for each participant. Until now, this was not helped by the on-site system, but now we have a CSV export to easily extract the entries into a spreadsheet. One of the benefits of a forum thread is that it seemed easier to contact the users about any errors in their entries. The on-site system didn't help with that either but now there is a simple button to send a personal message to any or all participants who have signed up to your league.
There were other issues too, for example the in-game sign-up link would take people directly to the sign-up page, without presenting them with any information to read. Now the link takes them to the round information page which has been improved and information and links are readily available. Navigation around the leagues section has been improved so visitors should be able to find all the info they need and links to forum threads and other websites if needed.
The entry form can be customised to include as many fields as you need (e.g. race number, real name, country, team, etc... whatever you want). These can be for individuals, or team entries are also supported, e.g. for endurance races, so for example you could allow 40 teams of up to 4 people each.
The entry data of anyone who has signed up are visible with a single click from the season or round pages (depending on whether you selected entry per season or per round) and the link can be posted anywhere.
List of sign-up features:
Additional administrators can be specified by the owner of the league
Set up a customised race entry format, for individual or team entries
Entries can be set to be for the whole season or for individual rounds
Round or season entries can be seen by anyone who visits the round or season page
Any number of required fields may be set, per team or per racer (e.g. name, country, number, etc)
For team-based entries, a minimum and maximum number of racers per team can be set
An opening and closing time for entries can be specified
There is an option for entries to require approval by an admin
Entries can be deleted by an admin (or the person who signed up)
The person who signed up can edit their entry at any time or remove or add team members
Admins can download a CSV file containing the info of all entrants, to paste into a spreadsheet
Admins can now send a message to any or all participants from the signup administration page
The attached images show an example of a single-entry (not team) per season (not per round) setup.
Further development:
I am working on other things now, but if there are simple features that are still missing for your purposes, or any more issues I should consider, I would like to hear about it. Maybe you need another type of data export, maybe there should be another link or option, or you have an idea to improve presentation.
Thank you for your support!
Last edited by Scawen, .
Reason : updated images
As mentioned, the signups can be seen by anyone, so could be linked from a forum discussion thread.
Examples: (the required fields per entry are all editable)
1) Here is a list of signups for a test season in which you can enter as a single racer (1 per team).
https://www.lfs.net/leagues/22/season/1219/signup/view
2) Here is a list of signups for a test season in which you can sign up in teams of up to 4 racers per team:
https://www.lfs.net/leagues/22/season/1218/signup/view
3) Here is a list of signups for a test season in which you can sign up for individual rounds:
https://www.lfs.net/leagues/22/season/1223/round/1/signup/view
Examples: (the required fields per entry are all editable)
1) Here is a list of signups for a test season in which you can enter as a single racer (1 per team).
https://www.lfs.net/leagues/22/season/1219/signup/view
2) Here is a list of signups for a test season in which you can sign up in teams of up to 4 racers per team:
https://www.lfs.net/leagues/22/season/1218/signup/view
3) Here is a list of signups for a test season in which you can sign up for individual rounds:
https://www.lfs.net/leagues/22/season/1223/round/1/signup/view
OK, I have completed the to do list now, including "Send message to all" participants.
Added links 'Website' and 'Discussion forum' to season and round pages
- Info is there for anyone who gets to the page from the calendar or by clicking signup in game
Improved some button placements for consistency of navigation around league section
- Trying to make it easier and clearer for participants and admins
Admins can now send a message to participants on signup administration page
- Send message to all participants
- Sent message to a single participant
- The list of recipients can be adjusted
Added links 'Website' and 'Discussion forum' to season and round pages
- Info is there for anyone who gets to the page from the calendar or by clicking signup in game
Improved some button placements for consistency of navigation around league section
- Trying to make it easier and clearer for participants and admins
Admins can now send a message to participants on signup administration page
- Send message to all participants
- Sent message to a single participant
- The list of recipients can be adjusted
FGED GREDG RDFGDR GSFDG