Dunbaratu

All those links are for what to do after it's installed. I don't even know what to install. Ah finally: After a rather long time googling and finding other links that all assumed I already had everything set up I finally found what I was looking for here: http://wiki.kerbalspaceprogram.com/wiki/Creating_your_first_module

Is there a "hello world" style tutorial example of a mod out there somewhere that walks a new person through the steps? I picture something where a new programmer doesn't work with artwork, or mesh modeling or any of that, but just wants to learn how to make a trivial alteration of game behavior - like maybe a window that says "hello world" when you launch a craft - just something really tiny who's only purpose is to prove "yes you have all the pieces you need for mod development installed right, configured correctly, and you did get it to compile and do a thing." There doesn't seem to be a lot of information at that getting started level. The closest I could find was this thread: http://forum.kerbalspaceprogram.com/threads/25013-Compilation-of-modding-information-links-for-0-19-20-21-Last-updated-24th-September But it seems to be spending all its time talking about making parts, which is a bit farther along than I am. I don't even know where the KSP API is downloaded from, or what development environment I'll need installed first. I have a lot of experience with other languages, but none with C#. I know Java and C++ so it should be simple to pick up. Finding information on C# isn't the problem. Finding information on KSP's modder API and how to get off the ground with it is the problem.

I'm having a heck of a time trying to trace a bug in one of my scripts where I have a single craft with more than one Volume on it and I'm trying to have multiple SCS units read the same volume. To do that correctly you must give the volume a name. The number is not sufficient because different SCS units number the volumes differently (One cpu might call a volume "2" while another calls it volume "1"). So the volumes NEED to be named. And that's where the problem is. First, on the master CPU that controls the craft, I RENAME VOLUME 1 to MasterDisk. Then I want the master CPU to copy some program files off to the child CPUs on the attached other parts. I do this by trying to use LOG and self-modifying code to write out these commands: COPY missile to 2. COPY missile to 3. COPY missile to 4. etc. in a loop going from 2 to 11. Each time I run the LOG'ed code, delete it, and recreate it to get the different statements. (You might ask why I don't just write all the statements and run them once - it's because if some of the missiles have been fired already by a previous use, then not all the volumes are still there and I don't want the error to stop the program from getting to the other ones.) The problem is, it always crashes and hangs KOS. But NOT always at the same point. Sometimes it gets a bit farther. I'm trying to trace down the exact circumstances but when I do it starts working correctly when I strip it down to the simplest test example. As near as I can tell it seems that once I rename "volume 1" to "MasterDrive" and then "switch to MasterDrive", that from then on it's a crapshoot whether or not file operations work. Sometimes it crashes on "delete", sometimes it crashes on "log". It is frustratingly inconsistent. When I make a tiny example on the launchpad, the tiny example works. Has anyone else had problems trying to get volume renaming to work for them? I'm beginning to wonder if there's a timing issue with all these file operations. Like it works when the CPU is fast and not when it's slow. I'm trying to test different cases to get it narrowed down but it's a tediously slow process when each test causes KSP to hang and need a task-manager kill and relaunch and reload.

I'm not so sure it is a good idea to wait because this change is large enough that it may become too big of a chore if the codebase is too large by the time it gets addressed. This is because it's not the sort of thing that can be addressed by merely adding more code to what's already there. It has to be addressed by going through and altering a lot of the code that's already there. The more code that's there, the more unappealing the project becomes and the more likely someone is to look at it and say "nope, too much work".

If the file is stored in the archive dir, then KOS automatically loads and runs it on the fly from there each time you do anything with it. If you do any of the following commands: EDIT progname. RUN progname. it just uses the file it sees stored on the drive in the archive dir. The only place where you have to do an extra step is if the program is off the archive and in the local volume instead. Then you have to copy it from the archive to the local volume after an edit - but then again that's true of any and all external editing of the file, whether it's with the IDE or with Notepad or vi or whatever.

Your stripped version breaks line numbering so that when KOS reports errors and tells you your error is on "line 20" it's not really line 20 in your source. My version preserved all block comments as still being a blank line. It still costs a bit of space but very little. (It only costs 1 character, or 2 depending on your OS's end-of-line convention, to store the existence of a blank line.) So this: //This is a comment[color=red]{EOLN}[/color] //typed into the code that is[color=red]{EOLN}[/color] //several lines long.[color=red]{EOLN}[/color] set x to 1. // this is a comment on the same line.[color=red]{EOLN}[/color] turns into this: [color=red]{EOLN}[/color] [color=red]{EOLN}[/color] [color=red]{EOLN}[/color] set x to 1.[color=red]{EOLN}[/color] Similarly, you could also strip leading indentation whitespace so that people who indent their code well aren't penalized for it, like this: This: // Countdown.[color=red]{EOLN}[/color] set x to 10.[color=red]{EOLN}[/color] until x < 1 {[color=red]{EOLN}[/color] print "x'.[color=red]{EOLN}[/color] set x to x - 1.[color=red]{EOLN}[/color] }.[color=red]{EOLN}[/color] Becomes this: [color=red]{EOLN}[/color] set x to 10.[color=red]{EOLN}[/color] until x < 1 {[color=red]{EOLN}[/color] print "x'.[color=red]{EOLN}[/color] set x to x - 1.[color=red]{EOLN}[/color] }.[color=red]{EOLN}[/color] The only place where stripping leading space can cause problems and require more complex code is if there is such a thing as run-on literal strings in the language, like so: set x to " This is a long string that spans lines". If the language allowed that, then stripping leading whitespace could be a problem, but it doesn't allow it so it's just a simple regular expression search-replace looking for "^\s*" and replacing it with nullstring.

Parts in the tech tree aren't the only place where mods may have compatibility issues with the core campaign game. The solution Squad proposes for that problem is a good one but it's not the only problem. The other problem is difficulty. Mods massively alter the difficulty level of the game. Some make it easy and some make it hard. When it's all just sandbox mode that doesn't matter. When you have to climb an achievement tree to get things unlocked it does start to matter.

A far bigger problem on the parsing front, is how bugs in KOS can cause the entirety of KSP to freeze up and require an external task manager kill to get unstuck (and often require that you save-scummed before you started testing your KOS script because not only will the bugs freeze KSP but they will also corrupt your vessel in the persistence file). THAT is a bigger hindrance than anything else. It means that you have to re-launch KSP and try another thing, watch it hang again, kill it, relaunch it, try another thing, kill it, etc until you trace down where the bug is. If KOS didn't cause KSP to freeze, then you don't have to bother with all that loading time because you just ALT-TAB between your text editor and KSP each time you want to try a different thing. THAT makes it very time consuming to find bugs in KOSscript code (or bugs in the KOS mod itself). Right now I'm trying to figure out why I get KSP hangs when using the LOG command on renamed Volumes, but I'm trying to winnow it down to the exact minimal set of conditions that cause it so I can submit a bug report, and this process is very time consuming because I have to wait 5 minutes between attempts as I have to re-run KSP each time I change one tiny thing trying to search for the exact cause. Finding out why KOSscript errors make KSP hang and getting that to stop would be very beneficial.

You still don't get what I said. The current situation is that the problem is solved neither IN *NOR* OUT of the game. I agree with a portion of (but not all of) those reasons for why solving it Out can be better than In. But since NEITHER solution exists, it's not a good reason to claim that solving it inside the game is a bad idea. To make that claim you have to compare to what exists NOW. Comparing a proposed solution for a real existing problem it to an imaginary solution that doesn't exist and is far less likely to be implemented isn't fair. It's the perfect being the enemy of the good. However, that being said (that either solution, the In or Out solution is better than the one we have now which is NO solution), if you are going to enter the red herring side topic of which of the two proposed ideas is better, there is one VERY good thing to put in the PRO column for the in-game solution - it would use the same code, bugs and everything, as will be used when really executing the program, rather than code someone else wrote outside the game. This makes it more accurate for the question "will my script run". We've seen lots of cases were we have to change the KOSscript program because despite the program syntax being correct, the game engine has bugs in how it interprets it and it doesn't understand it. For a pre-syntax check to be practical, not only does it have to succeed at parsing where the real game succeeds at parsing, but it also has to fail at parsing exactly where the real game fails at parsing.

But if this is done please don't break the self-modifying code trick I discovered by making LOG files and program files have different extensions. The self-modifying code trick si entirely dependent on the fact that the LOG command uses filenames with the same extension as the program code files.

I don't think the reason these operators are missing is because the underlying C# code is hard. That's the easy part. I think they're missing because each one requires setting up the parsing of a new keyword in KOS code first. What you do in C# once you've parsed the KOS code is the easy part. If you look at the GitHub code, when a new function is added to KOSscript it's about a 8:1 ratio between "how many lines are about parsing the KOSscript" and "how many lines are about executing it in C# after it's parsed."

It's possible. I did use that in my code. But I don't exactly know why getting the speed in 2-D way by using the Pythagorean formula on surfacespeed and verticalspeed gives a different answer from getting it the 3-D way by using the Pythagorean formula on the XYZ parts of the velocity:surface vector. In principle they should return the same number. Is something off in how they're calculated by KOS, I wonder.

I do have to say that there is an important information loss problem I'm getting with the new altimeter. I liked the idea at first until I tried using it. I used to be able to detect the following conditions separately: 1 - I am over water. I know this because alt:radar: is bigger than altitude. 2 - I am over water. I know this because alt:radar is equal to altitude. 3 - alt:radar is unreliable right now and I can't use it because I'm too high. I know this because it's -1. The reason the new inability to tell the difference between "I'm over water" and "I'm too high" is important is that I had a bit of my lander code that guessed at average ground height if it knew the radar was too high to work. If it didn't know the ground height, it would look up the body stats for the planet to obtain its terrain peak height, and take a guess that the ground height might be about half that. It wasn't perfect but it gave better approximations to use than what's there now (and once it got lower it stopped having to approximate and it could use the real data for the final landing). But I need to remove that now because I don't want false positives when it's over the water.

If you find a need to get a more accurate distance measure that does take into account the curvature of the body instead of the distance of tunneling through it, there's some helpful information here: http://www.movable-type.co.uk/scripts/latlong.html

Yes, I saw that. Which is why I can't figure out what that has to do with what you said about performance, since none of that is computationally expensive. Ah. You're comparing the suggestion that had been stated to a different suggestion that existed in your head but hadn't been stated up to that point so we had no way of seeing that that's what you meant. That makes more sense. I thought you were saying the suggestion was worse than what exists NOW, which is no checking ahead of time either in game or out of game. And THAT is not true. Pre-checking syntax does not take longer - it merely shifts the time burden earlier. If it takes time T to parse a typical line of code, and you have 10 lines in a program, pre-parsing just means that all of that wait time of 10*T happens before line 1 executes, compared to doing parsing like it is now where it happens on the fly, where each statement takes time T per line, for a total that still adds up to 10*T by the end of the program. Now, if you talk about statements in a loop, then not only is pre-parsing not slower, but it is in fact actually FASTER. An on-the-fly parser interprets the syntax of a loop's body each time the loop executes. An up-front parser does the parsing work on the loop body just once no matter how many times the loop executes. Your claim that editing on the launchpad is not practical I agree with. But it has no place in a discussion about whether or not the comments should be counted toward program size, or a discussion about whether the Mod performing pre-parsing would affect performance. And those two things were what the suggestion was about. The advantage to pre-parsing the code is that it finds syntax errors in code whether it gets executed or not, rather than waiting until it is executed to find the errors. When there's if-conditions that trigger only some of the time, that matters. You can write code to respond to an exception case and never realize it has a syntax error until the exception case happens and the on-the-fly parser finally gets around to trying to read it. I suspect that if it ever does switch to using a parser generator tool, it will end up having pre-parsing anyway, as that's how most of them work. They build a grammar tree and then you iterate through the grammar tree executing things as you visit the nodes.

Ah sorry I hadn't kept up with the changes. When I first suggested it in the IDE thread you said you weren't going to do it.

I see no connection whatsoever between what was suggested and your response to it. How on earth would having precheck for syntax errors, and choosing not to count comments against space limits do any of that?

The only good docking I've been able to do is from underneath. A rover with a docking port on top and a lander with a docking port underneath. I drive the rover under the lander's docking port and then retract the legs of the lander so it sits down on the rover, and when the ports connect they join. If the alignment is off, I just re-extend the landing legs to stand the lander back up again, and try to drive the rover to the right spot under it and try again. But yeah getting horizontal docking ports on landed craft to line up is a pain because of suspension springs. The height the craft sits at on its springy suspension varies depending on surface gravity, so testing the alignment on Kerbin does no good.

I can't answer the mass question, but I do know that when a strut between two parts of the vessel breaks because the vessel has decoupled or staged the parts, the one that retains the strut nub connected to it is the "from" end of the strut, not the "to" end of the strut. (When you built in in the VAB, it's the part you clicked on first not the one you clicked on second). However, I have seen slightly buggy behavior out of this sometimes where the strut nubs become individual bits of debris (each nub tracked separately in the tracking center) and float away. I can't remember now what causes that but it has something to do with the exact way the parts were connected.

The radar altitude change will save several lines of code in what I wrote. Also, I'm glad the inverse trig fixes are in. I needed those.

This is good as long as the IDE integration doesn't become a necessary thing to use the site (not everyone plays KSP on Windows and that IDE is Windows-only.). And I end up not using it because I want to do my editing outside of the archive directory and run my code through my comment and indent stripper first. (And because I know vi, which makes modern editors feel a bit stifling and clunky to work with by comparison. But I know that's a rather rare opinion and not as important as the other reasons.) But anyway, the comment stripper is important because instructive shared code of the sort you're talking about should be well documented and legible, but legibility runs afoul of the 10k limit. There's a community wiki here: http://kos.wikia.com/wiki/KOS_Wiki on which I've been adding some example code of my own. It's probably a good idea not to duplicate this type of thing so if your place works well I might remove the example code from there and put it on yours instead.

Yeah but if there's a chance there's no time to do all of it, I'd rather see TRUNC being the one that's done for the reasons stated. Obviously if both exist in KOS it becomes a moot point. Yeah but KOS currently has no way to do something like this: "give me a list of the parts on the vessel. Okay now I'm going to iterate over that list and ask for each part's drag.". The reason I was confused is because nothing I suggested mentioned WHO to do it, only WHERE to do it.

Agreed. While it's true that the real space race in the 60's used computers with very tiny capacity it's also true that they weren't sending ascii source code with the craft. They were sending machine code only. Comments cost nothing. Unfortunately I already suggested that on the Github and the suggestion was already rejected.

Yeah but so would what I hinted at. Here, I'll spell it out more explicitly without being so terse about it. I realize I wasn't clear because it was just one item in a list and I didn't mention all the steps correctly: For example: set x to 1.6666666. set y to round(x, 3). would become this instead: set x to 1.6666666. set y to TRUNC(X*10^3 + 0.5) / 10^3 . That would give you 1.667 as expected. X*10^3 is 1666.6666 1666.6666 + 0.5 is 1667.1666 TRUNC(1667.1666) is 1667. 1667 / 10^3 is 1.667 The general form is this: ROUND(X,d) is equal to TRUNC( X*10^d + 0.5 ) / 10^d .

How does that ruin the chance to get another editor? I was answering the question of where to add the information about drag. I was saying that's a good place to go add it.