The online racing simulator
Is there a way to engage starter motor in case gas engine stops? If not, Input 253 -> engage starter motor?
Thanks for the feedback and bug reports. I've done most of them and will release an update today.

Quote from Bokujishin :Input 254 does not seem to do anything right now, all controls stay in their...

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"

Quote from MizzMaster :Is there a way to engage starter motor in case gas engine stops? If not, Input...

Yes, I do this all the time when testing at layout square. Smile You set CS_IGNITION to 1
Multiple values per packet would be nice indeed, otherwise we may end up sending 10 packets or more every time we want to update (which might be every hundredth for more dynamic driving). And if multiple AIs are to be controlled, sending a single packet per car would help.

I take it 254 is not supposed to affect lights, only steering and throttle?
Quote from Flame CZE :Several people experienced a crash of their LFS when being on a multiplayer server where I was testing the AI packets.

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.

Quote from Bokujishin :Multiple values per packet would be nice indeed, otherwise we may end up sending 10 packets or more every time we want to update (which might be every hundredth for more dynamic driving). And if multiple AIs are to be controlled, sending a single packet per car would help.

I take it 254 is not supposed to affect lights, only steering and throttle?

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.
I just noticed that while ShowLights is supposed to follow OutGauge's DL_x enumeration, the extra light is missing from there, so unless I'm missing it elsewhere, we can't get this light's status from ISP_AII.

Quick question about the hold time for AIInputVal: what is supposed to happen if we issue a new command before the hold time expires? Is the command overridden entirely, or is the hold time supposed to release anyway? (for instance if we turn a fog light on for 10 seconds, but 5 seconds later we turn it on again for another 10 seconds, will it turn off after the remaining 5 seconds or stay on for the 15 seconds in total?)
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

// 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 ]
I understand the 2 points of view, between the impatience of the update with all that it brings new even without tires and on the other hand as a developer the need to correct when you come across crappy code, that you see something easy to implement (even if it always ends up taking longer than initially planned), etc..

In the meantime, I'll let you watch some beautiful ballets @Viperakecske...

@Scawen, works well for me so far after implementation in pyinsim, I'm still testing.
Quote from KingOfIce :I understand the 2 points of view, between the impatience of the update with all...

Bro thats so funny to see Big grin my experience with it
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.
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:

https://www.lfs.net/file_lfs.php?name=LFS_PATCH_7F_TO_7F4.zip
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. https://www.youtube.com/watch?v=jrgYdkmHdI4
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.

Other than that, AI flags work properly, I can disable autoclutch, and toggleable lights work fine too.

Edit: Actually it's a bit more complicated than that: if I send a 255, I can then have the AI downshift once more (but not upshift). When the AI stops and turns the engine off, I can here the wind blowing temporarily as it goes out of "sleep mode" whenever I give it its input again, but it keeps flashing and refusing to shift up.
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.
Thank you scawen for adding the auto clutch thing, as i promised ill be buying another account later Big grin
Thanks for the thanks but you don't need to buy an account just to thank me. Big grin
Quote from Scawen :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 and it's doing what you are telling it to do.

My bad, you're right and I was just misusing the time parameter, the documentation is fine as it did mention a short time was needed.

No more issues or further comments on my end then Big grin
Quote from Scawen :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!

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 of yours to check it up.

I did my investigation, checked my cruise mod and it works as intended, but still it has that problem but it was not visible till now. My framework have global packet listener and local packet listener, and i can bind any entity (like vehicle) to local packet handler, and after spectating that bind function removed wrong local packet handler and there is issue where problems occurs, i lost handler after spectating and made some sort of memory leak. Thanks. We learn from mistakes.
Quote from Scawen :Thanks for the thanks but you don't need to buy an account just to thank me. Big grin

I would still like to support you, so, take it, ill buy it later
Suggestions will be:
- let select a car for ai with /ai.
- add direction to IS_AII like CompCar struct has.
- add possibility to send multiple PLID with IS_SMALL to request IS_AII packet.

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

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.

Appreciate your work take your time. Thanks.
2

Simple control of AI car
(44 posts, started )
FGED GREDG RDFGDR GSFDG