Dunbaratu

If you're going to necro a thread at least read more than one post back into it. What I was talking about was on topic given the proposal of the previous post.

I think what Camcha was asking for was the ability to name the file with a variable, like so: set filename_string to "logfile1". set print_string to "this is some text in the file". log print_string to filename_string. And the reason you can't do that is that the filename string is read as a bare word right now, so it would make a file called "filename_string.txt" if you did that. Unfortunately the only way to fix this breaks backward compatibility a bit. In order to treat the bare word filename as an identifier variable name to look up, you have to distinguish it from the bare word string filename literal used now. And that would mean changing it to put quotes around it when it's a literal, like so: log "some text" to "literal_filename". log" other text" to variable_filename. Although you *could* do the self-modifying code workaround, it's really confusing since the self modifying code is itself also a LOG command.

The problem with that workaround is that it breaks out of all sub-programs, not just the current one. If your script calls a script that calls a script, there's a need to differentiate between quitting the current program and quitting all programs. kOS definitely could use some sort of an "exit". The reason I haven't pushed harder for it though is that its wrapped up with the idea of having functions - what is the difference between a return and and exit, does an exit return an exit code like a real program does, etc. So I'd like to wait and see how functions end up being dealt with.

Can you post a few examples of what you've tried typing?

I don't think there'd be a big learning curve if there was a more realistic aerodynamics model because the current model is so oddball that it defies intuition. I think newbies would actually have an *easier* time adapting to the change than experienced players because it would be closer to what intuition is telling you. Every time I show the game to a new person and they watch me doing a liftoff the first thing they comment on is "isn't a big ugly blunt nosed thing like that going to have huge drag? Why didn't you put nosecones on those boosters? I saw them in the parts bin when you were building the thing…" The current state, where adding nosecones *decreases performance* is certainly not intuitive.

That's not what the_bT was asking for. That's "This computer runs a program that's stored on the other computer's drive." what the_bT wanted was more like "This computer tells the other computer to run a program stored on it's drive." (Also, I think it included a request for redirected output from the other computer to this computer's terminal.) There's a beta feature in the works to run a program on another CPU. But the problem of displaying the output is still not addressed. Right now the only way to switch the terminal window is to close it and reopen it on the other CPU. I'd like to see some sort of tabbed buttons on the terminal to quickly swap which CPU the terminal is displaying for you.

VI began its life in the Unix world. But there's been ports to every other platform. I'm using it on Windows because doing csharp development for kOS requires Windows, unfortunately. (Csharp itself can in principle be done in Linux, but the peeking inside of KSP's DLL to see the class definitions is messy when you're on a system for which DLL's aren't native libraries. But the bigger problem is that it depends on a Windows parser generator tool called tinyPG.)

Please don't link them so strongly that the IDE is necessary to use the repository (like would happen if you make the IDE's stripper the universal way stripping is done). I don't use the IDE because I can edit about twice as fast in VI than in an editor that makes you take your fingers off the home row keys.

I have hit F9 when trying to type zero when typing a new vessel name. Don't jut look at the keys adjacent in the horizontal direction.

Because of course, nobody *EVER* types the wrong function key by accident. It's always intentional right? If you play hardcore enough not to use quick saves, you are one flubbed keystroke away from permanently destroying your entire career save, not just your current mission. How hard would it be to have the button pop up a window saying "about to load quick save saved at [display date/time stamp]. Continue?" Then it really would be the player's fault if they said "yes" to that, and a single fat-finger key error wouldn't delete the entire campaign.

kOS doesn't have the ability to read file input, making this sort of impossible right now. The reason I care about the stripping program is that I have examples I won't post without users being able to get them stripped, as they literally can't run without it (and if you do strip then trying to read it is messy).

Here's the story: http://news.nationalgeographic.com/news/2007/02/070227-ocean-asia.html Not an ocean, but just an area of water-bearing rocks.

You say you got the author page working now, but when I click on an author name link to see the author's page, I get this: Warning: mysqli_stmt::bind_result() [mysqli-stmt.bind-result]: Number of bind variables doesn't match number of fields in prepared statement in /home/a4228718/public_html/author.php on line 18

No, what I meant was "Can I share the Perl script on your site?", not "Can your site do the same thing as my Perl script?". You have a site for hosting of kOS scripts for sharing. I was trying to ask if it also supports sharing utilities that aren't kOS scripts but are directly related to them (like my Perl script).

This is a lot more reliable. Back in kOS 0.9, I wrote an asparagus staging logic for the Duna mission that had to do all the calculations about fuel consumption rate and it had a lot of sensitive problems. That was before you could query for flameout of engines. Now that you can, it's much more reliable to just do that.

I don't necessarily think this is related to the problem, but I think it's a really good idea to add a line as shown: set throttleVal to 1. lock throttle to throttleVal. [B][U]set [/U][/B]currentLiquidFuel to ship:liquidfuel. set lastLiquidFuel to currentLiquidFuel. set currentFuelFlow to 0. set lastFuelFlow to 0. set lastCheck to 0. until 0 { set now to time:seconds. [B][U]set currentLiquidFuel to ship:liquidfuel.[/U][/B] set currentFuelFlow to ((lastLiquidFuel - currentLiquidFuel) / throttleVal) / (now-lastCheck). //.... do stuff wait 0.00001. // <------ NEWLY ADDED LINE. set lastFuelFlow to currentFuelFlow. set lastLiquidFuel to currentLiquidFuel. set lastCheck to now. wait 0.1. // <---- Maybe reduce this to something very small like 0.0001 } This is because of some features of how kOS works that I've just found over the last few weeks that is awaiting documentation (I wrote the document, but it's not publishable until some other things about the next release are worked out because of other unrelated changes in the documentation that might not still be true anymore once the release is finalized.). Anyway that feature is this: kOS executes a certain number of underlying CPU instructions per physics tick of the KSP universe. (The exact number can be found by using PRINT CONFIG:IPU.) Keep in mind that the number of underlying instructions per line of code is not a 1:1 match. There are generally about 1-5 instructions per expression term - ish. Anyway the important thing is that the entire physical universe, including the clock time, the amount of consumables left (ship:liquidfuel), the position, the velocity, etc, is utterly frozen during the running of those statements. If you SET VAR TO TIME:SECONDS, then SET VAR2 TO SHIP:LIQUIDFUEL, then SET VAR3 TO SHIP:VELOCITY:ORBIT, and all those commands just happen to occur in the same KSP physics tick, then they represent a correct snapshot of that one instant in time, BUT, if the end of a physics tick happens to occur right in the middle of them, then the later statements are taking measurements from a different physics tick than the previous ones, i.e, like so: Imagine this scenario: some code here. // <-- A new physcs tick happens to start here. some more code here. some more code here. set var1 to time:seconds. // <-- The physics tick happens to end here. // <-- A new physics tick starts here. set var2 to ship:liquidfuel. set var3 to ship:velocity:orbit. If that occurs, then var1 is referring to a clock time that is a whole physics tick earlier than the time the var2 and var3 measurements were taken. For a program like you're trying to make that could throw off your results by quite a bit. In fact, exactly by doubling and halving factors, as it makes timeslice measurements exactly twice as long, or half as long, as expected. So the fix is that when you want to take samples of several measurements of the universe that were meant to refer to a single snapshot in time rather than being taken from a mix of two different snapshots in time, you have to do something that guarantees the physics tick won't end in the midst of taking those samples. And the way to do it is to force kOS to pause a moment and wait for the start of the next physics tick immediately before starting into the section of code where you take all the measurements. That way you know it will get through all the measurements in one go before the next border between physics ticks. And the WAIT statement does that because no matter what the WAIT condition is, no matter how small the WAIT time is, it's guaranteed to put the program to sleep until the next physics tick at least, where it wakes up and checks the wait condition to see if it's time to continue executing. (Effectively this means its actually impossible for WAIT to wait for a period of time less than one physics tick. If your physics ticks are occuring once every 1/10th of a second, then a WAIT 0.05 and a WAIT 0.00001 are effectively identical.) Saying WAIT 0.00001 is a way of saying "wait for the next physics tick rather than 0.00001 seconds, since there's no way your KSP is running with physics ticks smaller than 0.00001 seconds."

koS has plenty of memory. Did you mean disk space?

This is a great idea! Might there also be a place for helper tools external to the actual kOS script? I have a Perl script I use to strip down indentation and comments to try to get things under the 10,000 byte limit without having to "pay" the penalty of having proper commenting and indentation.

I've fiddled with enough of KSP's gui and map view systems when implementing the text editor and the vecdraw that I think I'd know how to go about implementing this if it's desired. I'm sort of stuck in the middle of a bigger project with erendrake right now, but it is potentially possible down the road. (Obviously I don't mean just lading for you like Mechjeb, that would defeat the purpose of kOS. I mean just having a way to print out the lat/long position of the click so you could take that information and do what you like with it. It may also be possible to turn the click into a position Vector inside kOS, like so: SET LOC TO GETSURFACECLICK. PRINT "YOU CLICKED AT LAT=" + LOC:LATLNG:LAT + " LNG=" + LOC:LATLNG:LNG + ".". PRINT "WHICH IS " + LOC:VEC:MAG " + meters away from your ship right now.". That's just a pie-in-the-sky idea. Generally, methods of getting runtime input from the user will probably have to be the focus of a future update at some point, and it would make sense to revisit this idea then. )

I've fixed the docs, reversing "VA" and "VB", but it's not published yet as there's other changes I don't want to publish until the next release mixed in with it. The markdown processing system used in the docs is a bit annoying in how it dictates explicit names of git branches you must use, thereby making it hard for me to make a branch in which to edit future doc changes that are unreleased yet. I sort of have to edit them all in one big pile. I may have to resort to using full forks for what you're supposed to be able to use just branches for. But at any rate, that's my problem to deal with. The important thing is that I took note of the error in the docs and the next time they're released it will be fixed. Thanks for pointing it out. EDIT: Oh, and I'm glad you're making use of vecdraw. When it was added I was afraid from the lack of responses that maybe it just wasn't useful and people didn't want to bother with it.

As a general design idea for the future, what do you think of this idea for a different way to do the prerequsite system? (I realize this would be a big change but I'm talking about pie-in-the-sky future ideas here). Right now, if mission B requires mission A as a prerequisite, then you MUST perform exactly mission A, even though there may be other missions that provide similar experience. This makes it so that if person A designs a series of missions in a pack, and person B designs a series of missions in a pack, then you pretty much have to stay on one mission pack's path or the other mission pack's path and can't easily mix and match them. If mission pack A has a few "orbit minmus, crash into minmus, land on minmus, land on minmus and return to kerbin" missions, and mission pack B has similar missions, mission pack B is unaware of the fact that you've already done a lot with minmus in mission pack A. It still requires you to do all of mission pack B's minmus missions to fufill the requirements because it doesn't know what you did in mission pack A. What I'm proposing is a change where the prerequisites of a mission are NOT "did you complete the exact mission named foo", but rather "did you accomplish the following mission goals before?" followed by, for example, a minmus orbitgoal, a minmus landininggoal, and so on. That would make it easier for different people to submit different missions to a large pile of interoperable mix-n-match missions. The idea would be that instead of just tracking "did you perform a mission with this name before?", the game would track the mission sub-goals that were accomplished as part of the mission. "you've done an orbitgoal with body=Mun and a nocrewgoal." "You've done an orbitgoal with body=kerbin and min periapsis=80,000 and max excentricity=0.01"... and so on. Then people who want their missions to have prerequisites could put in prerequisite queries that don't name specific missions but instead name mission goal queries that have to find a match in the campaign save's history somewhere, for example, "to perform this mission, you must first have completed an orbitgoal with body=Mun, max apoapsis < 60000, and at least one crew member.".

Thanks. I'll be giving 0.70 a try probably later today. I hope it will be compatible with an existing save game and not require that I start over.

I've been burned enough times with MCE failing to recognize that I'm still on the same mission when I leave the craft and return to it that I'm always afraid now to try going to the tracking center as it will "forget" that it's the same craft as the one that started the mission when I return to it.

Wold it be possible to weigh the duration of the orbital probe contract missions such that they tend to shorten the duration if the body being orbited is small? When it's a mission to orbit a tiny moon like Bop, with a small sphere of influence, the game's time limit max cap at those low altitudes makes it really slow to try to time warp through 5 days of wait.

The word "to" should be replaced with "in". It's not: list engines to enginelist. It's: list engines in engineList. Then engineList[0] is the first engine, engineList[1] is the next engine, and so on. The rotational pitch/yaw/roll is expressed in terms relative to KSP's own strange raw axis system. It's not how far you are pitched from the horizion, but how far you are pitched from the Z axis of the XYZ grid, wherever that happens to sort-of-randomly be at the moment. Using the built-in Directions of UP and NORTH can help a bit, as it can let you define a rotation relative to them, as in UP+R(-90,0,0) to pitch down 90 degrees from straight up. (I think the first item in the R() tuple is pitch - I usually prefer to fly by vectors so I don't have it memorized which is which off the top of my head). A system to give users the ability to pick the reference frame they meant when they input a Direction or Vector, and conversely a way for them to convert between different reference frames is a thing I really want to fix but it's such a large potential change to many places in the code so I'm waiting for buy-in from the others before I embark on it.