KevinLaity
Members-
Posts
130 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by KevinLaity
-
I've used Damned Robotics and the values it saves are global to everything. That's why it doesn't support action groups. I'm trying to find a way to save and load data into a craft file at the time it's saved or loaded in the VAB. That way, you could one class of ship that always gets launched with the needed programs loaded, and another class of ship loaded with a completely other set of programs.
-
One problem with that is that it would apply to every ship you launch from that point on, which may or may not make sense for everybody. And it would take us further away from having the system make sense inside the Kerbal universe. I didn't want the Archive drive to transcend time and space the way it does now, I just didn't have a good way for it not to. When you revert in KSP, everything in the universe reverts to the way it was at that time, except the Archive drive. I consider this a bug, not a feature. The reason the Archive drive exists is to give you a place to back up your files and share files between craft. If you're looking for a way to do fast development iterations, I recommend using F5 before you launch and F9 after. But yes, that does make it a pain if you also want to also backup to the Archive at the same time. My ideal would be that you configure the loadout of your unit while you're in the VAB, including assigning autoexecs that apply to individual craft or whatever you like to it. But again I haven't found a way to do that. Clearly something is needed here to make this less painful. I'd like it to be something that makes sense in-universe. But if this is the only way, then I'll do that.
-
What I'm getting at is this: Each unit is a virtual computer. If you set the autoexec on your ship, and then later launch another ship (or revert to launch), the autoexec would then be blank.
-
Wouldn't it make more sense to run the splash screen FROM the orbit program, like a subroutine? And then return to the orbit program to finish. If chaining programs is needed I can probably come up with some kind of BREAK AND RUN command. How do you envision autoexec working?
-
Crap, sorry! I'm relatively new to git and thought it was auto adding everything for me. I've added those now.
-
Okay, it looks like this was the result of some experimental things I was doing. Sorry! I didn't mean those to go into the upload. Please grab 0.46!
-
I definitely am seeing this bug with one of my launches. That's a weird one.. stay tuned
-
Hmm I did mean to keep it case insensitive. Its because I made a new Regex and forgot to specify RegexOptions.IgnoreCase. I won't put out a fix just for that, but it'll be rolled into the next version. Uhhh... I have no idea! I don't think anything I did in 0.45 could explain that...
-
Try 0.45, I made AND And OR require whitespace on both sides, and fixed the order they're processed in.
-
Actually the system thinks the OR in tOrbit is an OR operator. I'll work on this bug next
-
Hmm, you should be able to save directly to the Archive volume without having to use copy, even on a fresh install. I'll do some more testing on this.
-
I don't know if this is in reference to addressing individual parts in code, if it is: Listing the parts is not the issue. This problem is, I need to assign an identifier to each part. KSP gives each part a "unique ID" already. However it's quite long, random, and CHANGES every time the ship loads. If you write a program that addresses part# 11708957121, that program will be useless when you save and come back. So the next thought is "ok, I'll assign one myself!" but then I have to bring that number back later. So I assign them in order. Starting from the root part, part 1 gets #1, part 2 gets #2 and so on. This should work fine and I can rebuild it later after you reload. So far so good. And then you go and dock two ships. Now I have a conflict, there are two #1's, two #2's etc. AND I can't rebuild that later, one of the root parts is no longer a root.
-
Holy crap, good work!
-
Which version are you using? I observed this problem in 0.40 and released a fix for it. Can you check if this folder exists? <KSP Folder>\Plugins\PluginData\Archive kOS can't write to Archive if it doesn't. 0.41 fixed that by ensuring that that folder exists on startup.
-
Try 0.43, you can use STAGE:LiquidFuel, which will give you the total fuel that is connected to all of the engines which are currently active. However, this value will not read zero if you're doing asparagus staging, since you'll have one or more engines that still have fuel at the time you want to stage. I haven't worked out a reasonable way to refer to individual parts in code. A lot of this kind of stuff will open up when I find a way.
-
To anybody having this kind of problem: Check out 0.43. There was an issue regarding compound statements in that they wouldn't get recalculated when used in WAITs and LOCKs.
-
It's something I haven't tested fully yet. The intent is to have it nestable yes, but I can see people are having a lot of issues. Currently doing an IF inside an UNTIL works well. Fixing up if statements is something I want to do in the next big release, along with boolean operators (AND, OR)
-
For this and some of the other bugs reported here today, try 0.42 which I uploaded just now. http://kerbalspaceprogram.com/kos/
-
I'm looking at fixing your first issue now. Your second example didn't crash for me.. EDIT: My testing didn't include the colon in your string. It looks like my methods of looking for colons aren't beefy enough. Regex to the rescue!
-
Whoops! I didn't increment the version number on the terminal. 0.4 creates the Archive folder the first time it saves a file, or you can create it yourself, but yeah there is a lot going on in that video, I don't blame you for missing it. EDIT: Problems occur when the Archive folder doesn't exist yet, please grab 0.41 from spaceport now. It creates the archive folder the first time you load up a ship with a kOS unit on it.
-
Cancelling horizontal velocity would be a tough one right now. Right now you can get the total surface speed but not lateral direction of travel. I need to think about how to solve this one.
-
Already taken care of, see the 0.4 release video:
-
This does seem to happen occasionally. Have you tried closing and re-opening the terminal? Is it happening 100% of the time?
-
It'll be in 0.4, coming this weekend!
-
The only interoperability you get right now is via action groups. I don't believe MechJeb exposes any of its functions to action groups