ouch

Members
  • Content Count

    58
  • Joined

  • Last visited

Community Reputation

5 Neutral

About ouch

  • Rank
    Rocketry Enthusiast
  1. Link is fixed folks. Sorry! SignalCorps: because I haul cargo in those cargo bays... The tanks are there just for a simple ballast without increasing the part count too much. Alshain: that doesn't seem to much of a problem in my experience. All the weight in the back is though. that's why you can jettison the the tricoupler engines to move the center of mass more towards the front if if you get into a flat spin. (I have only needed to use that once however.) The brakes in the back also keep the thing pointing forward quite easily. Old Foxboy: A main sail really? The thing would burn for like 2 seconds and then be out of fuel... Those things have terrible isp in a vacuum.
  2. Ok I uploaded a new version of that file with both the modded an modless versions in it.
  3. Here is a link to the plane: https://sites.google.com/site/ouchsdownloads/home/downloads/Big%20Space%20Plane.zip I don't think I'm flying it right. The most I can get out of it is about 700m/s deltaV left one in an orbit of around 80k. It just feels like I'm wasting fuel or something and could get more out of it. The roll of this thing was to be an all encompassing craft. Something capable of lifting 13.5 tons into orbit, having a bunch of fuel to refuel a station onboard all the while still having enough lift and all the sensors and experiments to go to other worlds built in. There is also the problem of me being about half way in the tech tree which severely limits what stuff I can actually build this thing out of. The craft itself is stock. But it has scansat, protractor, kis and kas accessories. If you guys need a mod less version just let me know. (Mod less version added in to the file) Anyway here are some pics of it for those that want them: This one shows total DeltaV on that launch when you enable the fuel tank payload for use.
  4. Still can't believe this isn't stock yet...
  5. ok so the code now looks like this: clearscreen. list targets. list targets in tar. set arrows to list(). set x to 0. for t in tar { arrows:add(VECDRAWARGS(v(0,0,0), t:position-ship:position, rgb(1,0,0), t:name, 1.0, true)). } until abort { for t in tar { set arr to arrows[x]. set arr:vec to (t:position - ship:position). set arrows[x] to arr. //set arrows[x]:vec to (t:position - ship:position). set x to x + 1. }. set x to 0. }. for arrow in arrows { set arrow to "". }. arrows:clear(). I'm getting a new error at "set x to x + 1." it's pointing to the plus sign and it says that it can't add VectorRenderer to int32... I don't even know what it's talking about, it's just a simple "x++;" equivalent... lol, I think you guys broke KOS's brain... both sadly... my existing pre patch drone died after I tried running my code on it but the file was blank... So I went to the VAB and got fresh one. And after saving and reloading, that too was blank. also a new suffix problem: print (ship:velocity:surface*v(1,0,1)):mag. says values of double can't have suffixes. on the plus side it my drone seems to know exactly where stuff is now once I strip out all the code with errors.
  6. Found what looks to be a bug with lists, here is the code: clearscreen. list targets. list targets in tar. set arrows to list(). set x to 0. for t in tar { arrows:add(VECDRAWARGS(v(0,0,0), t:position-ship:position, rgb(1,0,0), t:name, 1.0, true)). } until abort { for t in tar { set arrows[x]:vec to v(0,0,0). //(t:position - ship:position). set x to x + 1. }. set x to 0. }. for arrow in arrows { set arrow to "". }. arrows:clear(). The set arrows[x]:vec to v(0,0,0). fails saying that "values of type system.int32 cannot have suffixes"... However: set tester to VECDRAWARGS(v(0,0,0), target:position-ship:position, rgb(1,0,0), target:name, 1.0, true). set tester:vec to v(0,0,0). Works, so I assume the problem has to do with lists. also code stored on a ship are not being saved. The file has size 0 after loading a saved game.
  7. steddyj, I was just trying to point out that setting a target and basing your code off doing things to said target can cause quite a few issues and should be avoided. For instance, if you have a craft that deploys a probe with kos on it. If your still in control of the main vessel and the probe tries to target the main vessel it can't because you can't target yourself. So it's best to store the object from the list command as a variable and work with it that way. For the other thing, since each object your targeting is not going to be an exact copy of an another object then you can compare parts between the two so that you can select the one your looking for. Using the parts list is kinda like a unique finger print. So for instance if you have a main vessel and a probe then you can look for a part one has that the other does not. It might be enough to just look at how many parts are on each object a well.
  8. steddyj: you want to use just :name for targeting, not :vesselname But to save you time I wouldn't bother targeting the ship. There can only be one target regardless of what ship your in. So if you want to say run the script on one ship and dock with another you can't change your target because it will break your kos script. Not targeting something first will likely save you time down the road. Secondly to pick a specific object out of a bunch of the same name then, it's best to use list to look through all the objects parts till you find an object that has the parts your interested in. you can look here for more info on how to do that: http://ksp-kos.github.io/KOS_DOC/command/list/index.html (specifically #4) Trewor007: what do you mean exactly? if you have a vector and want to look at a specific axis than you can just specify that axis like so: print "myvector x axis: " + myvector:x. print "myvector y axis: " + myvector:y. print "myvector z axis: " + myvector:z. A direction has it's own suffixes: print "mydirection pitch axis: " + mydirection:pitch. print "mydirection yaw axis: " + mydirection:yaw. print "mydirection roll axis: " + mydirection:roll.
  9. Well in my experience the word "NULL" tends to scare away non-programmers. They seem to have a hard time figuring out that NULL and a 0 length string or "" are two separate values. And while I definitely think being able to resize lists like that would make lists easier to use for both non-programmers and programmers, it also comes at a risk of alienating the non-programmers. To solve this I think you could get away with making null and "" mean the same thing according to KOS.
  10. Sounds like you might not have seen the new, updated wiki. Check it out here: http://ksp-kos.github.io/KOS_DOC/ But yes you can actually create multi-dimensional arrays and step through them just like c++. So: Set mything to stuff[2][5]. Is valid kos code.
  11. That makes sense as it seemed like the more the craft moved and rotated the farther off it got, almost like rounding errors were accumulating or something. But has anyone else confirmed? I have quite a few mods installed. one could be affecting it. Oh, and I don't mean to add to your stress, I do realize your just doing this for free... So fix it if you want to fix it and when you want to fix it. I still need to develop a better target seeking pathing for the drone anyway.
  12. Yeah there is definitely a problem here. take a look at this: http://cloud-4.steampowered.com/ugc/53243610307866655/3A13CFB12778276D3DA2E6BA7CAEAB881E1EBA07/ In this picture I have 3 rovers pointing to the exact position where KOS thinks all objects in the world are. As you can see all 3 rovers thinks Enmy Kerman is in a different position. These positions seem to change depending on the rovers orientation in the world. Here is the code each rover is running: (note only the color was changed for each rover.) clearscreen. list targets. list targets in tar. set arrows to list(). set x to 0. for t in tar { SET arrows:add TO VECDRAWARGS(v(0,0,0), t:position-ship:position, rgb(1,0,0), t:name, 1.0, true). } until abort { for t in tar { set arrows[x]:vector to t:position-ship:position. set x to x + 1. }. set x to 0. }. for arrow in arrows { set arrow to "". }. set arrow to arrows:clear. I know you said you guys are working on new stuff right now but, won't this throw off orbital projections and well... Just about everything else? Knowing where stuff is, is pretty important... Do you guys an updated version of KOS that I can test out for you?
  13. yep the version file says it's 14.2. come to think of it here, this might help you track down the issue: clearscreen. list targets. list targets in tar. set arrows to list(). set x to 0. for t in tar { SET arrows:add TO VECDRAWARGS(v(0,0,0), t:direction:vector, rgb(1,0,0), t:name, 5.0, true). } for t in tar { set target to t:name. set arrows[x]:vector to t:direction:vector. set arrows[x]:color to rgb(0,1,0). set arrows[x]:scale to 10. //SET pointything TO VECDRAWARGS(v(0,0,0), t:direction:vector, rgb(0,1,0), t:name, 10.0, true). wait 2. set arrows[x]:vector to t:direction:vector. set arrows[x]:color to rgb(1,0,0). set arrows[x]:scale to 5. set x to x + 1. }. for arrow in arrows { set arrow to "". }. set arrow to arrows:clear. creates red arrows pointing at each target, and the cycles through them making the arrow green and larger 2 seconds at a time. I made it when I was having issues targeting stuff but might come in handy for this.
  14. here is the code for the vector lines: SET anArrow2 TO VECDRAWARGS( v(0,0,0),target:position-ship:position, rgb(1,0,0), "Target Heading", 5.0, true ). SET anArrow3 TO VECDRAWARGS( v(0,0,0),(-1*ship:velocity:surface), rgb(0,0,1), "Surface Velocity", 5.0, true ). SET anArrow4 TO VECDRAWARGS( v(0,0,0),target:direction:vector, rgb(1,1,0), "Target Direction", 5.0, true ). these run forever in an "until abort" loop. And ignore the label on the red one, it was the heading, I just quickly replaced the target heading with the position subtraction to see where the game was telling my craft to go. And the green one was an experimental path finding vector that didn't work out. it's also worth noting that when I used jeb to push the box the line followed it's movements precisely, which leads me to believe it's either pointing at a spot at water level or something else entirely...
  15. I found that turning on precision mode saves oodles of rcs. And disabling it while landing and taking off gives you that extra control you need for those operations. Once I started doing that I found I had enough Mono Fuel to last the mission... But just barely... We really do need an extra Mono fuel tank I think. Simply adding mono fuel to the list of resources for all the storage parts should be fine. Or maybe making the RCS parts double their thickness to store more?