Dunbaratu

http://ksp-kos.github.io/KOS_DOC/ The wiki is slowly becoming out of date but much of what it says is still true. For now. The last thing that was updated on the Wiki was to just change some of the hyperlinks to point at the newer Spacehub, github, and forum pages. Other than that nothing has really changed or kept up to date. To a certain extent, the motivation for that Wiki was the fact that Kevin Laity hadn't really documented things much and so people in the user community tried to document it instead, using trial and error to learn how things work and then posting the information for others to read. @erendrake seems to be much more interested than Kevin was in making sure documentation gets updated and accurately released with new changes, putting the docs on github too so they can be version tracked and updated just like code. I much prefer this to the Wikia approach. While I like wikis and am comfortable with them, what they don't do a good job of is letting you release the docs as a set of pages all tagged together as being "version xx", so you can have both a historical and a recent and an in-development set of docs. Instead wikis only let you have *the* current set of docs, each of which has an individual history you can go back and look at, but not a collected together history of the set of all of them. Besides, Wikia's version of mediawiki is terrible, IMO. The Wikia website is full of advertising banner boxes with badly made nonstandard javascript crud in them. I often had to quit the page and reload it to get a different set of ads in order to get the rest of the page to render right.

IF AG1 { PRINT "ACTION GROUP 1 IS ACTIVE". }. // or ON AG1 SET VAR TO TRUE. Action groups act like toggles. if viewed as a boolean var they flip between true/false on each keypress. The ON command triggers on the next flipping regardless of if its a flip on or a flip off.

In general this is a variant of the math problem "find the line of intersection between two planes." That line of intersection is where the ascending and descending nodes are. In this case the two intersecting planes are your oribtal plane (which can be found by the normal vector obtained by a cross product of orbital velocity and ship's position relative to the planet), and the plane defined by the planet (or moon)'s equator, which always happens to be the XZ plane. That's just a hint to help. I don't remember the answer myself right now but it should be findable with some google searching. But what you actually want is MUCH harder to calculate. You don't just want to know the position of the AN and DN, but how long it will take you to get there. And there's a reason those math answers are not readily available to come by with a bit of searching. It's because that's actually a hairy *ugly* math problem. If your orbit is perfectly circular then it's easy. But if it's any arbitrary eccentric ellipse then forget it. Calculating how long it will take you to get to a location on your orbit path typically involves running a numerical approximation algorithm rather than having a nice perfect analytical answer. This is a thing that KSP itself does under the hood, and it's why predictions of ETA times are a bit fluttery. There's a tradeoff between accuraccy and speed where to give a properly static precise answer would require running the algorithm too long for speedy updates in the user interface. But if you *really* want to do it, and *really* want to jump into the hairy math, here's a link to look at: http://mathworld.wolfram.com/KeplersEquation.html A solution that might be easier to implement is instead of trying to calculate the ETA, is to realize that you really only want to know when the ETA is getting close to zero so you can do your burn then. To a certain extent, you don't care if the program can figure out whether the intersection is 5 minutes versus 15 minutes away. What matters for making the algorithm work is that the program needs to know the difference between and ETA of 0 and and ETA of 20 seconds or so. So perhaps you can work it out by monitoring a math expression that will tell you if you are or are not at the AN right now, and saying something like "wait until this vector is pointing in nearly the right direction" instead of "wait until such and such a time." For example, if you can find the line of intersection of the two planes, as described above, then you'll be on that line when your position vector relative to the planet' center is perfectly parallel to that line, which you can work out from the dot product of the two vectors.

Here's something you may find useful to help update the syntax highlighter. I built this by running a bash shell script pulling stuff out of the kOS C# code downloaded from github. I did it because I want to have a VIM syntax highlighter and I was tired of trying to update it by reading the code by eyeball. It's *almost* got everything. There's a few suffix terms it doesn't have because they were processed in the C# code using a different sort of code design (I was looking for: case "SUFFIXNAME": in the file, but sometimes the code hands off the task of looking at the value to a deeper function, and my bash grep/sed tools didn't catch those.) # terms.txt # This file is automatically generated by Autogen.sh - do not edit manually. # [SYNTAX_TERMINALS] + - * / ^ E AND OR TRUE FALSE >= <= = > < SET TO IF ELSE UNTIL LOCK UNLOCK PRINT AT ON TOGGLE WAIT WHEN THEN OFF STAGE CLEARSCREEN ADD REMOVE LOG BREAK DECLARE PARAMETER SWITCH COPY FROM RENAME VOLUME FILE DELETE EDIT RUN LIST REBOOT SHUTDOWN FOR UNSET BATCH DEPLOY ( ) { } , : IN # ALL [A-Z_][A-Z0-9_]* [0-9]+ [0-9]*.[0-9]+ @?"""""" [^""]*"" . ^$ S+ //[^N]*N? [BOUND IDENTIFIERS] ABORT AG1 AG10 AG2 AG3 AG4 AG5 AG6 AG7 AG8 AG9 BRAKES CHUTES GEAR LEGS LIGHTS PANELS RCS SAS CONFIG LOADDISTANCE WARP ALT_APOAPSIS ALT_PERIAPSIS ALT_RADAR ANGULARVELOCITY COMMRANGE ENCOUNTER ETA_APOAPSIS ETA_PERIAPSIS ETA_TRANSITION INCOMMRANGE MISSIONTIME NEXTNODE OBT SHIP STAGE STATUS TIME VESSELNAME TARGET HEADING VESSELNAME SESSIONTIME VERSION VOLUME:NAME [SUFFIXES] [Suffixes of BodyAtmosphere] :BODY :EXISTS :HASOXYGEN :SCALE :SEALEVELPRESSURE :HEIGHT [Suffixes of BodyTarget] :NAME :DESCRIPTION :MASS :POSITION :ALTITUDE :APOAPSIS :PERIAPSIS :RADIUS :MU :ATM :VELOCITY :DISTANCE :BODY [Suffixes of Config] [Suffixes of ConstantValue] :G :E :E :PI [Suffixes of Direction] :PITCH :YAW :ROLL :VECTOR [Suffixes of ElementValue] :NAME :UID :PARTCOUNT :RESOURCES [Suffixes of FlightControl] :YAW :PITCH :ROLL :FORE :STARBOARD :TOP :ROTATION :TRANSLATION :NEUTRAL :MAINTHROTTLE :WHEELTHROTTLE :WHEELSTEER :BOUND [Suffixes of GeoCoordinates] :LAT :LNG :DISTANCE :HEADING :BEARING [Suffixes of ListValue] :ADD :CONTAINS :REMOVE [Suffixes of Node] :DELTAV :BURNVECTOR :ETA :PROGRADE :RADIALOUT :NORMAL :ORBIT [Suffixes of Orbit] :APOAPSIS :PERIAPSIS :BODY :PERIOD :INCLINATION :ECCENTRICITY :SEMIMAJORAXIS :SEMIMINORAXIS :TRANSITION :PATCHES [Suffixes of DockingPortValue] :STATE :ORIENTATION :DOCKEDVESSELNAME :TARGETABLE [Suffixes of EngineValue] [Suffixes of PartValue] :CONTROLFROM [Suffixes of SensorValue] :ACTIVE :TYPE :READOUT [Suffixes of ResourceValue] :NAME :AMOUNT :CAPACITY [Suffixes of SpecialValue] [Suffixes of StageValues] [Suffixes of Timespan] [Suffixes of Vector] :X :Y :Z :MAG :VEC :NORMALIZED :SQRMAGNITUDE [Suffixes of VersionInfo] :MAJOR :MINOR [Suffixes of VesselSensors] :ACC :PRES :TEMP :GRAV :LIGHT [Suffixes of VesselTarget] :PACKDISTANCE [Suffixes of VesselVelocity] :ORBIT :SURFACE :SURFACEHEADING [FUNCTIONS] BUILDLIST ABS CEILING FLOOR LN LOG10 MAX MIN MOD RANDOM ROUND ROUNDNEAREST SQRT VANG, VECTORANGLE VCRS, VECTORCROSSPRODUCT VDOT, VECTORDOTPRODUCT VXCL, VECTOREXCLUDE ADD CLEARSCREEN LOGFILE PRINT PRINTAT REBOOT REMOVE RUN SHUTDOWN STAGE TOGGLEFLYBYWIRE COPY DELETE RENAME SWITCH PRINTLIST BODY BODYATMOSPHERE CONSTANT HEADING LATLNG LIST NODE Q R V VESSEL ARCCOS ARCSIN ARCTAN ARCTAN2 COS SIN TAN Note: I think the underscores in terms like ETA_APOAPSIS are a way of encoding a "fake" suffixed term - in which the underscore in the source code is really a placeholder for a colon lookup, but the thing to the left of the colon "the ETA:" isn't really a real object so therefore APOAPSIS isn't really a real suffix, even thought it looks like one to the user and should be highlighted like one in the editor.

Seriously, I only suggested this because I didn't see asteroids giving any sort of science points whatsoever. The fact that they do but only if you approach them with a manned mission and EVA near the asteroid was not something I'd ever have gotten around to guessing. I was primarily concerned with making them worth *something* instead of *nothing* and was suggesting the biome thing as a way to implement it. The fact that there was a hidden way in which they already *were* worth something but I hadn't stumbled on it yet changes everything. That makes the entire reason I first posted moot.

I never said you remove the rotation cheat afterward. You inserted that and pretended I'd said it in order to make up this strawman of what I suggested.. Argue honestly instead of against a strawman you've invented and your argument goes away, because both the "remove rotation cheat" and the "some players are angry for getting their comfortable cheat key stolen" steps only exist in your strawman of what I proposed. Take them out and Scenario 1 stops looking bad compared to Scenario 2. There's lots of cheats already that you can use if you don't want to play the game hardcore. Leaving the rotation killer as a cheat makes it clear that it's a cheat. Leaving it as a side effect of an incomplete on-rails system makes it look like it's not a cheat.

Yeah that was in Fallout 3. The only two options were: 1- Continue letting mad scientist / little girl mentally torture the test subjects for all eternity as the life support machines kept their bodies alive. This is the outcome the game called "evil". 2- Free them from this mental torture by killing all of them. This is the outcome the game called "good". Those were your only two options, and it felt like a bogus forced choice. Surely the option I'd have taken would be: Keep them alive for now while I go find a better computer expert who can come back and find a way to extract them from the VR without killing them. But the first part of that option - keep them alive for now - flags your karma as "evil" because there's no way to tell the game that you're only doing it temporarily so you can come back and free them later and let them live. Once you decide to kill them, you can't come back later and change the outcome if you end up learning more about how to work the VR. That's an unalterable permanent choice. If you keep them alive, you can still keep both options open. That's NOT a permanent choice. The dilemma was forced and artificial. When the choice between two bad outcomes is based on the player's character being dumber than the player and unable to think of an option the player thinks of easily, then I feel zero guilt over the outcome. Because the outcome wasn't my choice. My choice was the one the game developers didn't implement.

Okay I didn't have time yet to view the entire video but here's two things I can see so far that might be problems: 1 - You're using an older version of kOS than I am. I'm operating on the prerelease from the development thread. That's evident from the fact that you can use the EDIT command and it works (in newer versions it was dropped in favor of just editing the code outside KSP in a text editor which is what everyone seems to do anyway). This is also probably why you can use the "-" character in a filename. The parser changed in more recent versions and no longer will accept a filename that isn't a valid identifier (it has to follow the same naming rules as a variable name now). Just a heads-up warning - I think you'll have to change your filenames when the next update gets released. 2 - You appear to be trying to change a parameter passed in to a subprogram in the hope that doing this will change the value in the parent program. That doesn't work. You can't do something like this: incrementProg declare parameter thingy. set thingy to thingy + 1. mainProg set val to 1. print "value before: " + val. run incrementProg( val ). print "value after: " + val. You appear to be trying to write code as if that would print this: value before: 1 value after: 2 When in fact it would print this: value before: 1 value after: 1 All variables in kOSscript are global *except for* program parameters. Those are local to the subprogram only, and are passed by value, not by reference (if you know what that means). IMO, the ability of kosscript to pass information into and out of subprograms could use an overhaul. Currently there's no such thing as a return value from a subprogram, and no such thing as passing by reference, so the only way the subprogram can do any mathematical work on behalf of the main program is for it to store the results in global variables that the main program already created before the subprogram was called. Otherwise the main program can't see the results. But that's for another time. There's other bugs to squash first.

It depends on how forced it is. Some games, like Elder Scrolls and Fallout New Vegas (no suprise as the same people designed the plots for both), force false choices on you that require you to pick between two choices that are both bad, and because of the constraints of the game you're not allowed to think outside the box and reject the dilemma and pick a better option. You're railroaded into "To get access to the rest of the game content, choose bad thing A, or bad thing B." When that happens my sense of guilt is gone. I get annoyed at the game designers and think "up yours, this is a fake choice, and the effects of my choosing it are your fault, not mine." An example of this was the civil war in Skyrim. You either side with a racist faction of Nords or a faction of a draconinan Empire that's appeasing racist Elves. You have to pick one or other to advance that plot, and thus it's a false choice. I don't feel like that as much in KSP, where when people die it feels like my fault (unless triggered by a bug like the space kraken). To feel guilt, I have to feel in control. Otherwise what happens is the game developer's fault, not mine.

Thanks for the reply. But the only thing I've ever seen in the menu when I rightclick the asteroid is "target center of mass". No sample option showed up in the menu, even when clamped to it with the claw. Does it require that a kerbal exists on the vessel at the time, like surface samples do? If so that would explain why I never saw it. All my ARM missions have been unmanned so far. And it sounds from what you're saying that if you only ever do unmanned ARM missions you'll never see the one and only way that asteroids offer science points.

The solution to the "twist the ship" problem is the same solution that to some extent makes a lot of the reason for mutli-docking ports moot in the first place: Allow a player to rotate the docking port connection post-atachment. Often times the reason for the multiple docking port arrangement is to force the alignment to be oriented the way you want, which is hard to do by hand with one central docking port because the control over roll rotation is too touchy and you can't get it to stop where you want it (even with caps lock on). (i.e. you tap the "Q" key for as short a time as is humanly possible and you're rotating too much to the left, then you tap the "E" key for as short a time as is humanly possible and you're now rotating too much to the right. The controls are oversensitive and that makes it impossible to get the darn thing to fully stop. This stems from the fact that the keyboard controls are all or nothing. They don't have an analog "push just a little bit" ability. It may be easier with a joystick.) But at any rate the fix is to stop locking the roll rotation permanently when docked. Allow docking rings to have a small electric motor that slowly rotates on the roll axis, to bring the two ships to the exact alignment you want. Something like this: The right click menu would have a button for "lock/unlock roll". When unlocked, the ports are still attached, but now you can rotate the attachment a bit, then lock it again when done.

Or, rather than continuing to support one buggy behavior in order to use its side effect to counter another buggy behavior, why not just have a "kill rotation cheat button" as a separate thing? Using the side effect of time warp that stems from the fact that time warp models rotation incorrectly, as the means of having a kill rotation cheat seems the wrong way to go. By the way, I've had lots of phantom rotation bugs, but none that were so bad in magnitude that they weren't stoppable by SAS.

There may be something buggy happening in my installation, because people are responding as if I was asking to *reduce* the amount of science available because asteroid science is too much. But in reality I thought I was asking to *increase* the amount of science available because currently asteroids aren't worth anything at all for science. If they're meant to be worth something then either I have a bug or I'm misunderstanding what's going on. When I gather science while attached to an asteroid, I only get the science for where the asteroid is, without any bonus at all for the fact that there's an asteroid there. (In other words, a science experiment while grabbing an asteroid that is in Minmus's SOI is the same thing as just being in Minmus's SOI period, with or without an asteroid.)

I like the proposed interface because it is very unobtrusive and adds no screen clutter at all - it just slightly fades the color of the line that was already on screen before the proposed change.

Asteroids should be separate science "biomes" (Darn it "biomes" is a very bad choice of terminology. grr.) so you can model the idea of the research learned from sending probes to study them. i.e. you see things like this in the science center log: "+40 science for Materials Study In space near a Class A Asteroid." "+30 science for Materials Study Attached to a Class D Asteroid.". To prevent an exploit in which the fact that asteroids infinitely spawn, potentially leading to infinite sources of science points from asteroid missions alone, I propose just having one or two "biomes" per type of asteroid, as hinted at by the examples above (one for "near" the asteroid (within the 2.5 km on-rails limit) and one for "docked with" the asteroid. If you mined out all the science points from a Class C asteroid already, then you'll have to seek out a class A,B,D, or E asteroid to get more asteroidy science points. Getting yet another Class C would be like going back to the same Mun crater again with the same sorts of diminished returns.

Granted the phantom rotational accelerations are quite annoying, but I doubt they'd be "in play" for an object on rails. Rotation on rails would by its very nature have to contain no rotational acceleration (for the same reason that there's no linear accelerations when going on rails - the math equations are only modeling momentum. That means velocity and position, but not acceleration.) The math wouldn't even be capable of *storing* any changes to the rotational momentum. It's assuming a constant rotational velocity is happening while on rails. So as long as you kill the rotation with SAS prior to going on rails, there won't be any phantom rotations while on rails. The parts of the physics engine that are causing the phantom rotations aren't active and the time warp rotation would only be capable of remembering what the rotational velocity was at the moment you went on rails. It wouldn't be capable of altering it while on rails. (So if you are rotating slowly at 2 RPMS when first going into rails, you'll still be going 2 RPMs when you come out. You won't have accelerated via phantom rotational forces to something like 100 RPM or anything like that because those forces don't exist while on rails.)

It's hard to diagnose a program with key parts of it not being shown. You're showing cut and pasted sections and the problem may be outside those sections. But at any rate, I notice you tried to call you program by this name: TrmVel-Tlv-Control-Uns And I don't think that's a legal name. A program name must be a valid identifier and the definition of an identifier is this regular expression: [a-z_][a-z0-9_]* It doesn't look like it allows minus-signs in the identifier. Just underscores. I have no idea how the parser is managing to read this: RUN TrmVel-Tlv-Control-Uns(AltRng, TrmVel, Tlv). and not end up barfing with syntax errors. I imagine it would interpret that as "run something called TrmVel, without any arguments, then subtract the value of Tlv from that, then subtract the value of Control from that, then run a function called Uns, with arguments AltRng, TrmVel, Tlv, and subtract that result." And since there's no such program called TrmVel, no such function called Uns, and subprograms aren't implemented with return values (yet?) so there shouldn't be anything to subtract FROM after doing a run.... I have no idea how it's not complaining like crazy when it sees that line.

That's good to hear. I admit I've gotten lazy at times and exploited timewarp to stop a rotating object that I really shouldn't have been able to stop, but that's a hole that really should be plugged.

I haven't played GC2 but I have played Endless Space, and I have to say that Endless Space has one very big problem, and it's highlighted by the name. It's Endless. As in you get bogged down in slow slow slow progress as your empire grows. You seem to asymptotically approach winning without actually getting there, as the closer you get to winning, the longer the admin per turn takes. And like happens in a lot of 4x games, delegating some of the admin to the AI is just a sure formula for losing. To keep your civilization from doing stupid things, you have to control it manually. All Of It.

A sensible solution is to not even have two different popup windows. Have one, that works like this: Has a mission ended OR a crash happened? If so, we're going to be popping up a window about that. Fill the contents of that window with the following: IF mission has ended successfully, show the mission success widgets and information. ELSE the mission has not ended successfully, then it's a crash, so show the crash/revert widgets and information. Now, make that window appear. That way you don't get both dialogs at the same time. If there's both a crash and a success together at the same time, the fact that it's a success overrides the fact that it's a crash, in terms of deciding what to ask the user to click on. The windows stop being "this is the mission success window" and "this is the crashed window". Instead they become "this is the 'its over' window, regardless of why it's over. Depending on why it's over, the contents of the window are different."

To repeat what I already said, the windows are layered on top of each other in the wrong order to be able to actually do that. The button you're telling me to click on FIRST is covered up by the window you're telling me to click on second. If the windows weren't semi-transparent I wouldn't even be able to see the button you're telling me to click on first.

What does Ship:Body:Body:Velocity return? That would be, I'd assume, the velocity of your SOI body's parent relative to your SOI body. (i.e. if Ship is in orbit around Kerbin, it's the velocity of Sun relative to Kerbin.) So Ship:Body:Body:Velocity would be the inverse of the velocity you want - just multiply it by the scalar -1. If that works (I haven't tried it) then I have no problem with the system as it would at least be using a consistent frame of reference. On the other hand, if BOTH Kerbin's velocity AND the Sun's velocity are both reported as V(0,0,0) *at the same time from the same position* then I'd consider that a bug, as it means the frame of reference isn't remaining consistent for all measures returned.

It looks nothing like Basic. The terminal does, however, look like a bit like a C64, specifically the font. But I'd prefer it if it *really* looked like a C64. That would be great for nostalgia: 40 columns, 24 rows, cyan color on blue background.

The "old KSP window" the message is talking about is not one of the two windows I'm referring to. So technically it's not 2 windows that appear, it's 3. I just didn't mention the KSP's window as it's not relevant to the problem. The problem involves 2 popup windows that are BOTH from MCE. One is the window you show, the other is the window the MCE uses to show you the mission reward. The problem is that the "mission succeeded" event and the "you have crashed" event occur at exactly the same time when the mission has a crashgoal, and so MCE triggers both of these MCE popups. And although the last line says "if your [sic] doing a CRASHGOAL Mission Ignore This Screen!!" the problem is that you can't ignore it when it's on TOP of the mission success popup. You have to make it go away first because it's obscuring the mission success window under it.

I've noticed more than once now that there's a problem with crashgoal missions. There's a dialog box that MCE pops up whenever your ship crashes, asking if you want to accept the results of the crash or if you want to undo it and revert. There's a dialog box that MCE pops up whenever you successfully complete a mission and you have to click on it to get the reward payout. In a crashgoal mission, of course, both of those are going to happen at the same time. If I tell it that I'd like to accept the crash (of course I want to accept it - that was my goal), and then click the confirm button on the reward for the mission, then what seems to happen is that I DO get the money for the mission, but I do NOT get the science points for it. (And then it does get flagged as a completed mission so if it's not a repeatable mission then those science points are forever unattainable.)