Search the Community

import turtle Dlugo_PiS = turtle.Pen() Dlugo_PiS.shape("turtle") Dlugo_PiS.forward(200) Dlugo_PiS.left(120) Dlugo_PiS.forward(200) Dlugo_PiS.left(120) Dlugo_PiS.forward(200) Dlugo_PiS.left(60) turtle.done() turtle.bye() Want to write it simpler import turtle Dlugo_PiS = turtle.Pen() Dlugo_PiS.shape("turtle") while i in range(3) Dlugo_PiS.forward(200) Dlugo_PiS.left(120) turtle.done() turtle.bye() What i need to do to make it works

Quicktex Available on Github License: LGPL Quicktex is a python library and command line tool for encoding and decoding DDS files. It is based on the RGBCX encoder, which is currently one of the highest quality S3TC encoders available. Quicktex has a python front end, but the encoding and decoding is all done in C++ for speed comparable to the original library. While it is not only useful for KSP, KSP is what I initially made it for, so I think it can go here for support and visibility. It should have higher quality than NVTT or DDS4KSP, while still being reasonably fast, as well as having a (in development, unstable) python API for custom scripting and tricky image types like light cookies. Installation If you are on macOS, you need to first install openMP from homebrew to enable multithreading, since it is not included in the default Apple Clang install: brew install libomp To install, just install from PyPI using pip (the package manager built into python) pip install quicktex and setuptools will take care of any python dependencies for you. The package also makes tests, stub generation, and docs available. To install the required dependencies for them, install with options like so (Docs are still a work in progress): pip install quicktex[tests,stubs,docs] Quicktex will be available on Pypi once it is out of alpha. Usage Usage: quicktex [OPTIONS] COMMAND [ARGS]... Encode and Decode various image formats Options: --version Show the version and exit. --help Show this message and exit. Commands: decode Decode DDS files to images. encode Encode images to DDS files of the given format. To decode DDS files to images, use the decode subdommand, along with a glob or a list of files to decode. To encode images to DDS files, use the encode subcommand, plus an additional subcommand for the format. For example, quicktex encode bc1 bun.png will encode bun.png in the current directory to a bc1/DXT1 dds file next to it. For KSP textures I recommend quicktex encode auto -r [filenames] encode and decode both accept several common parameters: -f, --flip / -F, --no-flip: Vertically flip image before/after converting. [default: True] -r, --remove: Remove input images after converting. -s, --suffix TEXT: Suffix to append to output filename(s). Ignored if output is a single file. -o, --output: Output file or directory. If outputting to a file, input filenames must be only a single item. By default, files are converted in place.

yaclog-ksp A command line tool based on yaclog for converting markdown changelogs to KerbalChangelog config files. available on github and pypi Installation run: pip install yaclog-ksp Usage Usage: yaclog-ksp [OPTIONS] Converts markdown changelogs to KSP changelog configs. Options: --path FILE Location of the changelog file. [default: CHANGELOG.md] -o, --output FILE Output file to write to. Uses 'GameData/{name}/Versioning/{name}ChangeLog.cfg' by default. -n, --name TEXT The name of the mod. Derived from the current directory by default. --version Show the version and exit. --help Show this message and exit. for example, running yaclog-KSP --path MyLog.md -n "My KSP Mod" would output to GameData/MyKSPMod/Versioning/MyKSPModChangeLog.cfg Input files are in markdown, and use a certain syntax to be readable by the tool. Metadata is included in a table at the top of the file (which row you make the header doesnt matter). Each version is an subheading with the version, an optional date, and the KSP version as a tag on the end in brackets Example Changelog: # Changelog This is the changelog for my cool mod! | modName | MyCoolMod | | ------- | ------------- | | license | CC-By-SA | | website | Example.com | | author | A cool person | ## 1.0.0 - 2020-04-16 [KSP 1.11] First full release ### Fixed - Nyan Cat now has correct music ### Added - Multiplayer ## 0.9.1 [KSP 1.10.1] Supported versions: 0.2.0 beta to 1.10.x ### Changed A very complicated thing that I can't easily explain in bullet points, but this paragraph works pretty well to get the point across! - Another thing that has multiple specific items - this bullet point * and this other one + oh and another one! ### Removed - Herobrine I'm currently working on a command line tool to generate and append to markdown changelogs

Hello people, I came here to talk about my new project called KSPython. As the name suggests, it is an open source library made in python for the KSP community, to help with designing and developing new rockets. The idea is to have something that empowers the user to make quick prototyping and to verify designs feasibilities. The library also allows the user easy interactivity with other python libraries, in order enable a great deal of functionalities, like plotting and optimization. While still being accessible to new programmers and python users. If you're interesting in checking some examples and learning more about the library, check the repository and documentation at: https://github.com/fred1608/KSPython https://kspython.readthedocs.io/ Also, if you're interesting in contributing to the project, feel free to reach in.

First for those who have remembered my old threads on coding I have decided to bite the proverbial bullet and learn python soon. I wanted to ask a few questions. First I have been informed by a mostly reliable source that Python can interface with hardware such as motors and electric "stuff" in general. This is true right? Secondly I have no intention of doing this anytime in the next year but is Python capable of making an AI of sorts. I ask all of this because I want to make a model rocket that has a full guidance system as well as staging system ect and I want to make sure before I put a bunch of time into learning this code that is it worth my time and is what Im looking for. Is this true? Finally are they any pointers that people can suggest to learning this language if it is really what im looking for.

So, I have decided to master a programming language. However, I can't decide: Python or C# or C... Which is the hot commodity in the market? There are lots of programming genii here, so I will be glad if someone helps me out on this one...

I have Asperger even if I was kid I was suspected (wrongly) that I have ADHD I could not learn the multiplication table, which was required in my country, Poland I can not do it until today, and I am almost 33 years old I often flunk math I could make calculations, but only with the help of a calculator. I remember once from boredom I started playing with a calculator and started to add numbers to each other. The teacher saw it and asked what I was doing? I apologized to him, and I said I was just having fun. This teacher said that I was just doing the Fibonacci sequence, do not even know it, and that I would not put crap on him, that I do not know mathematics, because from what I see it could be quite a good mathematician xD One of my friend who is also having Asperger advised me to learn to programming in Python, that is the easiest programming language to learn. I bought a course on Udemy and start to study, but I'm afraid that I'm too old https://answers.yahoo.com/question/index?qid=20190124084232AA3Yh98

I'm currently looking for a way to read information from KSP (ingame) on my main pc and use a Raspberry Pi 3 to display the information. My main pc will play the game and I want to use my raspberry pi with 7-Segment display. I just need a way to transfer data from my pc to the pi or even simpler just aquire the data, from there I can code the Pi 3 & 7-Segment Display by myself. So how can I read information like the height, velocity etc...? I have a good portion of programming expierence in Python, C++ & Web but some to none expierence with C# which is needed for KSP.

Hi there. I wrote a small tool to allow for rapid prototyping of rockets before actually building them, as I like to tinker with the components until I get just the dv and accelearation per stage I want. Although I play without mods, I believe this does something similar to KER, but without the need to actually build the rocket. As the tool was getting more and more useful to me, I thought maybe other people might like it. So I made it public (and FOSS) and uploaded it to gitlab. I would love to get some feedback. It runs on python3 and I tested it under GNU/Linux, but I don't see why it shouldn't run on Windows/Mac. At its core it consists of a rather intuitive language for speciying staged rockets: 1t + t400 + reliant, 200kg + 2*rocko64 + mainsail (That's a stage 0 of 1t payload, an FL-T400 liquid fuel+oxigen tank and a LV-T30 Reliant engine, on top of a Stage 1 with 0.2t additional payload, two Rockomax Jumbo tanks and a Mainsail) It then prints all stats I found useful about the rocket (such as delta-v). There is a comprehensive README with more information, oh and it has auto-complete so you don't have to memorise all component names. This is what the output looks like for a rocket I built to go to Jool and back again: Also, I'm new here, btw. Hi to all.

Hi guys, for a school project wanted to to some BFS style landings and tried krpc with Infernal Robotics and a python script to build it. Unfortunatly, my script is not working at all. I can run it and krpc get a popup that a scripts want to connect, but if I run it it says "RESTART" and thats all. As if it never get over the initial connection with krpc. Can somebody please help me? My setup: KSP-Version: Steam, 1.4.2 CKAN 1.25.4 Kronal Vessel Viewer 0.0.9.6 with Click Through Block 0.1.6.7 and Toolbar Controller 0.1.6.16 (installed with CKAN) KRPC 0.4.8 Kerbal Engineer Redux 1.1.4.10 Infernal Robotics - Next 3.0.0.0 beta3 for KSP 1.4.2 # Import benötigter Module import krpc # Aufbau der Verbindung zu KRPC und Auswahl der aktiven Raumfähre verbindung = krpc.connect(name='Alpha ') faehre = verbindung.space_center.active_vessel # Anlegen von Variablen um die Servos zur Steuerung ansprechen zu können lb = verbindung.infernal_robotics.servo_with_name(faehre,"LinkerBug") rb = verbindung.infernal_robotics.servo_with_name(faehre,"RechterBug") lh = verbindung.infernal_robotics.servo_with_name(faehre,"LinkesHeck") rh = verbindung.infernal_robotics.servo_with_name(faehre,"RechtesHeck") # Ausgabe der aktuellen Position der Servos print lb.name + " " + str(lb.position) print rb.name + " " + str(rb.position) print lh.name + " " + str(lh.position) print rh.name + " " + str(rh.position) # Anlegen von Variablen für die Servopositionen, setzten auf 0 lbp = 0 rbp = 0 lhp = 0 rhp = 0 # Überprüfen ob die Bremse aktiviert wurde # Wurde die Bremse aktiviert, # wird der 'Servo-Modus' gestartet, der erlaubt, über die # Spielsteuerung die Seitenleitwerke mithilfe der Servos zu kontrollieren bremse = vessel.control.brakes servoModus = False while(1): if vessel.control.brakes: if bremse != vessel.control.brakes: rhp = -45 lhp = 45 rbp = -45 lbp = -45 rh.move_to(rhp,5) lh.move_to(lhp,5) rb.move_to(rbp,5) lb.move_to(lbp,5) bremse = vessel.control.brakes servoModus = True else: if bremse != vessel.control.brakes: rh.move_to(0,5) lh.move_to(0,5) rb.move_to(0,5) lb.move_to(0,5) bremse = vessel.control.brakes servoModus = False # Bewegungen entlang der Roll-Nick-Gier-Winkel if servoModus: neigen = vessel.control.up bewegung = False if(neigen != 0): bewegung = True if(neigen < 0): lbp = lbp + 0.5 rbp = rbp - 0.5 lhp = lhp - 0.5 rhp = rhp - 0.5 if(neigen > 0): lbp = lbp - 0.5 rbp = rbp + 0.5 lhp = lhp + 0.5 rhp = rhp + 0.5 gieren = vessel.control.right if(gieren != 0): bewegung = True if(gieren > 0): lbp = lbp + 0.1 rbp = rbp + 0.1 lhp = lhp - 0.1 rhp = rhp + 0.1 if(gieren > 0): lbp = lbp - 0.5 rbp = rbp - 0.5 lhp = lhp + 0.5 rhp = rhp - 0.5 rollen = vessel.control.forward if(rollen != 0): bewegung = True if(rollen > 0): lbp = -45 rbp = -45 lhp = 45 rhp = -45 if(rollen < 0): lbp = 0 rbp = 0 lhp = 0 rhp = 0 if bewegung: rh.move_to(rhp,1) lh.move_to(lhp,1) rb.move_to(rbp,1) lb.move_to(lbp,1) Thank you! HCF

It's not working for me

KSP Mod Analyzer 1.1.1 has been released, with the following new exciting features: Support for SpaceDock, Curse and CKAN repositories Clickable links to mod page, source code repository and forum if available Filter on mod name Many UI improvements 60s cool down period after updating SpaceDock and Curse, to limit network traffic Possiblity to do analysis on mods, e.g. "Mods only available on CKAN", with aggredated metadata CSV export Note! Due to recent changes to the Curse page, "Update Curse" is broken, I'm looking into the problem. In summary, this application gives you a clear overview of all all KSP mods with relevant metadata in one single application. Note that is is not a mod manager like CKAN, but I hope you find it useful anyway :-) Please find download details below the screenshot. Technical details Written in Python 3 using Qt 5 for the UI Source code is available on GitHub Latest release, packaged as a stand-alone application, is available on the release page (Python is not required) Let me know what you think about this application, feedback and improvement ideas are welcome.

Hi everybody! I've been playing with kRPC, and loving the fun of learning how to Python (which is how I justify playing more Kerbal) and have a question that's stumped me the last few days. I have a craft with a central LFO engine, surrounded by decoupler attached LFO booster stacks. I'm looking for a way to determine when the fuel tanks that are radially attached are empty. Currently, I can call resources in a specific stage, which includes the main engine, and I can call object instances of all engines. Neither of those, however, help me, because the total resource level will never equal zero before I need to jettison tanks, and I cannot seem to pinpoint a singular engine instance to test for whether the engine has_fuel. I can test if all the engines have fuel, returning true if any single one still does, which also doesn't get me a usable result. Finally, I've tried to mathematically calculate the usage of propellant based on the stats of the engines, but the central and radial engines are different rates, and I also have vernor engines that differ in consumption, so my attempt to compute a hard time limit on the burn without, of course, first just running the rocket on the stand (which kinda defeats the purpose I'm looking for) failed. Any help is appreciated! Thanks all for any insight, this has been a really good challenge, but I'm breaking down and asking for help. Cheers!

KONRAD is Yet Another Telemachus Frontend. It's a curses program, so each console is a character-cell display in an 80x24 terminal. (It's aimed at Linux, but ought to work on other OSes - no guarantees though.) It can be found here, on GitHub. It's designed to be useful for co-operative "mission control" streams like Real Space Program or Go For Launch. Here are screenshots of the current consoles, taken during an Atlas-Agena launch (in Realism Overhaul): Obviously you will need Telemachus in order to use this. You will also need Python and curses, and a terminal emulator. An adjunct to KONRAD is the JSON Booster file format, used for describing a space vehicle in sufficient detail for the Booster Dynamics console to give up-to-date delta-V readings. It's fairly simple (some examples are included in the repository), but does currently have to be created by hand. It's not too hard to do: just take your vehicle apart into stages, count up the propellants in each, empty them out, and read the dry weight and engine (vacuum) Isp. For parallel-staged designs a little more cleverness is required; the included MercuryAtlas example shows how to do it. Basically, you have to guess (or measure in simulations!) how much of your fuel will be left when you stage your boosters away, and that's how much you record as being in the core stage. If you try and use asparagus staging it'll just completely fail to work; it can currently only reliably cope with at most one 'horizontal' staging event per 'vertical' staging event. (I have some ideas for dealing with this, but won't bother unless it turns out people actually want to do that kind of thing.)

I’m in the camp where I think “best practice” is to leave my Steam™ installation alone, and copy the entire KSP folder to a different spot and use that to play KSP with. That also has the advantage that you can keep your existing 1.1.3 install while frolicking around with the 1.2 pre-release. Of course there is the boring act of copying over the files from Steam when a new pre-release-release has taken place. A simple file copy will do, but there’s always the theoretical risk of leaving files from a previous release that are no longer needed. More thorough is to remove all existing files, but keep your mods and saves, and then copy the new release over. To get a clean update, every single time, I’ve written a simply Python script that does all that for me. I’m sure there is room for improvement—let me know! The advantage of using a script like this is the ability to extend it. This weekend I'll add a function to change some of the settings (notably using IJKL to steer rovers, and running KSP in window mode) for instance. That will be easy at this point. Anyway, I thought sharing wouldn’t be harmful. Enjoy! # --------------------------------------------------------------------------- # update KSP installation by copying over from steam # --------------------------------------------------------------------------- import os, shutil from zipfile import * # source is the location of your steam (squad?) copy SOURCE = r'C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program' # dest is the actual install you're playing with DEST = r'C:\Users\Kerbart\Documents\Kerbal Space Program 1.2' # zipfile is where the data is temporarily saved. your system temp folder # would be good. or a ramdrive, if you have one. ZIPFILE = r'R:\kspsave.zip' # the exception list of directories NOT to back up EXCEPT = ['saves\\scenarios','saves\\training','gamedata\\squad'] def main(): exec('Backup', makeZip) exec('Clear', clearDest) exec('Copy', copyAll) exec('Restore', extractZip) print('Done') def exec(title, function): print(title) function() def clearDest(): shutil.rmtree(DEST) def copyAll(): shutil.copytree(SOURCE, DEST) def extractZip(): myZip = ZipFile(ZIPFILE, mode='r') myZip.extractall(DEST) def makeZip(): myZip = ZipFile(ZIPFILE, mode='w') process_sub_path(DEST, 'gamedata', myZip) process_sub_path(DEST, 'saves', myZip) myZip.close() def process_sub_path(base_path, sub_path, zipfile): full_path = os.path.join(base_path, sub_path) for name in os.listdir(full_path): short_path = os.path.join(sub_path, name) if short_path.lower() in EXCEPT: pass else: full_name = os.path.join(base_path, sub_path, name) if os.path.isfile(full_name): zipfile.write(full_name, short_path, ZIP_DEFLATED) elif os.path.isdir(full_name): process_sub_path(base_path, short_path, zipfile) if __name__ == '__main__': main()

SpaceDock and Curse analyzer Hi, I would like to share a Python project I have been working on, "SpaceDock and Curse analyzer". I started working on this mostly for learning Python, and now I have a version up and running. The idea behind the project is "How to get a list of all mods that are hosted only on Curse but not on SpaceDock?" My preferred mod hosting site is SpaceDock, but I suspected that some mods are only available on Curse. How to get this analyzed in a nice way, and learning Python at the same time? Long story short, here is how it works, and a description of each Python file: get_curse.py - Parses the Curse page and retrieves all mods and store them on disk as a list. I did not find any API for Curse, so it's done with BeautifulSoup and a bit of reg-exp hacking. get_spacedock.py - Using the SpaceDock API to get a list of all mods and storing the list on disk. disk_helper.py - Helper functions to serialize data for storing on disk as well as reading and de-serializing the data from disk (used in the files above). curse_helper.py - Helper functions for parsing Curse spacedock_helper.py - Helper functions for parsing SpaceDock analyse.py - Reads the mod lists from disk for further analysis (e.g. to check which mods are only on Curse). This file is still a work in progress, currently it just list the mods. The files are available on GitHub The serializing to disk is for offloading the web servers, as you can play around with "analyse.py" without causing unnecessary traffic. Please let me know your comments on this project. There is probably a lot of Python code that can be optimized, but bear with me as it's my fist project

Hello all! I've been working on this project off and on for quite some time now. (tl;dr, magically rescale parts, follow instructions at bottom of post to install.) Backstory! I like to play on rescaled systems, 6.4x to be exact. But, this brings with it challenges as anyone who has tried it knows. Launch and Reentry are particularly trying. Several solutions exist for this problem, the two main ones that leap to mind are Realism Overhaul and SMURFF, both fantastic works that put mine to shame as far as sophistication goes. Realism Overhaul brings out the big guns as far as making the changes for a rescaled system go. SMURFF has a very comprehensive system while remaining lightweight. I admit I haven't tried it out in a while, but it's on my to-do list. Major props to @Kerbas_ad_astra for inspiration and some gleamed MM tricks. The solution presented here expands upon ROMini.cfg, from RO. It's not prominent, but available on their github page. It works by applying a similar methodology as RO does, to rescale parts more to a realistic scale size wise, along with some mass adjustments, such that density comes into line more or less naturally. A blanket scalar is applied, which was conveniently set at 1.6x times original size, so 1.25m becomes 2m, and so on. I instantly found it a blast to play with, as it kept things interesting without being too complicated to maintain. Major props to @NathanKell for this one, for originating the script/numerous other reasons. So, why is this post here? In 1.0.5, there exists a rather annoying bug in that rescaled root parts (specifically, those scaled by rescaleFactor) do not persist through load events. So, on vessel load or quickload, a rescaled part would revert to its original, smaller size. I never was able to ascertain if it was visual or if FAR was affected to. There exists a alternate method to scale parts in KSP, the model Scale variable. This one works correctly for loading, but doesn't rescale attach nodes to match. Boo! Module Manager (Props to @sarbian!) can do the appropriate scaling math on attach nodes perfectly well, but it has no means to do wildcard matching on them as far as I can tell. The MM patch looks funny, but works well to fix nodes. The problem is that a separate patch needs to exist for each kind of attach node that a part uses. This lead to a lot of copy and pasting to get a proof of concept working. So, I wrote some code. Specifically a python script to parse every cfg file in GameData, extract the node_* names, and write me the MM patch out. That's why we're here: The zip file below contains three components: A modified copy of ROMini.cfg with scaling code adjusted; a python script to generate a MM patch for said script, and a pre-generated patch file based off my install. (It's fairly large, but certainly it doesn't include every mod. It ought to cover the most common cases though, I would think.) Install! Install is easy: The config files can go anywhere in GameData. I would stick them in a directory named zzzzzzROMini, but I don't think it's strictly necessary. (We want it to run at the end of the MM passes, without using :FINAL.) The generateNodes.py ought to go in the base KSP directory (The one that GameData sits in) This also isn't strictly necessary, but it saves a step when running it, if you need to. If a node didn't scale right, and you don't wish to/aren't able to easily run the script, one or two nodes aren't too painful to edit in to the MM config: Find the part in question, and look for its "node_(whatever)" entries. Copy a block of patch and paste it to the end of the file, and adjust the text in the template. Requirements! KSP 1.0.5 Some sort of rescale, unless crazy OP is your goal semi-Optional: Python, minimum 2.7. (3 should work as far as I know.) Platform independent! Also as far as I know, this should work on Windows/OS X/Linux just fine. Optional: Having fun playing with your newly rescaled parts! Download!: Here Let me know if you have any trouble with it, i'd love to get feedback, as this is really the first 'addon' i've posted here. Good/Bad News! This will only be relevant/required for a few more weeks/couple months, as the aforementioned rescaleFactor bug has been fixed for 1.1, by, @NathanKell. (More props! And some jets, for that matter!) Still, if it is useful in the meantime, great! Also, it might serve as utility to someone who wants to write a similar helper script and/or learn python. (Which I kinda did to do this.) Snippets! These are just some extra tweaks I use, that you might all find handy. CustomBarnKit Config: This ups the mass and size limit on the level 1 and 2 launchpads to make it a little saner to blast off. Procedural Fairings: These are borrowed straight from RP-0, so all the credit goes over to them. They adjust the size limits and tech tree nodes at which the fairings unlock. It's only the front of it, just as an example, as I think this is something that might be a matter of taste as far as tech tree balance. In MM code, @ edits a value, % edits or ADDS a value if it is missing, ! deletes a value. The node names are fairly straight forward. If you're curious further, just drop a post here and lets see what we can work out. (Adjusting when the parts themselves unlock may be a worthwhile venture, as well.) Starting Launch Clamps: This one is from the 64x pack. It adjusts the launch clamps in the tree such that you start with them in the 'Start' node, as they may be of some significant utility for oversized craft. ... I swear there was another one. Blah Known Issues: If a Node needs to be added to the list manually, double check that it's the correct one; a duplicate entry will quite happily end up scaling twice (that is, squaring the scale). Procedural Fairings are still WIP: They certainly work, but they play a little bit of 'man behind the curtain', as the numbers displayed don't jive with the visuals presented elsewhere in the game. I'm still seeing what can be done about this, so its WIP. Not an "Issue" Issue, but be aware that SRBs are scaled to a VERY high TWR out of the box: This is so launch escape systems and the like can work properly. For regular "SRB-ing", you'll likely find that they're a little much. (Your Kerbalnaut may find that they're a little bit 'chunky guacamole', in other words.) Aim for 10-25% on the thrust limiters. This is easily adjustable, at the top of ROMini.cfg, in the first config block, look for @maxThrust, and tweak the multiplier to taste. Changelog: License:

So, here we go. I had/have the idea of creating a mfd (MultiFunctionalDisplay, what raster prop monitor basically is) outside of KSP using the kRPC mod and python. Doing the readouts and whatnot isn't the problem but the UI is. Currently it looks like this (pic) and I'd be great to have somebody who knows python and QT/qtpy and could help me making the actual display (the switching screens, displaying the navball and so on) since I'm fairly new ot the whole thing and I'm currently a little out of ideas. To people who would like know why I want such a display: There would be soo many new things to implement like imagine all the graphs you could draw using matplot for example, it would also be awesome for the people who have the Thrustmaster Cougar MFD, you can also calculate a excrementston of things which may not be possible inside of KSP/RPM. ui.py is the .qt (xml) code from the UI, translated by pyqt4 and ksp.py are the readouts done through the kRPC plugin stored in dictionaries for the moment. ui.py ksp.py I hope somebody could help since once the way how to create the tabs is figured out, the other stuff becomes rather simple and should be rather easy to do. And if somebody wonders how to execute the following code: 1. downlaod python 2. pip install krpc 3. pyqt4 wheel (wheels = installer for binaries/packages) is available on http://www.lfd.uci.edu/~gohlke/pythonlibs/ 4. run the code.

Debate on what is the best programming language! RULES: Forum rules Examples: 1: Python rules!!! 2: Yes! Python FTW! 3: Pffffffffft! Lua! Lua! I'l start, Look at my profile picture