ElWanderer

March 3, 2019

Woo! Pity I missed most of that and lost all sound on the stream I was watching.

February 20, 2019

17 minutes ago, Devoblue said:

But

https://ksp-kos.github.io/KOS/structures/vessels/crafttemplate.html#attribute:CRAFTTEMPLATE:FILEPATH

Ooops, sorry, that's my mistake. I was thinking about two things at once and thought you were after the boot file path!

February 19, 2019

1 hour ago, Devoblue said:

I'm trying to make use of CraftTemplate:FILEPATH but I get suffix not found? I hadn't tried using it before. Is this a new problem related to the latest release?

For my test vessel "aaa 3.1" which is in "aaa 3_1.craft" and also for "aaa" which is "aaa.craft"

This works:

PRINT KUNIVERSE:GETCRAFT(SHIP:NAME, KUNIVERSE:ORIGINEDITOR).

This doesn't:

PRINT KUNIVERSE:GETCRAFT(SHIP:NAME, KUNIVERSE:ORIGINEDITOR):FILEPATH.

In any event, I was just looking for an escaped name to save a log file as, so don't need the whole path.

I don't see that suffix in the documentation for a craft template:

https://ksp-kos.github.io/KOS/structures/vessels/crafttemplate.html#structure:CRAFTTEMPLATE

February 16, 2019

1 hour ago, RizzoTheRat said:

The target ship is only 3 or 4 meters long, while the offset looks to be 200 or so. I wondered if it gives an approximate location when you're further away, but it draws the target in the right place and updates when 200m away so must know where it is.

This weirdness rings a bell, but I may be thinking of something else. I could've sworn I read once that the other ships' positions are not calculated super-accurately until you get close enough to them, which can cause them to appear to jump. Will have to Google it.

Edit: first Google result:

Are you using time warp?

February 14, 2019

12 minutes ago, RizzoTheRat said:

As someone who learned programming in BASIC what I really need is a GOTO, but that's the kind of talk that gets you dragged outside and lynched by programmers

Yeah trigger variable has the same problem as my previous attempt, it will only stop the loop at the end of the current run through, if the loop still has things that use the Target after it's been lost it falls over.

I've set it to stop the loop when the distance is less than 0.5 for now but the fact I'm having this issue suggests there's a better way I should be doing the flow control.

It could suggest you're doing too much in one loop or that your final approach velocity is a bit high... For comparison, my loop ends when the docking port changes to any state that isn't ready, and I've never noticed this kind of problem. Then again, my loop is fairly simple, especially compared to the initial route calculation before approach. My final approach velocity is 0.2m/s once within a few metres.

I guess one goto-like approach would be to stick the loop contents into a function and load it with checks that can return early if the target becomes invalid midway through.

February 13, 2019

24 minutes ago, funkheld said:

Hi good afternoon.

I built two computers at the Pegasus:
- Pegasus CPU: CompoMax (test)
- Pegasus CPU: CompoMax (test1)

How can I load a program in each one now?
test.ks and test1.ks

Thank you.
greeting

If you've already put the ship on the launchpad, you can right-click on each CPU part and open a terminal. In each terminal, you'd then copy over and run one program. e.g. you might type COPYPATH("0:/test.ks","1:/"). RUNPATH("1:/test.ks"). in one terminal.

In general, its easier to set these up as boot programs that get loaded and run automatically. You do that in the ship editor (VAB/SPH) by right-clicking on the part and selecting a boot script. Note that first you need to have a folder named Boot within your Ships/Script directory, and have the programs you want to run in there, as it's that directory that is scanned when the VAB/SPH build editor starts. Note also that this choice of boot file(s) will be saved against the particular ship design so would need to be repeated for new designs. https://ksp-kos.github.io/KOS/general/volumes.html#special-handling-of-files-in-the-boot-directory

February 12, 2019

41 minutes ago, RizzoTheRat said:

How do I store it as my own variable?

Instead of "SET TARGET TO port." do "SET my_variable TO port."

In my case I do something like "LOCAL target_port IS pickTargetPort(TARGET)." where the function loops through the ports on the input vessel and picks the "best" one. Actually I store the target in a variable too in case the player accidentally deselects or changes it during docking.

February 12, 2019

38 minutes ago, RizzoTheRat said:

So supplementary question, is there a way to figure out the port facing vector for further away than 200m? What I'm trying to do is manoeuvre the ship to a point a given distance away from the docking port along the port facing vector so I can come straight in to dock.

Do you have the same problem if you store the port in your own variable rather than using TARGET? That's what I do, and I've never had this problem, though my rendezvous is usually less than 100m out.

Also, I imagine that if you are far enough away that the target ship hasn't been properly unpacked/loaded (I forget which one is which right now), you may not be able to do anything as KSP won't know where the port is. You could carefully play with the various load distances if that turns out to be a problem.

February 12, 2019

5 minutes ago, Xd the great said:

As in what exactly do i have to type.

"lock steering to prograde."

Literally, what's inside the quotes is what you would type in the terminal (or into a script) to lock the steering to orbital prograde (surface prograde would need srfprograde instead of prograde).

Is there more to your question than that?

February 10, 2019

14 minutes ago, funkheld said:
Hi good afternoon.
can you start with kos two programs independently please?

Thank you.
greeting

program 1:
	until false 
{  
  PRINT ":".
  PRINT ROUND(SHIP:ALTITUDE,0).
  PRINT ":".
  PRINT ROUND(SHIP:APOAPSIS,0).
  PRINT ":".
  PRINT ROUND(SHIP:PERIAPSIS,0).
  PRINT ":".
  PRINT ROUND(SHIP:VELOCITY:SURFACE:MAG,1).
  PRINT ":".
  wait 0.1.
}
	
program 2:
	until false 
{  
  wait 0.1.
}
	

You can have two separate CPU parts with two different boot scripts, yes. Each CPU would run its own program.

January 26, 2019

20 minutes ago, infinite_monkey said:

Is the program state saved in a quicksave? So if I use FMRS, do stage separation, continue to orbit, then jump back - will a program stored in stage 1 continue where it was at (stage separation + FMRS save delay)?

No, but the local hard drives retain their state. So you can save commands to a file on the local hard drive that put you into the right state to resume after a reload.

My approach is fairly simple most of the time, saving "SET run_mode TO x." to a file that can be run during start-up to get the current run-mode. You can store quite a few variables if needed, though. The complicated bit is writing the main program in such a way that it can recover gracefully from a restart using this data.

Edit: you would need the craft to run the mission from a boot file to do this automatically, else you'd need to run the program manually on switching back.

January 24, 2019

9 hours ago, meyerweb said:

This did not work for me. Does there need to be a `WAIT 1`. before it or something?

Hmmm. My shared boot script does have this first, so possibly:

WAIT UNTIL SHIP:UNPACKED.

January 23, 2019

13 minutes ago, squidgeny said:

Alright I'm a bit new to this and I'm sure this has come up before so I apologise in advance but...

How do I open the console on the launch pad if the computer is inside a shroud? I can't click on the part

You can get one to open automatically if you stick the following in a boot file:

CORE:DOEVENT("Open Terminal").

January 14, 2019

7 hours ago, FloppyRocket said:

The situation is something like this? (please comment)

That looks right to me.

A note on VECDRAW (as it's much easier to talk about with a diagram): vectors A and C originate at the ship's current position, or V(0,0,0), so the origin parameter of the vecdraw would be V(0,0,0).

Vector B originates at the central body, so you would need to pass in BODY:POSITION as the origin parameter.

January 13, 2019

@FloppyRocket

It looks like you are mixing up two different vectors. SHIP:BODY:POSITION will give you a vector from your ship's current position to the middle of the central body (e.g. Kerbin). POSITIONAT(SHIP,t) will give you a vector from your ship's current position to where it will be at time t. (aside: the good news is that if your orbit is elliptical, both vectors are relative to the central body, so you don't have to take into account the motion of the central body in the meantime). That is, it'll be a vector between two points on your orbit. You want both vectors to be to (or from) the central body to be able to compare them.

To convert between the two, you need to need to add/subtract the BODY:POSITION vector (note the SHIP: at the beginning is optional). I'm not great at explaining this bit, sadly. I think to get the predicted vector pointing towards the central body, you would need to use BODY:POSITION - POSITIONAT(SHIP,t).

Printing out the angles is good debugging practice, but I would also advise you to try drawing the vectors on the screen using VECDRAW(). I found it easier to keep track of what was happening that way. Of course, drawing vectors that don't originate at your current position is a learning curve in of itself...

January 12, 2019

On 1/11/2019 at 7:38 PM, Tyko said:

It's gone back and forth. In some versions the launch pad was exactly at zero, other times it wasn't. The runway is at 0.04857, so while it is different, it's not zero'd out either.

I'm pretty sure the KSC model is centered on the launch pad because when I moved the KSC once and did the calculation myself it was the launch pad, not the runway that was at exactly zero. If the KSC were centered on the runway then my calculations would have been off as well.

Blimey, I had no idea. I only checked the precise launch pad co-ordinates in one version when testing a kOS script, and it never occurred to me that it could change from version to version.

January 11, 2019

On 1/10/2019 at 3:18 PM, Tyko said:

Anyone notice that the KSC doesn't point due East anymore?

According to Kerbal Engineer a craft on the launch pad is sitting at 0.09721 degrees instead of 0.00000. It's a small annoyance, but easy for @SQUAD to correct. I feel like every couple of updates someone messes with the KSC location and doesn't include enough significant figures to properly define 0.00000 degrees.

Is this definitely a change? From checking in the past, I thought the runway was at 0 and the launchpad slightly to the South of the equator, but I could be remembering incorrectly.

On 1/10/2019 at 3:18 PM, Tyko said:

Duplicate

Duplicate

January 1, 2019

49 minutes ago, sevenperforce said:

WE WANT PICTURES!

[BUFFERING...]

December 18, 2018

12 hours ago, [email protected] said:

The problem is the capture. I have a 95% capture rate for mum, and thats eyeballing it. The problem is I'm right on with the suggested orbit, but no capture. I have no problem getting an orbit, if I can just get the capture. Should I make my orbit exactly on or exceed it. I haven't figured out what the 2 grey markers on the Minimus orbit are. Are they the best capture point the closer together they are?

Sounds like you are missing the sphere of influence altogether. You can't capture if you don't get close enough.

The two grey markers indicate closest approach. You want to plot a manoeuvre and tweak it in all directions until you find which way (or ways) causes the markers to get closer and closer together. If you change your trajectory such that you will go into the planet's sphere of influence, the display will change to show a periapsis at the target. You can keep tweaking until this periapsis is nice and low, then burn the manoeuvre.

December 8, 2018

Choo Choo!

Will there be hooks so a mod can query how much delta-v a ship/stage has?

December 7, 2018

13 minutes ago, scimas said:

Yeah, boot script works. I was just wondering if it was possible to have it deactivated right from VAB, like extendable antennas. But it isn't a big deal.

I don't think that's possible. Would be nice to have.

I would say I'd use it if it were... but actually I generally need my CPUs to run on the launchpad to download all the scripts they need when there is a guaranteed connection, in case there is no signal when they're run up "for real" later in the mission.

December 7, 2018

49 minutes ago, scimas said:

Is there a way to have a processor turned off when launching a rocket from KSC?

Give it a boot script that checks the vessel's status and turns off the processor if it is pre-launch, IF(SHIP:STATUS = "PRELAUNCH"), or whatever condition you want to check for. That way it'll stay running if powered up after launch.

Turning off a script's own processor is as simple as: CORE:DOEVENT("Toggle Power").

Turning other CPUs on or off is a bit more complicated, and probably involves part tags to identify things.

November 27, 2018

4 hours ago, EpicSpaceTroll139 said:

UPDATE: I may have found a solution to my problem, using EVENT instead of ACTION. Will have to check when I get home

If it is available as an option on the part action window (i.e. what pops up when you right-click on a part), it should be available as an event.

As you've seen, the availability of actions is a bit hit and miss, and depends on what the KSP devs decided to make actionable.

November 10, 2018

My Bible: http://www.braeunig.us/space/orbmech.htm#position

The game data files/wiki should contain each planet's mean anomaly at game start.

The time elapsed divided by the orbit period gives you the number of orbits. Multiply by 2π to get that in terms of mean anomaly and add to the first part. (if the answer is over 2π, keep subtracting 2π until it's in the 0-2π range).

Now convert mean anomaly to true anomaly (via eccentric anomaly). You will need the orbits eccentricity for this (again, this should be available from the wiki or possibly even in-game). Edit: ah, actually it may be that converting mean anomaly to eccentric anomaly and then true anomaly requires iteration (e.g. Newton-Raphson method) rather than a single calculation. I did write a bit of a Java program to work out where all the planets would be given a time point from a save, but that was many months ago and I seem to keep forgetting important details. At least I can link to it:

https://github.com/ElWanderer/kOS_scripts/blob/MissionBuilder-draft/src/com/elwanderer/missionbuilder/OrbitUtils.java

If you have the true anomaly, you can plug this into an equation that gives the orbital radius at that point, if you already have the semimajor axis and eccentricity (equation 4.43 in the link above).

November 4, 2018

By@Luovahulluus
You can pass parameters into a program. In the past it was a case of RUN filename(param1, param2, etc.). I imagine you can do something similar with RUNPATH, though I've not checked the syntax. Edit: yes, this is valid e.g. RUNPATH(filename, param1, param2, etc).

The program you call needs to declare the parameters you'll be passing in.

I believe a program can RETURN, so you'd have something of the form MYVARIABLE = RUN(X,Y). Again, I've not checked that in the docs yet. If it doesn't work, you could always set-up a global in your outer program then get the inner program to alter it.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Posts posted by ElWanderer