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 1EDIT: A new update is available below: https://www.lfs.net/forum/post/2114731#post2114731
OK, here is the test patch. The only new thing is AI control and data reporting through InSim.
docs/InSim.txt is included with this new section:
Download: [ download removed - F3 is now available ]
OK, here is the test patch. The only new thing is AI control and data reporting through InSim.
docs/InSim.txt is included with this new section:
// 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
// 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: [ download removed - F3 is now available ]
Last edited by Scawen, .
I've replaced that CompCar part with OutSimMain as it's more informative and relevant. I think you need MCI for general awareness.
I don't really want to get into setting intervals for AII packets and you can just request them with a SMALL_AII for now.
I think my testing is done, I can control a car through AIC, even if I haven't tested every possible thing. I seem to be getting info out from AII OK, even if I haven't checked ever single value.
So I'll prepare a simple patch zip.
I don't really want to get into setting intervals for AII packets and you can just request them with a SMALL_AII for now.
I think my testing is done, I can control a car through AIC, even if I haven't tested every possible thing. I seem to be getting info out from AII OK, even if I haven't checked ever single value.
So I'll prepare a simple patch zip.
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, .
FGED GREDG RDFGDR GSFDG