Edit: I removed this feature.

I've made a few big changes in the last few days.

Firstly I pushed the development version of pyinsim 3.0.0 to codePlex, overwriting the old repository. I wasn't sure if I was going to do this at first, but I figured that all the old code and old versions will still be there, so people can still find them if they need them.

The second change was to add support for both Python 2.7 and Python 3.0 in a single package. The latest version of pyinsim has support for both versions of Python without any changes. It does this by conditionally declaring and importing several functions depending on which Python version is installed. This wasn't as much effort as I thought it was going to be actually, Python 2.7 and 3.0 are more compatible than you think. That being said, support for two Python versions means twice as many bugs and twice as much testing needed!

Lastly I'm still making some changes to the API. I realised after some thought that what I really needed to do was to eliminate any situation where there was more than one way of doing something. This means that I've finally deprecated the old way of sending packets in favour of the simpler newer version. That means that to send a packet you now always do it like this:


In addition to this change I also renamed the pyinsim 'run' function to the new name of 'main_loop', which I think better describes what it actually is. There was always a lot of confusion as to what the run function did and why it was needed. Now it should be more explicit.


Um, I think that's it for the moment. As mentioned the library still needs a bunch more testing, and I also still need to rewrite the documentation to reflect all the API changes. That being said, it is coming along.

You can find the latest version of pyinsim 3.0.0 in the CodePlex repository.

To send a message to a user, I'd do something like the following, right?

The message only shows up on the server.
The same thing happens when I do this:


I'm using the most recent version of pyinsim.

Try

The first argument is normally ReqI, which you're attempting to set, rather than UCID.

Quote from the_angry_angel :

Try

insim.send(pyinsim.IS_MTC(UCID=User.UCID, Msg='Hi there!'))

The first argument is normally ReqI, which you're attempting to set, rather than UCID.

My problem was caused by neglecting to set the ReqI. Thanks
Python doesn't care about the order of keyword arguments. I could put UCID after Msg if I wanted to.

I don't know how to use ReqIs. Request ID? To be honest, I use totally arbitrary numbers.

Edit: I wrote this at the end of a long, shitty shift. I apologise if it comes across as short and argumentative. That wasn't the intention.

Quote from Mountaindewzilla :

Python doesn't care about the order of keyword arguments. I could put UCID after Msg if I wanted to.

In your example code you weren't using a named argument to refer to UCID (note the difference between 255 and the "Hello?" in the below quote, now checkout insim.py and look at the __init__ definition)

Quote from Mountaindewzilla :

insim.send(pyinsim.IS_MTC(255, Text='Hello?'))

I'm using the most recent version of pyinsim.

Therefore you are refering to ReqI since it's the first argument in the definition of IS_MTC. I assumed it was actual code you were using, I apologise. I should've read your mind.

Quote from Mountaindewzilla :

Python doesn't care about the order of keyword arguments.

Eh? Does it work out the parameters by reading your mind

Quote from the_angry_angel :

Edit: I wrote this at the end of a long, shitty shift. I apologise if it comes across as short and argumentative. That wasn't the intention.

In your example code you weren't using a named argument to refer to UCID (note the difference between 255 and the "Hello?" in the below quote, now checkout insim.py and look at the __init__ definition)



Therefore you are refering to ReqI since it's the first argument in the definition of IS_MTC. I assumed it was actual code you were using, I apologise. I should've read your mind.

I assumed my examples were correct when I read the reply.
Your post was funny and informative, no need to second guess the tone.

Worked well for my program (here is it). Appreciate your work.

But when I try to send IS_MSO packet, I get some strange error (something like "pyinsim: Unknown packet type (136 bytes)" from LFS. I call it this way:

Is it wrong?
So far I use send_message("/echo something") to send message to the host only.

I see that pyinsim 3.0.0 is in the repository but the latest released version is 2.0.5. Does anyone know if the 3.0.0 version works okay?

Quote from PoVo :

I see that pyinsim 3.0.0 is in the repository but the latest released version is 2.0.5. Does anyone know if the 3.0.0 version works okay?

I have no idea, try it out and let us know! I would think it's in an alpha state, I seem to recall a conversation with DarkTimes about it from _quite_ a while ago.

I have moved pyinsim onto GitHub and am in the process of updating it to LFS 0.6H.

I plan on doing three things:

• Updating pyinsim 2 for LFS 0.6H (completed)
  
• Updating pyinsim 3 for LFS 0.6H (in progress)
  
• Adding both libraries to PIP (in planning)
  

Once I add both libraries to PIP I won't need to bother making Windows binary releases or any of that stuff.

https://github.com/alexmcbride/pyinsim

Great! I was secretly hoping pyinsim would get an update

Tried running the (hello.py) example and this error showed up (Check attachement), and in LFS there's: InSim guest closed :

I have the same problem as racerss, IS_ISI has no attribute SP0, tried to reinstall many times in many ways, i know its been like 2 years since update but is it just broken now or something?

OK thanks - I fixed that error and updated the repo on GitHub.

Hey Wow, thanks very much! Quick Response , seems to have sorted it i can get connected now! Legend <3

Sorry for the bump, but does this still being updated?

I feel like it's fairly up to date, as last year I merged in a bunch of updates from Degats and also fixed some bugs. Exactly what is included vs missing I couldn't say for sure. If there is anything important needed it should not be hard to add.

It's worth noting that InSim does not change often so InSim libraries do not need to change often either.

Hi DarkTimes, I used a slightly updated version of your pyinsim in my g27 linux leds project (see forum). I have modded the outgauge reception to work with python3, as 2.7 support ends this year and I didnt want to create something thats obsolete soon
Are you planning to port the whole project to python3 anytime or even add support to this new custom outsim packet Scawen introduced in the last test patches?

I don't have time sorry. I do accept pull requests if anyone wants to contribute their changes.

I've managed to port most of this project to python 3.8, seems to be running fine (hasn't crashed and messages seem to look mostly ok)

One issue that I ran into with both python 2.7 & 3 was that the original insim.py file throws at line 2024, when attempting to send messages that start with a slash ("/"). The solution is kinda ugly atm, and there are probably some other hidden issues still, but I'll make a pull request when I'm more confident that I haven't left anything too horrific in there code.

Fork here: https://github.com/MilanFIN/pyinsim
Don't use this for other than testing, but if anyone can report any issues I'd be thankful.

So I started porting it to Python 3, at least a bit. I made a new branch and got it basically running with packets being both received and sent. There are some issues to work out, specifically how it should handle string encoding. As always with LFS it's the major blockage. Converting everything to 'latin1' doesn't work as LFS supports more types of encoding than that. Right now in my branch you need to make everything a byte string, by putting a 'b' in front of it e.g. b'Hello'.

Anyway, I spent a worryingly long amount of time on the issue with the IS_ACR packet throwing an error on line 2024. Seems like it was a Python 3 error.


Should be:


That works for me in my branch.

https://github.com/alexmcbride/pyinsim/tree/port-to-python3

Quote from DarkTimes :

So I started porting it to Python 3, at least a bit. I made a new branch and got it basically running with packets being both received and sent. There are some issues to work out, specifically

...

https://github.com/alexmcbride/pyinsim/tree/port-to-python3

Hey everyone. Stupid question from someone who has not a particularly high amount of skill in programming:
I am trying to figure out how to send autocross objects to LFS with python 3. I got everything else to work with byte stuff (car data, message handling, and so on), but I cannot figure out how to send autocross objects.

I've done basically everything but working with layouts so far, so I looked at the old examples, but I have no idea how that would work with the python 3 branch.

Firstly, ObjectInfo takes only two arguments, data and index, which is not a big deal I think i can figure that one out, but if I try to make that work I get this error:

self.X, self.Y, self.Zbyte, self.Flags, self.Index, self.Heading = self.pack_s.unpack(data[index:index+8])
TypeError: a bytes-like object is required, not 'tuple'

And I have no idea how to make a tuple a byte thingy .

Obviously only if anyone is bored enough haha, but it would be awesome if somebody could provide me with a newer little example with python 3.

Thank you

PS: Thank you for creating pyinsim in the first place, it was a huge help getting into programming with LFS and I was able to realize really cool projects.