Trewor007

Hi. Im trying to wire up BDArmory with a kOS script to operate my mech. The problem is that kOS can only use non-stock parts via the right mouse button menu, and the Modules in the part file. Because of that i can toggle my GAU-8 cannon on and off, but since the part does not have a fire button in its menu the script can't open fire. I will be very grateful if someone help mi with adding a fire button to the menu so my script can access it.

object reference... ble bla bla... that's just a not selected target, I remember seeing that very often when i programmed my missile. Steven Mading explained this once to me in this post http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-15-2-2014-11-19?p=1550611&viewfull=1#post1550611 this is how i understand this problem: things like target , body are special words, and some times they have a additional wrapper and instead of comparing if x=y we compare if (x^k)=(y^d) and that's a lottery. thou trial and error I can say that is always safer to do something like this: instead of set target to body("Duna"). use set t to Duna. this way You eliminate the wrapping in target (since its special) and You unwrap Duna from the Body wrapper. so its easier to predict the number of wrappers in wrappers (wrappercepcion ) in line 10 i see Your are checking if duna is duna. so maybe try setting duna to some value first and than comparing. in that way You unwrap unnecessary wrappers. but first try dooing that simple check i did in that pic i Posted in the previous post maybe its some different strange bug. set t_info to list(). set finished to false. set t to Duna. set COMPAREPLANET to Duna wait 1. until finished = true { // Forces you to select a target clearscreen. if ( (" " + t ) <> (" " + COMPAREPLANET) ) { print "Target Acquired". print "----------------". print "Target Distance: " + t:distance. print "Target Heading: " + t:heading. set heading_up to 90 - vang(t:position, ship:up:vector). print heading_up. t_info:add(t:distance). t_info:add(t:heading). t_info:add(heading_up). set finished to true. } else { print "Please select a target". } wait 0.2. } wait 0.5. print "You have "+stage:amount+" Missiles remaining". if (ship:electricity < 20) { print "You have low electricity". } if (ship:heading > t_info[1]) { until (ship:heading < t_info[1]) { AG1 on. } AG1 off. } if (ship:heading < t_info[1]) { until (ship:heading > t_info[1]) { AG2 on. } AG2 off. }print "Gathering Target Info...".

it has to work ive been given the same advice a while ago and it helped. the problem is somewhere else. if You compare directly 2 values that are planets like kerbin, duna, mun.. the code will don't work properly, but look what happens when i give it literary some space:

2 questions: Will future versions of kOS be able to detect biomes? for the moment the only way vessels can communicate is by their names. Is there, a way to trick kOS in such, a way it reads multiple info from one name by dividing the name and using something similar to getchar ? for example: lets say we have a station with 4 docking ports. all docking ports are free so the name of the station is "S0000". when a new module arrives its kOS script reads the name, then divides it like so: S 0 0 0 0. and by that it knows it arrived at the correct place "S" and that all its docking ports are free to use. the script decided that the second docking port is the best option for docking. after docking the station renames itself to "S0200". (where "2" is the code of the module. witch it i can store info of the type of that module, how big it is etc...). a different module arrives. again it divides the station name S 0 2 0 0. the script decided that the second docking port is the best option for docking. but its taken by a "type 2" module. with that knowledge the new module decides to dock to docking port 3. the script also know how big the "type 2" module so he can plan a docking trajectory that will avoid collision. after docking the station renames itself again to S0240. i know its possible to code using whole names but that would require a HUGE list with all combinations. im asking because i have a whole space program with ships named in a special system "[number]_[name]" and a "loader" program for every one of those vessels witch a number on the back. and many program names just have a different number at the back so im wondering if this can be done with a more efficient code than this: if x="1_ROVERmk3" {copy loader1.ks from 0. copy START.ks from 0. copy TRANSFER.ks from 0. run loader1.}.

some things have changed. https://github.com/KSP-KOS/KOS/blob/master/CHANGELOG.md but its easy to make changes to the code and it will work again.

oh sorry i meant on the same part.

only on the probes. having kos and kerbals on different parts is against my gameplay rules. ive only did that once when i was thinking the reason of spinning was having kos probe interfering with kerbal in the lander can.

i think i found the problem. but i hard to explain it because of the language barrier. if the root part of the ship contains a place that can hold a kerbal(pod, cockpit or living quoter) the problem does not exist. the part does not have to be occupied by a kerbal it just needs to be there. if the root part is, a probe and there is a kerbal in a pod on the part that is gone be detached that part will go nuts. it all depends on witch side of a decoupler the kerbal is. https://www.youtube.com/watch?v=U3SR__KZWt4

ships see they have new names. the ones with the kerbals still spin maybe there is some kind of log or output file a can give You for analysis?

the terminal in the top right corner is from the root vessel, it shows corect mass of 24t. the terminal on the bottom left is from the left lander can, unmanned, points correctly to prograde. corect mass of 1.2t. the terminal on the bottom right is from the right lander can, manned, SPINS (it can be seen in the left corner). corect mass of 1.2t. leaving the scene does not help, and in some cases is impossible (different bug) as an observation: the problem was effecting all the vessel both manned and unmanned, but now when I uninstalled TTNeverUnload mod the problem only with the manned craft separated from the root vessel.

after separation. for example the probe on the bottom is a root part created in the VAB, the probe on the top was created in SPH saved as the "bug test" subbasembly and attached to the root part in VAB. this is how they react: in this case the oscillation is light, when i tried this with a lander can they go like a tornado with spinning on all 3 axis. EDIT: I was unable to reproduce the same effect on a fresh copy of KSP witch only KOS installed and added modules. EDIT2: If a kerbal is in the capsule the spinning starts even with ships with no subassembly parts.

can anyone check and conform something? when build a small ship with a stock probe with a KOS module, and save it as a subassembly. an when i use that subbassembly is such a way that it detaches from the ship, and use a "lock steering to..." command. the detached ship starts to spin instead locking into the correct orientation. EDIT: this happens mostly in the SPH

This is more a question out of curiosity rather than a problem. I've created a small drop-ship, with 6 drop-pods controlled by, a very primitive program. The strange thing is that the manned pods are executing the drop correctly, but if i drop a empty one it flies of course on booster ignition. This is not a problem since i will drop them all with kerbals inside, but I'm really curios why the drop pods are behaving in such a way. on AG9 { stage.}. wait until ship:mass < 2.0. print "separated". sas off. rcs on. until 0{ if k=0 {wait 30. set k to 1.}. if k=1 {set ship:control:top to 1. wait 1. set ship:control:top to -1. wait 1. set ship:control:top to 0. wait 2. set k to 2.}. if k=2 {lock steering to prograde. wait 5. sas on. LIST ENGINES IN myVariable. FOR eng IN myVariable {eng:ACTIVATE.}. wait 5. sas off. set k to 3.}. when ship:altitude<50000 then {lock steering to retrograde.}. when ship:altitude<10000 then {unlock all.}. when alt:radar<100 and k=3 then {toggle gear. set k to 4.}. wait 0.001. }.print "gotowy". set k to 0.

i cant dock my capsule with the j-Utility Bay the ports are magneticly attracting etch other but instead of docking they fly thou etch other, does anybody else have this issue?

Currently if we want to play KSP without one or more of our installed mods we need to temporary delete them from the data folder or make a copy of the entire KSP game. What I suggest is a stock mod manager in witch we can chose active mods for every new game we start. And in case of resumed games a additional button where we can select the mods individually for each save. I realize this can be done with a mod but making it a part of the core game will give a grate advance in compatibility since not all mods are comparable with other mods, it will also create a standardize platform for auto upgrade of the mods. In addition to that files like "Firespitter.dll" with are used by many other mods can be shared. It will also resolve the problem of using multiple instalments of KSP (and using tons of disc space) just for playing witch different sets of modes. When sharing a save game or a ship/subassembly the information of needed mods (with their names and versions) can be stored inside the save game or ship/sub-assembly. When deleting/disabling a mod we can get a pop-up warning window informing us ahead witch ships wont work any more. This system might also be very useful with the upcoming upgrade for the tab system, but i don't want to speculate about that until i see that system. I really am curios what is the opinion of the KSP community about this idea.

the blue vector is my ship surface prograde. the red vector is my target position. and the green vector is target position - ship surface prograde. the green and red vector are so close they form a yellow line. When i was talking about adding and retracting vectors i meant constructing a vector that when pointed at will cause the angle between the blue and red vector to go to 0. probably something in style of this TRIM control.

My A vector is my target:position. My B Vector is my SHIP:SRFPROGRADE. How to explain to the KOS that i want to build a vector C witch C+B=A? Because what ever i do the missile don't compensate for the gravity enough and hits in the ground in front of the target. And can someone explain to me what Trim is (in sense of :YAWTRIM) because the translator is useless, and goggle just shows some articles about hard drives.

Fox Smith i think changing "E" to "e" might help. its the only possible error i can see there. set vo to 95.688*(e^(0.096*a1)). but what really interest me is how You get the "ce" for the line 76 when You tell the script in line 94.

ALT:RADAR The altitude of the current ship above the terrain, rather than above the sea level. Does not have an alias anywhere. if it comes to velocity there is a :VELOCITY suffix, it can be SHIP:VELOCITY:ORBIT or SHIP:VELOCITY:SURFACE or You cand use :mag suffix on Your vector and You will have a magnitude of the vector, as a scalar number.

maybe it can be, a "unofficial" bug fix, witch no number and after more bugs are smashed, incorporate it into a official v0.15.3 update. Or call the fix for just this single issue v0.15.2.1. I don't know what are the numbering rules in the dev team, so that's just a suggestion.

hvacengi there was some issues with boot files in v0.15 but as far as i know they was due to changes, not bugs. The problem You described allow happened tu me but only on loading existing ship. After i recopied the files from archive to ship and quicksaved, the problem was gone. So that is more of a inconvenience than a bug. Reddy This wiggling of the flaps etc. is kinda normal, the script is pointing the vessel in a very and i mean VERY specific position that is changing very fats with almost 0 margin for error, i remember MJ had the same issue( i don't know if it still have it).

Steven Mading That method its "ugly" but effective:P BTW: on http://ksp-kos.github.io/KOS_DOC/structure/part/index.html in the discription of the :GETMODULE the link is broken the link is http://ksp-kos.github.io/KOS_DOC/structure/partmodule.html instead of http://ksp-kos.github.io/KOS_DOC/structure/partmodule/index.html

OK now i see it. I have 1 more question. I set y to Duna, and when I use the " print y. " command i get body("Duna"). if i use the "print ship:patches[2]:body." i get 'body("Duna").'. But when i type: if ship:patches[2]:body=y {print "true".} else {print "false".}. i get the false result, despite the fact that "set target to y." will target duna. I'm assuming the problem is in the "set y to Duna." method. But I don't understand what is the nature of this type of error in KOS.

set y to Duna. set i to ship:patches:length. print i at (5,19). set k to 0. if i>{ until k=i { print SHIP:PATCHES[k-1]:body at (5,21+k). set destynacja to SHIP:PATCHES[k-1]:body. set k to k+1.}. lock throttle to 0.5. if destynacja=y{lock throttle to 0. set faza to 2.}.}. Hi this is my interplanetary transfer code. The problem witch it is when i get a duna encounter i get a message saying "Argument is out of range. Parameter name index. (Cannot show kOS error location - error might realy be internal. see kOS devs.)" is this a kOS problem or bad code?

if faza=1 { set target to y. // y is " duna" lock steering to ship:prograde. if round(ea)=round((kat21)-(SNS*(BurnTime/2))){lock throttle to 1. wait 1. }.//trigger condition for start if ship:liquidfuel=0 and huj=0{stage. set huj to 1.}. if ship:patches:length>2{ set i to ship:patches:length. print i at (3,20). if ship:patches[i-2]:body:apoapsis<47921949 {lock throttle to 0. wait 2. set faza to 2.}.}.}.//trigger condition for stop the 47921949 is Duna SOI radius.. if faza=2{clearscreen. break.}.// place-holder Hi i have a little problem witch my newest part of code. the STOP trigger part of the code does not work like I've imagined. It sees Duna, but there's no reaction. Probably the patches are all wrong but they are something new and threes not enough examples to check. If someone see where I made a mistake please tell me.