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.
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.
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?
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, .
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.
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.
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.
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, .
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.
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
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
// AI CONTROL
// ==========
struct AIInputVal // There is an array of these in the AIC packet below
{
byte Input; // Select input value to set
byte Time; // Time to hold (optional, hundredths of a second)
word Value; // Value to set
};
const int AIC_MAX_INPUTS = 20; // NOTE: Increase if CS_NUM is increased
struct IS_AIC // AI Control - variable size
{
byte Size; // 4 + 4 * (number of inputs)
byte Type; // ISP_AIC
byte ReqI; // Optional - returned in any immediate response e.g. reply to CS_SEND_AI_INFO
byte PLID; // Unique ID of AI driver to control
AIInputVal Inputs [AIC_MAX_INPUTS];
};
// If the Time value of AIInputVal 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 set Time you will need to send another packet to zero the input.
// Values for Input
// CS_MSX 0 - steer: 1 hard left / 32768 centre / 65535 hard right
// CS_THROTTLE 1 - 0 to 65535
// CS_BRAKE 2 - 0 to 65535
// CS_CHUP 3 - hold shift up lever
// CS_CHDN 4 - hold shift down lever
// CS_IGNITION 5 - toggle
// CS_EXTRALIGHT 6 - toggle
// CS_HEADLIGHTS 7 - 1:off / 2:side / 3:low / 4:high
// CS_SIREN 8 - hold siren - 1:fast / 2:slow
// CS_HORN 9 - hold horn - 1 to 5
// CS_FLASH 10 - hold flash - 1:on
// 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 - toggle
// CS_TCDISABLE 17 - toggle
// CS_FOGREAR 18 - toggle
// CS_FOGFRONT 19 - toggle
// Inputs marked 'hold' must be set back to zero after some time.
// This can be done either by use of the Time field or by sending a later packet with Value = 0.
// E.g. Set Time to 10 when issuing a CS_CHUP - hold shift up lever for 0.1 sec.
// E.g. Set Time to 50 when issuing a CS_HORN - sound horn for 0.5 sec.
// Inputs marked 'toggle' accept the following Values:
// 1 toggle
// 2 switch off
// 3 switch on
// Special values for Input
#define CS_SEND_AI_INFO 240
#define CS_REPEAT_AI_INFO 241
#define CS_SET_HELP_FLAGS 253
#define CS_RESET_INPUTS 254
#define CS_STOP_CONTROL 255
// CS_SEND_AI_INFO - Send an IS_AII (AI Info) packet
// CS_REPEAT_AI_INFO - Start or stop sending regular IS_AII packets
// Time = time interval in hundredths of a second (0 : stop)
// CS_SET_HELP_FLAGS - Value can be any combination of
// PIF_AUTOGEARS // 8 - auto shift
// PIF_HELP_B // 64 - brake help
// PIF_AUTOCLUTCH // 512 - auto clutch
// Default value for an AI driver is PIF_AUTOCLUTCH only
// If you set PIF_AUTOGEARS you don't need to set PIF_AUTOCLUTCH
// CS_RESET_INPUTS - reset all inputs
// Most inputs are zero / CS_MSX is 32768 / CS_GEAR is 255
// CS_STOP_CONTTROL
// The AI driver will stop the car
// AI car info
// -----------
// Send a SMALL_AII with UVal set to PLID to receive current information about a local car
struct OSMain // included in IS_AII - identical to OutSimMain (main data in OutSim packet)
{
Vector AngVel; // 3 floats, angular velocity vector
float Heading; // anticlockwise from above (Z)
float Pitch; // anticlockwise from right (X)
float Roll; // anticlockwise from front (Y)
Vector Accel; // 3 floats X, Y, Z
Vector Vel; // 3 floats X, Y, Z
Vec Pos; // 3 ints X, Y, Z (1m = 65536)
};
struct IS_AII // AI Info
{
byte Size; // 96
byte Type; // ISP_AII
byte ReqI; // ReqI from the SMALL_AII request packet
byte PLID;
OSMain OSData;
byte Flags; // AIFLAGS_x below
byte Gear; // Reverse:0, Neutral:1, First:2...
byte Sp2;
byte Sp3;
float RPM; // RPM
float SpF0;
float SpF1;
unsigned ShowLights; // Dash lights currently switched on (see DL_x in OutGauge section below)
unsigned SPU1;
unsigned SPU2;
unsigned SPU3;
};
#define AIFLAGS_IGNITION 1 // detect if engine running
//
#define AIFLAGS_CHUP 4 // upshift lever currently held
#define AIFLAGS_CHDN 8 // downshift lever currently held
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.
Usually if a few lines are added for a new teat patch I send a notification from our admin system to all the translators.
I'm not sure what this means. Auto shift doesn't work well?
Maybe a better solution would be if I would add a packet to request regular updates.
Maybe something like
struct IS_RAI // Regular AI
{
byte Size; // 8
byte Type; // ISP_RAI
byte ReqI; // 0
byte PLID;
word Interval; // time between updates, 0 to stop
byte Sp2;
byte Sp3;
};I think it should be easy enough though I haven't checked thoroughly yet.
Last edited by Scawen, .
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.
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.
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!
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, .
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".
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 ]
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
// AI CONTROL
// ==========
struct AIInputVal // There is an array of these in the AIC packet below
{
byte Input; // Select input value to set
byte Time; // Time to hold (optional, hundredths of a second)
word Value; // Value to set
};
const int AIC_MAX_INPUTS = 20; // NOTE: Increase if CS_NUM is increased
struct IS_AIC // AI Control - variable size
{
byte Size; // 4 + 4 * (number of inputs)
byte Type; // ISP_AIC
byte ReqI; // 0
byte PLID; // Unique ID of AI driver to control
AIInputVal Inputs [AIC_MAX_INPUTS];
};
// 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.
// Values for Input
// CS_MSX 0 - steer: 1 hard left / 32768 centre / 65535 hard right
// 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 - toggle
// CS_EXTRALIGHT 6 - toggle
// 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 - toggle
// CS_TCDISABLE 17 - toggle
// CS_FOGREAR 18 - toggle
// CS_FOGFRONT 19 - toggle
// CS_NUM 20 - number of input values above
// The Inputs marked 'toggle' accept the following Values:
// 1 toggle
// 2 switch off
// 3 switch on
// Special values for Input
// 253: set help flags - Value can be any combination of
// PIF_AUTOGEARS // 8 - auto shift
// PIF_HELP_B // 64 - brake help
// PIF_AUTOCLUTCH // 512 - auto clutch
// Default value for an AI driver is PIF_AUTOCLUTCH only
// If you set PIF_AUTOGEARS you don't need to set PIF_AUTOCLUTCH
// 254: reset all inputs
// Most inputs are zero / CS_MSX is 32768 / CS_GEAR is 255
// 255: stop control
// The AI driver will stop the car
// AI car info
// -----------
// Send a SMALL_AII with UVal set to PLID to receive current information about a local car
struct OSMain // included in IS_AII - identical to OutSimMain (main data in OutSim packet)
{
Vector AngVel; // 3 floats, angular velocity vector
float Heading; // anticlockwise from above (Z)
float Pitch; // anticlockwise from right (X)
float Roll; // anticlockwise from front (Y)
Vector Accel; // 3 floats X, Y, Z
Vector Vel; // 3 floats X, Y, Z
Vec Pos; // 3 ints X, Y, Z (1m = 65536)
};
struct IS_AII // AI Info
{
byte Size; // 96
byte Type; // ISP_AII
byte ReqI; // ReqI from the SMALL_AII request packet
byte PLID;
OSMain OSData;
byte Flags; // AIFLAGS_x below
byte Gear; // Reverse:0, Neutral:1, First:2...
byte Sp2;
byte Sp3;
float RPM; // RPM
float SpF0;
float SpF1;
unsigned ShowLights; // Dash lights currently switched on (see DL_x in OutGauge section below)
unsigned SPU1;
unsigned SPU2;
unsigned SPU3;
};
#define AIFLAGS_IGNITION 1 // detect if engine running
//
#define AIFLAGS_CHUP 4 // upshift lever currently held
#define AIFLAGS_CHDN 8 // downshift lever currently held
Download:
[ link removed - new update available ]
Last edited by Scawen, .
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.
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.
I request that people who can't understand the benefit of this system should avoid posting here.
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, .
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
Input = 0 : CS_MSX (steer)
Time = 0 : stay on
Value = 0 : full left
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.
That is true.
Checked again and steering does work in F3.
In my test program I have:
Full left lock would be the result of sending zero in the Value field.
In my test program I have:
case 'J':
SendCarPack(car_plid, CS_MSX, 32768 - 2000);
break;
case 'K':
SendCarPack(car_plid, CS_MSX, 32768);
break;
case 'L':
SendCarPack(car_plid, CS_MSX, 32768 + 2000);
break;
Full left lock would be the result of sending zero in the Value field.
Total speculation and in fact complete rubbish.
People are free to suggest what they want and I will choose what I do and how to manage my time.
If other people will be deciding what I do I might as well go and get a job as a programmer and earn 5 times the salary.
I'd be grateful if community members wouldn't try to be self appointed LFS project managers.
I did one afternoon's work and a morning fixing it, on something that people have been waiting for, for longer than people have been waiting for tyre physics. This had no bearing at all on the completion of the tyre physics. Please avoid making up rubbish and allow people to make sensible suggestions if they wish to.
This is the LFS Programmer Forum.
In most cases it is probably best to not comment if you aren't a programmer. Otherwise I would have posted in General LFS Discussion or Test Patch forum.
I don't go and post my opinions in the quantum physics forums because I probably don't know what the **** I am talking about.
In most cases it is probably best to not comment if you aren't a programmer. Otherwise I would have posted in General LFS Discussion or Test Patch forum.
I don't go and post my opinions in the quantum physics forums because I probably don't know what the **** I am talking about.
EDIT: There is a new update below: https://www.lfs.net/forum/post/2114810#post2114810
Here is the update with fixes and improvements for the new system.
I can't get into ray checks as it's not simple enough for this very quick update.
NOTE: If you wrote some code for F2, a small change is required in your AIC packet that has been updated to accept multiple inputs.
Changes from F2 to F3:
InSim:
IS_AIC can now accept multiple input values in a single packet
- a small change must be made if you used IS_AIC from version F2
IS_AIC inputs can now be given a time in hundredths of a second
- after time elapsed the input returns to default value
- this is probably most useful for shift up/down and flash/horn
FIX: Error messages for AIC and AII packets reported as IS_PLH errors
AI:
AI can now spawn in a config with an AI path even if knw has not been generated
FIX: AI now spawn in game with full fuel load if there is no path (or no knw)
FIX: Rare crash in AI code after another car spawned outside path
Here are the updates as seen in docs\InSim.txt
Download: [ link removed, new update available ]
Here is the update with fixes and improvements for the new system.
I can't get into ray checks as it's not simple enough for this very quick update.
NOTE: If you wrote some code for F2, a small change is required in your AIC packet that has been updated to accept multiple inputs.
Changes from F2 to F3:
InSim:
IS_AIC can now accept multiple input values in a single packet
- a small change must be made if you used IS_AIC from version F2
IS_AIC inputs can now be given a time in hundredths of a second
- after time elapsed the input returns to default value
- this is probably most useful for shift up/down and flash/horn
FIX: Error messages for AIC and AII packets reported as IS_PLH errors
AI:
AI can now spawn in a config with an AI path even if knw has not been generated
FIX: AI now spawn in game with full fuel load if there is no path (or no knw)
FIX: Rare crash in AI code after another car spawned outside path
Here are the updates as seen in docs\InSim.txt
// AI CONTROL
// ==========
struct AIInputVal
{
byte Input; // Select input value to set
byte Time; // Time to hold (optional, hundredths of a second)
word Value; // Value to set
};
const int AIC_MAX_INPUTS = 20; // NOTE: Increase if CS_NUM is increased
struct IS_AIC // AI Control - variable size
{
byte Size; // 4 + 4 * (number of inputs)
byte Type; // ISP_AIC
byte ReqI; // 0
byte PLID; // Unique ID of AI driver to control
AIInputVal Inputs [AIC_MAX_INPUTS];
};
// If the Time value is set, that input will return to default after that amount of time.
// This is expected to be most useful for CS_CHUP / CS_CHDN / CS_FLASH / CS_HORN inputs.
// If you don't use Time then you must send another packet to zero the input.
// 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
// AI car info
// -----------
// Send a SMALL_AII with UVal set to PLID to receive current information about a local car
struct OSMain // included in IS_AII - identical to OutSimMain (main data in OutSim packet)
{
Vector AngVel; // 3 floats, angular velocity vector
float Heading; // anticlockwise from above (Z)
float Pitch; // anticlockwise from right (X)
float Roll; // anticlockwise from front (Y)
Vector Accel; // 3 floats X, Y, Z
Vector Vel; // 3 floats X, Y, Z
Vec Pos; // 3 ints X, Y, Z (1m = 65536)
};
struct IS_AII // AI Info
{
byte Size; // 96
byte Type; // ISP_AII
byte ReqI; // ReqI from the SMALL_AII request packet
byte PLID;
OSMain OSData;
byte Flags; // AIFLAGS_x below
byte Gear; // Reverse:0, Neutral:1, First:2...
byte Sp2;
byte Sp3;
float RPM; // RPM
float SpF0;
float SpF1;
unsigned ShowLights; // Dash lights currently switched on (see DL_x in OutGauge section below)
unsigned SPU1;
unsigned SPU2;
unsigned SPU3;
};
#define AIFLAGS_IGNITION 1 // detect if engine running
//
#define AIFLAGS_CHUP 4 // upshift lever currently held
#define AIFLAGS_CHDN 8 // downshift lever currently held
Download: [ link removed, new update available ]
Last edited by Scawen, .
Reason : fix typo
No, it's not necessary.
But before once again rejecting the mod that was designed to allow some amount of fun, in this case I was able to spend a few hours doing something that allows a huge amount of possibilities. Then rejecting the mod, I'm not just being the nasty developer again.
I believe you are wrong about the calendar and league stuff. A lot of people were interested, especially in the calendar and it lead directly to the league stuff.
After discovering all the bugs and unfinished work in the league stuff, which I encountered while looking at the calendar which was so ugly before, it was near impossible for me to leave the league pages in that state. Victor had basically started a few things there but they were not finished and there were bugs, although basically he has written a good system. Unfortunately for us, he didn't take the time to work through the issues before he got fed up working on LFS. So I'm still left picking up the pieces when I find them.
It's actually a good thing, that I don't like leaving rubbish unfinished code lying around. That's how I work and I believe it leads to good things.
It's pointless to be worried about me delaying some extremely difficult head scratching work that I have been working on this week, to do something that the programmers here can do some super things with.
The tyre stuff is so extremely difficult, requiring a lot of experimentation and even disturbed sleep in the night, trying to think of the next way to attempt to fix the issue I'm trying to deal with. It's not the kind of thing I can just sit there and do it. It required pushes and recovery. I don't really expect people to understand. But after a strong push on Monday to Wednesday it is good for me mentally do to do some rapid coding that can increase the possibilities of LFS. It was 'one day' but there are always a few things to fix. Again, I believe that is a good thing. If I actually knew how long anything would take, I wouldn't even start it.
So I hope some people are very happy now that I have taken the time to explain why I make decisions. It would actually save me time if I could be allowed to do my job without having to explain every step I take. Maybe just watch and see why I do things, then you wouldn't be so confused.
But before once again rejecting the mod that was designed to allow some amount of fun, in this case I was able to spend a few hours doing something that allows a huge amount of possibilities. Then rejecting the mod, I'm not just being the nasty developer again.
I believe you are wrong about the calendar and league stuff. A lot of people were interested, especially in the calendar and it lead directly to the league stuff.
After discovering all the bugs and unfinished work in the league stuff, which I encountered while looking at the calendar which was so ugly before, it was near impossible for me to leave the league pages in that state. Victor had basically started a few things there but they were not finished and there were bugs, although basically he has written a good system. Unfortunately for us, he didn't take the time to work through the issues before he got fed up working on LFS. So I'm still left picking up the pieces when I find them.
It's actually a good thing, that I don't like leaving rubbish unfinished code lying around. That's how I work and I believe it leads to good things.
It's pointless to be worried about me delaying some extremely difficult head scratching work that I have been working on this week, to do something that the programmers here can do some super things with.
The tyre stuff is so extremely difficult, requiring a lot of experimentation and even disturbed sleep in the night, trying to think of the next way to attempt to fix the issue I'm trying to deal with. It's not the kind of thing I can just sit there and do it. It required pushes and recovery. I don't really expect people to understand. But after a strong push on Monday to Wednesday it is good for me mentally do to do some rapid coding that can increase the possibilities of LFS. It was 'one day' but there are always a few things to fix. Again, I believe that is a good thing. If I actually knew how long anything would take, I wouldn't even start it.
So I hope some people are very happy now that I have taken the time to explain why I make decisions. It would actually save me time if I could be allowed to do my job without having to explain every step I take. Maybe just watch and see why I do things, then you wouldn't be so confused.
This appears to be an existing bug, since the AI driving improvements some time ago. It is possible for the crash to appear in the ordinary AI code, if another car has spawned outside the path (so does not have a valid path node). Does that sound a reasonable explanation? I've fixed it but everyone on F will still have the bug. So better not spawn outside the path if ordinary AI are driving around on the track.
Multiple values per packet are done, I plan to add a "Hold time" which could be useful for shift up/down and horn/flash so you can send and forget.
struct AIInputVal
{
byte Input; // Select input value to set
byte Time; // Time to hold (optional)
word Value; // Value to set
};
const int AIC_MAX_INPUTS = 20; // NOTE: Increase if CS_NUM is increased
struct IS_AIC // AI Control - variable size
{
byte Size; // 4 + 4 * (number of inputs)
byte Type; // ISP_AIC
byte ReqI; // 0
byte PLID; // Unique ID of AI driver to control
AIInputVal Inputs [AIC_MAX_INPUTS];
};
254 doesn't switch lights, as zero for those inputs means no change, and they are auto-set to zero after use anyway. I think it is really for all the axes and shift levers, you would have to send a non-zero value to switch off lights.
Thanks for the feedback and bug reports. I've done most of them and will release an update today.
My test seems fine.
- set steering : ok
- set throttle : ok
- send a 254 : steering returns to centre / throttle returns to zero
I might change it to allow multiple values to be set at once in a variable sized IS_AIC (probably would change the zero byte to PLID and then allow multiple 4-byte blocks of "byte Spare/byte Input/word Value"
Yes, I do this all the time when testing at layout square. You set CS_IGNITION to 1
My test seems fine.
- set steering : ok
- set throttle : ok
- send a 254 : steering returns to centre / throttle returns to zero
I might change it to allow multiple values to be set at once in a variable sized IS_AIC (probably would change the zero byte to PLID and then allow multiple 4-byte blocks of "byte Spare/byte Input/word Value"
Yes, I do this all the time when testing at layout square.
You set CS_IGNITION to 1FGED GREDG RDFGDR GSFDG