Yeah, but you only notice the lack of compatibility for the programs that stop working. There are hundredths, if not thousandths, of old programs that MS hacked on their own kernel to support, and you don't realise that they've done it because those programs just work. As Spolsky says in the essay above, it's a question of philosophy. A long time ago MS took the decision that your old programs shouldn't stop working just because you upgrade your OS. Now, turns out that they cannot check every program ever made because that's impossible, some programs will still fail, but I still think that it's the right approach to have taken. Frankly I'd rather have some backwards-compatibility rather than none at all. I don't think that the alternatives (complete compatibility vs none) are feasible or, in the later case, desirable.
Edit: Incidentally Bioshock doesn't work on Windows 7 with Realtec HD audio. I may have just undermined my own argument. Bioshock isn't even a legacy app, it's DX10 for god's sake!
OK this is a scenario where I can imagine an error like that might be thrown. Can I ask is it only against an open config host that this occurs, or does it occur on a 'closed' config host as well? I'm thinking this error might be an open config issue as I haven't tested that yet.
It might be a bit late to start debugging tonight, but I'll try and check it out tomorrow.
Incidentally don't worry about testing it against old LFS versions, I'm pretty sure that's not the problem.
OK, thanks for the report, but I will need more information to be able to understand what's causing your error.
Which version of InSimSniffer?
Is the message a popup dialog box or the big unhandled exception dialog? (if the later please post the stacktrace)
Are you connecting to a dedi server or a local client?
Are you connecting to an empty host or to one with a race already in progress?
Does this happen with the old version of LFS or just Z32?
I have tested InSimSniffer 1.2.6 against LFS Z32 and it works fine (there is no reason it should not), so I would imagine this error must be caused by something else.
I agree, but I still don't like to see the car behind have such a straight line advantage that they've passed before they reach the braking zone. I'm not saying do away with the DRS advantage, but just tone it down a bit so that the driver behind can still get alongside and then make them fight it out under braking.
In my mind DRS was introduced to solve the problem of a trailing car that's faster being unable to pass a slower car due to not being able to follow in the slipstream. At the moment DRS seems like a big red 'overtake' button. I would prefer to see its effectiveness reduced to purely allow the driver behind to get into a position to attempt a pass, instead of at the moment where it seems to guarantee one.
But frankly, these are small tweaks to the system I'm suggesting. I was sceptical of DRS back at the start of the year, but I think it's been working out very well.
Well thanks for that really detailed error report! As I say I will only provide support for stuff that I have changed (e.g. CON, RST, MTC (except the variable-sized thing) and OutGaugePack).
Other than that the library is completely unchanged and works as it always did.
using System; using LFS_External.InSim;
class Program { static void Main() { InSimInterface insim = new InSimInterface(new InSimSettings());
insim.VER_Received += new InSimInterface.VER_EventHandler(insim_VER_Received);
According to the license for LFS_External you are free to disassemble the library and basically do what you like with it, so with that in mind I updated it for LFS Z32. This meant adding the IS_CON packet and event, updating OutGaugePack with the relevant dash-lights and flags, as well as a couple of other small changes, such as IS_MTC*.
I created a new assembly versioned 1.1.1.7 that you can download below, that includes the updated assembly as well as the disassembled source (updated for VS2010).
If you find a bug with my changes I'll fix it, but I am in no way providing support for this library and I will not add any new features (the source is included in my download so you can add them yourself). Also if T-RonX has a problem with it I'll take it down.
* Note that I did not make IS_MTC a variable-sized packet, as that would have required a crap-bunch more work, also LFS_External does not deal with other variable-sized packets anyway. If you want stuff like variable-sized packets (better performance), proper string support (for other charsets than just ASCII) and many other general improvements, I recommend using InSim.NET.
I have also updated the original example program, which can be found below. The changes are mainly improvements to the code to make it more succinct and more efficient.
Good race, a lot of action. I think DRS is proving quite good, but they need to tone down the effect. I'd like to see it allow drivers to get alongside, I don't like to see them passing before the braking zone. But other that than, been great so far this year!
I picked up Mass Effect for £2.50 yesterday, not played it much yet as I'm still working my way through Fallout 3. Yes, I am at least two years behind in games. Was tempted by Sim City 4, as I used to love playing that back on the SNES, but I guess it's too late now for the sale.
Incidentally, Fallout 3 is the best game I've played for a long time, well recommended. But then I guess most people figured that out two or three years ago.
This exception is being thrown by the Entity Framework, it's not got anything to do with InSim.NET. The reason InSim.NET reports the exception is because it's being thrown on the packet receive thread.
You need to look for this exception in reference to the Entity Framework, unfortunately I can't really help you fix it.
Hmm, well I love that song, truly, but I'm not sure the remix improves it. Frankly they could have just re-edited the original so it was twice as long and it would have been awesome.
Is there no documentation anywhere that shows what this OutSim derived packet is supposed to contain?
As I said, I'm happy to add it, but without knowing what the actual struct contains I can't do anything. I don't personally own any of those games, so I can't test them myself.
Edit: Whoops, it's OutSim, shows how much attention I'm paying.
If that's all I need to do, then I can create a new built with those floats added on the end, then you can figure them out in your own time. Once you've figured out what they mean, I can update the field names.
Just had a look at the source on SourceForge, it looks to me that JInSim has not been updated for quite a while, and doesn't have the updated DashLights/ShowLights flags. So it seems you can't use JInSim with the latest version of OutGauge, you'd either need to modify the source, or find another library.
Edit: Or as Morpha below says, use his nifty script.