Average movie, it wasn't worth downloading 100MB

Is there a script or something out there explaining what's going on? I still have to watch the first episode, but in this one I don't have a clue of what's happening most of the time XDDDDDD Anyway, I liked it!

Btw, I can do English with an Spanish accent

Quote from Dygear :

MaKaKaZo, just wanted to thank you for making this available to the public, I really think it adds a lot the sim.

Scawen, read this and think of it as a possible future feature

Quote from Greenseed :

Not sure i follow you... but if you wan to know if a driver is turning clockWise or not on a track, can be done with checking the y tangen angle from car x,y to 0,0 if you got : 51,52,53,54 mean i got clockwise if you got 54,53,52,51 mean counter clockWise. all track, Star/Stop are connected so work allways good, it just a way, i thought of some other.

Is that what you are looking for?

Easier than that would be to check if the nodes the car is in are increasing or decreasing, wouldn't it?

Quote from Scawen :

Path nodes are approximately as long as 0.2 seconds of time when driving a car.

That is because the original path nodes are created by driving a car smoothly around the track, then connecting the resulting path as a loop. A path node is created 5 times per second, with the position and direction of the car.

But that depends which car was used, so that's why the 0.2 seconds is just a rough guide. Anyway this means the path nodes are more spread out at higher speed sections of track.

That's cool, in that case they can be used as a distance factor when you consider "regular racing". Maybe I'll use it for an InSim application that would be used during our destrcution derby-like team matches where wrong way driving, ramming and driving off track to avoid incoming cars is a must.

By the way... regarding nodes and our crazy game something just came up to me. We've been playing this game for a while now, and as I say wrong way driving is an essential technique. We play on AS2 and this is what happens:

While some people are driving to win the 3 laps race, others constantly go to pits and start directly exiting the pits in the wrong way (we use /cruise yes to avoid wrong way messages). When this happens in the first lap I think that the drivers that start from the pits to wrong way appear in the positions list as 1st, 2nd, etc. like they are leading the race, when they actually aren't as they went to pits and started wrong way.

I think this might be because everyone is noted as being on their first lap, but the guys going wrong way are in nodes higher than the ones that are racing for the win, so the game thinks they are leading. Can anyone confirm if that would be the reason?

I'm interested in this because in my InSim app I'd need to know who's the first driver of each team to make a GPS-like device that would tell team members how far (in nodes) they are to the other team leader, because in the minimap you see many "yellow cars" but you are never sure of who is the one you are aiming at. If you can't tell who's first in the first lap I'd start the tracking on the second, that's no problem, but I'd prefer it to start in the second.

Last edited by MaKaKaZo, Mon 1 Sep 2008, 19:16.

Greenseed I've checked your code and I like your idea of using nodes, but in my example I just want to provide physical comparison relative to all cars present, not only the ones that are near you. So, if there are just two cars I don't care if they are really far away one from the other, I want the name of the closest one even if it's very far.

About the nodes idea... do all nodes have a similar length? For a in race usable application it would be nice to know.

I've seen in your code that your findNodeCars function repeats work all the time from previousNodeCount to nextNodeCount. I mean, it checks all cars at node previousNodeCount, then all cars again in previousNodeCount+1... and so on until nextNodeCount. Maybe you should do some change and do a simple loop that checks all cars just once, and if their node is within previousNodeCount to nextNodeCount then they're added to the List<CarMotion> carIds.

PS: I don't know C# but I think what I said makes sense

Quote from NiTRo_SvK :

The ideal line could be disabled by turning on FCV (Forced cockpit view), but TC not...

I'm not sure about that...

PS: And the "4 key line" being ideal is highly questionable

Quote from dawesdust_12 :

Kinda OT, but that Code::Blocks program seems to be very nice. Seems more versatile than Visual Studio. Nice find

What does OT mean?

Btw, I found Code::Blocks here in this forum, in TAA's C InSim tutorial.

I started using InSim with TAA C tutorial and built my own C++ library for using InSim. This library is now complete and I have written a couple of examples using it.

Although it's a library and stuff, it's still pretty basic, so it's more like a tutorial library than anything. Some people might want to give it a try and have a look at the examples provided. It is basic C++, just a simple class and the basics of InSim covered.

As I have already posted the files in other threads, I'll post just a link to the CInsim library thread, where you can find the links to both examples: http://www.lfsforum.net/showthread.php?t=47717

Quote :

Changelog:

UPDATE:
I haven't updated the library or been keeping track of InSim changes since January 2013. Forum member denis-takumi has created a repository on github.com that might be more stable and up to date than the files in this post. Check it at: https://github.com/turbosnail/cinsim

I have been off from LFS for a long time now and I'm not sure if I'll be back, but I receive email notifications of private messages and replys in this thread. I'll drop by to update whatever I can in the first post when I have time.

0.7 (Thanks to MadCatX for major improvements in this version)

• Supports all new InSim changes introduced as of LFS 0.6C.
  
• 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().
  
• Got rid of 100% CPU load caused by next_packet() on Linux systems by replacing select() for pselect() (other *NIX systems that use their own standard C library might exhibit a different behavior).
  

0.6

• Added support for *NIX platforms. You only have to change in the insim.h file the "#define CIS_WINDOWS" preprocessor directive to CIS_LINUX, and you are ready to compile the lib under UNIX/Linux with the exact same functionality. (Portability code provided by MadCatX)
  
• The additional function mstrostr() only uses ANSI-C functions now to ensure platform portability. All the occurrences of itoa() have been replaced by sprintf().
  

0.51

• Fix for the send_button() method. Now it's thread-safe, there was a small typo in one line.
  
• The additional function mstrostr() has been renamed to ms2str() and now has an optional third parameter to indicate if the resulting string will contain hundredths of second (default) or thousandths of second.
  

0.5

• New method called send_button(), used to send BTN packets of variable size. Up until now button packets were always 240 chars long in the text field, thus producing a big network overhead when a lot of buttons were sent. Now you have to create a button struct and fill it to your desire. The send_button method calculates the text length and only sends the appropiate amount of data. It also refills the 'Size' field of the struct based on the text length so you don't have to worry about that.
  
• Fix for the thread-safe send_packet() method. Actually, it was supposed to have been updated in the V0.4 but it never was because I didn't add a couple of lines... Now it's suppossed to be working fine.
  

0.4

• Now uses pthreads-w32 for thread-safe send_packet() method (several threads can use safely the send_packet() without overlapping). Before it had to be controlled by the application programmer.
  

0.31

• Adds all changes done to insim as of LFS S2 0.5Z28
  

0.3

• First stable version.
  

I started using InSim with TheAngryAngel C tutorial and built my own C++ library to use InSim. This library is now functional and stable. The library is called CInsim and it's meant for writing simple C++ InSim applications. It was originally written for Windows but UNIX/Linux portability was added in v0.6.

Most of the work must be done "manually". Creating and sending packets, multi-threading when needed and other stuff is responsability of the programmer. This library uses InSim as-is, and reading the insim documentation is a must when you have to manage packets.

What the library offers you is the basics of communicating with InSim:

• Establishing the connection to InSim (full TCP, full UDP, TCP+UDP), and using all possible parameters accepted by InSim IS_ISI (initialization) packets.
  
• Keeping the connection always alive.
  
• Keeping the packets coming one at a time.
  
• Peek the type of the next packet, so you know if you have to process it or skip it.
  
• Return the contents of the next packet so you can process it (in case it was one of the types you wanted).
  
• Send packets via the main connection (thread safe since v0.5).
  
• Send size trimmed button packets via the main connection (thread safe since v0.51)
  
• Close connection to InSim.
  
• There's also a function to convert miliseconds to a C string (this is an independent function).
  

You must cast the contents of the packets to a certain InSim packet struct to access the fileds. This is shown in the working examples linked below.


EXAMPLES:

Note1: Some of these examples don't use the latest version of CInsim, so if you are going to work on your own project, be sure to grab the latest version in this thread.

Note2: These examples might use functions that aren't ANSI-C defined, so maybe you won't be able to compile them right away under UNIX/Linux, sorry.

I have posted three examples using this library, so I'll link to them instead of uploading the same files again:

CInSim V0.7:

• Event Control: (Note: This was previously released using CInsim 0.6, but has since been updated to 0.7) This application is an event manager (it's server oriented). It was originally designed to enforce HARDCORE qualify sessions, in which the use of Shift+P and Shift+S is forbidden, so people can only do realistic pitstops. The current version allows the use of Race Directors, appointed by adding their lfs usernames in a text file, who can do more stuff to manage an event (restarting, ending, auto-reversing top grid drivers, director chat messages, etc.). http://www.lfsforum.net/showthread.php?p=1403034
  

CInSim V0.3:

• LFS Session Timing: This application shows sector times and time differences to the session best when you cross a checkpoint. It uses buttons, independent threads for button timers and some interesting stuff. http://www.lfsforum.net/showthread.php?t=46643
  
• X-Y-Z Positioning: This application shows the coordinates of your car and the name of the closest player to your position. Of course, more than one car must be online for a name to show up! It uses TCP for main connection and UDP for MCI packets.http://www.lfsforum.net/showthread.php?t=47675
  

The examples use the CInsim library (of course) and already come zipped with all the required files to compile and even an executable if you can't compile them. Also, code::blocks project files are provided for each example.

Last edited by MaKaKaZo, Mon 25 Aug 2014, 10:19. Reason : updated version

Quote from the_angry_angel :

The thread is open, so there's nothing stopping you from posting in it?

I'm very respectful and always ask for permission before intruding into a sticky I'll post both apps later.

SMALL UPDATE (2008-08-29):

The CInsim library was replaced with a newer version.


X-Y-Z POSITIONING v0.1

This is another application/tutorial I've written in basic C/C++ using my "CInsim" library. This time I have updated the library to support InSim TCP+UDP connection. The previous application I made can be found here: http://www.lfsforum.net/showthread.php?t=46643

All the source code is provided, of course, as well as a code::blocks project file

This application retrieves MCI packets every second and shows to each player his coordinates and the closest car at any moment while they are on track.

It provides a lot of information through the console so it's nice if you want to know what is happening and what packets are being received/what actions are being taken.


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 a welcome message should appear. You can be in the server when the application starts, but be warned that the first thing it does is end the current race/session.

Start running!


PS: I'd like these small apps I'm doing to be linked somewhere in the "My first InSim Application" thread or something like that.

Last edited by MaKaKaZo, Fri 29 Aug 2008, 09:48.

Quote from bukhem :

Hi.

I currently wonder how I can get a list of players that is currently connected.
I'm writing a small app that keeps track of lap and split times and therefor would need a list of existing players when it connects to the LFS-Client.

Thanks for your help.

Greetings.

This is a generic answer, not JInSim specific. As stated in the insim documentation, at any time you can request info about all connections and players sending an IS_TINY, with the following values (marked in red) in the field SubT:


With TINY_NCN the server will send an IS_NCN packet for each of the connections present (UCIDs).

With TINY_NPL the server will send an IS_NPL packet for each of the players present (PLIDs).

If you are keeping track of both connection IDs and players IDs (you should), you must do both.

Quote from Dygear :

Splits in AutoX do generate SPX packets.

Then what SecondSkin is asking can be done. The thing is that he would need to give an accurate description of what he wants and how he's planning to use it, then maybe someone can pick the project.

Quote from SecondSkin :

Posted this on the autox forum, but didn't get any response. Thought I'd try it here:

Is there any way to add minimum speed to autocross checkpoints (on any track), like is done in the LFS training modules? In the braking module, for instance, you can complete the course but you get a warning that your speed was too low and your time doesn't count. Is there any way to do this with a standard autox layout?

I guess this can be done with an InSim application. I don't know how autox checkpoints work... are they like normal track sector checkpoints? If so there's the chance that when a player crosses an autox checkpoint an IS_SPX packet might be sent. If that's the case then you can request an IS_MCI in which you can check the speed at that checkpoint.

There's also the possibility to check the speed at all times requesting MCI packets every second or so. If SPX packets are sent at checkpoints like I say above, then you can even set different minimum speeds for each sector of the layout.

Quote from Dygear :

Learn something new everyday Thanks for that . So I take it that if there was only one car on track, then you would get one MCI packet, with the info value of 192? And while this information will give the ammout of players in the MCI packet, it will not give you the overall players. (Correct?)


<?php 
if ($MCI[0]->ComCar[0]->Info = CCI_FIRST & CCI_LAST AND $MCI[0]->ComCar[0]->Position != 1) {
    # There is only one player in the race, and that driver is not first!
    # EPIC ERROR: PACKET ERROR, InSim ERROR, OR PROGRAM ERROR!
}
?>



Well, it gives enough info to know when a sequence starts and ends I didn't know about that either.


Good news guys: I managed to solve the UDP problem. As I thought it was a newbie mistake and some nice guy at www.codeguru.com helped me out checking my code.

The problem was that I wasn't binding the UDP socket to my local port. I mean, I specified that I wanted to use udpport 60000 and the server was sending packets to that port, but I never told my socket to listen on THAT port. I only told it to listen for incoming packets from IP x.x.x.x and port yyyy (the server's insim port).

So, when I use connect on the UDP socket without binding it previously to any specific port, it prepares a random port assuming that I'm going to start the communication (which I'm not). So, if I want to listen on a specific port I have to bind the socket first to my IP and port 60000 (the one I selected), and then use "connect()". That way my socket is prepared to listen on the desired port and not a random one.

I know most of you don't give a damn, but maybe someone that reads this will find it useful in the future. I'll be posting some example on car coordinates via UDP probably next week.

I'm trying now in a whats looks to be a nice forum for coders. If I get to solve it I'll post what was failing so people can laugh at my *probably* stupid mistake

Just forget the racism stuff and play the game, stop the racism discussion now please.

Would a name like "destruction checkers" fit better? The colours are already chosen and I don't know other words for white and black that are not racist. It's game made up by some spanish guy and I'm sure that he wasn't thinking about "negro" having racist connotations in English. I wasn't either when I posted the thread. Actually I've tried to change people's mind to make blacks->reds because black cars are harder to spot in the distance, but people still prefer black because they're opposite colors ans it's like checkers.

Dudes it's Spanish and we are talking about CARS!!!

Blancos = coches blancos (white cars)
Negros = coches negros (black cars)

There's no need to look for controversy in every word and less when it's a foreign language.

Btw, I've been on the black team every time because I like the black car better and I'm a winning streak, undefeated yet so... NEGROS FTW!!!

In Spain there's a much higher chance that people wouldn't want to be in the "blancos" team because it's Real Madrid (soccer team) color and there're a lot of Barcelona supporters that don't stand "being white", rather than people not wanting to be in the "negros" team for racism issues.

Last edited by MaKaKaZo, Tue 19 Aug 2008, 22:48.

Hi guys! We've playing this blacks vs whites game for a couple of days now and just wanted to share the idea with all the community as it's a hell of fun!

First of all, this is not about a new "crash everyone server" or anything like that. We're a bunch of racers that just finished the current league season and right now we are spending some time fooling around to break with the training/racing routine.

The game is played between two teams with like 4 to 8 players each: blacks and whites. Whites use white car/white nickname, and blacks use black car/red nickname (black nicknames are harder to read).


The server is set to:

- Cruise ON (wrong way is a must).
- Small track (around 1 minute per lap).
- A few laps (3 or 4).


The only rule is: the team that gets a car to complete all laps win a point. The only thing that matters is who wins the race. Everything is allowed: speeding on pits, skipping the starting lights... everything!

When a team wins they add it to their score at the end of their nicknames (just to keep track of the score). A score limit is set so the first team to reach that score wins.

The use of TS/ventrilo is strongly recommended but you can play without it if you master the basic strategies.

Basic strategies are learnt quickly after some rounds, like quickly going to pits and rejoining when the other team runners are about to start a new lap so you catch with them as you exit the pits and then you have a good attack chance at the first corner. There're tons of tricks.

We don't prepare team beforehand unless there are majority of people from one team and they have their own TS server. Usually people randomly connect and join the team with less drivers/less points to have teams as balanced as possible.

I attach a replay of today's last round. The race is pretty lame in the beginning as blacks start pretty bad. As you guess there's no driving skill needed to play this, most of the time you don't need/shouldn't follow a proper line. But most of all... you are really not going to give a damn about driving properly

The awesome highlight of that replay is the last lap, as whites have three guys on lap, aiming to finish and blacks have only one but far away in the back. The rest of the blacks perform an amazing defense crushing all three white cars in the last corner/straight and they manage to win.

Believe me, this game is a lot of fun. I'm not a cruiser or a drifter, I'm a good old hotlapper/racer, but every once in a while these kind of games are really fun.

Last edited by MaKaKaZo, Tue 19 Aug 2008, 22:36.

Quote from Dygear :

InSim.txt Patch Z

struct IS_MCI // Multi Car Info - if more than 8 in race then more than one of these is sent
{
byte Size; // [B]4 + [U]NumP[/U] * 28[/B]
byte Type; // ISP_MCI
byte ReqI; // 0 unless this is a reply to an TINY_MCI request
byte NumC; // number of valid CompCar structs in this packet

CompCar Info[8]; // car info for each player, 1 to 8 of these (NumC)
};

I am guessing that's an error, meant to say NumC. But, with the MCI packets by them selves there is no way to find the amount of players in the race just by using the MCI packet. The only information it will give is the number of CompCar structs in the packet. So you will not know if you still have more coming. (Unless the number is less then eight of course, then that's the last packet, for the sequence.)

That's an interesting point. I haven't checked, but if it's really NumP as in all the players, then you don't know the size of that packet if there are more than 8 players. If it's to mean NumC then there's the possibility that the number of players is a multiple of 8 and you won't know which packet is the last of the sequence.

Anyway, you can always track the number of players connected at any given time so you wouldn't have problems. But that's right, you'd have to use more logic than just the info provided in the MCI packets.

Subliminal PS: Someone help me with the UDP stuff XDDD

Quote from the_angry_angel :

UDP is sent a packet at a time, so unlike TCP (which is a stream) you don't have to worry about having partial packets, and having to have a global buffer, etc.

Totally right, hadn't thought about that. BUT, now that I think about it... if there's more than 8 people driving then multiple IS_MCI packets are sent "at the same time". That would cause problems, wouldn't it?

Last edited by MaKaKaZo, Tue 19 Aug 2008, 10:15.

After some more testing, sniffing and stuff I've checked that the UDP packets are actually being sent, at least when I connect to a remote server.

My problem right now looks evident: the "select()" call for the UDP socket is not working. It times out and does not receive anything at all as it should (as I've checked that the info is being sent).


If I use only ony socket everything goes fine, but when I set up a second socket (in this case for the UDP packets) it won't receive anything.

I'm using two independent select() calls, one for each socket, and I don't know if that may be causing all the trouble. I'll post some code now.


This is the class delcaration:


This is the code used for establishing/connecting the two sockets and the connection to InSim:
(any var used not defined here is because it's a private member)


Here's the code for retrieving TCP packets. This seems to work fine in all cases:


And here's the code for retrieving UDP packets. This is the function that is giving me problems:


I'm not sure if I'm doing something wrong with the sockets. If anyone is willing to check the code to help me I can provide tha full example and library code, executables, dlls and whatever you might want to give it a try.

Now that I'm not getting any help I'm wondering if anyone is currently using this TCP+UDP feature in InSim4 or everyone is just using full TCP for main and NLP/MCI packets in their applications.

Based on all the tests I've done I've come to the conclussion that the problem is in the InSim interface/reference or the server code, but not in my code. Let aside grabbing the UDP packets, it just seems like the server won't send the packets at all.

So, is someone currently using TCP+UDP???