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.
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?
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.
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.
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.
I'm a coder myself and I can say that should be no big deal at all for the devs of the X-System.
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.
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?
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
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!
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.
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
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
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
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.
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.
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.