inoculator

SOLVED: Current Version 1.3.6.3 is now working w/o the mentioned issue.https://github.com/linuxgurugamer/DockingCam/releases

Hi, like psychonaut25 I got the same issue: I did the tests with stock vessels in sandbox mode. Do You have a fix? -----------------UPDATE 2019-09-21----------------------- I did not notice the GitHub Release Version. It seems that CKAN was a little behind. Current Version 1.3.6.3 is now working w/o the mentioned issue. https://github.com/linuxgurugamer/DockingCam/releases

Hi, Thanks for the hint. I have uninstalled "DockingCam(KURS)" and did some test. Then I reinstalled it, and did the same tests. I can confirm, it is an issue of this Mod. I will check for the "bug" report. br

Hi, #1 my setup: +Hardware PC Win 10, ATI Radeon Graphics +KSP 1v73 build 02594 +Mods Installed (using CKAN): -+"Chatterer" -+"DockingPortSoundFX" -+"DockRotate" -+"EasyVesselSwitch" -+"HeapPadder" -+"KAS" -+"KIS" -+"kOS" -+"KVVContinued" -+"ManeuverNodeEvolved" -+"MemGraph" -+"ProbesBeforeCrew" -+"RemoteTech" -+"SCANsat" -+"TACLS" -+"WorldStabilizer" -+"xScienceContinued" -+"CommunityCategoryKit" -+"ModuleManager" -+"DockingCamKURS" -+"ContractConfigurator" -+"ToolbarController" -+"ClickThroughBlocker" -+"CommunityTechTree" -+"CelestialBodyScienceEditor" -+"CommunityResourcePack" -+"BackgroundResources" -+"HideEmptyTechNodes" #2: the issue: I have one Vessel in Orbit and approach with another one for rendevous. When coming into physics Range (2.2km) the orbits syncronize to the orbit of the currently selected vessel. So, if You just started from Mun surface and You are still suborbital while approaching the Mun Space Station, the Space Station gets suborbital, too. I first had "WorldStabilizer" in view, but installed on a fresh instance of KSP only running this MOD does not show that behavior. Any suggestions or ideas about this? br Carsten

Hi all, I am running KSP 1.3.1 using CKAN for Modding and Version 0.13.6.0 of TAC Life Support is installed.The BUG from https://github.com/KSP-RO/TacLifeSupport/issues/89 hit me on this.Question is: Where is the information stored about the value displayed or calculated.My target: Edit some file and change the miscalculated value, reload the game and be happy.Is this possible or is my game doomed to this failure? Currently I have a done a quicksave before my Kerbals die and I have disabled the Background Processing, which not really does make sense when using TAC ;-) br Carsten

Hi all, just a short link to a functional script I wrote. Hope it helps anybody. Have fun to use it. https://drive.google.com/file/d/1HYVjI_sNvVdbnFuCrrL6N2fx6aAO8piR/view?usp=sharing just put it as loader in the head of your script: e.g.: runpath("0:/functions/check_special_parts.ks"). The script consists of 4 functions, that are similar in their concept: If You call the function, it will return a value depending on the parts it scans and finds. You can call the function with parameter "arm" to trigger the parts in question. The idea of the script is for helping on automated launches with dynamicaly activate parts and no need of a seperate script for each. The script is written with "remote tech" installed and active. Here a short walkthough: "check_chutes" set test to check_chutes(). print "found " + test[0] + " drogue and " + test[1] + " regular parachutes". //deploy all safe to deploy chutes set test to check_chutes("arm"). print "found " + test[0] + " drogue and " + test[1] + " regular parachutes remaining for deploy". My usage (as a snipplet of my launch script): [.....a lot of other code ....] //pre flight check set THIS_CHUTES to CHECK_CHUTES(). if THIS_CHUTES[1] = 0 { //We have no chutes for landing clearscreen. print "W A R N I N G" at(5,6). print "We have no Parachutes for Landing !" at (2,8). print "I will disable deorbiting in any case." at (2,10). print "Are You sure to continue ?" at (2,12). print "Press CRS UP to continue or CRS DWN to cancel" at(2,14). set PAR_DEORBIT to 0. set THIS_GETKEY to 0. Until THIS_GETKEY<>0 {set THIS_GETKEY to GET_KEY(). wait 0.1.} if THIS_GETKEY = "cancel" { set core:bootfilename to "". reboot. } } [.....a lot of other code ....] // landing runmode if RUNMODE=9 {//reentry the last stage parachutes if RUNMODEINIT=0 { set RUNMODEINIT to 1. set RUNMODESTATUS to "Waiting for Parachutes". } if alt:radar<10000 { set THIS_CHUTES to CHECK_CHUTES("arm"). if THIS_CHUTES[0] = 0 and THIS_CHUTES[1]=0 { set RUNMODE to 99. } } } [.....a lot of other code ....] "CHECK_HULLS" -a protective shell must be tagged with "HULL" to be recognized here. set test to check_hulls(). print "Found " + test + " protective shells marked for deployment." set test to check_hulls("arm"). print "Found " + test + " protective shells remaining marked for deployment." And my usage: [.... a lot of code ....] set THIS_HULLS to CHECK_HULLS(). if THIS_HULLS>0 { clearscreen. print "A T T E N T I O N" at(5,6). print "Found " + THIS_HULLS + " protective shells" at(2,8). Print "For shell deployment at 70000m press" at(2,10). print "CRS UP otherwise CRSDWN" at(2,12). set THIS_GETKEY to 0. Until THIS_GETKEY<>0 {set THIS_GETKEY to GET_KEY(). wait 0.1.} if THIS_GETKEY = "ok" { when altitude > 70000 THEN {CHECK_HULLS("arm").} } } [... a lot of other code ...] And now Solar panels and Remote Antennas. Here I introduce the tag "noauto". If You tag a solar panel or an antenna with "noauto" it will not be set to automatic deployment. This protects objects from being deployed at the wrong time (e.g. covered satellites in protective shells not deployed during launch). "CHECK_SOLARS" set test to CHECK_SOLARS(). print "Found " + test[0] + " static, " + test[1] + " deployable and " + test[2] + " panels set to 'noauto'". set test to CHECK_SOLARS("arm"). print "Found " + test[0] + " static, " + test[1] + " deployable and " + test[2] + " panels set to 'noauto'". and here my usage: [... again a lot of code ...] set THIS_SOLARS to CHECK_SOLARS(). if THIS_SOLARS[0]=0 and THIS_SOLARS[1]=0 and THIS_SOLARS[2]=0 { clearscreen. print "W A R N I N G" at(5,6). print "No Solar Panels found !" at (2,8). print "Are You sure to continue ?" at (2,12). print "Press CRS UP to continue or CRS DWN to cancel" at(2,14). set THIS_GETKEY to 0. Until THIS_GETKEY<>0 {set THIS_GETKEY to GET_KEY(). wait 0.1.} if THIS_GETKEY = "cancel" { set core:bootfilename to "". reboot. } } if THIS_SOLARS[1] > 0 { clearscreen. print "A T T E N T I O N" at(5,6). print "Found " + THIS_SOLARS[1] + " solar panels to deploy." at(2,8). Print "For deployment at 70000m press" at(2,10). print "CRS UP otherwise CRSDWN" at(2,12). set THIS_GETKEY to 0. Until THIS_GETKEY<>0 {set THIS_GETKEY to GET_KEY(). wait 0.1.} if THIS_GETKEY = "ok" { when altitude > 70000 THEN {CHECK_SOLARS("arm").} } } [... and guess what.. just more code...] And to make a long story short, here is the adopted version for antennas (just usage): [... yes again previously there is code...] set THIS_REMOTE to CHECK_REMOTE(). if THIS_REMOTE[0]=0 and THIS_REMOTE[1]=0 and THIS_REMOTE[2]=0 { clearscreen. print "W A R N I N G" at(5,6). print "No Antennas found !" at (2,8). print "Are You sure to continue ?" at (2,12). print "Press CRS UP to continue or CRS DWN to cancel" at(2,14). set THIS_GETKEY to 0. Until THIS_GETKEY<>0 {set THIS_GETKEY to GET_KEY(). wait 0.1.} if THIS_GETKEY = "cancel" { set core:bootfilename to "". reboot. } } if THIS_REMOTE[1] > 0 { clearscreen. print "A T T E N T I O N" at(5,6). print "Found " + THIS_REMOTE[1] + " Antennas to deploy." at(2,8). Print "For deployment at 70000m press" at(2,10). print "CRS UP otherwise CRSDWN" at(2,12). set THIS_GETKEY to 0. Until THIS_GETKEY<>0 {set THIS_GETKEY to GET_KEY(). wait 0.1.} if THIS_GETKEY = "ok" { when altitude > 70000 THEN {CHECK_REMOTE("arm").} } } [... code, you know...] as allready said: have fun with it. br Carsten

Hi. I have been pointed to this MOD to give it a try in corporation with KAS. I have KSP 1.3.1 installed and I use CKAN. Is this MOD being compiled for it in near future?

Hi Igor, Thanks for Your answer. It is exactly, what I was expecting. Even so, it is not a solution at all, but it helps understanding, what the root cause is. Thanks for this hint, too, I will have a look, even so, it is just a workaround that needs additional procedures when switching vessels, I think. All in all... it's a pitty ... :-(

Hi IgorZ. Let me state one thing clearly: KIS and KAS are the most mindbreaking MODs for KSP I have seen so far. Thanks for this work. ...BUT.... let me also state: At least KAS is the most annoying and headache producing MOD in the hole Game Universe ;-) I really think, that it is a question of how UNITY treats objects, but I don't believe, that there is no solution possible. My (and I guess many players) problem: Surface Buildings. Even so, since 1.1 (or was it 1.2) when the "easing physics" routine came up, it still happens, that sudden acceleration is put into part, that are clearly sticked to the ground -or better: large structures, that are on the surface. It is absolutely hard, if you have managed to put hundreds of parts to the planet, let your engineer run around for hours and hours, and then suddenly the complete structure starts to wobble and lift off the ground, wobbling its way far up to the sky. Fireworks, if You don't have "unbreakable joints" and "no damaged" activated. Even F5/F9 does rarely help. My gameplay is not to build huge structures in the VAB/SHP and lift them with insane unrealistic rockets. I like the "real" style, and KAS /KIS is the MOD making this possible. So please, take a look at the code, if there is any part You can create making it possible to stick absolutely to the ground even on more than one point on the surface. Let me know, what You think. br Carsten https://www.youtube.com/watch?v=mKIfJCKlJmk

Finaly..... I think I got it. Maybe, someone can try it, I he likes, maybe it helps somebody. I went 3 days though all that navigation stuff and finally ended up in a totally simple solution: "orbit:inclination". I really don't know, why I haven't seen this command before. The final script gets an inclination of +/- 0.5° off. // Inclination correction // my_orb is the given heading in the main script // the function is to be called at the beginning of every control loop. // deklaration der variablen set bit_func_getprograde_rm to 0. //funktions laufmodus set int_last_inc to 0. set int_cur_inc to 0. set this_inc to 0. set this_qad to 0. set this_Kurswinkel to 0. if my_orb<=90 { set this_inc to 90 - my_orb. set this_qad to 1. } if my_orb>90 and my_orb<=270 { set this_inc to my_orb - 90. set this_qad to 2. } if my_orb>270 { set this_inc to 450-my_orb. set this_qad to 3. } declare function get_prograde { set int_last_inc to int_cur_inc. set int_cur_inc to orbit:inclination. if bit_func_getprograde_rm = 1 { //init ist gelaufen if mod(this_qad,2)=1 { set this_kurswinkel to max(-8,min(8,orbit:inclination-this_inc)) *2 +my_orb. } else { set this_kurswinkel to max(-8,min(8,this_inc-orbit:inclination)) *2 +my_orb. } } set bit_func_getprograde_rm to 1. return this_kurswinkel. } I have put the complete script library on to here: https://drive.google.com/folderview?id=0BxyO38kgW4YuWmE4Qlp3RXJhSGs&usp=sharing It is very raw and not really cleaned up, so don't expect to much ;-) Thanks for the help. Carsten

Hi again. As promised a short status. I took a more or less deep dive into navigation regarding the great circle (GC). I did some tests applying the formula and ended up in more misunderstanding, than before ;-) I think, the formula You provided is only step 1 out of 3 or more steps. 1. The angle calculated is the angle between two point, relative to the center of the GC. 2. To get the steering course I need to calculate the "Kurswinkel" which is written on the wiki below Your quotation. It calculates the angle relative to north (0°). 3. Nevertheless I get the issue, that the navigation is bound to the ground, and as soon, as I lift off, I have to compensate two further parameters: 3.a. Coriolis effect if inclination is not 90 or 270° 3.b. The rotation of the body. I put in here the current scripts sniplets of the calculation I have done up to now. This does not include (3a + b). //main script //Runmode contains the step of the launch phase the ship is currently in. //0 is waiting to launch //1 is lift off and clear launchpad //>1 are 2: Rollmanuever 3: gravity turn 4: coast to AP 5:orbital burn 6:cleanup and ready to load next phase. if runmode >1 { [...] //Kursrechner set my_prograde to get_prograde(). set my_bearing to get_bearing(my_prograde, my_orb). } // Prograde rechner //Es muss ermittelt werden, //welchen relativen Kurs wir zwischen der letzten und der // aktuellen position gehabt haben // dieser muss dann mit dem soll-kurs basierend auf der my_orb vorgabe // verglichen werden und ggfls. ein korrekturfaktor // eingerechnet werden // deklaration der variablen set bit_func_getprograde_rm to 0. //funktions laufmodus set int_last_lat to 0. set int_last_lon to 0. set int_cur_lat to 0. set int_cur_lon to 0. set this_Kurswinkel to 0. set this_GKANG to 0. declare function get_prograde { set my_position to ship:geoposition. set int_last_lat to int_cur_lat. set int_last_lon to int_cur_lon. set int_cur_lat to my_position:lat. set int_cur_lon to my_position:lng. if bit_func_getprograde_rm = 1 { //init ist gelaufen //Aus dem Forum: //tl;dr: tc1=mod(atan2(sin(lon1-lon2)*cos(lat2), cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon1-lon2)), 2*pi) set this_GKANG to mod(arctan2(sin(int_last_lon-int_cur_lon)*cos(int_cur_lat), cos(int_last_lat)*sin(int_cur_lat)-sin(int_last_lat)*cos(int_cur_lat)*cos(int_last_lon-int_cur_lon)), 2*constant:pi). set this_Kurswinkel to arccos((sin(int_cur_lon)-sin(int_last_lon)* cos(this_GKANG))/(cos(int_last_lat)*sin(this_GKANG))). } set bit_func_getprograde_rm to 1. return this_Kurswinkel. } // Prograde rechner // this one calculates the needed corretive course by given is-value and -shouldbe-value declare function get_Bearing { parameter int_prograde. //this is the course parameter int_orb. //this shouldbe the course set my_heading to (int_orb - int_prograde) + int_orb. return my_heading. //this needs to be the course to compensate } I expect, that these sniplets might get more questions than answers, but I just wanted to show up, that I don't forget about this thread ;-) I don't think, that the script quotes are usable for any other by c&p. There are a lot of further lines and functions. I hope to get some steps further today br Carsten

Hi swjr-swis, it has lasted a while since I hit the forum again. sorry for the delay. At the moment I have a lack of performance on my PC to get a propper developement running on KOS. Nevertheless I have read the links and You really hit the point that I was missing. Thanks for this. As soon as I got my environment back in bussines, I will return and post some results. Many thanks 'till now Carsten

Hi all, I have posted this question in the german sub forum as well, but only in the hope of finding somebody speaking my language ;-) Nevertheless I give it a try in here. I know about the issue with "pitch", "roll" and "yaw" for the "r(p,r,y)" direction, but I cannot match this with my tasks and I have hughe doubt about that I am on the right way. Here ist, what I try to get scripted: I would like to create a generic launch script, that is able to put the vessel in an orbit with an angle other that 90° (equatorial). The run command should be simple like this: run autlaunch(650000,56) which would bring up the vessel to an orbit at 650km and an angle of 56°N relative to KSC at start. Here is, what I got up to now: I have written a script, that is able to launch any regular vertical vessel to any equatorial orbit. I have also implemented, that the script accepts any angle to the startup, but here it comes to an issue with the angle during launch progress: it changes. So the task is, to have a given angle at launch time, and to recalculate the heading during launch to the new angle to keep the orbit that way. Abstract: //Launch by "autolaunch(orbit_alt,orbit_angle)." declare parameter my_height. declare parameter my_orbit. [...some code...] lock my_heading to my_orbit + ([CurrentLocationRelativetoKerbinOrKSC] * [SomeStrangeQuaternionOrFaktorToGetNeededHeadingByGivenOrbitAngle]). [..some other code...] lock steering to heading(my_heading,my_angle). [...some more code...] I hope I descripted the issue in an understandable manner. Any hints or examples to get my on the right track? br Carsten

Klappt es denn mittlerweile mit dem Docking? Es gibt ein sehr schönes YT Video von Scott Manley dazu: Er zeigt ganz gut, wie man die Annäherung mit dem Haupttriebwerk macht -so etwa ab 4:50min. Wenn man das Prinzip verstanden hat, ist der Rest eigentlich recht einfach. Hope it helps. Carsten

Tach zusammen, es gibt für KSP ja aktuell nur ein MOD mit dem man in so etwas wie einem Multiplayer Szenario arbeiten kann. Im Zuge meiner Versuche mit kOS Rover Scripte zu entwicklen ist mir eine Frage aufgekommen: Kann man die "active Vessel" Pflicht umgehen?! Wer sich jetzt die Frage stellt, was ich da für wirres Zeug schreibe, hier mal der Gedankengang: Um einen Rover auf Erkundungsfahrt zu schicken muss ich ihn immer als "active Vessel" laufen haben. Mit kOS kann ich jetzt zwar die Fahrt und die Tätigkeiten des Rover automatisieren, aber ich kann mich zur Laufzeit des Scriptes nicht um die anderen Fahrzeuge (Vessels) kümmern. Dann kam mir die Idee mit dem Mulitplayer MOD. Ich kann also "einfach" eine zweite Maschine als Multiplayer laufen lassen und dieser hält den Rover aktiv, während ich an der ersten Maschine die anderen Fahrzeuge bediene. Dumm nur, wenn man zum Beispiel im Karierremodus ist. Wenn der Rover gerade Wissenschaftspunkte sammelt, oder Aufträge erfüllt, wandern die Punkte nicht auf meine "Master" Maschine. Als ich bei Gelegenheit nun einen meiner Raspberries in der Hand hielt und mal wieder so ein tolles "56 mio Knoten Raspberry Cluster LED Blinken Lassen" Video bei You Tube bestaunte, kam mit der Gedanke, ob es theoretisch möglich wäre, nur den "numbercruncher" von KSP auf dem "kleinen" Raspberry laufen zu lassen. Dieser "Core" müsste dann an einen "Master" gekoppelt sein, der die Aufträge und Punkte verwaltet. Ich klemme mich dann mit meinem PC/Laptop an diesen Master und bekomme dessen Stand übermittelt und kann nun die einzelnen "Cores" bedienen. Seit ihr noch bei mir oder bin ich schon zu weit weg? Der "Core" entspricht also genau einem "Vessel". er muss keine Grafikengine haben, sondern nur die grundsätzlichen Bewegungen und Ergebnisse berechnen und an den "Master" übermitteln. Der "Controler" ist dann eine Vollversion mit einer Verbindung zum "Master". Alle Werte und Angaben werden von dem Master geholt und an ihn übermittelt. Jedes dieser drei Objekte stellt eine Blackbox dar, die wiederum als Prozess auf einer beliebigen CPU laufen kann -also es könnten auch 16 Cores, der Master und der Contoller auf einem fetten PC mit ausreichend Leistung zusammen laufen, oder halt auf einem Raspberry PI ein oder zwei Cores oder ein Master und der Controller auf meinem Laptop. Gibt es so etwas schon? Würde das Lizenzmodel von KSP/SQUAD das abbilden? Ist die Idee gut, oder schxxxxx? Was meint Ihr?!? Ich bin kein Programmierer und könnte das selber nicht umsetzen, daher auch die Frage, ob jemand diese Idee aufnehmen kann und vieleicht mal grundsätzlich herausfinden könnte, ob das machbar ist -überigens wäre der nächste Schritt dann die Frage, ob sich "RemoteTech" darin einlagern ließe . Gruss Carsten