1
2I told you that with that .dll the InSim program won't crash BUT all the LFS_External bugs are still there. In the specific case, you are facing the problem that when a string is too long External isn't able to display it.
What did you do? Replaced the reference and recompiled the project, or just replaced the .dll and tried to start the .exe? 'Cause the right thing is the first of the two.
Request an IS_ISM packet, which contains HName. (All details in InSim.txt doc)
With "Retrieve the Username of the player..." I meant the following: everytime a player joins the track or leaves the pits he gets a PlayerID number. You have to keep track of which number is assigned to which player. So then from a PlayerID number you can find who is the corresponding player that has that PlayerID, and finally you can pitlane him.
In your case those info are stored in the Connections List. So you have to do something like this:
// Retrieve the Username of the player...
foreach (clsConnnection Conn in Connections)
{
if (Conn.PlayerID == MCI.Info[n].PLID)
{
insim.Send("/pitlane " + Conn.Username);
}
}
Last edited by Comomillo, .
InSim insim = new InSim();
// Bind Received Packets to your methods.
// <IS_XXX> is the name of the packet, (XXX_Handler) is the method that is executed everytime a IS_XXX packet is received.
insim.Bind<IS_MCI>(MCI_Handler);
// Connect InSim (read about IS_ISI in InSim.txt doc for more info)
insim.Initialize(new InSimSettings {Host = "127.0.0.1", Port = 29999, IName = "InSimName", Flags = InSimFlags.ISF_MCI, Interval = 500});// Method that is executed everytime a MCI packet is received.
// (Read InSim.txt doc to understand what is contained inside InSim Packets and hence how to handle them).
void MCI_Handler(InSim insim_var, IS_MCI MCI)
{
for (int n = 0; n < MCI.NumC; n++)
{
if (MCI.Info[n].Node == 53)
{
// Retrieve the Username of the player which has "MCI.Info[n].PLID" as current PlayerID...
// Pitlane him...
insim.Send("/pitlane " + Username);
}
}
}The issue is mainly caused by the incompatibility of the outdated LFS_External library with the newer LFS versions. As "instant workaround" you can replace that LFS_External.dll library with the one I've attached and then re-build the InSim app.
But as suggested by everyone, the real solution is moving to InSimDotNet library. Once you have understood how it works, I can tell you that it is even easier than LFS_External; the only boring part is to fix the slightly different sintax of all this InSim app.
But the advantage is that you will be able to correctly use all the InSim packets (in the attached library I've simply disabled the ones that were causing the crashes. All the known LFS_External bugs are still there).
(PS: To be honest, the attached library was working fine with 0.6H version, then I switched to InSimDotNet.)
1. Press T (to open text input window)
2. Press UP Key till you see the message you want to copy
3. Press CTRL+C to copy the message
Does this work?
2. Press UP Key till you see the message you want to copy
3. Press CTRL+C to copy the message
Does this work?
Racon's approach is better 
Apaz123, it's just a matter of common sense: it's unrealistic that an user with zero kilometers driven online is interested in InSim programming.
No. I've read all the entire posts and my comment was indeed linked to Popughini's post just before mine.
I understand and agree with your points guys, but IMO a total block of demo users wouldn't be good. There are some of them who are fair and keep alive demo servers.
Uh, well what to say... Sorry. I had just given a glance to his registration date next to his avatar and (also considering that I got the same question also from other players) I thought that it was ok to answer here, so that everyone might have got help 
Hello,
From the code point of view, just be careful to don't truncate the computations especially during divisions by integers.
I try to explain how distance computation is working in your code:
Each X milliseconds (the MCI Intervals) you receive a Speed value. Then you multiply this speed for the X milliseconds, and you get the travelled distance.
The problems is that lots of simplifications are taken into account while doing that:
1. You are supposing that the Speed is constant in the whole X milliseconds (This can be considered almost true as long as the specified MCI Inteval is small enough).
2. By using the Speed value as soon as you receive it, you are over-estimating the travelled distance during acceleration transients, and under-estimating it during deceleration transients.
3. In the opposite way round, if you use the Speed value received in the previous MCI Packet (at time "t-X") to compute the travelled distance at time "t", you are under-estimating accelerations and over-estimating decelerations.
These are the main reasons why your computed distance can be so different from the real one.
Long story short: no divisions by integers + small MCI Interval time (I would say below 200ms should be fine), should already give you a good approximation of the real travelled distance.
If you want even more performances, I think you should decrease even more the MCI Interval, and using the average value of the Speeds between time "t" and time "t-X" to compute the travelled distance at time t.
EDIT:
Ah, of course check that:
- when you multiply the Speed by the X milliseconds, the X value must correspond to what you set in MCI Interval.
- you are using the right unity of measurements.
Otherwise of course the results are wrong.
From the code point of view, just be careful to don't truncate the computations especially during divisions by integers.
I try to explain how distance computation is working in your code:
Each X milliseconds (the MCI Intervals) you receive a Speed value. Then you multiply this speed for the X milliseconds, and you get the travelled distance.
The problems is that lots of simplifications are taken into account while doing that:
1. You are supposing that the Speed is constant in the whole X milliseconds (This can be considered almost true as long as the specified MCI Inteval is small enough).
2. By using the Speed value as soon as you receive it, you are over-estimating the travelled distance during acceleration transients, and under-estimating it during deceleration transients.
3. In the opposite way round, if you use the Speed value received in the previous MCI Packet (at time "t-X") to compute the travelled distance at time "t", you are under-estimating accelerations and over-estimating decelerations.
These are the main reasons why your computed distance can be so different from the real one.
Long story short: no divisions by integers + small MCI Interval time (I would say below 200ms should be fine), should already give you a good approximation of the real travelled distance.
If you want even more performances, I think you should decrease even more the MCI Interval, and using the average value of the Speeds between time "t" and time "t-X" to compute the travelled distance at time t.
EDIT:
Ah, of course check that:
- when you multiply the Speed by the X milliseconds, the X value must correspond to what you set in MCI Interval.
- you are using the right unity of measurements.
Otherwise of course the results are wrong.
Last edited by Comomillo, .
When you click on a button, LFS sends a packet to your InSim app. In order to catch this packet you have to bind it:
InSim.Bind<IS_BTC>(BTC_Handler); // It's for "standard" clickable buttons.
InSim.Bind<IS_BTT>(BTT_Handler); // It's for the clickable buttons that popup a window where you can write text.
BTC_Handler and BTT_Handler are the methods (that you have to add in your code) that execute what is inside them each time the clickable button is clicked.
Each button that you create has an ID, and the same ID is also reported back in the IS_BTC,IS_BTT packets with other infos too (for example the UCID of the player who clicked the button), so you can handle them using those infos.
InSim.Bind<IS_BTC>(BTC_Handler); // It's for "standard" clickable buttons.
InSim.Bind<IS_BTT>(BTT_Handler); // It's for the clickable buttons that popup a window where you can write text.
BTC_Handler and BTT_Handler are the methods (that you have to add in your code) that execute what is inside them each time the clickable button is clicked.
Each button that you create has an ID, and the same ID is also reported back in the IS_BTC,IS_BTT packets with other infos too (for example the UCID of the player who clicked the button), so you can handle them using those infos.
Hmm, these could be two possible solutions (most probably not the best ones, but this is what came in my mind):
1. Basically as inputs you have: the string that the user wrote (!pm "bla blabla bla"), and the list of the Usernames of the players in the server.
At the moment your code is splitting the "bla blabla bla" string and then comparing the first word (in our case "bla") with all the Usernames. Of course it fails if the complete username to search was "bla blabla", for example.
So, you could temporarily split also all the Usernames of the list, and then check for each Username in the list wich is the one that matches the highest number of strings contained in the !pm message.
Example to make things clearer:
Usernames in the list: Conn[0].Username="Hello", Conn[1].Username="Hello Hey", Conn[2].Username="Bye".
!pm Message="Hello Hey How are you?"
The code splits the Usernames of the list:
Conn[0].TempUser[] = Conn[0].Username.Split(' ');
Conn[1].TempUser[] = Conn[1].Username.Split(' ');
Conn[2].TempUser[] = Conn[2].Username.Split(' ');
And the !pm Message as well:
Msg[] = Message.Split(' ');
Now for each User let's check how many matches we have:
Conn[0].TempUser[0] == Msg[0] ---> 1 Match
Conn[1].TempUser[0] == Msg[0] ---> 1 Match
Conn[1].TempUser[1] == Msg[1] ---> 2 Match
Conn[2].TempUser[0] == Msg[0] ---> 0 Match
So the one who should receive the pm would be the 2nd one (Conn[1]).
In case of zero matches for all players, you can write "User not found".
2. Change the way in which the !pm command works:
- Create a new command (for example !upm <username>) which takes and stores the username of the player you want to send messages to. In this way you know for sure that the username is the whole string after !upm characters, so usernames with spaces won't create problems.
- Then, you can send whatever you want to that player just by sending a !pm <message> command.
1. Basically as inputs you have: the string that the user wrote (!pm "bla blabla bla"), and the list of the Usernames of the players in the server.
At the moment your code is splitting the "bla blabla bla" string and then comparing the first word (in our case "bla") with all the Usernames. Of course it fails if the complete username to search was "bla blabla", for example.
So, you could temporarily split also all the Usernames of the list, and then check for each Username in the list wich is the one that matches the highest number of strings contained in the !pm message.
Example to make things clearer:
Usernames in the list: Conn[0].Username="Hello", Conn[1].Username="Hello Hey", Conn[2].Username="Bye".
!pm Message="Hello Hey How are you?"
The code splits the Usernames of the list:
Conn[0].TempUser[] = Conn[0].Username.Split(' ');
Conn[1].TempUser[] = Conn[1].Username.Split(' ');
Conn[2].TempUser[] = Conn[2].Username.Split(' ');
And the !pm Message as well:
Msg[] = Message.Split(' ');
Now for each User let's check how many matches we have:
Conn[0].TempUser[0] == Msg[0] ---> 1 Match
Conn[1].TempUser[0] == Msg[0] ---> 1 Match
Conn[1].TempUser[1] == Msg[1] ---> 2 Match
Conn[2].TempUser[0] == Msg[0] ---> 0 Match
So the one who should receive the pm would be the 2nd one (Conn[1]).
In case of zero matches for all players, you can write "User not found".
2. Change the way in which the !pm command works:
- Create a new command (for example !upm <username>) which takes and stores the username of the player you want to send messages to. In this way you know for sure that the username is the whole string after !upm characters, so usernames with spaces won't create problems.
- Then, you can send whatever you want to that player just by sending a !pm <message> command.
Last edited by Comomillo, .
I tested. Otherwise I wouldnt have written it xD
Anyway it may work in a different way from what you could expect:
It sets the values on your car only if you were using lower ones. Otherwise no changes are made to your car.
Anyway it may work in a different way from what you could expect:
It sets the values on your car only if you were using lower ones. Otherwise no changes are made to your car.
Not sure if this can be your case, but you could add mass and/or restrict the intake for a car, in real time, sending a IS_HCP packet through InSim.
There are the following constraints, though:
- the InSim app must be connected with admin pass
- the changes affect all the drivers using that car
There are the following constraints, though:
- the InSim app must be connected with admin pass
- the changes affect all the drivers using that car
// HANDICAPS
// =========
// You can send a packet to add mass and restrict the intake on each car model
// The same restriction applies to all drivers using a particular car model
// This can be useful for creating multi class hosts
struct CarHCP // Car handicaps in 2 bytes - there is an array of these in the HCP (below)
{
byte H_Mass; // 0 to 200 - added mass (kg)
byte H_TRes; // 0 to 50 - intake restriction
};
struct IS_HCP // HandiCaPs
{
byte Size; // 68
byte Type; // ISP_HCP
byte ReqI; // 0
byte Zero;
CarHCP Info[32]; // H_Mass and H_TRes for each car : XF GTI = 0 / XR GT = 1 etc
};
In addition, the main issue is that LFS_External is not more compatible with new (or modified) InSim packets added over the years, so expect crashes at any time.
Probably because you are sending multiple is_small packets at the same time. Send only one containing the whole configuration.
Anyway, I see DarkTimes is adding this stuff in his library
Anyway, I see DarkTimes is adding this stuff in his library
Yea. "bit 0" means that you have to set at 1 the bit at position zero, though.
I suggest also to define constants in your project, like this:
const long FastSiren = 1048592;
const long Hazard = 769;
So then you can use names instead of numbers for UVal:
UVal = FastSiren + Hazard, for example
And you understand better what your code actually does
I suggest also to define constants in your project, like this:
const long FastSiren = 1048592;
const long Hazard = 769;
So then you can use names instead of numbers for UVal:
UVal = FastSiren + Hazard, for example
And you understand better what your code actually does
Just taking the binary numbers from InSim.txt and converting them in decimal ones.
For example, Let's say we want to turn on "fast siren":
#define LCS_SET_SIREN 0x10 //bit 4
- "bit 4" means that we have to set the 4th bit at 1, to enable siren control.
- Bin Number: "10000" -----> Decimal Number: "16".
- (bits are counted from right to left, starting from zero)
// bits 20-21 (Switches & 0x300000) - Siren (0 off / 1 fast / 2 slow)
- "bits 20-21" means that we must create a bin number with 2 digits.
- "1 fast" means that we have to create the bin number 1, that is: "01".
- Now lets create the complete bin number (because these 2 bits didnt start from zero position, but from 20th slot): "0100000000000000000000" -----> Decimal: "1048576".
Then let's sum: 16 + 1048576 = 1048592.
For example, Let's say we want to turn on "fast siren":
#define LCS_SET_SIREN 0x10 //bit 4
- "bit 4" means that we have to set the 4th bit at 1, to enable siren control.
- Bin Number: "10000" -----> Decimal Number: "16".
- (bits are counted from right to left, starting from zero)
// bits 20-21 (Switches & 0x300000) - Siren (0 off / 1 fast / 2 slow)
- "bits 20-21" means that we must create a bin number with 2 digits.
- "1 fast" means that we have to create the bin number 1, that is: "01".
- Now lets create the complete bin number (because these 2 bits didnt start from zero position, but from 20th slot): "0100000000000000000000" -----> Decimal: "1048576".
Then let's sum: 16 + 1048576 = 1048592.
Hello, all info needed are inside InSim.txt file in docs folder
Send this packet to control lights/horn/siren:
UVal is the number that detects the configuration. It is the SUM of everything that you want to edit.
SIGNALS:
+1 (turn signals off), +257 (turn left indicator on), +513 (turn right indicator on), +769 (hazard on)
FLASH:
+2 (turn flash off), +1026 (turn flash on)
HEADLIGHTS:
+4 (turn headlights off), +2052 (turn headlights on)
HORN:
+8 (turn horn off), +65544 (turn horn1 on), +131080 (turn horn2 on), +196616 (turn horn3 on), +262152 (turn horn4 on), +327688 (turn horn5 on)
SIREN:
+16 (turn siren off), +1048592 (turn FastSiren on), +2097168 (turn SlowSiren on)
Send this packet to control lights/horn/siren:
insim.Send(new IS_SMALL {ReqI = 0, SubT = (InSimDotNet.Packets.SmallType)9, UVal = 0});UVal is the number that detects the configuration. It is the SUM of everything that you want to edit.
SIGNALS:
+1 (turn signals off), +257 (turn left indicator on), +513 (turn right indicator on), +769 (hazard on)
FLASH:
+2 (turn flash off), +1026 (turn flash on)
HEADLIGHTS:
+4 (turn headlights off), +2052 (turn headlights on)
HORN:
+8 (turn horn off), +65544 (turn horn1 on), +131080 (turn horn2 on), +196616 (turn horn3 on), +262152 (turn horn4 on), +327688 (turn horn5 on)
SIREN:
+16 (turn siren off), +1048592 (turn FastSiren on), +2097168 (turn SlowSiren on)
I faced the same issue. As workaround I composed the packet manually and then I sent it:
var Packet = new IS_JRR();
Packet.StartPos.X = 0;
Packet.StartPos.Y = 0;
Packet.StartPos.Zbyte = 255;
Packet.StartPos.Heading = 0;
Packet.StartPos.Index = 0;
Packet.StartPos.Flags = 0x80;
Packet.PLID = car.PLID;
Packet.JRRAction = JrrAction.JRR_RESET_NO_REPAIR;
insim.Send(Packet);
I don't know if it is the best way to do it, tho.
var Packet = new IS_JRR();
Packet.StartPos.X = 0;
Packet.StartPos.Y = 0;
Packet.StartPos.Zbyte = 255;
Packet.StartPos.Heading = 0;
Packet.StartPos.Index = 0;
Packet.StartPos.Flags = 0x80;
Packet.PLID = car.PLID;
Packet.JRRAction = JrrAction.JRR_RESET_NO_REPAIR;
insim.Send(Packet);
I don't know if it is the best way to do it, tho.
Last edited by Comomillo, .
1
2FGED GREDG RDFGDR GSFDG