Quote :

I've got a report of an interesting exploit where people are able to make InSim.NET's string handling code crash by typing certain characters (and are then able to use that to grief servers). I'm struggling to reproduce it here but I have a few ideas for what's causing it.

Can I ask, has anyone had any of these sorts of problems running InSim.NET on Windows?

On Windows server 2012 I encountered the following causing InSim.NET to crash:

Quote :

24/09/2014 15:59:22 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2
24/09/2014 15:59:41 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2
24/09/2014 16:00:14 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2put uoru ramp here
24/09/2014 16:00:23 CHAT: ^7☆^4Nitro^1Circus^9☆ ^8(onecheque) ^7: ^2your(
24/09/2014 16:00:33 ERROR: 9/24/2014 4:00:33 PM System.Text.DecoderFallbackException: Unable to translate bytes [81] at index 14 from specified code page to Unicode.
at System.Text.DecoderExceptionFallbackBuffer.Throw(Byte[] bytesUnknown, Int32 index)
at System.Text.DecoderExceptionFallbackBuffer.Fallback(Byte[] bytesUnknown, Int32 index)
at System.Text.DecoderFallbackBuffer.InternalFallback(Byte[] bytes, Byte* pBytes)
at System.Text.DBCSCodePageEncoding.GetCharCount(Byte* bytes, Int32 count, DecoderNLS baseDecoder)
at System.String.CreateStringFromEncoding(Byte* bytes, Int32 byteLength, Encoding encoding)
at System.Text.EncodingNLS.GetString(Byte[] bytes, Int32 index, Int32 count)
at InSimDotNet.LfsEncoding.GetString(Byte[] buffer, Int32 index, Int32 length)
at InSimDotNet.Packets.IS_MSO..ctor(Byte[] buffer)
at InSimDotNet.PacketFactory.BuildPacket(Byte[] buffer)
at InSimDotNet.InSim.TcpSocket_PacketDataReceived(Object sender, PacketDataEventArgs e)
at InSimDotNet.TcpSocket.OnPacketDataReceived(PacketDataEventArgs e)
at InSimDotNet.TcpSocket.HandlePackets()
at InSimDotNet.TcpSocket.<ReceiveAsync>d__0.MoveNext()
24/09/2014 16:00:33 ERROR: 9/24/2014 4:00:33 PM InSimDotNet.InSimErrorEventArgs

Could this be related to that infamous exploit?

EDIT

I suppose this wont be of much help?

Quote :

Problem signature:
Problem Event Name:CLR20r3
Problem Signature 01:clavico.exe
Problem Signature 02:1.0.0.0
Problem Signature 03:541452ec
Problem Signature 04:mscorlib
Problem Signature 05:4.0.30319.18449
Problem Signature 06:528fdb6a
Problem Signature 07:3511
Problem Signature 08:8a
Problem Signature 09:System.Text.DecoderFallback
OS Version:6.2.9200.2.0.0.400.8
Locale ID:1033
Additional Information 1:5861
Additional Information 2:5861822e1919d7c014bbb064c64908b2
Additional Information 3:1a2a
Additional Information 4:1a2aa8e38ac8adbb6fe1e594fa623c2e

Last edited by sicotange, Wed 24 Sep 2014, 16:22.

The palm trees do look better

I'm not a fan of the superficial glitter of fora. When I visit a forum I usually look for pertinent information. The faster I can do this without having to read unnecessary things, the better.

Impressive out of the blue surprise to say the least I am testing the new hosting service, so far my favorite new "feature". Really happy with it. I suppose the ability to host a custom InSim app would require to much work?

So far so good! I have been working on my InSim app franticly recently and haven't encountered issues with 2.1.0 so far

Quote :

It's just a little messy because you would wait for the restart, everyone would be on the grid and a second later they would all teleport somewhere else. I think you could send all the packets at once.

It would certainly not be an example of elegance but it would do the trick. If it is possible to teleport a full start grid in under 5 seconds with this packet that would be neat. Either way, I welcome this new packet with open arms

Quote :

but it's really not easy to update that without releasing an updated track, which we don't have plans to do.

Understandable.

On the other hand I must admit still not getting this "move this existing car to this position" packet. How I understand it:
1) Player X is on track with car Y
2) Send packet with new position
3) Car spawns at new position

If I understand this right would it then be possible to send several of these packets in a few seconds time resulting in a custom grid? It would make it possible to organize races with InSim without being bound to the LFS grids or is that a bridge too far?

Last edited by sicotange, Sun 31 Aug 2014, 14:39.

Quote :

2. If it ain't that hard, once you have set a "starting position" it will override the track's maximum pits with the server's maximum cars on track. For example AU1 has 16 slots max, by setting a starting position, it will set them to the maximum "cars on track" which is usually 32 by the server.

I think he means the following. Once the feature

Quote :

- Position car at X, Y, Z, heading / repair y/n / ground level y/n

is implemented there is is no reason anymore to limit the max amount of cars in race (or on track). Setting the limit to 32 (or more) on all tracks seems to be a pertinent suggestion. For example, at the moment, Autocross track is limited to 24 (or is it 16?) cars in race if my memory serves me right. Why not lifting that limitation by increasing it to 32?

The following link gives a nice overview of the gridsizes of LFS tracks: http://en.lfsmanual.net/wiki/Tracks

EDIT: Only S1 tracks seem to be concerned by this limitation. And if in open config mode only Autocross track has this limitation.

EDIT2: Perhaps a small improvement would be to remove this max cars on track limitation on Autocross. All tracks (in open config mode) can handle 32 cars on track except for Autocross. But perhaps there is a reason Autocross has this limitation?

Last edited by sicotange, Sun 31 Aug 2014, 14:22.

Quote :

- Position car at X, Y, Z, heading / repair y/n / ground level y/n
- Autocross object ground level y/n

Thanks for the prompt reply. These future features are already mouth-watering I hope you won't find to many hurdles on the road to implementing TEA.

OFF-topic:

I don't want to come over as an annoyance (not my intention) but do you know if you plan to work on some InSim changes/improvements for next official patch or will this one's focus be on DK2 and graphical improvements "only"?

I still secretly hope some InSim surprises may come soon. Either way it would be nice to confirm if these are still on your todo list or not so the excitement remains manageable

It doesn't seem to be a bad idea to separate the Helpers. I use some of the InSimDotNet.Helpers but have written plenty of my own. I may have written some helpers which could be of use if integrated with InSimDotNet.Helpers.

Somehow I feel that adding more documentation or making examples on how to make use of multiple InSim instances could make InSimDotNet more popular but it is probably not the most fascinating thing to write.

I wonder how much ground this warning obligation has. Perhaps once I have the chance to try on a Rift and get hit in my UF1 by a furious FZR I might relate to this warning

It would make more sense if Oculus implemented this warning instead of obliging devs to implement their warning. Detecting when a Rift is on someones head and then automatically displaying that warning popup shouldn't be that difficult. A procedure with buttons on the Rift with users confirming they read & saw the warning message could be an option too. It just feels wrong to release it in the wild and expect devs to deal with it.

Cool, will play with BytesSent and BytesReceived more seriously once I get a few things sorted out with my app.

Quote :

If you are using the library from a console app then it's up to you to deal with
any possible threading issues that might occur.

Found this out the hard way


It might be nice to have a basic example on how to make the socket connection bulletproof (from your own code). I found ways to kill the connection somehow and wish to have the connection code as stable as possible so that I can fire things at it without losing connection.

Loading times are indeed drastically lower now

I do hope you will be around to update InSim.NET with the (hypothetical) new InSim packet(s) and other InSim improvements Scawen may introduce in upcoming patches.

Quote :

I also added BytesSent and BytesReceived properties to the InSim class, which track the total number of bytes transferred since the connection was initialized (for both TCP and UDP).

I have now tested these changes:

1) Could it be useful to separate TCP and UDP? I suppose not otherwise you would have done so.


2) If someone happens to know what these mean exactly (reported in the LFS dedi log file)? I presume it is related to the buffers?

Quote :

Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 INSIM ERROR : MESSAGE LIMIT
Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:14 INSIM ERROR : MESSAGE LIMIT
Jul 30 16:05:15 TCP ERROR : MESSAGE LIMIT
Jul 30 16:05:16 TCP ERROR : MESSAGE LIMIT
Jul 30 16:17:25 TCP ERROR : INSIM LIMIT
Jul 30 16:17:25 TCP ERROR : INSIM LIMIT
Jul 30 16:17:25 TCP ERROR : INSIM LIMIT

Great stuff I will look into it once I get the opportunity to do so. In hindsight it might be wise to leave this up to us but perhaps somewhere in between, providing documentation or an example on how to make use of it instead.

For instance, currently I removed the helpers from InSim.NET (the rest remains untouched) as I have my own helpers classes in my InSim app. The InSim.NET helpers are partially copied into my own helpers classes. It probably doesn't make much sense but I know each programmer has his habits...

Either way you are the best placed to suggest how to use it elegantly and whatever you decide I will gladly make use of this new possibility

Quote :

Certainly it would be easy to keep track of how many bytes had been sent and received. Then you could check the bandwidth usage over time, warn if it goes over a certain amount etc..

That's exactly what I meant but explained better It would help to see "bursts" of bandwidth usage in order to identify bottlenecks etc.


I still haven't fixed my button "overflow" issue. Finding the best way to send a page of 100 buttons to each player at the same time isn't easy. Batch sending packets progressively using a buffer is more likely more your cup of tea than mine

Perhaps unrelated to InSim.NET but it would be nice to have a button "manager". At the moment I'm breaking my head to find a way to deal with buttons accordingly. My InSim app has many button calls and it can impact performance as well as stability (LFS dedi reporting INSIM LIMIT).

A neat way to buffer buttons and manage ID's as well as ButtonClick flag events would be nice. Perhaps a feature in InSim.NET reporting bandwidth usage could help too. It would help making stable InSim apps.

Quote :

What do you mean, is there a problem with the socket code?

So far I'm not really sure, I'm merely speculating. It would be nice to have a more elaborate "DisconnectReason" to know why exactly the connection was lost although "InSimErrorEventArgs" is already pretty useful.

I don't mind ditching .NET 3.5 at all. I'm looking for a file which contained notes about InSim.NET I took over the years. It was a long list but only recently, a few months ago I started having instability issues. Because I'm not sure yet what causes the crashes I can't blame InSim.NET. A foolproof/bulletproof socket would be neat.

Do you already have a vague idea of what you are planning to improve or what you are willing to achieve with the new version?

Great news! I'm still smitten with InSim.NET and have been coding plenty features around it for the past few years. Get ready for some requests, suggestions and general coding help inquiries. I will make a small (sadly small) contribution once I get home but might consider a bigger one when InSim.NET S2 is reality.

Glad you are back in business (right on time for upcoming LFS patch(es))!

Quote :

the C2 was go error while i put or del obj little quick

I don't understand this.

I don't have XP on hand at the moment so I can't test it :/ I only tested on Linux, Windows 7 & Windows 8.

You seem to be running Windows XP. Have you installed .NET framework 4.0?

I haven't tested ClaViCo on Windows XP in a while. I don't know if it is compatible.

Can you post the content of the error file?