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.
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 1Multiple 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?
I take it 254 is not supposed to affect lights, only steering and throttle?
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.
Is this all necessary?
Couldn't you have waited until the "retro" version is ready? don't take it as an insult or hurt, I just don't see the point in putting this before the big update, same thing with the calendar, it just happened out of nowhere and dont think people actually asked for it or took interest in it though you have done a good job.
PS: Am i able to join leagues through calendar during my ban period? joking
Couldn't you have waited until the "retro" version is ready? don't take it as an insult or hurt, I just don't see the point in putting this before the big update, same thing with the calendar, it just happened out of nowhere and dont think people actually asked for it or took interest in it though you have done a good job.
PS: Am i able to join leagues through calendar during my ban period? joking
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.
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?)
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?)
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: https://www.lfs.net/file_lfs.php?name=LFS_PATCH_7F_TO_7F3.zip
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: https://www.lfs.net/file_lfs.php?name=LFS_PATCH_7F_TO_7F3.zip
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.
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.
Im not interested in ballet
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.
To answer my own question, toggle lights don't seem to be affected by the hold time, which works only for axis inputs, horn, flash, look left/right and I assume gear up/down.
Also for some reason, I'm only getting full left steering, whatever the value (1000, 32000, 55000, all result in full left lock).
Also for some reason, I'm only getting full left steering, whatever the value (1000, 32000, 55000, all result in full left lock).
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.
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.
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.
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.
Bro thats so funny to see
my experience with itNo 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.
The issue was much simpler than that actually: I was forcing the packet to its maximum size, no matter the actual inputs, that probably messed up things. Steering does work now, sorry about that. (still not sure why just steering was broken, even when moving it around the buffer, but not really important now)
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
1
2
Simple control of AI car
(43 posts, started )
FGED GREDG RDFGDR GSFDG