Search the Community

Showing results for tags 'python'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • The Daily Kerbal
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


Location


Interests

Found 12 results

  1. 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.
  2. 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
  3. 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...
  4. Pawelk198604

    Starting to learning Python

    It's not working for me
  5. 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.
  6. Bosun

    kRPC Question

    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!
  7. 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.)
  8. 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()
  9. 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
  10. 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:
  11. 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.
  12. JPmAn

    Programming languages

    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