ElWanderer
-
Posts
397 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by ElWanderer
-
-
11 hours ago, kerboman25 said:
The craft that it worked on was just a regular rocket without anything attached on the side.
I am speculating somewhat wildly on a small amount of information, for which I apologise in advance, but I'm just wondering if it's gone a bit weird due to staging off the root part.
i.e. Did you build your shuttle in the SPH then attach it to the stack in the VAB? If so, is the root part on the stack, not the shuttle? If so, does changing the root part to be the shuttle's cockpit do anything to avoid the issue?
Edit: the other question I meant to ask is whether you can control the shuttle manually after staging (both if you fly the whole ascent manually, and if you run kOS then kill the script post staging). That might help narrow down the cause as to whether it is KSP itself or kOS that is being weird.
-
On 23/01/2018 at 10:35 AM, kerboman25 said:
i'm almost certain that it has something to do with the decoupling clamp on the side because i tested the program on a craft that does not use this and it works fine.
Is the craft that worked identical other than the type of decoupler, or are there other differences?
Does KSP remain focused on the shuttle when you stage/decouple, or does it follow the external tank instead?
Does your shuttle have a connection, control and the ability to steer once staged?
What versions of KSP and kOS are you running? I'm aware there have been problems in the past with the kOS steering manager going into a bad state when vessels are created and destroyed, particularly with craft docking and undocking.
As you can probably tell, I'm just throwing out things to check/investigate.
-
That might work if you lock AG_ID rather than set it.
-
6 minutes ago, kcs123 said:
You don't need return command with triggers. Also, if you want for trigger to be repeatable, each time some event happen, not just first time, you need preserve keyword.
Returning true is meant to be equivalent to using the preserve keyword.
https://ksp-kos.github.io/KOS/language/flow.html#preserving-with-return
-
52 minutes ago, kcs123 said:
Is it possible to find out what is targeted in reliable way ?
Does TARGET:TYPENAME help?
-
5 minutes ago, jbakes said:
I'm new to KOS and programming in general so I don't really understand these commands. I'm guessing LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv". is going to log my data to some file. Where would that file be located?
The root of 0: aka the archive is your Ships/Script directory inside your KSP install. So that example would save to something like C:\Program Files (x86)\Steam\Steamapps\common\Kerbal Space Program\Ships\Script\log\ascent.csv
-
39 minutes ago, jbakes said:
Can anyone tell me how to log some flight data? I'm creating an ascent profile script and I need to log some data to tell how efficient I am. For instance knowing like my pitch and altitude throughout the flight or even velocity. Just so I can graph it. Thanks in advance.
LOG my_variable TO log_file_path.
If log_file_path is on the archive (e.g. "0:/log/testrun1.txt") you'll need to have a connection back to KSC (assuming you're playing with CommNet enabled or Remote Tech installed), but it will persist after mission end.
If you want to make it easier to graph it, you can concatenate the various values with commas into a single string variable, then log that into a .CSV file e.g.
LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv". -
1 hour ago, Zhetaan said:
KSP doesn't appear to use a common epoch for all vessels (that would be the obviously simple choice of 00:00:00:00:00.000, the start time of the game); if I were forced to guess, I would say that the epoch value it stores is the time of launch
I believe the epoch time is reset at regular intervals for the active vessel. I have been told it was deliberately done this way as part of the effort to avoid the Kraken (i.e. keeping the current vessel at the centre of the game universe to avoid floating point errors building up too high).
This is second-hand knowledge, I've not checked it myself, but it's what I was told when I asked if the epoch was the beginning of the game (i.e. time 0).
-
5 hours ago, Spazem said:
The only thing i can think of is even though both orbits are lined up fine in the tasks it says Longitude of ascending node. Its currently at 180 but i cant for the life of me change it.
Ah, yes. That means you are orbiting in the wrong direction. The simplest manoeuvre to align with the target orbit is to burn twice your current velocity magnitude, retrograde, until you're going the same speed in the opposite direction. Around Minimus, velocities are low, it is fairly cheap to change, so it may work. There are more efficient methods (generally raising your apoapsis very high, then changing direction there, then lowering the apoapsis back down) if you need them.
-
8 hours ago, scimas said:
Another thing I need help with, has anyone figured out a way to obtain the local orientation of the surface, basically a normal vector to the surface of the celestial at current position? I don't need exact normal vector at every point, approximation over, say, about 2 m^2 area is good enough too. I want to try to improve my landing and rover control scripts using it.
My slope library is here: https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_slope.ks / https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_slope_readme.md though all the hard work was taken from episode 42 or 43 of Cheers Kevin's Kerbal Space Programming series on YouTube.
-
Once you're in space, you don't need to do any spaceplane-specific calculations (unless visiting Laythe!) Find out how much delta-v it will take to get where you want to go from LKO from a delta-v map, then use the rocket equation to work out how much fuel you'll need for your dry mass of 70t. Add some for luck. Then add the mass of that to the dry mass you're plugging into your SSTO equations.
e.g. if you need 50t of fuel to get to Duna's surface (or to get back after refueling), you effectively have a spaceplane with a dry mass of 120t to get into orbit of Kerbin.
This changes if you can refuel in LKO, as then some of the fuel capacity used to get into orbit can be reused to go places in space.
Edit: ah, wait. Adding engines and fuel tanks will increase your dry mass, reducing the delta-v you have once you reach orbit, so you would need to iterate adding extra fuel to account for the extra mass, then check if you need extra engines/fuel to get into orbit, and so on until the difference is negligible.
-
6 minutes ago, garwel said:
Actually, you can use AIRSPEED for magnitude of surface velocity.
Ah, now that I did not know!
-
1 hour ago, MinimumSky5 said:
I'm having trouble with this quite simple launch program (I'm building it in stages, so it isn't complete yet)
set throttle to 1.0.
stage.
when velocity > 50 then{
set steering to heading(90, 85).
}when the program runs, it only seems to run the when command once, rather than wait for the velocity, as it says "program ended" just after the rocket gets off the launch pad. Any ideas?
The WHEN ... THEN ... syntax does not initiate a loop. Instead it sets up an interrupt that will be triggered when the condition is met. But the program must be running for any triggers to fire.
The traditional thing to try first is to put "WAIT UNTIL FALSE." at the bottom of the script, so it never ends. Or rewrite your code to use WAIT UNTIL ...
Notes:
I don't think you can "set" steering, you need to "LOCK STEERING TO ..."
I think you'd need to check "SHIP:VELOCITY:SURFACE:MAG > 50" (VELOCITY is an object that contains a surface velocity vector and an orbital velocity vector, in turn you need to call MAG to get the magnitude of the vector).
-
1 hour ago, windystig said:
Hey
As it is for the shuttle it doesn't matter whether the angle change is towards or away from the planet. The burn is using the OMS engines, which are mounted at a 15 degree angle so if i point directly at NP then my actual direction when i burn will be 15 degrees off. So i need to 'nose up' in relation to the NP, regardless of what that means in relation to the planet. I did try using the rotation formula but all that did was lock me to 15 degrees above the horizon. Not 15 degrees about where the NP was.
Someone posted about this on the kOS reddit recently:
https://www.reddit.com/r/Kos/comments/77x3n3/script_to_deal_with_crafts_where_the_thrust_is/
Whoa, the forum initially tried to embed the entire reddit post within this post...
-
3 hours ago, Steven Mading said:
I think that's a duplicate of this: https://github.com/KSP-KOS/KOS/issues/1905
-
Before v1.0, I had a spreadsheet that simulated a vertical ascent second by second (or some fraction thereof). Back then, drag was predictable (and highly unrealistic) so this was not only possible with relatively simple calculations, but actually gave useful results. The introduction of a realistic drag model (amongst other things) changed all that.
These days, I'd go with trial and error for anything that involves the atmosphere - the game is itself the best way of simulating. You can even justify (if you feel the need to) a few reverts by pretending you are running simulations ahead of actual missions.
-
Apoapsis is a floating point number. Chances are it will never equal 300000.
Also, the games proceeds at a certain number of ticks/updates per second. Your apoapsis could easily be under 300000m one update, then over 300000m a split second later.
Better to use a greater than check. WAIT UNTIL APOAPSIS > 300000. -
1 hour ago, ebigunso said:
I remember hearing somewhere that I can write script in other languages, that I can then use on kOS, but I can't find any website that explains how to do this. Is this actually doable, and if so how?
(Unrelated quote. I can't get rid of the reference above though)
That sounds more like kRPC than kOS.
-
10 minutes ago, scimas said:
Yeah, I checked, KSP does shows zero resources in the stage.. that's super weird. Guess I have to figure out other variables to write staging logic.
kOS devs, please take 'fixing' this as a feature request if you can!
I think it was deliberately changed to be consistent with what KSP displays, in an effort to solve various problems, so it's unlikely to get changed back to be inconsistent again (unless KSP itself changes!) There is at least one issue requesting a change to the current behaviour on the kOS github: https://github.com/KSP-KOS/KOS/issues/1908
-
58 minutes ago, scimas said:
Is this a bug or intended behaviour? The resource values for a stage (STAGE:RESOURCES) are all zero unless the next stage has a decoupler. I'm running into a problem because of this.
The context is this: I'm placing a satellite in orbit. The stages are as follows (0 - upper engine, 1 - stack decoupler, 2 - fairings, 3 - lower engine). When I perform a 'STAGE' command on launch pad, the resources in the current stage are detected as zero
. And yes, I am waiting a full second before I check for the resource values. My script is basically staging once (current stage 3) and then staging again (current stage 2) because of this.
Could someone confirm this either as bug or intended (and if its intended, I would appreciate if you tell me the reason too)? Thanks!
KSP itself has a habit of showing 0 stage resources under certain conditions. If kOS agrees with what KSP displays (toggle the "stage view" in the resources tab), then this isn't a bug in kOS. It is frustrating, though. I had to switch from using STAGE:RESOURCES to something more complicated to calculate current stage delta-v.
-
29 minutes ago, garwel said:
Is there a safe way to call Part:GetModule when I don't know if such module exists? I have basically to do this work twice: first to iterate through all the Part:Modules to find the one I need and then to request it via Part:GetModule; otherwise I risk getting an error. I wish there were Part:HasModule command or GetModule returned false or something if nothing was found.
As PART:MODULES is a list, you can use CONTAINS() instead of iterating yourself.
IF p:MODULES:CONTAINS(mn) {
LOCAL m IS p:GETMODULE(mn).Where p is a part and mn is a module name (string).
Edit: yes a PART:HASMODULE() check would be a bit more obvious and save a few characters...
-
7 hours ago, theSpeare said:
Need help, kOS doesn't seem to work with RemoteTech at all.
Testing with a manned 1-man capsule, see setup below. Console returns "Signal lost. Waiting to re-acquire signal." Adding antenna changes nothing.
Do you have a probe core? I don't use Remote Tech myself, but usually these issues go away if people add a probe core and/or an antenna.
-
On 08/20/2017 at 0:47 PM, Vaulter said:
with 1.1.2 I've found that script that contains "///////012345678901234567890123" hangs.
But if I put only this line into new scripts it runs.
Test script:
line #85 is the cause.
very strange.
Possibly related to this known issue? https://github.com/KSP-KOS/KOS/issues/2080
-
4 minutes ago, FumbeiNumbie said:
I could take some screenshots but the deviation is usually less than 0.00001% so I don't think it will make any difference. I just though that it's odd that you get different readings without leaving the launchpad.
On the one hand, I don't know exactly which "readings" you are referring to. On the other hand, that is a tiny difference that could have lots of explanations, not least of which would be the natural inaccuracy of floating point representation and arithmetic, and that Kerbin is always rotating and revolving, so the game engine is having to adjust all the time (though this may be a case where Kerbin remains fixed and the engine rotates the universe around it).
. And yes, I am waiting a full second before I check for the resource values. My script is basically staging once (current stage 3) and then staging again (current stage 2) because of this.
Making History & 1.4 Image Preview Collection
in KSP1 Discussion
Posted
From what I remember of the devnotes, I think that's 0.625m, 1.25m, 1.875m (NEW), 2.5m, 3.75m and 5m (NEW)... what they call the parts internally would be even more guesswork!