Um, I've been an utter forum ninja as I stealth updated my post before you posted. Sorry! 
It looks to me like a concurrency issue caused by multiple threads updating the QueueHolder at once (most likely multiple timer threads). That's the only way I can account for the QueueHolder.Count being zero in that screenshot. I didn't notice that the first time I looked at it, sorry.
The question is then, do you have any timers or other threads that manipulate the QueueHolder variable?
It looks to me like a concurrency issue caused by multiple threads updating the QueueHolder at once (most likely multiple timer threads). That's the only way I can account for the QueueHolder.Count being zero in that screenshot. I didn't notice that the first time I looked at it, sorry.
The question is then, do you have any timers or other threads that manipulate the QueueHolder variable?
Last edited by DarkTimes, .
Edit: Ignore previous post.
Actually I see now that it says the QueueHolder.Count == 0 in the debug info. Can I ask, do you have a lot of timers or other threads running in your code? It looks like this might be a concurrency issue and another thread might be updating the QueueHolder between the Count > 0 check and where you index into it. The method in the screenshot is obviously not atomic and none of the .NET generic collections are thread-safe by default. Presuming that Dizplay does not modify QueueHolder, it looks like another thread must be causing the issue.
Actually I see now that it says the QueueHolder.Count == 0 in the debug info. Can I ask, do you have a lot of timers or other threads running in your code? It looks like this might be a concurrency issue and another thread might be updating the QueueHolder between the Count > 0 check and where you index into it. The method in the screenshot is obviously not atomic and none of the .NET generic collections are thread-safe by default. Presuming that Dizplay does not modify QueueHolder, it looks like another thread must be causing the issue.
Last edited by DarkTimes, .
Great thanks, that causes the bug for me. You don't need all those packets by the way, just hook up an MSO handler that sends any messages received back to LFS. 
I'll look into the exact cause later.
I'll look into the exact cause later.
Is the guy with this name on your server, or do you have a replay with his name in it? I can't seem to figure this out, I need some debug info (a replay would be ideal).
The place where this error occurs is not where I would expect, it seems likely to be the symptom of an error somewhere else, but to find that place I need more information.
The place where this error occurs is not where I would expect, it seems likely to be the symptom of an error somewhere else, but to find that place I need more information.
Last edited by DarkTimes, .
Try this version and see if it works any better.
Edit: removed.
Edit: removed.
Last edited by DarkTimes, .
What's the exception that gets thrown? Also does the error occur when receiving a string or sending a string?
Last edited by DarkTimes, .
Just a reminder that you can attach an event to InSim.InSimError to see if any background exceptions are being thrown. You can also look at the Debug > Windows > Output window, as background exceptions are dumped to the debug output as well (handy for copy/paste). The packet handlers are called from a background thread so any exceptions thrown in the packet events will only get picked up by InSimError, that is if you don't catch them yourself.
Last edited by DarkTimes, .
I uploaded a changset with a fix for the MTC bug.
In terms of the BTT packet, it works fine for me, that packet hasn't changed as far as I'm aware. I don't understand why it would fail after 6 players are on the server and I don't have the ability to test that myself right now.
In terms of the BTT packet, it works fine for me, that packet hasn't changed as far as I'm aware. I don't understand why it would fail after 6 players are on the server and I don't have the ability to test that myself right now.
Hi Scawen,
I noticed that the IS_CON packet does not appear to be sent when playing back multiplayer replays from previous versions of LFS. I'm wondering if this is a bug or just a limitation. They seem to be sent fine when running a replay from Z30, but not for replays from, say, Z13. I don't have any old singleplayer replays lying around to check those.
I noticed that the IS_CON packet does not appear to be sent when playing back multiplayer replays from previous versions of LFS. I'm wondering if this is a bug or just a limitation. They seem to be sent fine when running a replay from Z30, but not for replays from, say, Z13. I don't have any old singleplayer replays lying around to check those.
I've uploaded a new version for InSim 5 to the repository, but I haven't been able to test it yet. My graphics card is broken and these onboard graphics struggle to run Solitaire (seriously), so running LFS is a bit of a pain. I'll see what I can do tomorrow.
Feel free to try it and report any bugs in the meantime and I'll see what I can do (I also accept patches of course).
Note: the update is in the repository, there is no release yet.
Feel free to try it and report any bugs in the meantime and I'll see what I can do (I also accept patches of course).
Note: the update is in the repository, there is no release yet.
Last edited by DarkTimes, .
If anyone is interested here is a diff of InSim.txt showing all the changes.
@@ -13,18 +13,28 @@
// NOTE : This text file was written with a TAB size equal to 4 spaces.
-// INSIM VERSION NUMBER (updated for version 0.5X)
+// INSIM VERSION NUMBER (updated for version 0.5Z30)
// ====================
-const int INSIM_VERSION = 4;
+const int INSIM_VERSION = 5;
-// CHANGES in version 0.5Z (compatible so no change to INSIM_VERSION)
+// CHANGES
// =======
+// Version 0.5Z (compatible so no change to INSIM_VERSION)
+
// NLP / MCI packets are now output at regular intervals
// CCI_LAG bit added to the CompCar structure
+// Version 0.5Z30 (INSIM_VERSION increased to 5)
+
+// IS_CON (CONtact) reports contact between two cars (if ISF_CON is enabled)
+// IS_MTC (Msg To Connection) now has a variable length (up to 128 characters)
+// IS_MTC can be sent to all (UCID = 255) and sound effect can be specified
+// ISS_SHIFTU_HIGH is no longer used (no distinction between high and low view)
+// FIX : Clutch axis / button was not reported after a change in Controls screen
+
// TYPES : (all multi-byte types are PC style - lowest byte first)
// =====
@@ -108,6 +118,7 @@
#define ISF_MSO_COLS 8 // bit 3 : keep colours in MSO text
#define ISF_NLP 16 // bit 4 : receive NLP packets
#define ISF_MCI 32 // bit 5 : receive MCI packets
+#define ISF_CON 64 // bit 6 : receive CON packets
// In most cases you should not set both ISF_NLP and ISF_MCI flags
// because all IS_NLP information is included in the IS_MCI packet.
@@ -179,6 +190,7 @@
ISP_BTT, // 47 - info : sent after typing into a button
ISP_RIP, // 48 - both ways : replay information packet
ISP_SSH, // 49 - both ways : screenshot
+ ISP_CON, // 50 - info : contact (collision report)
};
enum // the fourth byte of an IS_TINY packet is one of these
@@ -188,7 +200,7 @@
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_VTC, // 5 - both ways : game vote cancel (info or request)
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)
@@ -363,8 +375,8 @@
#define ISS_REPLAY 2 // in SPR
#define ISS_PAUSED 4 // paused
#define ISS_SHIFTU 8 // SHIFT+U mode
-#define ISS_SHIFTU_HIGH 16 // HIGH view
-#define ISS_SHIFTU_FOLLOW 32 // following car
+#define ISS_16 16 // UNUSED
+#define ISS_SHIFTU_FOLLOW 32 // FOLLOW view
#define ISS_SHIFTU_NO_OPT 64 // SHIFT+U buttons hidden
#define ISS_SHOW_2D 128 // showing 2d display
#define ISS_FRONT_END 256 // entry screen
@@ -384,7 +396,6 @@
// These states can be set by a special packet :
-// ISS_SHIFTU_FOLLOW - following car
// ISS_SHIFTU_NO_OPT - SHIFT+U buttons hidden
// ISS_SHOW_2D - showing 2d display
// ISS_MPSPEEDUP - multiplayer speedup option
@@ -516,19 +527,19 @@
char Msg[128]; // last byte must be zero
};
-struct IS_MTC // Msg To Connection - hosts only - send to a connection or a player
+struct IS_MTC // Msg To Connection - hosts only - send to a connection / a player / all
{
- byte Size; // 72
+ byte Size; // 8 + TEXT_SIZE (TEXT_SIZE = 4, 8, 12... 128)
byte Type; // ISP_MTC
byte ReqI; // 0
- byte Zero;
+ byte Sound; // sound effect (see Message Sounds below)
- byte UCID; // connection's unique id (0 = host)
+ byte UCID; // connection's unique id (0 = host / 255 = all)
byte PLID; // player's unique id (if zero, use UCID)
byte Sp2;
byte Sp3;
- char Msg[64]; // last byte must be zero
+// char Text[TEXT_SIZE]; // up to 128 characters of text - last byte must be zero
};
// Message Sounds (for Sound byte)
@@ -1013,8 +1024,8 @@
// You can send one to LFS before a race start, to specify the starting order.
// It may be a good idea to avoid conflict by using /start=fixed (LFS setting).
// Alternatively, you can leave the LFS setting, but make sure you send your IS_REO
-// AFTER you receive the IS_VTA. LFS does its default grid reordering at the same time
-// as it sends the IS_VTA (VoTe Action) and you can override this by sending an IS_REO.
+// AFTER you receive the SMALL_VTA (VoTe Action). LFS does its default grid reordering at
+// the same time as it sends the SMALL_VTA and you can override this by sending an IS_REO.
struct IS_REO // REOrder (when race restarts after qualifying)
{
@@ -1259,7 +1270,7 @@
// To receive IS_NLP or IS_MCI packets at a specified interval :
-// 1) Set the Interval field in the IS_ISI (InSimInit) packet (50, 60, 70... 8000 ms)
+// 1) Set the Interval field in the IS_ISI (InSimInit) packet (40, 50, 60... 8000 ms)
// 2) Set one of the flags ISF_NLP or ISF_MCI in the IS_ISI packet
// If ISF_NLP flag is set, one IS_NLP packet is sent...
@@ -1296,7 +1307,7 @@
int Y; // Y map (65536 = 1 metre)
int Z; // Z alt (65536 = 1 metre)
word Speed; // speed (32768 = 100 m/s)
- word Direction; // direction of car's motion : 0 = world y direction, 32768 = 180 deg
+ word Direction; // car's motion if Speed > 0 : 0 = world y direction, 32768 = 180 deg
word Heading; // direction of forward axis : 0 = world y direction, 32768 = 180 deg
short AngVel; // signed, rate of change of heading : (16384 = 360 deg/s)
};
@@ -1328,7 +1339,46 @@
// ReqI : 0
// SubT : SMALL_NLI (Node Lap Interval)
-// UVal : interval (0 means stop, otherwise time interval : 50, 60, 70... 8000 ms)
+// UVal : interval (0 means stop, otherwise time interval : 40, 50, 60... 8000 ms)
+
+
+// CONTACT - reports contacts between two cars if the closing speed is above 0.25 m/s
+// =======
+
+struct CarContact // Info about one car in a contact - two of these in the IS_CON (below)
+{
+ byte PLID;
+ byte Info; // like Info byte in CompCar (CCI_BLUE / CCI_YELLOW / CCI_LAG)
+ byte Sp2; // spare
+ char Steer; // front wheel steer in degrees (right positive)
+
+ byte ThrBrk; // high 4 bits : throttle / low 4 bits : brake (0 to 15)
+ byte CluHan; // high 4 bits : clutch / low 4 bits : handbrake (0 to 15)
+ byte GearSp; // high 4 bits : gear (15=R) / low 4 bits : spare
+ byte Speed; // m/s
+
+ byte Direction; // car's motion if Speed > 0 : 0 = world y direction, 128 = 180 deg
+ byte Heading; // direction of forward axis : 0 = world y direction, 128 = 180 deg
+ char AccelF; // m/s^2 longitudinal acceleration (forward positive)
+ char AccelR; // m/s^2 lateral acceleration (right positive)
+
+ short X; // position (1 metre = 16)
+ short Y; // position (1 metre = 16)
+};
+
+struct IS_CON // CONtact - between two cars (A and B are sorted by PLID)
+{
+ byte Size; // 40
+ byte Type; // ISP_CON
+ byte ReqI; // 0
+ byte Zero;
+
+ word SpClose; // high 4 bits : reserved / low 12 bits : closing speed (10 = 1 m/s)
+ word Time; // looping time stamp (hundredths - time since reset - like TINY_GTH)
+
+ CarContact A;
+ CarContact B;
+};
// CAR POSITION PACKETS (Initialising OutSim from InSim - See "OutSim" below)
@@ -1387,7 +1437,7 @@
byte ReqI; // 0
byte Zero;
- byte ViewPLID; // UniqueID of player to view
+ byte ViewPLID; // Unique ID of player to view
byte InGameCam; // InGameCam (as reported in StatePack)
byte Sp2;
byte Sp3;
@@ -1421,22 +1471,19 @@
float FOV; // 4-byte float : FOV in degrees
- word Time; // Time to get there (0 means instant + reset)
+ word Time; // Time in ms to get there (0 means instant)
word Flags; // ISS state flags (see below)
};
// The ISS state flags that can be set are :
// ISS_SHIFTU - in SHIFT+U mode
-// ISS_SHIFTU_HIGH - HIGH view
-// ISS_SHIFTU_FOLLOW - following car
+// ISS_SHIFTU_FOLLOW - FOLLOW view
// ISS_VIEW_OVERRIDE - override user view
// On receiving this packet, LFS will set up the camera to match the values in the packet,
// including switching into or out of SHIFT+U mode depending on the ISS_SHIFTU flag.
-// If ISS_SHIFTU is not set, then ViewPLID and InGameCam will be used.
-
// If ISS_VIEW_OVERRIDE is set, the in-car view Heading Pitch and Roll will be taken
// from the values in this packet. Otherwise normal in game control will be used.
@@ -1695,7 +1742,7 @@
// Text in the IS_BTN packet. If the first character of IS_BTN's Text field is zero, LFS will read
// the caption up to the second zero. The visible button text then follows that second zero.
-// Text : 0-65-66-0 would display button text "AB" and no caption
+// Text : 65-66-67-0 would display button text "ABC" and no caption
// Text : 0-65-66-67-0-68-69-70-71-0-0-0 would display button text "DEFG" and caption "ABC"It existed for while as part of InSimSniffer, so it's been around for a couple of years, although it wasn't given a proper release until about a year ago. Version 2.0 came out in the last couple of months and is the first version that's been designed purely as a standalone library.
InSim.NET runs on Mono as well, just FYI.
In terms of .NET support I provide .NET 3.5 and 4.0 binaries, although to compile it for 2.0 you would need to do some modification, mainly you would need to rewrite any LINQ stuff. Probably wouldn't be too hard but not something I plan on doing.
OK, thanks for the tips and the offer. I have a friend who can do me a HD 4670 for £20, which seems ideal. So Imma gonna go with that then.
At first I thought you was crazy, but then on closer inspection I saw a bug in the code. I fixed the bug and pushed out a release onto CodePlex. Try the new one as I think it should work for you now.
Sorry about that!
http://insimdotnet.codeplex.com/releases/view/64947
Sorry about that!
http://insimdotnet.codeplex.com/releases/view/64947
I'm going to hijack this thread a bit (looks like it's done now anyway). My graphics card went kaput today (on painful onboard graphics now). I have similar requirements to the OP, except due to financial constraints I'm looking at the sub-£50 range. Basically...
Any help welcome!
- PCI-E 16x
- ~£50 (56 euros)
- ATI or Nvidia
Any help welcome!
It's not the official patch that's being released, it'll be the test patch first, so it doesn't really matter when it comes out so long as there are enough people to test it (which I'm sure there will be).
Last edited by DarkTimes, .
Yes, it's easy to run pyinsim scripts inside Eclipse (that's how I test it). You open the script you want to run in the editor and click the Run button (or CTRL+F11). If it asks you to choose how to run it select 'Python Run'. Then you should see any output in the Console window. To stop the script click the Terminate button on the Console panel (the red stop button).
The only thing to watch out for is if you start another script before stopping the first, as then you end up with multiple scripts running at the one time, which gets confusing. Well, it confuses me.
The only thing to watch out for is if you start another script before stopping the first, as then you end up with multiple scripts running at the one time, which gets confusing. Well, it confuses me.
Last edited by DarkTimes, .
Well, I wrote them for myself because I wanted to get an idea of how InSim.NET would look in the different .NET languages, so I figured I'd just post it. I thought it was quite interesting, although examples that showed receiving packets would probably be better, as that's where the languages seem to diverge the most.
Just to note that I haven't done IronRuby or F#, mainly because IronRuby has stopped working with VS2010 SP1
and I don't really understand F# yet.
Just to note that I haven't done IronRuby or F#, mainly because IronRuby has stopped working with VS2010 SP1
and I don't really understand F# yet.
Last edited by DarkTimes, .
Hello InSim in VB.NET
Hello InSim in C++/CLI
Hello InSim in IronPython
Hello InSim in C#
Imports InSimDotNet
Module InSimExample
Sub Main()
' Create InSim object
Dim insim As New InSim()
' Initialize InSim with specified settings
insim.Initialize(New InSimSettings() With {.Host = "127.0.0.1", .Port = 29999, .Admin = String.Empty})
' Send message to chat
insim.Send("/msg Hello, InSim!")
' Keep program open
Console.WriteLine("Press any key to exit...")
Console.ReadKey(True)
End Sub
End ModuleHello InSim in C++/CLI
#include "stdafx.h"
using namespace System;
using namespace InSimDotNet;
int main(array<String ^> ^args)
{
// Create InSim object
InSim ^insim = gcnew InSim();
// Initialize InSim
InSimSettings ^settings = gcnew InSimSettings();
settings->Host = L"127.0.0.1";
settings->Port = 29999;
settings->Admin = String::Empty;
insim->Initialize(settings);
// Send message to chat
insim->Send(L"/msg Hello, InSim!");
// Stop program from exiting...
Console::WriteLine(L"Press any key to exit...");
Console::ReadKey(true);
return 0;
}Hello InSim in IronPython
import clr
clr.AddReference('System')
clr.AddReference('InSimDotNet')
from System import *
from InSimDotNet import *
# Create InSim object
insim = InSim()
# Initialize InSim
settings = InSimSettings()
settings.Host = '127.0.0.1'
settings.Port = 29999
settings.Admin = String.Empty
insim.Initialize(settings)
# Send message to chat
insim.Send('/msg Hello, InSim!')
# Stop program from exiting
Console.WriteLine('Press any key to exit...')
Console.ReadKey(True)Hello InSim in C#
using System;
using InSimDotNet;
class Program {
static void Main() {
// Create InSim object
InSim insim = new InSim();
// Initialize InSim
insim.Initialize(new InSimSettings {
Host = "127.0.0.1",
Port = 29999,
Admin = String.Empty,
});
// Send message to chat
insim.Send("/msg Hello, InSim!");
// Stop program from exiting
Console.WriteLine("Press any key to exit...");
Console.ReadKey(true);
}
}
Last edited by DarkTimes, .
I think I figured it out, basically PRISM is not requesting the connection list when a replay starts. I think it just requests the conns list when first connecting to LFS. As soon as any packet that needs the UCID is received, it crashes as it cannot find the connection in the list (the fact it was on a CPR packet is just a coincidence).
I solved this in InSimSniffer by requesting the conns/players list whenever a ISM packet is received, which seems to work pretty well.
I solved this in InSimSniffer by requesting the conns/players list whenever a ISM packet is received, which seems to work pretty well.
Last edited by DarkTimes, .
Hey there, I seem to have found a bug, it crashed when I was fast-forwarding through a replay.
FGED GREDG RDFGDR GSFDG