The online racing simulator
Searching in All forums
(473 results)
MaKaKaZo
S2 licensed
Quote from Furiously-Fast :Oooh yes, remove number plates, then replace window plates with names and Contry flags, big +1!

I liked this one too.

Of course, I'd leave plates in road cars.
MaKaKaZo
S2 licensed
I'm surprised that just one person said this...

I'd change it, but not just because it's a dangerous place for cutting and getting damage, and ruining nice hotlaps, but because if considerable braking would be needes in this corner it would be one of the coolest overtaking points in the track. Right now you can get another car slipstream going into the oval, and when you reach that point side to side it's the moment to pray that you'll end up alive. With a real chicane and people having to do full braking it would be great

An there's more, having it slower would mean that a good corner exit could provide again a better braking battle in the next hairpin than right now.
Last edited by MaKaKaZo, .
MaKaKaZo
S2 licensed
Quote from Christofire :Suggestions are always good. Sometimes I just get a little frustrated that we can't get everything in there.

I have some more suggestions, but some of them but be harder and other might have been suggested tons of times. Is there anything like an official CTRA suggestions thread anywhere?
MaKaKaZo
S2 licensed
Quote from N I K I :@layout:
I just tried that layout on server and IMO that pylon is too close at chicane exit.

Here's a pic of MoE rules in this corner and as they're really close I'd be really nice if you guys both use same rules, so we don't have to practice two different lines thou there, because to practice up a line in that corner takes ages
http://www.lfsforum.net/attach ... id=40185&d=1190917380

I agree with the first but not with the second. The green part should not be used as track, but just the painted kerb itself.

Anyway, I haven't tried the layout but I have seen it and I think that the second corner pylon is still too much on the inside, even if you keep the inner tyres wihtin the kerb (not the green area) you might still hit the pylon with the front of the car.
MaKaKaZo
S2 licensed
I liked the video, but after a while it becomes repetitive. All the takes are pretty much the same thing but with different cars in different tracks. It's just a lot of cars going through corners at the same time. It looks like a movie made entirely from first laps. You finish it with "this is Live For Speed", but there's a lot more to LFS than that. On the other hand, I liked the camera work and the edition.
MaKaKaZo
S2 licensed
Quote from Mp3 Astra :But I did get the gist of it by the end of the 3rd episode.



I'm up for Spanish accent roles for the next movie, if there's a next
MaKaKaZo
S2 licensed
Quote from Christofire :Having a little forewarning of the next track is something we can look at, but I don't think it's a priority to retro-fit into the current system.

A suggestion is just a suggestion, not a demand. Just consider it and put it on the to-do list if you like it
MaKaKaZo
S2 licensed
Quote from pacesetter :I have just downloaded all setupgrids' setups. That way I can change quickly and be ready for the next race

As I said, with setupgrid's contests there have been a lot of setups submitted there that are not very good. Speaking of the XFG, that is an easy car for experienced drivers, I (and I'm sure everyone) can usually do 3~4 tenths of a second better with some setup from my team (might not be even a good one for my driving style) than with one downloaded from setupgrid.

Quote from J@tko :Im pretty sure the next track is chosen randomly after the race ends, so doing this would require a re-code.

I'm a coder myself and I can say that should be no big deal at all for the devs of the X-System.

Quote from Toddshooter :Do we really want the newest drivers on the WR sets?, or do we want them to learn on a nice stable set that isn't so twitchy?
I vote for the stable set for close racing.

I want the newest drivers to drive clean, I don't mind which sets they use. Usually they have WR sets because they are always asking the fastest guy in the server "can I have your set plz?" and most people always send their sets. So, let them learn with whatever sets they want, that is not the point of my suggestion, but a pack of sets for fast drivers, so they can have good duels close to record times. Remember that not all CTRA servers are Race1 and SS1.
CTRA servers setup packs (and suggestions)
MaKaKaZo
S2 licensed
Hi, lately I'm having a go at the CTRA servers (mostly Race1 as it's the most crowded one) and as it happened to me in the past I usually miss the first race when there's a track change because I have to go and download a setup for that track @ setupgrid or inferno.

Well, that's solved after some time because you get to gather all setups needed, but it's a bunch of combos you need to collect.

As a first suggestion, it would be nice to have the next track in the rotation shown in the $track command, so you can go look for a set for the next track beforehand. That would be very nice.

Other thing I've thought is if anyone would be interested in opening a project aimed to collect setups for all CTRA combinations by servers. And I mean FAST setups. I've downloaded some setups from setupgrid that are easy to drive but can't get close to record times, and it's a bit frustrating.

It would be great if someone would be interested in creating setup packs for every CTRA server that can be downloaded directly from the CTRA website, or in collaboration with setupgrid or other site. These packs wouldn't be a starting point for beginners, but packs for fast drivers to achieve excellent laptimes.

I can provide some setups, and we would need some *really* fast drivers to test them in sprint races. It'd surely take some time, but it would be great, don't you think so?
MaKaKaZo
S2 licensed
There's no way I would ever get that much of the storyline down by just watching the movies

For the next one you could try and make something with a script easier to follow to non native English speakers so we know what's going on
MaKaKaZo
S2 licensed
I think the plot is a little confusing. I don't know if I like this or not but I'd definitely watch more episodes because even if you don't get all the action it's still very entertaining

Shame it's over
MaKaKaZo
S2 licensed
Average movie, it wasn't worth downloading 100MB
MaKaKaZo
S2 licensed
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
MaKaKaZo
S2 licensed
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
MaKaKaZo
S2 licensed
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?
MaKaKaZo
S2 licensed
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, .
MaKaKaZo
S2 licensed
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
MaKaKaZo
S2 licensed
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
MaKaKaZo
S2 licensed
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.
C++ tutorial (CInsim library)
MaKaKaZo
S2 licensed
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
C++ - CInsim - A basic C++ InSim library (for Windows & UNIX/Linux)
MaKaKaZo
S2 licensed
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, . Reason : updated version
MaKaKaZo
S2 licensed
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.
C++ / X-Y-Z Positioning (application/tutorial)
MaKaKaZo
S2 licensed
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, .
MaKaKaZo
S2 licensed
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:

enum // the fourth byte of IS_TINY packets is one of these
{
TINY_NONE, // 0 : see "maintaining the connection"
TINY_VER, // 1 - info request : get version
TINY_CLOSE, // 2 - instruction : close insim
TINY_PING, // 3 - ping request : external progam requesting a reply
TINY_REPLY, // 4 - ping reply : reply to a ping request
TINY_VTC, // 5 - info : vote cancelled
TINY_SCP, // 6 - info request : send camera pos
TINY_SST, // 7 - info request : send state info
TINY_GTH, // 8 - info request : get time in hundredths (i.e. SMALL_RTP)
TINY_MPE, // 9 - info : multi player end
TINY_ISM, // 10 - info request : get multiplayer info (i.e. ISP_ISM)
TINY_REN, // 11 - info : race end (return to game setup screen)
TINY_CLR, // 12 - info : all players cleared from race
[COLOR=Red] TINY_NCN, // 13 - info : get all connections
TINY_NPL, // 14 - info : get all players[/COLOR]
TINY_RES, // 15 - info : get all results
TINY_NLP, // 16 - info request : send an IS_NLP
TINY_MCI, // 17 - info request : send an IS_MCI
TINY_REO, // 18 - info request : send an IS_REO
TINY_RST, // 19 - info request : send an IS_RST
TINY_AXI, // 20 - info request : send an IS_AXI
TINY_AXC, // 21 - info : autocross cleared
};

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.
MaKaKaZo
S2 licensed
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.
FGED GREDG RDFGDR GSFDG