Indeed you should be able to use the Gateway module included in RaceManager (http://lfs.marcoz.org ). It hasn't been updated in a while, but it should still work just fine.
If you're using Python, you might be interested in Race Manage: http://lfs.marcoz.org , which is Insim only, but you can probably inspire yourself with it, especially structs and stuff.
In your resulting program, you're not actually using the language, but the compiled code that was generated by each language compiler (usually as DLLs, in some sort of "machine language"). These can interoperate.
From memory:
numnodes: 477 // Number of nodes for the whole track
finishline: 431 // Node number where the finish line is in the current track config
node 1:
centre X=19.59 // Position of Node 1 in the World coordinates
centre Y=550.94
centre Z=10.09
dir X=0.02 // Vector giving the orientation of the node in the world coordinates
dir Y=1.00
dir Z=0.00
limit left=-23.67 // Distance from the center point to the outer edge of the driving area (usually the wall), on the left side
limit right=28.65 // same distance on the right side
drive left=-1.45 // Distance from the center point to the outer edge of the actual paved track, on the left side
drive right=18.80 // same distance on the right side
numnodes: 477 // Number of nodes for the whole track
finishline: 431 // Node number where the finish line is in the current track config
node 1:
centre X=19.59 // Position of Node 1 in the World coordinates
centre Y=550.94
centre Z=10.09
dir X=0.02 // Vector giving the orientation of the node in the world coordinates
dir Y=1.00
dir Z=0.00
limit left=-23.67 // Distance from the center point to the outer edge of the driving area (usually the wall), on the left side
limit right=28.65 // same distance on the right side
drive left=-1.45 // Distance from the center point to the outer edge of the actual paved track, on the left side
drive right=18.80 // same distance on the right side
If I remember correctly the way I did it in the RollingStart module of RaceManager (it's been a long time, forgive my failing memory), you'd need to:
- compare the lap number
- compare the nodes (I determined the node of the start/finish line by using the node the first car starts from at race restart)
- if 2 cars are on the same node, calculate the distance between the 2 cars projected on the axis of direction of one of the cars.
This is definitely not perfect, as the node for the start/finish might not be quite accurate (1 or 2 nodes off), and that the cars travel fairly straight (for distance comparison). This works fine for rolling start, since they are all on lap 1, and going at a reduced speed. For a full race, you might have some small errors for like a second, in case a car spins, or close to the finish line.
And to answer Dygear's questions (although I wasn't included in his list):
What is your programming languages of choice?
Python
What programming languages do you know?
Python, Java, PHP (and a few others, like C/C++, Perl when I've got no other choice).
What do you use the most as your text editor for programming?
Vi
What IDE do you use, if any, and if you don't do you have problems with them?
None, usually
What is your compiler of choice, for your primary programming language?
No compiler for Python
What libarys do you recomend for your primary programming language?
Just about everything is included with Python. A few specialized libraries can be used, but rarely.
Anytime. Glad to hear you got it to work.
You would need to keep an updated table in your program with the Usernames/Player names, associated with the ID of the player, so you can do a lookup when an interesting packet references this ID. This would be done by adding to the list when you receive a new non-existing NPL packet, and removing from the list when receiving a PLL packet.
If you want to refresh the table at some point (like when you start your program), send a STA packet to get the number of players, and then ask for new NPL packets.
If you want to refresh the table at some point (like when you start your program), send a STA packet to get the number of players, and then ask for new NPL packets.
Most likely cause is a Firewall that is preventing RM to send messages back to the LFS Server, thus the packets never get acknowledged, and eventually the connection times out.
In the RM folder, there is a pynsim.log file which might give you more information (if you don't quite understand, delete it, do your testing, and send me by private message the new one that is generated).
In the RM folder, there is a pynsim.log file which might give you more information (if you don't quite understand, delete it, do your testing, and send me by private message the new one that is generated).
Indeed, the site is down, and I haven't taken the time to switch it over to somewhere else.
You can download the python version here though:
http://www.marcoz.org/RaceManager-Oct12.zip
You can download the python version here though:
http://www.marcoz.org/RaceManager-Oct12.zip
Indeed, RM does not have a great graphical interface. But after all, it was made to be used on a server without a graphic card 
.
As for configuring the Gateway mod, once RaceManager actually starts and connect, you need to:
- edit RaceManager.cfg
- go to the Gateway section
- enter a free "insim" port, and a password (this port and password is what your other insim applications need to use in their settings. Instead of connecting to the LFS Server, they need to connect to the Gateway to this port and password)
- restart RM
- start the Gateway module
For each insim app you want to use:
- configure your other Insim app to use the new "insim" port and password (from the Gateway config)
- start your app
All the insim apps i've tried this way actually worked correctly, but I haven't tried with PitSpotter or Ghost car mod.
If someone feels like repackaging all that to be easier to install, feel free to do so.
.As for configuring the Gateway mod, once RaceManager actually starts and connect, you need to:
- edit RaceManager.cfg
- go to the Gateway section
- enter a free "insim" port, and a password (this port and password is what your other insim applications need to use in their settings. Instead of connecting to the LFS Server, they need to connect to the Gateway to this port and password)
- restart RM
- start the Gateway module
For each insim app you want to use:
- configure your other Insim app to use the new "insim" port and password (from the Gateway config)
- start your app
All the insim apps i've tried this way actually worked correctly, but I haven't tried with PitSpotter or Ghost car mod.
If someone feels like repackaging all that to be easier to install, feel free to do so.
For the flags, it refers to the actual bits (1 or 0) within the byte, not the decimal value. So:
0: no shift or ctrl pressed (in binary 00)
1: SHIFT (in binary 01)
2: CTRL (in binary 10)
3: SHIFT+CTRL (in binary 11)
And to determine the state, the only way I can see would be to send 2 such packets quickly, and parse the output. Not very elegant though.
0: no shift or ctrl pressed (in binary 00)
1: SHIFT (in binary 01)
2: CTRL (in binary 10)
3: SHIFT+CTRL (in binary 11)
And to determine the state, the only way I can see would be to send 2 such packets quickly, and parse the output. Not very elegant though
.Yes, a few of the packets were changed, in particular the RES one. The total size of the packet didn't change, but the fields inside did somewhat.
I think your error is here:
It should be Array[0..3], it's 1 Char too big, meaning you're shifting all the values later on. So, you were indeed reading the NumResults value, instead of the VerifID.
It should be Array[0..3], it's 1 Char too big, meaning you're shifting all the values later on. So, you were indeed reading the NumResults value, instead of the VerifID.
As mentioned in the doc, Z is the vertical axis.
X and Y are 2 axes on the ground, independant of the car (world axes)
It's been a while, but i'll try to answer:
1. UniqueIDs do not change if someone leaves the race (unlike PlayerNum). I don't think there is any guarantee to get the same ID should someone leave and then come back. In such a case, your program should update its list when it receives the NPL packets.
2. Your description is correct. It is possible that the UDP packets gets out of sync. To check for this, you can verify the Total field of the CNL packet. If it is different than OldTotal-1, then more than 1 left the server. In this case, you would have to ask for new NCN packets for everyone (loop for 1 to n, send ("NCN",x) ).
1. UniqueIDs do not change if someone leaves the race (unlike PlayerNum). I don't think there is any guarantee to get the same ID should someone leave and then come back. In such a case, your program should update its list when it receives the NPL packets.
2. Your description is correct. It is possible that the UDP packets gets out of sync. To check for this, you can verify the Total field of the CNL packet. If it is different than OldTotal-1, then more than 1 left the server. In this case, you would have to ask for new NCN packets for everyone (loop for 1 to n, send ("NCN",x) ).
Glad you like the program . That's correct, it uses a /car and a /track admin command to set the car and track. Just set it in the config file as you would as an admin.
I haven't updated RM in a while, mostly because it still works even after all the updates, including S2. If there are issues with it, just let me know.
It is not a program geared towards "players", it's made for server admins. So, if you want to use it, you need to set up your own server using the dedicated host you pointed to.
. That's correct, it uses a /car and a /track admin command to set the car and track. Just set it in the config file as you would as an admin.I haven't updated RM in a while, mostly because it still works even after all the updates, including S2. If there are issues with it, just let me know.
It is not a program geared towards "players", it's made for server admins. So, if you want to use it, you need to set up your own server using the dedicated host you pointed to.
You pay mostly to get Point2Play, which is their pretty interface to configure, start games, and updates Cedega/WineX very easily. Then you get support, and some votes to determine what are the next supported games.
If I remember correctly, in S1, the problem was a few missing registry keys in the Cedega registry. IIRC, the solution was to import the Wine registry into the Cedega registry, or something of the sort. I believe it causes problems with S2 though if you bring the whole registry, but might be worth a try. Some trial and error might help in determining exactly which sections of the Wine registry you would need.
If I remember correctly, in S1, the problem was a few missing registry keys in the Cedega registry. IIRC, the solution was to import the Wine registry into the Cedega registry, or something of the sort. I believe it causes problems with S2 though if you bring the whole registry, but might be worth a try. Some trial and error might help in determining exactly which sections of the Wine registry you would need.
I get pretty good performance on Cedega 4.4.1, about 50fps (about 25fps with a full field of AI in front of me), perfectly playable. Nvidia 6600GT, on Gentoo. My only problem is the huge weird deadzone with the wheel, just can't get rid of it whatever I try. It's the only thing that is installed on my Win partition now...
Last edited by Silkswift, .
That's correct oper@tor. I didn't mention it like this though, because I didn't want to give too many details on how to "cheat" .
.@Bruce: It's true, it's probably not best to change the protocol for this, but using a 0, or the max possible value to warn that the lap time went over would be possible without changing the protocol at all.
@operator: The example I gave is obvious to detect, and can be ruled out very easily. However, there are cases where all the splits appear normal (go through SP1 just after the time goes back to 0), and can't be ruled out.
Also, it does happen mostly on the lap out of the pits, but it could happen as well on a flying lap. In any case, I don't think there is any way to detect it consistently without the server actually notifying Insim of it.
@operator: The example I gave is obvious to detect, and can be ruled out very easily. However, there are cases where all the splits appear normal (go through SP1 just after the time goes back to 0), and can't be ruled out.
Also, it does happen mostly on the lap out of the pits, but it could happen as well on a flying lap. In any case, I don't think there is any way to detect it consistently without the server actually notifying Insim of it.
SPX and LAP packets for laps longer than 256 minutes
It seems like the lap time counter resets to 0 once it reaches 256 minutes. This causes a problem with the Qualif mode of RaceManager, with the server set on Practice. People are allowed to race as many laps as they want, and RM tracks the best laps for everyone set on the server for a whole week. But, when spending some time in the garage, the timer can often be close to or over this limit.
Since S2, we've seen a few laps such as:
SP1: 255:05.62
SP2: 255:27.41
Lap time: 0:02.04
This example is quite obvious, but there are times that would be a lot harder to detect.
Would it be possible to increase the maximum number of minutes, or having Insim sending a LAP error message of some sort (or set the lap time as 0:00:00 or 255:99:99), as well as resetting the timer when someone exits the garage (I think that's when it happens)?
Since S2, we've seen a few laps such as:
SP1: 255:05.62
SP2: 255:27.41
Lap time: 0:02.04
This example is quite obvious, but there are times that would be a lot harder to detect.
Would it be possible to increase the maximum number of minutes, or having Insim sending a LAP error message of some sort (or set the lap time as 0:00:00 or 255:99:99), as well as resetting the timer when someone exits the garage (I think that's when it happens)?
FGED GREDG RDFGDR GSFDG