Haven't tried it yet, but it's going to happen soon! I'll make sure to post some feedback when I get my hands on it. ^^

I'm currently fiddling with the IS_CON packet. I wondered if someone has found an appropriate way to distinguish an intentional crash from an accidental crash. Any advise about this matter?

Quote from sicotange :

I'm currently fiddling with the IS_CON packet. I wondered if someone has found an appropriate way to distinguish an intentional crash from an accidental crash. Any advise about this matter?

Well, one nice way would be via a drift meter-like detection. If one of the two (or both) cars are sliding sideways, the chance of it being an accidental crash is much higher, imo. If they are not sliding, the chance of it being an accidental crash is lower.

And imo, whoever is sliding should be the one responsible for the crash.

But of course, this is too vague. If you have an idea how to improve it - great, please share! ^^

Interesting, I think there is an accurate way to be found combining the data in the IS_CON packet and the IS_MCI packet. At the moment I'm trying to find a way to calculate if car A was driving towards car B while not showing a sign of slowing down if the magnitude of the impact is greater than a constant value.

Quote from sicotange :

Interesting, I think there is an accurate way to be found combining the data in the IS_CON packet and the IS_MCI packet. At the moment I'm trying to find a way to calculate if car A was driving towards car B while not showing a sign of slowing down if the magnitude of the impact is greater than a constant value.

Other than the case when somebody may be trying to drive out of a potential crash by accelerating, that sounds pretty good.

Imo, if you combine that and multiply it by the number of potential intentional crashes this user has been involved in, or a value to represent that in another way, you may actually have a pretty safe bet.

And of course, disable "blaming" of other users, if they crash in the 2 already crashed people (maybe for something like 5 - 10 seconds?). In the case of a pile-up, you can't possibly know who wanted to join the party, and who's just an innocent victim.

I think going with some empirical evidence would be a better choice. Take the MCI packet data, along with the CON packet data, and take a 'snap shot' of time of the MCI packet before and after the CON packet. Then with an application state if you intended to drive into the subject or not. See if you can find any patterns in the data.

About the new update.

The only thing bugging me is that constant change of ConnectionId between int and byte. Can we come to a nice final conclusion of what is better? My opinion is that ConnectionId is better since it's future-proof, as well as more compatible with other programming languages (unless I'm wrong and you can ban me from this forum, haha).

Other than that, I was really annoyed having to change all the packet names, but once that was done and I let the thought sink, it does look better, and while scrolling down the code, the new names definitely ring a bell faster, when I'm wondering where the hell I am.

The transition was rather easy too. Once you get familiar with the new names, it's a piece of cake. Well, a bit too much cake, but I like cake.

The second thing bugging me (yes, I lied above :razz is the way InSim.Send changed. I had my own function to use InSim.Send within, and now I have to duplicate that.. like.. a million times. Or is there an easier way? Is there an argument type I can use to accept all packet types? (I hope my terminology is fine here, and I'm not saying some random crab)

Hi!

I've got one problem with InSinDotNET. I'm only using Outgage. I open the connection, subscribe to event and it work OK. But, the properties: engineOilPressure, engineOilTemp and engineWaterTemp is always = 0.0

Is it a bug?? Or something is wrong in my code??

Thanks in advance!

Do oil pressure, oil temperature and water temperature work in-game?
not yet implemented

Consulting DarkTimes' expertise once more concerning this packet:

• In single player intersecting Autocross objects can't be added. Nor can objects be added out of bounds. Is there a workaround? I assume there isn't but I would rather be sure.
• I'm having a hard time making use of the axm.UCID. I'm trying to find out who is adding/deleting a specific object, unsuccessfully so far.

I found out recently that Microsoft are only releasing Visual Studio 2012 Express versions for Metro and Web. That means you won't be able to create desktop or even console applications for .NET 4.5 without buying a full version of Visual Studio. You won't be able to create standalone DLLs like InSim.NET either. This is very bad news for hobbyist programmers in general, such as the ones on this forum who write InSim programs. Because of this there is pretty much no point in continuing to create a .NET 4.5 version of InSim.NET, as the hobbyist programmers it's aimed at won't be able to use it.

I read that too but I'm not convinced this is factual. It seems a bit radical and blunt to suddenly add restrictions to Visual Studio Express while introducing a new (innovative) OS.

Sadly, it has been confirmed. They outlined details about the different product lineups on the Visual Studio blog a couple of weeks ago.

http://blogs.msdn.com/b/visual ... and-platform-support.aspx

Also you only need to look at the Express Edition product page to confirm it.

http://www.microsoft.com/visua ... 11/en-us/products/express

It lists only Metro and Web Express for download, then says at the bottom, "To create desktop apps, you need to use Visual Studio Professional 2012, or higher."

Mmm, not really rejoicing news... I'm wondering how Microsoft is going to convince Express users to pay 500$ in order to continue working on their desktop application on Visual Studio 2012.

Perhaps W7 users won't be easily tempted to buy W8. Also, it seems to me Microsoft is convinced that more & more people will ditch a desktop PC for a touchscreen alternative. Perhaps this restriction is one more way to promote Metro.

Concerning InSim.NET, is .NET 4.5 a big improvement over .NET 4.0? (I'm currently very happy with InSim.NET 2.0.14 by the way)

I can't help to think there is something missing in the picture. As far as I'm concerned I will reserve judgement once W8 & Visual Studio are released commercially. I do hope you won't abandon InSim.NET 3.0 though, that would be a shame. I assume you have no intention to revert back to .NET 4.0 if Visual Studio Express is as restrictive as it appears to be?

Suddenly pyinsim catches my eye Is there an evident difference of pro's & contra's of pyinsim vs InSim.NET?

Microsoft are aiming to make W8 a better OS than W7, but it seems that this won't happen. I hated Metro and no there's even less point to make a permanent switch to W8

I too, am happy with the current version of InSimDotNet. It does the job well and I don't think there's a huge need to switch.

MS have been doing some weird decisions lately. Is this their way of getting people write apps for the "cool" Metro? Do older versions of MSVS work under Win8? I also hear they decided to mangle C++11 support in MSVS 2012. Not much, but enough to create issues when people will try to build their code on other platforms. God knows why I try to stay away from MS stuff as far as possible

Rant aside, what does this mean for .NET developers?

Quote from MadCatX :

Rant aside, what does this mean for .NET developers?

It pretty much kills this project outright for Windows 8. No point in continuing a project if no one else can use it. If the PHP devs charged me to make PHP scripts, I'd be pretty pissed.

Crisis averted. If I'm reading through all the marketing speech correctly.

http://blogs.msdn.com/b/visual ... -for-windows-desktop.aspx

Relieve²

Oh, so they realized that they where being stupid. That's good.

Im having problem with IS_PIT.Work.

When I try to get every PitWork done, I dont know how to do it..

What im trying is:


But it doesnt work. Looking for a solution, i found this class helper http://hugoware.net/blog/enums-flags-and-csharp

Very easy and pretty, but didnt worked neither..


So at this point, I just tought InSim Lib outdated, I were using 2.0.12, updated to 2.0.14b and still with problem..

So I decided to look into the InSimDotNet´s source code, as Im with Visual Studio 2010, I couldnt open 2.0.14b source, I got the .13

I changed InSimDotNet.Packets.PitWorkFlags adding their values, like next:


I tryied again, and first code I posted worked fine, but as It was so verbose, I tryied the second one.. But that one didnt worked..

So, I want to know, Im doing it wrong since first code, its a bug of InSimDotNet?? And, Its there a way I can use the second way to check every flag?

Thanks in advance

PS. Sorry for that long code posting, but I want to help C&P for if someone want to try easy..

FYI Visual Studio 2012 Express for Windows Desktop is now available:
http://www.microsoft.com/visualstudio/eng/downloads

DarkTimes, any news concerning InSim.NET?

Hello,

I'm just asking if its me or the library itself was not working...

...currently porting my race insim project from LFS_External but it seems IS_PLC packet doesn't really work i tried it so many times but it seems no work and whenever launch the insim on the server i wrote my pw, port on the insim but when it connects it doesn't message any packet until i disconnect and comeback to the server and thats the time all packets is going to function..

is there any code sample for this library?

thanks!

I'm having a problem where my insim is working normally, but after a while it stops processing packets. An exception is thrown at BindingManager.cs:102 because reference.Target is null, as the WeakReference is used without checking reference.IsAlive.

I've been checking around and it seems that WeakReference is an inappropriate type to be using here, as the GC can collect these references in some cases.

http://msdn.microsoft.com/en-us/library/ms404247.aspx

The unreleased stuff in the repository is untested and buggy, so I don't recommend using it unless you're keen to help deal with these sorts of issues. It may be that the WeakReference stuff is implemented incorrectly, it was an experiment and I guess I'll have to reevaluate it. I thought I was using it correctly, but frankly it's been a while since I worked on it and I must have been wrong. In general I suggest using the source code from the last released version of the library, as that should be relatively bug free. Alternatively you could copy back in the old version of the BindingManager.cs file, but I think you might have to make a few other changes to the code in order to get it to compile correctly.