ElWanderer
-
Posts
397 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by ElWanderer
-
-
2 hours ago, Warp11 said:
I'm having a problem with the "lock steering to" command. Sometimes when I use it point at a maneuver node the controls for one or more axis just spasm around wildly, burning through all my precious RCS fuel. It also does not settle down eventually, the control just keeps oscillating quickly.
I can't really tell when this happens and when not, so its really difficult to pinpoint the problem. SAS is off :).Is this a known issue?
I'm running KSP 1.2.2, RT 1.8.9, kOS 1.1.0 and Realism Overhaul v. 1.0.3.0. MechJeb is also installed.
Thanks a lot!
To add to infinite_monkey's answer: if you are running Realism Overhaul then you probably have no (or practically no) reaction wheel torque. The steering manager is known to struggle under such conditions.
Also, are you locking to a particular vector or are you providing a direction with a sensible top vector? If you don't provide a top vector, it'll default something and quite possibly try to rotate the ship right around as well as hunt for the new forevector, which can result in a complete mess, though I think this has been improved relatively recently (only rotates once you're facing down the right vector), but I've lost all track of kOS version numbers!
-
1 hour ago, NewtSoup said:
Your mistake is a KOSProcessor is not a part it's a part module
if you make a simple ship and tag your kOS part (kal9000 in this case) with the tag "brain" the following will work:
print ship:partsTagged("brain")[0]:getModuleByIndex(0):volume:freespace.Is it guaranteed that the kOS CPU part module will be at index 0? A safer way would be to find out what the module is called and replace getModuleByIndex(0) with getModule("module_name")
As to how to find out what the module is called, I would try PRINT CORE:NAME. Sometimes I just put a ship on the launchpad and run a script to print out all the part names and their modules...
PS thanks, I had missed getting the free space with a tag/part as the starting point from my own answer.
-
CORE gets you the CPU module which your script is running on. Modules that are a kOS CPU have a VOLUME suffix.
So CORE:VOLUME:FREESPACE should get you the free space on the volume used by the CPU part module.
If you want to check other volumes, it is a bit more awkward. If you have named a volume, you can use VOLUME(volume_name):FREESPACE. I think I found by default the name is unset, so my multi-CPU scripts name them all on start-up. You can loop through all volumes by looping through all the CPU part modules (e.g. LOCAL pl IS LIST(). LIST PROCESSORS IN pl.)
-
4 hours ago, lajoswinkler said:
Aww...
I think each day the window starts a bit later. Like an hour later, something like that.
Looks like the window opens two minutes earlier (3:31 local time)
-
Same time tomorrow...?
-
10 hours ago, garwel said:
Great, thanks. I had this idea too, but haven't tested it yet.
It looks like the documentation is incorrect on this issue then. This page mentions DockingPorts as well as other suffixes as "listable keywords" that can be used with LIST ... IN command.
Does LIST DOCKINGPORTS IN someListVariable work? That's all that page is talking about, I think, and will only get you the ports for the active vessel. To get the ports for another vessel, you can't use that format.
-
52 minutes ago, garwel said:
Ok, I have another question. I'm trying to write a script for docking two kOS-controlled vessels and I need to look at the other vessel's parts, specifically its docking ports to find eligible one(s).
I tried this:
LIST DOCKINGPORTS FROM TARGET IN targetPorts.
and this:
LIST TARGET:DOCKINGPORTS IN targetPorts.
But both cause a syntax error for the FROM keyword (in the first case) or the colon character (in the seconds case). The same statement for the current vessel appears to work ok.
What am I doing wrong and how do I loop through target vessel's ports?
The LIST ... IN form only works for a few, pre-programmed cases. Any ship object has a DOCKINGPORTS suffix that returns a list of ports. To loop through them, do something like:
FOR p IN TARGET:DOCKINGPORTS { // do something with each p. }
-
12 hours ago, garwel said:
How do I use a quote mark (i.e. " symbol) in a string? I tried escaping it with a backslash or with doubling it, but it doesn't seem to work. I haven't found it in the documentation.
CHAR(34), but you'll need to append it to the string.
e.g. SET myString to "He said " + CHAR(34) + "no" + CHAR(34).
That'll set myString to 'He said "no"'
-
7 hours ago, infinite_monkey said:
Yeah, but how do I say "steer x deg from vector va to vector vb"? I guess that's possible with the rotate functions somehow?
A vector cross of the two vectors will give you an axis (as it'll be at 90 degrees to both input vectors) vector around which you can rotate (ANGLEAXIS function) va by X degrees towards vb. I have an example of this somewhere in my ascent code (to avoid straying too far from surface prograde) if you'd like code to look at. The hard part is working out which way around things are to avoid going the wrong way... partly as KSP/Unity's coordinates are left-handed.
Edit to add a link: https://github.com/ElWanderer/kOS_scripts/blob/f5e22ce98925976497ee9acc5216c56c4f7d8372/scripts/lib_launch_common.ks#L345
-
7 hours ago, Ultimate Steve said:
I'd love to see (in the medium term when mass isn't as much of a problem) a BFS (or anything, really) with a permanent grand piano in front of the window.
"We're about to dock with the ISS"
"Oooh, quick! To the piano!"
*starts playing The Blue Danube, badly*
"Oh well. Makes a change from Knees Up Mother Brown..."
-
@MaltYebisu
SpoilerSpoilerPosting on a mobile, can't get rid of these
I know that when I first started using kOS, when you did "RUN X" twice in a row (without rebooting in between), you'd get the same results even if you'd changed the contents of X in the meantime. It's as if the file is cached when the run command is issued. From memory, there was a technical explanation about how files are parsed and their symbols stored when run, but I can't remember the details.
It's entirely possible that's still the case. One way around it is to vary the name of the file e.g. by appending a counter. That said, I'd echo @Pand5461's advice of checking the actual file contents first.
-
1 hour ago, Inspierio said:
How can I do that?
I've tried giving a nametag and calling it but it refuses to work
How are you "calling" it? Are you using the syntax from the kOS docs (bearing in mind that you get a list of parts from SHIP:PARTSTAGGED, so have to iterate) e.g.
SET allSuchParts TO SHIP:PARTSTAGGED("my nametag here").
// Followed by using the list returned:
FOR onePart IN allSuchParts {
// do something with onePart here.
}
Copied from:
https://ksp-kos.github.io/KOS/general/nametag.html#examples-of-using-the-name
-
2 hours ago, jbakes said:
Okay so today I wrote some other scripts and it works fine. Yes the fps drop only happens when running a script. This is the script that keeps lowering the fps. I'm guessing my problem lies in the pitch change script. Probably something to do with it continuously looping that's bogging down my computer.
until Apoapsis > 75000 {lock targetPitch to 88.963-1.03287 * alt:radar^0.409511.set targetDirection to 90.lock steering to heading(targetDirection, targetPitch).}This bit is quite expensive in terms of operations. You don't need to lock the steering continuously in a loop; just once. Take out the until apoapsis bit, and stick a wait until apoapsis > 75000 below the steering lock.
Haha - totally beaten to it.
-
2 hours ago, jbakes said:
I'm having a major issue where my frames gradually drop from 100 fps to 5 fps in about 15 seconds. I'm running a simple as you can get script with no mods on the latest version of KOS and KSP. Any ideas? It was not happening a few days ago and I haven't changed anything.
Does this only happen while the script is running? What is your kOS "instructions per second" / CONFIG:IPU set to? Can you share the script?
-
3 hours ago, Gilead said:
I believe the radial mounted chutes add more drag to your capsules, thus slowing them more than the capsule with only an Mk-16.
I think that'll be dwarfed by the drag from the extra capsules having an abrupt 0.625m to 1.25m transition (capsule top to decoupler) and an open 1.25m node (decoupler to nothing). Admittedly, I can only view the video at poor resolution on my mobile phone screen at the moment, so I'm somewhat guessing at the parts. Either way, I agree that the extra capsules slow down just in time because they have considerably more drag than the prime capsule.
Solutions include making the prime capsule more draggy and/or lighter (if you have a heat shield, remove all the ablator... or even the entire part), adding chutes that open earlier (drogues) or pitch over more during ascent so that you have a flatter trajectory. The last one gives you more time to decelerate. I think these have all been mentioned already.
I would add that this type of craft is inherently risky - if the individual capsules get too far away from each other, those outside the active craft's physics bubble will be deleted. Admittedly, that's something like 23km now, so you should be okay.
My other advice would be to orient to normal before firing the decouplers. That brings everything down with a more similar periapsis, but on slightly diverging courses. That reduces the chance of running into your own dropped stages. That said, (argh, out of place quote follows, stupid mobile interface)
5 hours ago, IILEOII said:The other 2 pods are slowed enough by reentry for the chutes to deploy.
I MUST be doing something wrong for the final pod not to work,this may not be appropriate for this particular craft if the extra pods have tourists and can't orient back to retrograde for reentry.
-
23 hours ago, Mokmo said:
Is there any way, stock or not, to know the orbital parameters of a rescue mission ?
Hmmm, this information isn't displayed on the map beforehand, but it might be available in the save file (and therefore findable manually or via a mod)... unless the mission parameters aren't actually generated until you hit accept. That would be a pain.
I'd be interested to know what the deal is.
-
Hmmm, a different possible answer: as you have clearly got quite a few mods that may have affected this, it's possible one of them has implemented the behaviour described in the junior docking port's flavour text i.e. that they're too small to transfer crew through.
That's never been true of the stock game, though. In stock you don't need to have a 'route' between two modules to transfer crew, they just need to be on the same vessel.
-
Right (or possibly left?) click on the hatch of the part you want to transfer crew out of. You should get a list of occupants with options to transfer or EVA them.
Docking ports have nothing to do with transferring crew, by the way; you can transfer crew between individual modules of a craft that has no ports.
-
23 minutes ago, Inspierio said:
I tried using SHIP:THRUST
Yes, that won't work as it doesn't exist. Vessels don't have a THRUST suffix; only engine parts do.
Do you know how to get the list of engines and loop through them looking for those that are active? You can get the current thrust for each active engine and add them up.
Alternatively, you could tag the engine(s) in the VAB and look for just parts with that tag in your code.
-
Just now, Inspierio said:
I've tried doing that but kOS replies with it being undefined
What exactly have you tried?
MAXTHRUST and AVAILABLETHRUST are both vessel attributes, but from memory only MAXTHRUST has an alias that means you can leave off the vessel (defaults to SHIP) - hence you need to use SHIP:AVAILABLETHRUST. THRUST is a part/engine attribute, so you would need to have looked up the right part to use it.
-
14 minutes ago, Inspierio said:
I'm using Tundra Exploration so there's an option to toggle between central engine and all engines
I don't know what that is, but it sounds like the engines are a single part with mode switching (I think I've seen a SpaceY engine that did that). Sadly... I don't know how that would affect the values of MAXTHRUST and AVAILABLETHRUST. It shouldn't be too hard to test, though. If there is a single part involved, you could also get the current THRUST from it.
-
34 minutes ago, Inspierio said:
When I disable all the engines except the single core, the script still thinks it has all it's engines on. What's the problem here?
if runmode = 27 { // Suicide burn lock STEERING to velocity:surface * -1.//Point retrograde set landingRadar to min(ALTITUDE, betterALTRADAR). set GRAVITY to (constant():G * body:mass) / body:radius^2. lock TWR to MAX( 0.001, MAXTHRUST / (MASS*GRAVITY)). set TVAL to (1 / TWR) - (verticalspeed + max(5, min (250, landingRadar^1.08 / 8)) ) / 3 / TWR. // add realism by activating gear at slow speeds if ABS(VERTICALSPEED) < 20 { gear on. } if ABS(VERTICALSPEED) < 1 { brakes off. lights off. RCS off. SAS on. lock throttle to 0. lock steering to up. print "LANDED!". wait 2. set runmode to 0. } }How have you "disabled" them? If you have set their throttle limiters to 0, that would not affect the value of MAXTHRUST. SHIP:AVAILABLETHRUST is better in that situation as it takes limiters into account.
-
1 hour ago, RizzoTheRat said:
However the burn starts with a vertical velocity of about -7 and ends up around +15, so I'm clearly to far nose up, despite the throttle not being set slightly below 1 so I should have less vertical thrust than the calculation assumes.
How fast are you going horizontally when this begins? At orbital velocity, the gravity you are trying to cancel out is effectively zero. By the time you are hovering, you do have the full force of gravity to counter.
I'll look up the calculation for 'effective' gravity...
Edit: okay, so your orbital velocity sideways can be used to calculate a centripetal acceleration. You then need to subtract that from local gravity when trying to determine how much you need to accelerate upwards:
LOCAL v_x2 IS VXCL(UP:VECTOR,VELOCITY:ORBIT):SQRMAGNITUDE.
LOCAL cent_acc IS v_x2 / (BODY:RADIUS + ALTITUDE). -
46 minutes ago, Black-Two- said:
How do I get the slope angle from above? Do you compare the target site with the surrounding area or something?
Yes, I use something based on what (Cheers) Kevin Gisi did in Kerbal Space Programming episode 42 or 43:
Calculate three points on the ground (A, B, C) a couple of metres away from the target site, in different directions (forming an equilateral triangle in my case). I then take vectors A->B and A->C and cross them, to get a new vector that will point at 90 degrees to the apparent slope of the ground i.e. if the ground is flat, it'll point straight up. The vector angle between that resultant vector and the up vector at the target point gives you the slope angle. Excluding the up vector from the resultant vector gives you a horizontal vector that points down the slope, which is probably the best direction to go in to look for somewhere flatter. That said, I have some breakout code that jumps half a kilometre away if it looks like we've got stuck in a hole or something!
Though a work in progress generally, I do seem to have the slope code in a finished (i.e. documented state!)
https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_slope_readme.md
https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_slope.ks
kos trouble
in KSP1 Technical Support (PC, modded installs)
Posted · Edited by ElWanderer
This is correct. Anything under SHIP:SENSORS needs the relevant science part to be attached to work.
https://ksp-kos.github.io/KOS/structures/vessels/vesselsensors.html