You are pretending that sending the command "!engage" by a cop then a chase starts, don't you? In that case YOU must decide how you are going to decide who to chase.
There are some possibilities. One is "!engage user_name", thinking that you have in some kind of structured the players mapped, so you correlate the username to its UCID.
Another possibility is to check how far are all drivers respect to the cop that typed "!engage", and select the closest one. I haven't worked with MCI and NLP packets yet, but you have the exact coordenates of each car by requesting IS_MCI packets sending a request via an IS_TINY. Then you compare the coordinates of all cars with the one that typed "!engage" and select the PLID of the one that is closest, and from then you get the matching UCID.
There's high probability that you are already receiving IS_MCI packets on a fixed interval, so there'd be no need to use an IS_TINY to request.
How do you like this solution? It might look complex, but it lets you assign "!engage" to one function key so you don't have to care about who you are going to chase. You just have to make sure that the closest car to yous is the one you want to chase
PS: I'm not into cruising servers and I'm not a good InSim programmer myself yet, so it'd be good if someone who has already done these things could help you too.
There are some possibilities. One is "!engage user_name", thinking that you have in some kind of structured the players mapped, so you correlate the username to its UCID.
Another possibility is to check how far are all drivers respect to the cop that typed "!engage", and select the closest one. I haven't worked with MCI and NLP packets yet, but you have the exact coordenates of each car by requesting IS_MCI packets sending a request via an IS_TINY. Then you compare the coordinates of all cars with the one that typed "!engage" and select the PLID of the one that is closest, and from then you get the matching UCID.
There's high probability that you are already receiving IS_MCI packets on a fixed interval, so there'd be no need to use an IS_TINY to request.
How do you like this solution? It might look complex, but it lets you assign "!engage" to one function key so you don't have to care about who you are going to chase. You just have to make sure that the closest car to yous is the one you want to chase
PS: I'm not into cruising servers and I'm not a good InSim programmer myself yet, so it'd be good if someone who has already done these things could help you too.
Do you play any other 3D-graphics game? If not, it could be the graphics card causing an overheat. This happenned to me when I had to switch to al older graphics card for a couple of weeks when the one I had died. The older card generated a lot more heat and after a while playing LFS the system would reboot.
The button shouldn't be shown to everyone, but just the guy that is being chased. If no one is chasing me I don't have to have a text telling me "police, pull over".
You must know the UCID of the driver that is being chased to send the button only to that specific driver. The way to know this UCID depends on how you trigger the persecution.
Another tip. If you want the text to appear in the center of the screen then don't use ISB_LEFT. Don't use neither left or tright alignment, and the text will be centered within the button. Then you just have to make the appropiate maths. Max width is 200, so left-place the button at "(200 - button_width) / 2"
A little more help/tips on this topic This is only helpful if you haven't worked with manipulating button aspect properties before:
This is the structure of button packets:
Take a look at filed "BStyle". If you don't set it to any of ISB_DARK or ISB_LIGHT then the button will be transparent, so only the text will show.
You can have coloured text in two ways. One is using LFS colour tags wihtin the text. For example: "^1POLICE! STOP". If you want to have that message in red.
The other one is using BStyle field. For red you would use ISB_C1 + ISB_C4.
The difference is that default button colors defined with BStyle field are darker/lighter than the ones you get using color tags. The red color tag would give a very bright red, while BStyle defined red is darker red, tending to brown. Something like this:
Color tag: POLICE! STOP
BStyle: POLICE! STOP
This is the structure of button packets:
struct IS_BTN // BuTtoN - button header - followed by 0 to 240 characters
{
byte Size; // 12 + TEXT_SIZE (a multiple of 4)
byte Type; // ISP_BTN
byte ReqI; // non-zero (returned in IS_BTC and IS_BTT packets)
byte UCID; // connection to display the button (0 = local / 255 = all)
byte ClickID; // button ID (0 to 239)
byte Inst; // some extra flags - see below
byte BStyle; // button style flags - see below
byte TypeIn; // max chars to type in - see below
byte L; // left : 0 - 200
byte T; // top : 0 - 200
byte W; // width : 0 - 200
byte H; // height : 0 - 200
// char Text[TEXT_SIZE]; // 0 to 240 characters of text
};
// BStyle byte : style flags for the button
#define ISB_C1 1 // you can choose a standard
#define ISB_C2 2 // interface colour using
#define ISB_C4 4 // these 3 lowest bits - see below
#define ISB_CLICK 8 // click this button to send IS_BTC
#define ISB_LIGHT 16 // light button
#define ISB_DARK 32 // dark button
#define ISB_LEFT 64 // align text to left
#define ISB_RIGHT 128 // align text to right
// colour 0 : light grey (not user editable)
// colour 1 : title colour (default:yellow)
// colour 2 : unselected text (default:black)
// colour 3 : selected text (default:white)
// colour 4 : ok (default:green)
// colour 5 : cancel (default:red)
// colour 6 : text string (default:pale blue)
// colour 7 : unavailable (default:grey)Take a look at filed "BStyle". If you don't set it to any of ISB_DARK or ISB_LIGHT then the button will be transparent, so only the text will show.
You can have coloured text in two ways. One is using LFS colour tags wihtin the text. For example: "^1POLICE! STOP". If you want to have that message in red.
The other one is using BStyle field. For red you would use ISB_C1 + ISB_C4.
The difference is that default button colors defined with BStyle field are darker/lighter than the ones you get using color tags. The red color tag would give a very bright red, while BStyle defined red is darker red, tending to brown. Something like this:
Color tag: POLICE! STOP
BStyle: POLICE! STOP
Yes, the best way is to use buttons for that. RCM messages are no good because they conflict with each other, but transparent buttons are ok.
If you are using a time-based library (I think LFS External is one of these), you must create and send an IS_BTN button, then after one second you clear it with an IS_BFN, then after one second you send the same button (no need to create it again), and so on. All this controlled by a var that tells the application when to stop this sending/clearing button thing.
If you are not using a timed library, you should use some other way, like a separate thread that controls all the button thing using a function like "sleep()".
If you are using a time-based library (I think LFS External is one of these), you must create and send an IS_BTN button, then after one second you clear it with an IS_BFN, then after one second you send the same button (no need to create it again), and so on. All this controlled by a var that tells the application when to stop this sending/clearing button thing.
If you are not using a timed library, you should use some other way, like a separate thread that controls all the button thing using a function like "sleep()".
I totally agree with you. It's like using automatic gears. If you use automatic gears, how can you say "it's not fair that the people using manual gear shifts are faster than me"?
As Glenn said, the point is not the manual clutch (both button and axis) working better than autoclutch, but the autoclutch being worse than those. With LFS you are provided an automation of the clutch pedal called autoclutch, so you don't have to worry about it. But you are also provided a manual way to use the clutch. It happens that the automatic clutch is slower and has poorer performance than the manual one, so it's just natural that some people will chose manual clutch over automatic.
Now, how can you tell that someone using manual clutch is using a macro or not? Well, there's simply NO way. You might say that analyzing his RAF or whatever. But it can perfectly be the case that the guy masters the technique of pressing two buttons at the same time (which is not difficult at all). That's having no evidence at all.
Before, I was against the macro because I thought its performance was unreachable by humans, but after reading glenn's report on different clutch method's behaviour, now I find it pretty interesting. AC is indeed VERY unrealistic, while pedal/button/macro are all more realistic. I don't consider it an unfair advantage anymore, but I consider AC a disadvantage now.
Now, how can you tell that someone using manual clutch is using a macro or not? Well, there's simply NO way. You might say that analyzing his RAF or whatever. But it can perfectly be the case that the guy masters the technique of pressing two buttons at the same time (which is not difficult at all). That's having no evidence at all.
Before, I was against the macro because I thought its performance was unreachable by humans, but after reading glenn's report on different clutch method's behaviour, now I find it pretty interesting. AC is indeed VERY unrealistic, while pedal/button/macro are all more realistic. I don't consider it an unfair advantage anymore, but I consider AC a disadvantage now.
If any track editor were to happen, I hope it would be one where people would build entire tracks from scractch, to the level of the actual circuits in the game, and they had to be accepted by the dev team to get into the game based on strict qulity standards or something like that.
Not to get on your nerves, but I think the terms split/sector are used in the opposite way
The track is divided into sectors, and the sector time is the time you do in one specific sector (what I show in yellow/green/purple). On the other hand, the split time is the aggregated time from the start of the lap to one specific point (what LFS shows by default). Anyway, I totally understand what you're saying.
In my case, it dependes on whether the first sector was good or bad. If my lap is being a fast one then I'll look at the red/green difference first, to see how much time I'm losing to the fastest. When I do one bad sector time, then I'll look at the sector time in the following splits to see if at least I'm doing fine in the final sectors. In these laps, the global time is not that important anymore as you already lost it.
Also, when you are in a league race in which the fastest lap gives you some points, it's nice to know after the second split if you are being faster than the current fastest lap at that point, so you go for it in the final sectors.
PS: I'm sorry that this conversation is starting to go off-topic Maybe it would fit better in the thread I started
Last edited by MaKaKaZo, .
Thanks! What I noticed after running it a bunch of times with some friends is that after a while you check the coloured text before having a look at the standard RCM split time. And playing a bunch of short, consecutive races, the first thing you do when you finish is check "!splits" and "!best" too see where you were losing most time.
I think what he means is to create tracks using pre-built tiles, just like in the old 4d sports driving (stunts), so you don't need any knowledge on modelling, etc.
How many servers have you tried? I don't have any problems, I can connect.
I just saw a couple of laps and I noticed:
- You don't hit the brakes, you just touch them gently. You have to step on the brakes with full force and then release them gradually (but not too much). Also you need to brake much later.
- You look like you don't care much about your line, you never hit an apex, and never use the track width when exiting corners.
- You are too late accelerating. Maybe this is because you are not confident in your counter-steering. Work on this too.
- Sometimes you are using the wrong gear. Maybe you went in too slow into a corner and instead of shifting down you keep and upper gear at very low rpms.
I recommend you to watch some WR replays with the pedal bars on. That way you can see how people step on the pedals (both brake and throttle), and how they use the full width of the track.
Also, in real life you have to set a starting point and then each time you try to brake a little later, step on the throttle earlier, etc. until you see where is your limit. This is a game, so you can try the opposite approach. Set yourself a risky starting point, and if it's too late and you get off-track, then try a little earlier until you discover how late you can brake into a corner.
I think your problem is that you don't understand the basics of sports driving. This is the first thing though, to understand how lines should be. You can try using the AI line (key '4'). After some time you will understand what racing lines are all about, and you'll be able to discover them by yourself when you are in a new track.
- You don't hit the brakes, you just touch them gently. You have to step on the brakes with full force and then release them gradually (but not too much). Also you need to brake much later.
- You look like you don't care much about your line, you never hit an apex, and never use the track width when exiting corners.
- You are too late accelerating. Maybe this is because you are not confident in your counter-steering. Work on this too.
- Sometimes you are using the wrong gear. Maybe you went in too slow into a corner and instead of shifting down you keep and upper gear at very low rpms.
I recommend you to watch some WR replays with the pedal bars on. That way you can see how people step on the pedals (both brake and throttle), and how they use the full width of the track.
Also, in real life you have to set a starting point and then each time you try to brake a little later, step on the throttle earlier, etc. until you see where is your limit. This is a game, so you can try the opposite approach. Set yourself a risky starting point, and if it's too late and you get off-track, then try a little earlier until you discover how late you can brake into a corner.
I think your problem is that you don't understand the basics of sports driving. This is the first thing though, to understand how lines should be. You can try using the AI line (key '4'). After some time you will understand what racing lines are all about, and you'll be able to discover them by yourself when you are in a new track.
C++ - LFS Session Timing (application/tutorial)
SMALL UPDATE (2008-08-29):
The CInsim library was replaced with a newer version, but in this application no new features are used.
LFS SESSION TIMING v0.1
Ok, here is the application I made based on the example request by Dygear (http://www.lfsforum.net/showthread.php?t=46253).
First of all, I didn't know where to post this, as a reply to Dygear's thread, here as a new thread, or in the unofficial addons sub-forum. As it's more an example/tutorial I've chosen to post it here, moderators feel free to move it elsewhere, merge it with another thread, etc.
Also I'd like people to test it. I haven't tried it for long periods of times with many people connecting and leaving. Give me some feedback please! And take a look at the code!
But, WHAT THE HELL IS THIS?
It's an example InSim console application using the C++ language and my own small library.
It's meant to be used as an example/tutorial, and helping people understand how InSim works.
This application writes tons of stuff to the console. If there are too many players it might be impossible to follow, but if there are just a few, you can keep an eye on the console and pretty soon you will have a good idea on how InSim works, and what the application is doing at any time.
There are a lot of comments in the code too so it's easy to read and analyze
WHAT DOES IT DO?
It just shows extra information every time a driver completes a sector of the track. That info is:
To achieve this I have used transparent buttons. If you use RCMs they overlap (and erase) the standard split time, and you can't have several RCMs at one point, so buttons are an alternative, although their colors might be a bit too bright for some people.
There are some added features, like consulting lap and sector times for any driver connected to the server, the best times, and disabling the screen messages.
Admins also have more features, like making times permanent or resetable at each restart. By default all times (both individual and global) get reset at each restart, but you can set it so they are permanent. In that case they are reset only when the track is changed. Admins can also reset the times at any given time.
QUICK START
Just run the executable in the zip with 3 arguments: IP PORT ADMIN_PASS
(The PThreads dll must be in the same directory)
I recommend to create a Windows link and add those arguments in the properties.
Connect to the server and the help screen should appear. You can be in the server when the application starts, but be warned that the first thing it does is send everyone to spectators. The help screen is pretty self explanatory.
Start running!
LIMITATIONS
The application doesn't know when you are in shift+F mode, so you have to manually turn screen messages off, because buttons show even when you are in shift+F mode.
NOTES:
A file called insim.h is used. This is the original InSim.txt file included in the docs/ folder of your LFS installation, renamed to a .h. The only change that has been done to this file is in the line 1568:
char Text[112]; // 0 to 240 characters of text
The original button struct does not define a static text size, but permits different sizes. As a novice programmer I didn't know how to use buttons with variable sized texts, so I fixed it to 112. This causes a notable overhead when sending multiple IS_BTN packets to the server. If anyone knows how to use variable sized text with this CInsim library please tell me!!!
I'm also open to suggestions and awaiting for corrections to the code!
The CInsim library was replaced with a newer version, but in this application no new features are used.
LFS SESSION TIMING v0.1
Ok, here is the application I made based on the example request by Dygear (http://www.lfsforum.net/showthread.php?t=46253).
First of all, I didn't know where to post this, as a reply to Dygear's thread, here as a new thread, or in the unofficial addons sub-forum. As it's more an example/tutorial I've chosen to post it here, moderators feel free to move it elsewhere, merge it with another thread, etc.
Also I'd like people to test it. I haven't tried it for long periods of times with many people connecting and leaving. Give me some feedback please! And take a look at the code!
But, WHAT THE HELL IS THIS?
It's an example InSim console application using the C++ language and my own small library.
It's meant to be used as an example/tutorial, and helping people understand how InSim works.
This application writes tons of stuff to the console. If there are too many players it might be impossible to follow, but if there are just a few, you can keep an eye on the console and pretty soon you will have a good idea on how InSim works, and what the application is doing at any time.
There are a lot of comments in the code too so it's easy to read and analyze
WHAT DOES IT DO?
It just shows extra information every time a driver completes a sector of the track. That info is:
- Sector time coloured depending on how fast it was. Purple is global best, green is personal best and yellow is used in other cases.
- Difference to the best lap of the session at that point. Red means you are slower, green means you are faster, and white is used if you are doing the exact same time.
To achieve this I have used transparent buttons. If you use RCMs they overlap (and erase) the standard split time, and you can't have several RCMs at one point, so buttons are an alternative, although their colors might be a bit too bright for some people.
There are some added features, like consulting lap and sector times for any driver connected to the server, the best times, and disabling the screen messages.
Admins also have more features, like making times permanent or resetable at each restart. By default all times (both individual and global) get reset at each restart, but you can set it so they are permanent. In that case they are reset only when the track is changed. Admins can also reset the times at any given time.
QUICK START
Just run the executable in the zip with 3 arguments: IP PORT ADMIN_PASS
(The PThreads dll must be in the same directory)
I recommend to create a Windows link and add those arguments in the properties.
Connect to the server and the help screen should appear. You can be in the server when the application starts, but be warned that the first thing it does is send everyone to spectators. The help screen is pretty self explanatory.
Start running!
LIMITATIONS
The application doesn't know when you are in shift+F mode, so you have to manually turn screen messages off, because buttons show even when you are in shift+F mode.
NOTES:
A file called insim.h is used. This is the original InSim.txt file included in the docs/ folder of your LFS installation, renamed to a .h. The only change that has been done to this file is in the line 1568:
char Text[112]; // 0 to 240 characters of text
The original button struct does not define a static text size, but permits different sizes. As a novice programmer I didn't know how to use buttons with variable sized texts, so I fixed it to 112. This causes a notable overhead when sending multiple IS_BTN packets to the server. If anyone knows how to use variable sized text with this CInsim library please tell me!!!
I'm also open to suggestions and awaiting for corrections to the code!
Last edited by MaKaKaZo, .
I'm using a LGPL library. I think that allows me to choose any license for my application, even one not GPL compatible. I think I'll be going with the MIT license.
I need to do some tasks before releasing it though:
- Translate the code into English (var names, etc.)
- Add comentaries so it's easy to follow.
- Add license text and notices to the code and stuff like that.
I have made this "project" as a side job and I think I'll be releasing it tomorrow as a tutorial on InSim programming with C. It doesn't generate CSV files though.
I first made this as a feature for another bigger insim app, but thought it would be nice to have something like this as a standalone application that can be running all the time on a dedi server.
I hope some people will volunteer to do a little beta testing. And I hope someone takes a look at the code and corrects the many mistakes I must have done
I first made this as a feature for another bigger insim app, but thought it would be nice to have something like this as a standalone application that can be running all the time on a dedi server.
I hope some people will volunteer to do a little beta testing. And I hope someone takes a look at the code and corrects the many mistakes I must have done
Thanks for the info. I already have it working with Pthreads-w32 mentioned by Karl in the first reply. It's working nice but I don't like much that I need a dll for it to work. That's Windows for you
If that's what he meant I understood it totally the opposite way
I wonder why it only happens to arrechee then. And double up-shift... how can you say that's a side effect of macro clutch? Dude, don't try to make up shit. Believe it or not there are guys FASTER than you (and quite a bunch, tbh).
About F1 tyre pressures
This is a small quote extracted from a feature at f1.com website. These are words from Hirohide Hamashima, Bridgestone’s Director of Motorsport Tyre Development:
In some ways the behaviour we have in LFS is the opposite to what thery're saying here. What do you think?
You can read the whole article here:
http://www.formula1.com/news/features/2008/7/8164.html
In some ways the behaviour we have in LFS is the opposite to what thery're saying here. What do you think?
You can read the whole article here:
http://www.formula1.com/news/features/2008/7/8164.html
I don't give a damn about the people who use the macro, which I don't like, but I also don't like people accusing someone without any evidence and just saying "take a look at the analyzer".
Ok... take a look at this evidence:
http://www.lfsworld.net/?win=h ... ;config=cadet&car=UF1
Donwload and play arrechee's WR for this combo (AS1 - UF1). You can see how many times there's a miss when he up-shifts. It was some weeks ago. I asked him directly and he told me that his old sidewinder (or whatever it is) wheel had the up-shift paddle a little broken and some times it won't make contact and the gear just won't kick in, so he has to keep pressing the clutch button and hitting the paddle until the paddle works. There's even a time when he shifts up involuntarily two gears because the paddle makes a double contact. Does the clutch macro generate that behaviour? I hope no one says now that this is macro clutch...
Now some people will say that using the clutch in a button -not using a macro- is also illegal.
Ok... take a look at this evidence:
http://www.lfsworld.net/?win=h ... ;config=cadet&car=UF1
Donwload and play arrechee's WR for this combo (AS1 - UF1). You can see how many times there's a miss when he up-shifts. It was some weeks ago. I asked him directly and he told me that his old sidewinder (or whatever it is) wheel had the up-shift paddle a little broken and some times it won't make contact and the gear just won't kick in, so he has to keep pressing the clutch button and hitting the paddle until the paddle works. There's even a time when he shifts up involuntarily two gears because the paddle makes a double contact. Does the clutch macro generate that behaviour? I hope no one says now that this is macro clutch...
Now some people will say that using the clutch in a button -not using a macro- is also illegal.
Last edited by MaKaKaZo, .
Don't fight guy s
Well, I'm a noob programmer and I don't think what I did could be of any use to the LFS programmers base, except for learning purposes.
What I've done is a simple class and a few independent functions that I use for my tests. I work with my little class and the original insim.h (InSim.txt in docs folders renamed to .h) which defines the C structs for all IS packets, enums, etc. Here is my CInsim.h file
In my main I start the connection, send some initialization packets to setup the host, and then I enter the main loop in which I get the next packet. Then I have a switch inside that loop that calls individual functions depending on the packet received.
If someone finds this interesting I have no problem releasing it to the community. I think that all the code related to my CInsim class is in English.
Well, I'm a noob programmer and I don't think what I did could be of any use to the LFS programmers base, except for learning purposes.
What I've done is a simple class and a few independent functions that I use for my tests. I work with my little class and the original insim.h (InSim.txt in docs folders renamed to .h) which defines the C structs for all IS packets, enums, etc. Here is my CInsim.h file
#ifndef _CINSIM_H
#define _CINSIM_H
typedef unsigned char byte;
typedef unsigned short word;
// Custom InSim specific database types
typedef struct NodeLap NodeLap;
typedef struct CompCar CompCar;
typedef struct
{
int x;
int y;
int z;
} Vec;
typedef struct
{
float x;
float y;
float z;
} Vector;
#include "insim.h"
#include <winsock2.h>
#define PACKET_BUFFER_SIZE 512
#define PACKET_MAX_SIZE 512
#define IS_TIMEOUT 5
// Definition for our buffer datatype
struct buffer
{
char buffer[PACKET_BUFFER_SIZE]; // Packet buffer - 512 should be more than enough
unsigned int bytes; // Number of bytes currently in buffer
};
/**
* CInsim class to manage the Insim connection and processing of the packets
*/
class CInsim
{
private:
SOCKET sock; // Socket
struct buffer gbuf; // Our global buffer
struct buffer lbuf; // Our local buffer
char packet[PACKET_MAX_SIZE]; // A buffer where the current packet is stored
fd_set readfd, exceptfd; // File descriptor watches
struct timeval select_timeout; // timeval struct for the select() call
public:
CInsim::CInsim(); // Constructor
// "int init(...)" Establishes connection with the socket and insim.
//+ The last argument ch_ver is a pointer to a IS_VER struct. If it's used an IS_VER packet
//+ will be returned. If ch_ver is not used in the call no IS_VER will be requested/returned.
int init (int protocol, char *addr, word port, char *product, char *admin, byte prefix = 0, struct IS_VER *ch_ver = NULL);
int isclose(); // Closes connection from insim and from the socket
int next_packet(); // Gets next packet ready into "char packet[]"
char peek_packet(); // Returns the type of the current packet
void* get_packet(); // Returns a pointer to the current packet. Must be casted
int send_packet(void* packet); // Sends a packet to the host
};
/**
* Other functions!!!
*/
char* mstostr (long milisecs, char *str); // Converts miliseconds to a C string.
#endifIn my main I start the connection, send some initialization packets to setup the host, and then I enter the main loop in which I get the next packet. Then I have a switch inside that loop that calls individual functions depending on the packet received.
If someone finds this interesting I have no problem releasing it to the community. I think that all the code related to my CInsim class is in English.
Auto-quote myself:
This also means that I don't have any intention to completely rewrite my API and all the code I've been doing. Most of all, I don't have experience with event based systems, so that would be a completely time consuming task to research. Maybe some day. Anyway, I don't think that event based, timed systems do any kind of magic. If you don't use threads for these kind of things I think any other solution would be slower.
OK. I have downloaded pthreads-w32 and I'll try those
Now I have another question related to RCMs. I've noticed that when I send a RCM to a user it will erase other RCMs like the ones that tell you about your lap and split times. My intention was to provide additional info on split times added to the standard RCMs. When I receive an IS_SPX packet the "split time x
xx" appears for a fraction of a second and then it gets erased my my insim-created RCM. I'd like to know if any of these would be the solution:
- Somehow disable the standard RCM messages generated by LFS so the only ones that show are the ones my InSim app send.
- Use transparent buttons instead of RCMs and try to manually place them in the center if the screen below the standard generated RCMs.
EDIT: I already have a working example using Pthreads-w32, and it seems pretty fast. Now I need to add mutual exclusion checking and tidy up a little the code. I needed to make some basic structures global in order for the threads to be able to access some data, and that leads to mutex issues and blablabla... A pain, but thinking about it, it's the way it must be done (I think).
Now I have another question related to RCMs. I've noticed that when I send a RCM to a user it will erase other RCMs like the ones that tell you about your lap and split times. My intention was to provide additional info on split times added to the standard RCMs. When I receive an IS_SPX packet the "split time x
xx" appears for a fraction of a second and then it gets erased my my insim-created RCM. I'd like to know if any of these would be the solution:- Somehow disable the standard RCM messages generated by LFS so the only ones that show are the ones my InSim app send.
- Use transparent buttons instead of RCMs and try to manually place them in the center if the screen below the standard generated RCMs.
EDIT: I already have a working example using Pthreads-w32, and it seems pretty fast. Now I need to add mutual exclusion checking and tidy up a little the code. I needed to make some basic structures global in order for the threads to be able to access some data, and that leads to mutex issues and blablabla... A pain, but thinking about it, it's the way it must be done (I think).
Last edited by MaKaKaZo, .
Control timing for RCMs
Hi, I'm working in my insim example app which I built from scratch -using karl's C example as a base to get the socket and insim connection to work- and I've reached a point where I'd like to use/test RCM messages.
The "problem" is that I know how to send a RCM to any player, but I'm guessing that the correct way to clear those RCMs would be using an independent thread that would act as a timer that clears one specific RCM message, or maybe even handles all RCMs present at one time. Maybe I'm totally wrong and there's another way to do it. Of course I don't want my main thread to be on an active wait for like 4 or 5 seconds to clear the RCM and then continue.
I haven't used threads in a LONG time, and I think that I would breaking platform compatibility because I think there are no standard libraries for threads in C/C++. Right now all my code would be linux/windows compatible with tiny changes to the InSim API I've created, and I wouldn't like to break compatiblity...
Can anyone point me into the right direction?
PS: Please no responses like "use LFS External, that will do the job" or the like. I'm just toying with InSim to learn how it works, and as an exercise on C/C++ programming. I have no intention to pick any already existing InSim library.
The "problem" is that I know how to send a RCM to any player, but I'm guessing that the correct way to clear those RCMs would be using an independent thread that would act as a timer that clears one specific RCM message, or maybe even handles all RCMs present at one time. Maybe I'm totally wrong and there's another way to do it. Of course I don't want my main thread to be on an active wait for like 4 or 5 seconds to clear the RCM and then continue.
I haven't used threads in a LONG time, and I think that I would breaking platform compatibility because I think there are no standard libraries for threads in C/C++. Right now all my code would be linux/windows compatible with tiny changes to the InSim API I've created, and I wouldn't like to break compatiblity...
Can anyone point me into the right direction?
PS: Please no responses like "use LFS External, that will do the job" or the like. I'm just toying with InSim to learn how it works, and as an exercise on C/C++ programming. I have no intention to pick any already existing InSim library.
FGED GREDG RDFGDR GSFDG