Dunbaratu

Well, whatever the problem was, the 0.60 update seems to have fixed it. Thanks.

Of the two ways to interpret what you said, the one that you claimed to have "never said" is in fact the more obvious one. You can't really blame other people for failing to read your mind and guess you meant the less likely meaning. The reason you had to follow up what you said with further explanation was because of how you phrased it. For "around" to mean moving around something, rather than "near to" it, is the more obvious meaning. If you didn't mean that it's not other people's fault that they didn't read your mind to figure that out.

Supposedly, but in practice it gives an error when you try.

I just tried with KSP 0.23.5 (with the previous MCE code, not the new update that's not quite released yet) and discovered one thing that's behaving differently: Now when I use the "circled arrow" button to revert flight, I don't get my money back.

Good news. I just downloaded the 0.23.5 KSP update (the NASA asteroid update) and kOS appears to be working just fine without any need to change it. I was a bit worried given what happened in the past with the 0.22 -> 0.23 update.

Yeah it seemed pretty clear how to change the file, which says you compare 'or/and' expressions together, rather than saying you 'or/and' the compare expressions together. I just was unclear on how to run the parser generator after that. Thanks. I'll probably get a chance to try this tomorrow.

You can get the name of the engine, but then you have to know which engines are named what, making it impossible to write a script that will generically work regardless of what mod parts are installed. The script has to know the names of all the SRB parts installed in the game.

On a side note, the "#" operator isn't particularly useful because of how it only works with hardcoded literals in the code like that. It would be useful if you could do this: foo#y using a variable for the index. (But since kosscript programmers don't directly control the datatype of numeric variables, it would have to be implemented to deal with cases where y is implemented in a floating point format - i.e. it should handle when y = 2.0 just as well as when y = 2. ). Right now the only way to access an element of a list in a truly generic varying way is with the list's for loop. Even if you know ahead of time "I want to access the Nth element where N is stored in a variable", you still have to iterate over them from the beginning to get to it. I was considering starting to contribute to the code by trying to implement this after I get a handle on the parser generator tool used by the code.

Marionapp: I was looking into trying to make contributions that might end up meaning adding some syntax, and I noticed that there appears to be a file in the source code that looks for all the world like input for a parser generator - kRISC.tpg - It seems to be a for a parser generator called "tinyPG". Is there a good rundown of which of the C sharp source files are auto-generated by tinyPG and therefore I should NOT be trying to edit them directly? I was going to try looking at the order of operations for AND versus comparators and it looks like to work in that area I'll need to install tinyPG and use it.

In the past I had a very convoluted algorithm for detecting when to do an asparagus stage and it had gotten messy and ugly as I tried adding more support for solid boosters and different sorts of arrangements. It was based on trying to watch the rate of losing consumables (sometimes by measuring fuel, other time by measuring mass), and deciding that if the rate of consumption drops it must be because an engine stopped. But I realized that some of the new features added more recently to kOS solved this problem ages ago and I just didn't notice. // Check for flameout of any of the existing engines: set numOut to 0. list engines in englist. for eng in englist { if eng:flameout { set numOut to numOut + 1. }. }. If numOut is > 0 after running that code, then at least one engine is trying to be throttled that isn't working because it's starved of fuel, so it's time to asparagus stage. Changing the code to use this instead reduced the bytecount of my script by about 1000 bytes or so. I thought 'flameout" was just for jet engines starved of air, but it works on rockets too, and triggers when any starved resource is stopping the engine from working (lquid fuel, solid fuel, oxidizer, whatever). But it turns out you do need to have the throttle > 0 in order for KSP to flag the engine as flamed out. If your throttle is idle, then eng:flameout will always return false no matter what.

The most useful thing for what you want is probably the 'lock' command. If you can think of a math expression to respond to the changing conditions, it works well. For example, to lock altitude to the altitude you started the code at, something like this might work: // current altitude at the start of the program. set startAlt to altitude. // The desired vertical speed - want it to be negative if above startAlt, or positive if below startAlt. // In this example, the vertical speed desired is 1 m/s per 10 meters off from the target altitude. // You might have to tweak that up or down. lock seekVSpd to (altitude - startAlt)/10. set curPitch to 0. until 0 { // loop forever - probably need a good end condition for a real program. set curPitch to curPitch + (seekVSpd-verticalspeed)/5. set ship:control:pitch to curPitch. }. I haven't tried compiling that or anything. It's just a first guess at how I might do an altitude maintainer for an airplane. It's supposed to adjust pitch more strongly the further the verticalspeed differs from the desired verticalspeed, where in turn the desired verticalspeed is itself dependant on how far off you are from the desired altitude. Its sort of a lazy attempt at something like a PID controller. Give it a try and see what's wrong with it and go from there. I doubt it will work out of the box.

It should be possible. You can read your verticalspeed with the term 'verticalspeed', so you should be able to write something that adjusts the pitch depending on the vertical speed, to try to seek a vertical speed of zero.

A lot of what's in the wiki is out of date and becoming more and more incorrect as time goes on. It was basically created because Kevin Laity didn't want to make comprehensive documentation so a fan-made documenting project was started but we were mostly guessing by trial and error how things worked. Documentation is in the plans for the newer iteration of kOS so keeping the wiki up to date is no longer a top priority.

Well, then I have no idea. You are correct that config.xml is autogenerated by the mod when you run it. In fact, the fact that it's missing helps indicate something : that the mod didn't actually run.

I'm worried about market saturation from the early release being so far in advance of the final product. Is there a danger that SQUAD will find that by the time the game is finished everyone who would potentially have wanted to buy it already has bought it early, so there's nobody left to sell it to and the income dries up?

Well at first you said you *wanted* to point prograde or retrograde which is why I gave the answer I did. Now you're talking about the situation where you emphatically do NOT want to do that. Those markers moving around the navball really are the true retro/prograde markers, and it's correct that they do that when you get near zero vertical velocity. What you really want is not "how do I steer retrograde" but rather "how do I NOT steer retrograde in this one instance"? And here's how I did it ages ago, although there may be something coming soon that makes it easier: http://kos.wikia.com/wiki/Tutorial_-_KOS_0.61_and_above:_Finding_surface_dynamic_information It rotates the frame of reference using matrix math so it turns your velocity:surface into north, east, and up components instead of KSP's native xyz which is a mess. In a nutshell, you use tfXYZToEnu from that page to take any vector (in this case velocity:surface) and transform it into tfE, tfN, and tfU for its east, north, and up components. Once you've split it into east, north, and up, then you can work out what you want to do with that information, for example, if you're going east at 5 m/s, and north at -5 m/s, then that means you're drifting on a heading of 135 degrees (southeast). For a general solution, the compass heading you are drifting on will be derivable by using the trig function arctan2(tfN,tfE). Once you have the compass heading, you can do something like this: lock steering to heading(-compass,85). to aim mostly up, but tilted 5 degrees off opposite of your current surface drift.

Short answer, get into orbit, then try experimenting with these statements to see what they do: lock steering to mysteer. // followed by these, try them one at a time and watch the effect: set mysteer to velocity:orbit. set mysteer to (-1)*velocity:orbit. set mysteer to velocity:surface. set mysteer to (-1)*velocity:surface. (The reason for using the intermediate "mysteer" variable instead of locking directly to the vectors is because of a bug in how the interactive terminal works. The parser breaks when you try to lock the same variable a second time from the interactive terminal, and you'd have to toggle power on the unit to fix it.)

Ah yes. The files on Spaceport have everything, but not up to date with the latest development changes. To get the latest version, from scratch, you get the spaceport zip first, and then on top of it install the github zip, which replaces the .DLL code, but doesn't ship with all the other files.

Has anyone had this problem with 'lock steering'? As long as my craft has some mass located radially away from the central axis, helping give it a lot of rotational inertia, the steering algorithm seems to be able to correctly work out how to dampen its inputs to stop oscillations: But once I drop that raidal mass away so the entire ship consists of only parts centered exactly on the axis, like this: Then the steering keeps oscillating the roll back and forth, as if a pilot was pressing "Q" for a full second, and then "E" for a full second and then "Q" again and then "E" again and so on. The oscillation seems to progressively get bigger and bigger the longer I leave the steering locked. It starts out small, and then after a few minutes it's oscillating through a range of about +/- 70 degrees. It seems the steering code doesn't handle the case very well where the rotational control available from the torque wheels is large compared to the rotational inertia resisting it. It doesn't just overshoot and move a bit too far, the oscillations build on each other and get bigger and bigger.

Are your files for kOS arranged in exactly the following way? Your base folder may be different from mine., but everything from "KERBAL SPACE PROGRAM" on down should be the same: Folder PATH listing for volume BOOTCAMP Volume serial number is EA40-27E1 C:\PROGRAM FILES (X86)\STEAM\STEAMAPPS\COMMON\KERBAL SPACE PROGRAM\GAMEDATA\KOS | Readme | +---Flags | kOS-Logo.png | +---GFX | FontFinder.png | font_sml.png | monitor_launch.png | monitor_minimal.png | +---Parts | \---kOSMachine1m | model.mu | model000.mbm | model001.mbm | part.cfg | \---Plugins | kOS.dll | \---PluginData \---kOS config.xml

The exact words in the title are "around other celestial bodies". What celestial bodies did you mean, then, if not planets. I don't understand what you're saying.

I'm not sure I'd agree, having been a developer of stuff myself. If you release everything to too large an audience immediately, before it's tested, then you get the same exact errors being reported again and again and again, clogging up the issue tracking list. The big problems that everyone runs into get reported by everyone. Instead you first release to a small population, discover the big problems that are so common everyone hits them, fix those problems, and then for round two you release to a larger population to find the slightly less common bugs, then for round three a much larger population, and so on. Even open source projects stored on public sites like github, that theoretically have every little change released to everyone in the public at once, still tend to flag the code as "developers only for now" and then promote it to "beta for testers" and only after a while do they promote it to "ready for the public now". You can access the newest code at any time but are warned in a big way that a lot of it doesn't work yet and unless you're trying to become part of the development process by making bug reports and participating in the QA of it, you should still stay away. (That if you're just trying to use it as an external end-user, it's not ready for that yet.)

A tiny example of pseudocode to generate some content procedurally but not randomly: for x = 1 to 10. print x. endfor. A tiny example of changing it to add some random starting point to it: x = milliseconds since epoch. startX = rand(x) for x = startX to startX + 10 print x. endfor. Stop pretending just so you can have an argument to derail the suggestion. That's two tiny examples of algorithms that generate admittedly boring content, both procedural, one fully deterministic, and one only partly so because the algorithm began from a more random starting point. Using an algorithm that doesn't give the same deterministic content every time because it's seeded. By a value as close to randomly generated as is actually possible on a computer without using inputs external to the computer like waiting for how long it takes for a particle to be ejected from a block of radioactive material.

The idea that randomly generated content must necessarily be boring is also a misunderstanding of how random content can be generated. It can be generated within limited parameters and with good algorithms operating from the random seeds to guarantee interesting landforms and interesting stuff is made. Take Minecraft as a good example. Not only can the entire terrain be re-genned from just one seed number, but it doesn't make flat uninteresting terrain.

The comptronix part looks very similar to other parts. Go to the "control" tab and hover over all the parts there to make sure none of them are it. If you're sure that it's not there, then check your installation as follows: Is the part located here? Kerbal Space Program -> GameData -> kOS -> Parts -> kOSMachine1m -> You should see these files there: model.mu model000.mbm modeloo1.mbm part.cfg If you don't see that in that location, then you probably exploded the ZIP file in the wrong place.