I have added a link to denis-takumi's repository on github.com. I have been off from LFS for a long time, sorry for not keeping the library up to date. Anyway, the work needed to update it is very simple and I think many members here can do it easily. I still receive email notifications of replys in this thread and private messages, so I'll try to drop by from time to time to update the first post if needed.
Not anymore. They were needed in earlier versions of CInSim, but I think from version 0.5 and onwards all the library functions are thread safe, which means that you don't have to use mutex_lock or unlock anymore inside your own application code, as it is done already inside the library functions.
@denis-takumi:
That's in cinsim.h because it's needed for insim.h where Scawen uses byte all the time. I, on the other hand, don't use it in my own code. There's no other reason actually, so at one point I might change all my unsigned chars into bytes for better legibility. I hadn't even thought about it to be honest
I just posted an official update to CInSim, version 0.7, which includes all the changes/additions MadCatX made to the 0.6 code and the new insim.h that was released with LFS 0.6C. I think I did some minor contributions to the code that were necessary for some of the new packets to work, but haven't tried using the new stuff myslef. I think it should work.
I rebuilt my Event Control application to do a quick check and it worked fine, so I'll hope everything works ok (until someone comes and tells me otherwise).
Thanks a lot again for your work in CInSim MadCatX, as I think it is now quite reliable and fast
I rebuilt my Event Control application to do a quick check and it worked fine, so I'll hope everything works ok (until someone comes and tells me otherwise).
Thanks a lot again for your work in CInSim MadCatX, as I think it is now quite reliable and fast
@denis-takumi:
I don't understand what you want or mean.
@MadCatX:
I believe there were recent changes to insim, I'm going to take a look because maybe there's an update needed to CInsim. Now I have some free time, although I haven't toyed with code for a veeeery long time
I don't understand what you want or mean.
@MadCatX:
I believe there were recent changes to insim, I'm going to take a look because maybe there's an update needed to CInsim. Now I have some free time, although I haven't toyed with code for a veeeery long time
Car #44:
After seeing that admins don't know the first thing about race control and championship organization, I withdraw from this series. You should learn how a racing car series work before trying to create your own. This one is sub-par, not fun anymore.
After seeing that admins don't know the first thing about race control and championship organization, I withdraw from this series. You should learn how a racing car series work before trying to create your own. This one is sub-par, not fun anymore.
Maybe you meant car #44 instead of car #45? I'm #44, the one with the +10 seconds penalty. I don't know about any penalty for #45, but he finished 4th, behind 44, 99 and 21.
I'll tell you there's no such mention. I read the rules and I did leave pits wihout crossing the yellow lines because I'm used to it, but there's no such thing in the rules.
I'm not in this for the points or prizes, in fact I probably won't be participating again until the next one hour race - 2 hours is too much for me. But I have to say that there's an apparent lack of transparency on the rules, penalties and scores:
- What are those "pit entry" penalties?
- Why is there no mention to the scoring system used in the rules?
- Why does car #45 have the highest subtotal score if he finished 4th?
- Why does car #00 not appear in the drivers table and has no points?
Protest sent. It's a race incident.
But I would like to discuss the policy used on issuing penalties, as that is not subject for protest, as it has nothing to do with race incidents.
I received two penalties in the race, which I'm ok with. I don't like -and I'm not used to- using safety cars and all that realistic stuff, so it's no wonder I ended up messing it up a couple of times. But my second penalty was a +10 seconds penalty. I don't know exactly when I received that penalty because I don't see server admin chat messages in the replay, but I think it was something like halfway, about 30 minutes into the race. At that moment I knew that I had absolutely no chance of winning. My only chance was to end 10 seconds ahead of the second driver, but having had already three safety cars in 30 minutes, it was virtually impossible to gain a 10 seconds advantage. I knew that there would be more safety cars and my lead would be cut down to nothing again.
In the end, we had another safety car with 5 minutes remaining, and that was it, the end to my race. I finished 1st after the safety car, but my final position is 5th because of the +10 seconds penalty.
The thing is, you *never* issue a time penalty when there are more than 3 laps remaining in the race. With so much time left, you should issue a DT for a light penalty, and a S&G for a harsh one.
Even though +10 seconds is less than what you lose during a DT, what's the point when there are safety cars deployed constantly and it's impossible to build up a gap to the cars behind you? You should think about that.
Also. You added an extra lap after the race time had finished and announced it when I was about to cross the finish line. I released the gas pedal and was already slowing down when I realized there was another lap left and cars behind me were still racing. What's the point of that? The race should have finished with the safety car deployed. Adding a last sprint lap is just calling for people to go crazy and try to win in the last lap what they couldn't in one hour. That's just calling for accidents.
I have to say that I had fun. It had been years since my last competitive LFS race, and although the grid was quite small, it was fun racing. But maybe you should keep it a little simpler. Making things so complicated sometimes goes against the fun.
Btw, safety cars totally killed tire temperatures, and it was dangerous to try and warm them up. People were following the car in front of them way too close. I got bumped several times by the car behind me during the last safety car period.
But I would like to discuss the policy used on issuing penalties, as that is not subject for protest, as it has nothing to do with race incidents.
I received two penalties in the race, which I'm ok with. I don't like -and I'm not used to- using safety cars and all that realistic stuff, so it's no wonder I ended up messing it up a couple of times. But my second penalty was a +10 seconds penalty. I don't know exactly when I received that penalty because I don't see server admin chat messages in the replay, but I think it was something like halfway, about 30 minutes into the race. At that moment I knew that I had absolutely no chance of winning. My only chance was to end 10 seconds ahead of the second driver, but having had already three safety cars in 30 minutes, it was virtually impossible to gain a 10 seconds advantage. I knew that there would be more safety cars and my lead would be cut down to nothing again.
In the end, we had another safety car with 5 minutes remaining, and that was it, the end to my race. I finished 1st after the safety car, but my final position is 5th because of the +10 seconds penalty.
The thing is, you *never* issue a time penalty when there are more than 3 laps remaining in the race. With so much time left, you should issue a DT for a light penalty, and a S&G for a harsh one.
Even though +10 seconds is less than what you lose during a DT, what's the point when there are safety cars deployed constantly and it's impossible to build up a gap to the cars behind you? You should think about that.
Also. You added an extra lap after the race time had finished and announced it when I was about to cross the finish line. I released the gas pedal and was already slowing down when I realized there was another lap left and cars behind me were still racing. What's the point of that? The race should have finished with the safety car deployed. Adding a last sprint lap is just calling for people to go crazy and try to win in the last lap what they couldn't in one hour. That's just calling for accidents.
I have to say that I had fun. It had been years since my last competitive LFS race, and although the grid was quite small, it was fun racing. But maybe you should keep it a little simpler. Making things so complicated sometimes goes against the fun.
Btw, safety cars totally killed tire temperatures, and it was dangerous to try and warm them up. People were following the car in front of them way too close. I got bumped several times by the car behind me during the last safety car period.
Last edited by MaKaKaZo, .
Can we send protests using lfsforum private messages? I'd rather use that instead of regular email.
I read on the rules that we have to be on a TS channel to receive race commands. Will that TS channel info arrive with the server info before the race? I'd like to have that configured beforehand.
Do we have to announce the car we will use before the race? I'll be using the UFR in all races.
I don't know if I can still apply to join the series, but here I go:
Real Name: Cristóbal Mákaro
Team: Q3team
Race Number: 44
Nationality: Spain
Real Name: Cristóbal Mákaro
Team: Q3team
Race Number: 44
Nationality: Spain
Hi. Thanks MadCatX for your work again. The thing is that right now I have too much of a life. So much that I don't have any time for gaming or leisure projects. I hope to have the time and be in the mood to go back to LFS at some point, but this year doesn't look too promising in that front, so every work you or anyone does on CInSim is very welcome
After this discussion, I think that you get my point now. This is very common in C, the programmer is responsible for filling in the data structures adecuately before passing them to functions. I don't say that it's the best way. Anyway, in this case, if a programmer overflows the Text field of the button it's his responsibility and CInSim's send_button() function won't fail because of this, probably the whole application will fail in an unexpected way.
And people don't get too scared of the overflowing example above. To prevent this you can use standard functions like strncpy() which will copy n characters and truncate the rest, although no null character is appended at the end if it has to truncate, so you actually have to copy text_field_size-1 characters if you want to ensure the C string is null terminated (considering you have previously filled the whole string with all zeroes, of course). Sounds easy, uh?
And people don't get too scared of the overflowing example above. To prevent this you can use standard functions like strncpy() which will copy n characters and truncate the rest, although no null character is appended at the end if it has to truncate, so you actually have to copy text_field_size-1 characters if you want to ensure the C string is null terminated (considering you have previously filled the whole string with all zeroes, of course). Sounds easy, uh?
Yes, that's the main idea. I'd keep the send_button() probably for compatibility reasons.
About checking text size, I don't want to do it. When you declare an IS_BTN struct the Text field is statically set to 240 chars long. In theory you shouldn't be able to send a button packet with a text longer than that, unless you modify the definition of the struct in insim.h or you do something nasty in your application. So I consider there's no need to worry about that
Last edited by MaKaKaZo, .
Nice, that one is sorted then, and I won't have to change my code for sending buttons
I think I'll redo the send_packet() function so that depending on the packet type -which is always the second byte of the struct/data to be sent- it will then call to separate functions in case it's a button, a mtc or otherwise (generic packet). I'm not feeling like doing it today anyway. What do you people think?
I think I'll redo the send_packet() function so that depending on the packet type -which is always the second byte of the struct/data to be sent- it will then call to separate functions in case it's a button, a mtc or otherwise (generic packet). I'm not feeling like doing it today anyway. What do you people think?
I think you should open a new thread to report this and maybe Scawen will have a look at it. The behaviour should be persistent regardless of the text size.
I think I never did a hard test on this matter, I just went on with what the doc said. But now I think that I have been sending buttons without a null terminator all the time since I included the send_button() function (aproximately one of every four buttons that contain text). The text on this buttons shows up just fine, so maybe it's a bug that happens with texts 240 chars long.
I can't do a test right now, but i'm pretty sure that a button containing "1234" will send only those four bytes as the Text field (in the latest CInSim version), and they will show right without any need of a null terminator. I don't know about 240 chars...
I used
because in the insim documentation it doesn't say anywhere that the "Text" field for the IS_BTN packet must end with a zero:
That's why I used that. I understand that in IS_BTN packets you don't need to add a terminating zero byte. In IS_MTC the situation is different as it states that the string must be zero terminated.
(1+((text_len-1)/4))*4because in the insim documentation it doesn't say anywhere that the "Text" field for the IS_BTN packet must end with a zero:
char Text[240]; // 0 to 240 characters of textThat's why I used that. I understand that in IS_BTN packets you don't need to add a terminating zero byte. In IS_MTC the situation is different as it states that the string must be zero terminated.
I'll think about this, it sounds like a good idea indeed.
Why don't you just copy and edit the send_button() function? It's exactly the same case and it works fine.
BTW, there's a mistake in your code because you use the field "Msg" in the IS_MTC, but now it's called "Text".
I'll change the library source code with the new insim changes when I have some time. It's a quite simple task. The good thing is that it will be backwards compatible. We will have a new send_mtc() function to send variable sized mtc packets, but the generic senc_packet() will work as well, causing a little network overhead because in that case packets sent will be the biggest possible (with 128 bytes of text).
BTW, there's a mistake in your code because you use the field "Msg" in the IS_MTC, but now it's called "Text".
I'll change the library source code with the new insim changes when I have some time. It's a quite simple task. The good thing is that it will be backwards compatible. We will have a new send_mtc() function to send variable sized mtc packets, but the generic senc_packet() will work as well, causing a little network overhead because in that case packets sent will be the biggest possible (with 128 bytes of text).
The FRL has been running constantly for at least 2 years now. It would be nice to have a little aknowledgement to the work of the people working there. Anyway, Victor seems to be focused on other things and hasn't been doing this kind of stuff anymore for some time. Lys don't push it too hard.
PS: I'm sorry for not showing to the FRL for a long time, I haven't been on the mood to play LFS for a while now. When I'm more motivated I'll be racing in the FRL again for sure
PS: I'm sorry for not showing to the FRL for a long time, I haven't been on the mood to play LFS for a while now. When I'm more motivated I'll be racing in the FRL again for sure
That's right. X-Y-Z positioning was my first attempt on an insim app using buttons and MCI packets. It's very old and uses an earlier version of CInSim. As Madcatx said, CInSim 0.6 is thread safe already so you don't need to use them.
Actually, aside from what has been already mentioned about UDP and TCP using the same method for sending packets, my main concern was using the same method frmo different threads.
For example, I usually create new threads that act as timers. They are created, wait for several seconds, and then they do something like clear a set of buttons that were created previously (this is the way I create a message that automatically disappears after X seconds). This timer thread has to use the send() method. If you have several threads like this doing different stuff, there's quite a high possibility that at some time two of them will try to use the method at the same time, and the result might lead to a unstable status or even a crash. It actually happened to me before I fixed it.
CInSim 0.6 blocks the critical methods before using them, so that only one thread can use them and calls from other threads are queued until the current one finishes. You don't need to handle that manually anymore.
If you are interested in CInSim maybe you should download the latest demo application which uses the latest CInSim version (I think...).
Actually, aside from what has been already mentioned about UDP and TCP using the same method for sending packets, my main concern was using the same method frmo different threads.
For example, I usually create new threads that act as timers. They are created, wait for several seconds, and then they do something like clear a set of buttons that were created previously (this is the way I create a message that automatically disappears after X seconds). This timer thread has to use the send() method. If you have several threads like this doing different stuff, there's quite a high possibility that at some time two of them will try to use the method at the same time, and the result might lead to a unstable status or even a crash. It actually happened to me before I fixed it.
CInSim 0.6 blocks the critical methods before using them, so that only one thread can use them and calls from other threads are queued until the current one finishes. You don't need to handle that manually anymore.
If you are interested in CInSim maybe you should download the latest demo application which uses the latest CInSim version (I think...
).That is used for mutual exclusion:
http://en.wikipedia.org/wiki/Mutual_exclusion
This is *only* important if you have a multi-threaded application.
As I recall, I used those functions inside the main application code in earlier versions of CInSim, but soon I realized that I could just put that code inside the library code itself, so the programmer doesn't need to control mutual exclusion.
The thing is, if you have an application where multiple threads are created, and those threads use common resources (ie. global variables), then it could happen that those resources might be used by both threads at the same time, resulting in undesirable consequences.
Please tell me which file you are viewing that code in (and CInSim version used) and I'll go into deeper detail of why I used it, but I'm pretty confident that it has to be something related with the main application algorithm, not with the library. I mean, it isn't supposed to be something that has to be used for all CInSim applications!
I can help with this! This is a problem that comes from mingw compiler code optimization options. I think there were three levels of code optimization in the compiler options. If you check some of them *sometimes* it will generate an executable that crashes. This has been reported in mingw support several times, it has nothing to do with code::blocks, CInSim or my application. It works when debugging because in debug mode no optimization options are checked. You can just uncheck some of the optimization levels until you get a working executable.
This actually got me crazy some time ago when I did some minor changes to a project and suddenly it started crashing for no reason.
With you VS problem I can't help much. It's pretty clear that it's something to do with the includes, libraries and such. I'm no expert at all at that matter neither I know about VS as I have never used it.
FGED GREDG RDFGDR GSFDG