The online racing simulator
Quote from MadCatX :C++ has it's own big-scary-monstrous things too BTW

If anything I'd say it's more monstrous. Simply put, C hands you a shotgun to shoot yourself in the foot with, C++ offers a wide array of weaponry. Some very elegant, some very bloody, but the end-result is still a missing foot.

Quote from Dygear :Well, that makes two of us, but I leave my suckieness out there (and my foot in my mouth for the whole world to see).

To keep the foot-analogy going, a foot in your mouth is a foot safe from being shot

Programmers need to shoot themselves in their feet though, best way to learn. Also, often times it's actually good fun.
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?
Hey guys,

since MaKaKaZo is busy having a life and all, I took the liberty of getting CInSim up to date to make it work with 0.6B. The list of changes include
  • Updated send_packet(). It now properly handles both IS_BTN and IS_MTC packets and sends only the amount of data that is needed.
  • Removed send_button() as it is no longer needed. (This breaks compatibility with old apps)
  • Simplified next_packet() and udp_next_packet()
    As I understand it there's no need to check for FD_ISSET(&readfd). If select() returns a positive number, FD_ISSET should be also true. (It should, right?)
  • Got rid of 100% CPU load caused by next_packet()o n Linux systems
    select() on Linux (and possibly other *NIX systems) reduces the passed timeval so that it contains the time that was left until a timeout would occur. I assume that's not the case on Windows. This eventually leads to zero timeval and select() returning immediately, which in turn causes very high CPU load.
    I replaced select() with pselect() which doesn't modify the timeval.
    (Other *NIX systems that use their own standard C library might exhibit a different behavior)
If MaKaKaZo ever decides to update CInSim himself, this little fork of mine will be removed.
EDIT: File removed, changes have been merged into CInsim 0.7.
I really want to do some C++ programming.

Nice job guys!
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
I expect my free time to become a rather rare commodity too later this year, but I think I can keep CInSim in a working state in case another InSim update is released. Should you ever decide to update the mainline CInSim, just let me know and feel free to use anything I posted or wrote so far, GL with your excessiveness of a life BTW
i use it > 2 years
send_button and send_mtc is privat

<?php 
/**
* Send a packet
*/
bool CInsim::send_packet(voids_packet)
{

    
byte Type = *((unsigned char*)s_packet+1);
    switch(
Type)
    {
    case 
ISP_BTN:
        return 
send_button(s_packet);
        break;

    case 
ISP_MTC:
        return 
send_mtc(s_packet);
        break;
    }

    
pthread_mutex_lock (&ismutex);
    if (
send(sock, (const char *)s_packet, *((unsigned char*)s_packet), 0) < 0)
    {
        
pthread_mutex_unlock (&ismutex);
        return 
false;
    }
    
pthread_mutex_unlock (&ismutex);
    return 
true;
}


/**
* Send a variable sized button
*/
bool CInsim::send_button(voids_button)
{
    
struct IS_BTN *pack_btn = (struct IS_BTN*)s_button;

    
int text_len strlen(pack_btn->Text);
    
int text2send;

    if (
text_len == 0)
        
text2send 0;
    else
        
text2send = (1+((text_len-1)/4))*4;

    
pack_btn->Size 12 text2send;

    
pthread_mutex_lock (&ismutex);
    if (
send(sock, (const char *)pack_btnpack_btn->Size0) < 0)
    {
        
pthread_mutex_unlock (&ismutex);
        return 
false;
    }
    
pthread_mutex_unlock (&ismutex);
    return 
true;
}

/**
* Send a variable sized message to connect
*/
bool CInsim::send_mtc(voids_mtc)
{

    
struct IS_MTC *pack_mtc = (struct IS_MTC*)s_mtc;
    
int text_len strlen(pack_mtc->Text);
    
int text2send;

    if (
text_len == 0)
        return 
false;
    else if (
text_len 127)
        return 
false;

    
text2send text_len text_len%4;
    
pack_mtc->Size text2send;

    
pthread_mutex_lock (&ismutex);
    if (
send(sock, (const char *)s_mtc,*((unsigned char*)s_mtc), 0) < 0)
    {
        
pthread_mutex_unlock (&ismutex);
        return 
false;
    }
    
pthread_mutex_unlock (&ismutex);
    return 
true;
}
?>


<?php 
void send_mtc 
(byte UCID,const charMsg)
{
    
struct IS_MTC pack_mtc;
    
memset(&pack_mtc0sizeof(struct IS_MTC));
    
pack_mtc.Size sizeof(struct IS_MTC);
    
pack_mtc.Type ISP_MTC;
    
pack_mtc.UCID UCID;
    
sprintfpack_mtc.Text"%.127s\0"Msg );
    
insim->send_packet(&pack_mtc);
};

void send_mst (const charText)
{
    
struct IS_MST pack_mst;
    
memset(&pack_mst0sizeof(struct IS_MST));
    
pack_mst.Size sizeof(struct IS_MST);
    
pack_mst.Type ISP_MST;
    
sprintfpack_mst.Msg"%.63s\0"Text );
    
insim->send_packet(&pack_mst);
};
?>

Thanks for tool and thread stuff, was able to run EventControl in MSVC without too much headache in 2 hours.
Wil LFS be able to hold two applications of this type simultaneously, let's say two EventContros or EventControl&stuff like Airio?
Cause "(Tv)Director" line in config may mean otherwise?
LFS supports up to 8 InSim applications connected simultaneously, but I guess that each of them must report a different name in IS_ISI.
Lightspeed answer after month of sleeping forum Thanks
@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
Quote from MaKaKaZo :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

The way LFS sends packets was indeed updated. There is a lot more buffering now so it's very common to get multiple packets in one shot. CInsim appears to handle it just fine though
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
BTW, Very usefull sources. Kinda combined EvHandler and Positioning program, works well. And all that comments - wonder how much time percent they took.
Just two questions (may be noobish):
-pthread_mutex_t and etc: do they required in main.cpp? (Looking on positionig example & *_buttons functions). One of pthread_mutex_unlock returned me smth like owerflow, so just commented them.
-Do udp_loop_thread really need it's own thread? Or udp_next_packet & next_packet may freeze a bit?
need. bcz next_packet and udp_next_packet use different sockets

<?php 
SOCKET sock
;                            // TCP Socket (most packets)
SOCKET sockudp;                         // UDP Socket (if requested, for NLP and MCI)
?>

some lols
cinsim.h have line


<?php 
typedef unsigned char byte
;
?>

but in cinsim.cpp using only

<?php 
unsigned char
?>


Quote from [SC] :-pthread_mutex_t and etc: do they required in main.cpp? (Looking on positionig example & *_buttons functions). One of pthread_mutex_unlock returned me smth like owerflow, so just commented them.

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:

Quote :typedef unsigned char byte;

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
Does anybody want to share their updated library with public? Thanks.
No update should be necessary, you might only have to replace the insim.h file to gain compatibility with a particular version of InSim.
Maybe publish a library on github, so other users can extend the functionality of the library.

I had already added to the library methods of sending certain types of packets, using safe methods like

<?php 
sendButton
sendMtc
sendMst
?>


i'm add lib to github

https://github.com/turbosnail/cinsim
in some future i'll try use gcc 4.8 for using <mutex>
Quote from repeat83 :don't use gcc 4.9.0
http://habrahabr.ru/post/231243/

Open Linus bug 61904 (gcc bugzilla) was closed as a duplicate of bug 61801. 61801 existed in versions with gcc 4.5.0 on 4.8.3, 4.9.0 and 4.9.1 (but not to 4.9.0 error led to trimming constants in the code load_balance). Fixed since 4.8.4, 4.9.2, 4.10.0.
install gcc-4.8.1 and g++-4.8.1 for <mutex>



<?php 
g
++ -o main.---std=c++11 -march=i686 -Imain.cpp
g
++ -o test cinsim.o main.o
done building targets
.
?>

added new branch gcc4.8

FGED GREDG RDFGDR GSFDG