VS2003 supports .NET 2.0, need VS2005 for 3.0, VS2008 for 3.5, VS2010 for 4.0
VS2003 should support Win32 OK, I'm not 100% sure about this. I don't think it's changed much for a while.
I'm not sure exactly what VS2003's feature set was, but certainly VS 2010 Express' core programming features are vastly improved. The main things missing from the Express versions are support for working on teams, unit testing support, plugins, plus a few other kinda "high-end" features. The core coding experience though is very similar to the premium version.
Edit: And yeah, VS C++ Express supports DirectX. The only really annoying thing missing from VS Express is a resource editor, but you can find free ones online.
It's not that there are too many cruise servers, it's that there are too many people asking for cruise servers. I think part of this is down to the fact that no one has ever created a nice, user-friendly cruise server, that people can download and deploy. Really, where is the Lapper or AIRIO of cruise servers?
At the moment if people want a cruise server they have to download and compile a buggy Visual Studio solution, learn how to program and spend hours tweaking the code, even just to add there own server name.
I've said this for the last few years, but you guys need to get together and create a full user-friendly configurable cruise server that "normal" people can download, the way that the Lapper guys have done. A real program with configuration and help files, that someone who isn't a programmer can actually understand.
If you do this, not only will you reduce about 99% of the spam on the programmer forum, you'll become heroes. Hell you could probably even charge money for it!
It came from C++. In C++ new means something specific. In PHP it doesn't do anything, it's just syntax noise. In fairness C# and Java also needlessly copied it. I blame Java.
Ah, method chaining. That's a brilliant idea! I'm kind of annoyed I didn't think of that myself, seeing as how much I work with LINQ. You could do code like this:
I wrote a program a while back that was ment to demonstrate drawing the tracks with WPF, but it also shows the coords as well, in meters. You can select the track to view and pan and zoom with the mouse. Note that the Y axis of the tracks is flipped (didn't notice that at the time ), but the coords are still correct.
Pushed beta 5 to release. Only a small bug fix with using the background=True parameter of the run function. Backgound is useful when using pyinsim in a GUI app, as it makes the socket code run on a background thread so it doesn't block the message pump.
I think the next release of the library will be final.
Yes for me the question was too specific. I tend to answer questions that are broad, such as "how do you write a swear filter", and shy away from questions like "help me fix this specific problem using this specific API". The reason for this is that I don't really understand how the other APIs work. My advice is to make your question vague and not to require the answerer to have knowledge of any specific API or library. That way you will be more likely to have your question answered.
Edit: Sorry, I didn't realise this was the old thread. I don't provide support for this version of pyinsim anymore. If you really want to use it, you're on your own (the code is in site-packages if you want to read it). I suggest moving to the new and shiny version of the library.
Edit: I wrote a rough example of doing this with pyinsim 2.0.
There is nothing to learn here. You would be far better off spending two minutes reading a "introduction to programming" tutorial than reading this thread.
A long race. I had to go make food half way through, as I realized I would need some sustenance to make it through a 2 hour F1 afternoon. A great result for Alonso, my early prediction for him to win the championship is not looking so bad. Feel sorry for Lewis, I think that was a racing incident, Hamilton just came off the worse. Good result for Button, he's picking up the points.
Yeah, Python has a tendency to look like pseudocode.
Anyway, pushed beta 4 out to release. I rewrote the UDP timeout code, which has broken the API a little. You now specifiy a timeout when initializing the connection, so OutGauge now works like this:
import pyinsim
def outgauge_handler(og, packet): pass # Do something with packet.
# Set timeout to 30 seconds. pyinsim.outgauge('127.0.0.1', 30000, outgauge_handler, 30.0)
pyinsim.run()
Also fixed a small but significant bug in the tounicode() string function.
I've released beta 3 to CodePlex. There was a bug that was making pyinsim use 100% CPU which I've now fixed. I also fixed the issue with EVT_INIT not being raised and an issue affecting disconnecting from hosts.
It should be pretty stable at the moment, but a few thing are still incomplete, mainly the documentation, also there are a couple of bugs I need to work out. If you find any bugs or issues please assign them to me using the Issue Tracker.
I spotted a couple of small issues with your code. Firstly there is an easier way to check for system messages, and secondly strings in .NET are immutable, so string.Replace() does not affect the original.
// Check if was a system message. if (MSO.UserType == Enums.MSO_UserType.MSO_SYSTEM && MSO.Msg.EndsWith(" : took the wrong route")) { // Strings in .NET are immutable. string message = MSO.Msg.Replace(" : took the wrong route", "");
for (int i = 0; i < Connections.Count; i++) { if (Connections[i].PlayerName == message) {
// You got the player that took wrong route // Do some stuff.
// Exit from loop early return; } } }
I would probably have written it like this:
if (MSO.UserType == Enums.MSO_UserType.MSO_SYSTEM) { var index = MSO.Msg.IndexOf(" : took the wrong route"); if (index > -1) { var playername = MSO.Msg.Substring(0, index); var connection = Connections.Single(c => c.PlayerName == playername);
pyinsim is a InSim library for the Python programming language. It allows you to create a socket connection with the game and to send and receive packets of data. These packets can be used to control LFS, to request information and to send various commands. pyinsim provides a high-level abstraction for dealing with InSim, to save you from having to deal with the nitty-gritty of working with sockets directly.
As mentioned, pyinsim now has an official project page on GitHub, and this is where all future development will take place. It will also be the place to go to download the library and will always have the latest release and revision of the source code. You can find our new home at:
OK, sod it. I've decided not to use Google Code but to use CodePlex instead, as really that's what I'm familiar with anyway. You can visit the new CodePlex site for pyinsim here:
I've done an initial commit for the pyinsim 2.0 source code, which you should be able to access. I'm almost ready to release pyinsim 2.0, but a couple of things still need to be worked on, such as the OutGauge and OutSim support which is currently very buggy. That said, InSim and InSim relay are currently fully supported and seem to be working well.
I decided to use Mercurial for this project, as I've been messing around with it for a couple of days and it seems really good. I have to say getting the CodePlex site setup literally took less than five minutes. And to commit the source code all it took was...