hvacengi

I just downloaded the MM cfg files from Kolago and tried them on an install and they appear to be working well. I wish there was a way to set a default texture when the tank type is changed, but that's very manageable. I would recommend one addition to Kolago's files: I added a MM patch to add Karbonite to the default liquid tank. I simply wanted to keep a single fuel tank in my list of parts rather than a copy that just contained Karbonite. I suppose the biggest benefit using a separate part is the ability to change the default texture. Anyways, here is the patch in case you want it: @PART[proceduralTankLiquid]:NEEDS[ProceduralParts&Karbonite]{ @MODULE[TankContentSwitcher] { TANK_TYPE_OPTION { name = Karbonite dryDensity = 0.10865 RESOURCE { name = Karbonite unitsPerT = 1600 forceEmpty = true } // 'KB4560 Karbonite tank' has dry mass of 0.5 and can store 800 Karbonite // Procedural Karbonite tank of the same size has dry mass of 0.5 and can store 800 Karbonite, phew } } } With this patch, a 1.25m diameter by 3.75m tall tank contains 800 units of Karbonite, and matches the mass of a default 800 unit tank. If you do not choose to use this patch, make sure to include your original TankKarbonite.cfg (not included in Kolago's zip). I would recommend including it in your own directory instead of in the ProceduralParts directory to allow for less confusion on install/uninstall. But I love these textures! The life support tanks look so much cleaner (most notably in the taller form factor)! I'm glad you shared.

Just to update, using parenthesis with the print command did not cause any errors. It proceeded to the next line without issue. As a temporary shim, I push the number 0 to the stack before returning toggleflybywire, which prevents the pop error. Without more testing though, that is a stack overflow error waiting to happen. I didn't try using toggleflybywire without the parenthesis while using a defined string variable (if I just used a string literal it threw a syntax error on compile without running). Depending on the rocket design though, these built in maneuver snap seems to be more touchy than the built in stabilization (much less dampening and higher output spikes). I am going to experiment a bit with rocket design to see if it is related to rocket wobble, or to the ratio of torque to the mass and to the overall length. These are an issue when using the built in buttons as well as when using kOS, so I don't think it should prevent implementing the functionality. So at this point there are two things I need to fix before it could be submitted to be included: find a stable fix to the pop bug; find out how to toggle the ui icons for the different modes as well.

Thanks Steven. I hadn't though about that being a potential issue. I'll give that a try and see what happens. I've run into a couple other complications with using the built in autopilot system, so I'm not sure how perfect it will be yet. I'll give it a shot tonight or some time tomorrow and report back.

Over the holiday weekend I tried to add support for the new built in autopilot features (just prograde and maneuver for the initial proof) and I ran into a weird complication. I added the abilities to the "toggleflybywire" function, and implemented them in the FlightControlManager. Through my first round of testing I only used the commands directly from the console, and both worked with no issues. Then I tried to run the command from within a script, and it failed. Through a bunch of debugging, I've found that it looks like the opcode has an extra pop, which is causing an error with the stack being queried out of range (it appears to be trying to pop at an index of -1, with the stack empty). Digging into the opcode is a little beyond my knowledge of kOS, so I thought I would bring it up here. I didn't want to make a pull request to bugged code, but you can see/clone my changes here: https://github.com/hvacengi/KOS/tree/Enable-builtin-autopilot The script I am trying to run afterwards is pretty simple: sas on.lock throttle to 1. stage. wait 5. toggleflybywire("prograde", True). wait 5. I'm also attaching the error text: [LOG 12:33:45.430] Code FragmentFile Line:Col IP opcode operand ---- ----:--- ---- --------------------- archive/testflybywire.ks 1:5 0152 push True archive/testflybywire.ks 1:5 0153 store archive/testflybywire.ks 2:1 0154 push $throttle* archive/testflybywire.ks 2:1 0155 push 132 archive/testflybywire.ks 2:1 0156 store archive/testflybywire.ks 2:1 0157 push 134 archive/testflybywire.ks 2:1 0158 addtrigger false archive/testflybywire.ks 2:1 0159 push throttle archive/testflybywire.ks 2:1 0160 push True archive/testflybywire.ks 2:1 0161 call toggleflybywire() archive/testflybywire.ks 3:1 0162 call stage() archive/testflybywire.ks 4:6 0163 push 5 archive/testflybywire.ks 4:6 0164 wait archive/testflybywire.ks 5:17 0165 push prograde archive/testflybywire.ks 5:29 0166 push True archive/testflybywire.ks 5:29 0167 call toggleflybywire() archive/testflybywire.ks 5:29 0168 pop <<--INSTRUCTION POINTER-- archive/testflybywire.ks 6:6 0169 push 5 archive/testflybywire.ks 6:6 0170 wait archive/testflybywire.ks 7:1 0171 push 138 archive/testflybywire.ks 7:1 0172 addtrigger true 0:0 0173 return [LOG 12:33:45.420] At testflybywire.ks on archive, line 5 toggleflybywire("prograde", True). ^ Called from boot.ks on 1, line 23 run testflybywire.ks. ^ Called from boot on 1, line 1 clearscreen. ^ [LOG 12:33:45.423] System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[System.Object].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at kOS.Execution.Stack.Pop () [0x00000] in <filename unknown>:0 at kOS.Execution.CPU.PopStack () [0x00000] in <filename unknown>:0 at kOS.Execution.CPU.PopValue (Boolean barewordOkay) [0x00000] in <filename unknown>:0 at kOS.Safe.Compilation.OpcodePop.Execute (ICpu cpu) [0x00000] in <filename unknown>:0 at kOS.Execution.CPU.ExecuteInstruction (kOS.Execution.ProgramContext context) [0x00000] in <filename unknown>:0 at kOS.Execution.CPU.ContinueExecution () [0x00000] in <filename unknown>:0 at kOS.Execution.CPU.Update (Double deltaTime) [0x00000] in <filename unknown>:0 I think this feature could be a really useful addition to kOS. Any help you can give with implementing it would be awesome!

Git is the solution to every thing, isn't it? Some day, it will create world peace! In all honesty... it just made sense to me since everything is handled in plain text. So changes in files are handled very gracefully and without the repository growing astronomically. I tried using zip files, but those options were either complicated or an ever increasing list of files. As is my DMP folder (minus git) is 20MB, while the git folder is 8MB. Mind you it's only dating back to the end of October, but I'm still pleased. One of these days I'm gonna figure out what it takes to write a plugin for DMP, there are a few things I think it would be cool to do with it without asking you to implement features (like a website displaying a snap shot of the universe, or play time statistics).

I have github for windows installed, but you can use whatever git client you prefer. I set up the following power shell script: invoke-expression -Command "C:\Users\[username]\AppData\Local\GitHub\shell.ps1" $CommitName = Get-Date -Format "s" $CommitName = "AutoCommit - $CommitName" cd "[put the path to your server instance here]" git add . git commit -am $CommitName Add a push command to upload to a repository of your choosing, or just keep it in dropbox to keep it backed up on multiple machines. Then just schedule a task to run "powershell [path to your script]" at whatever interval you prefer. (Task scheduler from computer management) If you use another platform besides windows, the git commands will remain the same but the shell script will be different. You could do the same thing using batch files, I just like using power shell even for simple scripts.

I have a git repository set to automatically backup a snapshot of the dmp server folder twice a day for this very reason. Then if something goes wrong in the last 12hr, I can just discard those changes. If it's more complicated, I can pull the old data out of the historical commits. It would be nice to have an integrated way to manage this. I would probably still maintain my git backup, since it allows me a lot of fine grained control (replacing just the one thing that got messed up instead of reverting the whole universe).

I feel like I must be doing something wrong. I've tried installing the basic option, and then the aggressive option (after deleting all components of basic of course) but I don't seem to see any appreciable reduction in RAM usage or loading time. And if I check the log file, if find this: [LOG 13:08:45.915] ActiveTextureManagement: Memory Saved : 0B [LOG 13:08:45.916] ActiveTextureManagement: Memory Saved : 0kB [LOG 13:08:45.917] ActiveTextureManagement: Memory Saved : 0MB As near as I can tell, all that I should have to do is copy the ActiveTextureManagement and BoulderCo folders into my GameData folder, but I feel like I'm missing something. Do I need to be doing something else to enable the mod to work? I have a copy of my output_log.txt that I can PM a drop box link as needed.

More comments on the 6000m bug: I had experienced it briefly. I deleted the kOS folder and installed fresh from the download and it went away instantly (exact same ship, exact same script, literally 5min loading time apart). To make sure I was being kind of scientific, I loaded KSP multiple times before hand and tried multiple ships (a mix of space planes and rockets). Then I deleted the folder and installed from scratch, and haven't had a single issue with it since (I want to say it was Tuesday of last week, but I can't be sure). To be clear, I deleted the kOS folder entirely and then modified settings from within the game (I did not replace the settings file with the previous settings file, but the settings matched exactly).

I think it was Steven who posted this fun little code block that I now use for staging. It's much more generic, and doesn't care which fuel you ran out of. It will also work with asparagus staging, assuming you have everything in the right order. set stagemaxthrust to ship:maxthrust. when (ship:maxthrust<stagemaxthrust or ship:maxthrust<1) then { print "Stage!". stage. set stagemaxthrust to ship:maxthrust. preserve. } You could also add a check in the when...then code for each fuel "if not stage:liquidfuel < 0.001 { stage. }" in the solid fuel loop, and vice versa in the liquid fuel loop. I also like to add a counter to my staging. So that it stops the preserve command if you stage more than a given number of times (say 20, since I can't recall having a rocket with that many stages). Wait's in when...then code don't work because that code is executed outside of the timer execution. You also cannot use "run" from within when...then.

Does it stage the one time? Because it looks like you're code is missing a closing delay. As long as it stages, adding "wait until altitude > 70000." (not a good choice of altitude permanently, but OK for proof of concept) should keep the script running. But the way you have it written, the when triggers get unloaded because there is no wait.

Has anyone else had an issue with getting boot files to work after the update to 15.x? I had been using a boot.txt file before the update without any issue. Now, boot.ks doesn't seem to launch or get copied to the local volume. I have run a simple script of just wait 10. clearscreen. toggle ag10. where ag10 opens the console. I wait and nothing happens. If I open the console manually, the standard boot text is there (though it identifies as v0.15.1 even though I've confirmed it is v0.15.2), and the clearscreen command has obviously not cleared anything. Listing files shows a single boot file on the local volume, but attempts to edit, copy, or rename all return that the file doesn't exist (edit displays [New File] on the terminal). The file size is pretty close to the actual size of the boot file (using the windows file properties dialog). My first thought was that it was complication due to me storing all of the scripts in dropbox and a directory link to point the script folder there, but the same holds true if I use a normal folder. I have also tried it both with compression turned on and without. If I switch to the archive and then "run boot." the boot script executes fine. I wanted to check and see if any one else has had this issue, or if I'm just completely crazy, before issuing an issue on the github page. Thanks!

I had to increase my ipu. If I didn't, I was getting this weird error where kOS would try to run each line of my script twice (so it would run the launch, then try to run it again, then execute the circularize node, then try to execute a nonexistent node and fail). All this talk of doing a PID controller made me look into it again just to figure out which are the part that are holding me back. Looks like my two biggest stumbling blocks are wrapping my head around the coordinate system, and code re-usability. I really miss being able to write a function once and just call it later. I have a couple ideas about how to use locks to do the same thing, but I'll have to see. I'd also like to chime in on the storage size. I too find my self running out of space, but I don't like the idea of simply editing the config file to increase my capacity. I don't know how complicated this would be, but would it be possible to preset the structure of the multiple volume file system? I like the idea of simply adding additional storage from other kos modules. So one could hold the orbit insertion scripting, another module could hold a log file, and one dedicated to landing, all the while not requiring a connection back to Kerbin. I want to experiment a little with selective boot scripts this weekend to try and make this work, but the last time I tried to adjust the boot script execution I don't think it worked.

I can't test it right now, but here is how I would implement your code: set p to 0.01. set o to 0. until alt:radar < 0 { print "this is the current pitch= " + o at (0,1). print "this is the current vertical speed= " + verticalspeed at (0,2). if (verticalspeed <-1) { set o to o + p. }. set SHIP:CONTROL:PITCH to o. }. That way you aren't adding a new when trigger every time you run through the loop. Otherwise you could do it like this: set p to 0.01. set o to 0. when verticalspeed < -1 then { print "this is the current pitch= " + o at (0,1). print "this is the current vertical speed= " + verticalspeed at (0,2). set o to o + p. set SHIP:CONTROL:PITCH to o. if not (alt:radar < 0) { preserve. }. }. wait until false. You had the "{" in the wrong spot on your second code block, which is why you got a syntax error. Also, I deleted the declare portion on each script because you immediately redefined the values, but you can re-add them as a declarable variable if you want to assign them from another script. I'm not saying that this code will accomplish anything, btw. It kind of looks like you'll keep spinning in circles until you hit the terrain, and eventually you'll overflow the variable "o" to be greater than 1. But if you're going for proof of concept, then don't worry about it. I'm by no means an expert, and will defer to any of the people more experienced than I with kOS. Edit: I see I took too long to hit post after reading and madlemur already posted some code that looks more helpful than mine.

For a while, I would include the line to enable RT2 support at the beginning of every boot script (just because I was paranoid). But in my experience, kOS still has control when leaving comm range, I've even had code executed on the far side of the sun. Do you know what version of kOS you are using and of RemoteTech? RemoteTech made a change at version 1.5 (iirc) that forced erendrake to change the internal checks in kOS. So if you have a version mismatch, it will behave the way you've described. That would be the first place I'd check.

I see that you posted what you found as a work around. The issue is that the "on" trigger can't contain much logic, since it interrupts the virtual cpu stopping all other functions until the code finishes. Wait commands get ignored in it, as do run commands. Your work around is really the best option. Use the trigger to set a flag to true when the trigger occurs, and then maintain an loop that checks these flags. Since it sounds like you have a loop that updates the screen regularly anyways, using that existing loop was a great idea. In a more simple application, you can also use "wait until" to block the processing until that flag flips true. (for instance, if you wanted to just wait to launch until you activated ag1). It's easy to mix up interrupts with the way that events work in a multi-threaded environment. It was probably the most frustrating lesson to try and learn when I moved from PC programming to microcontroller programming.

Yes, you can by launching the game on the computer that has the save you want to convert. Then at the main menu, click "options" in the dmp window. One of the buttons there says "generate universe from saved game". Click it, select the save file, and the mod will create a Universe folder in your KSP root. Just copy that to your dmp sever folder (replacing the old universe) and you should be good to go.

It is interesting to see the differences in how people use kOS. I like the phrasing that it's a mod for people who want to write their own autopilot. But I also think that definition changes depending on the user. Once you've created a way to launch and to execute a node, you could say that you have written the majority of the "autopilot" portion. Where I think kOS really shines is not in allowing you to write your own auto pilot execution, but rather in letting you write your own autopilot course plotting. With kOS I'm not limited to the set of functions that a tool like MechJeb provides, and I don't have to come up with a way to manually place and edit nodes sufficiently. I can use kOS to calculate a Mun gravity assisted launch to Minmus, or to set up a geosynchronous relay network, or a solar system relay network. All of these things are still complicated problems to solve, and they usually happen after you've written and refined your launch and node script. Really, whatever mission you can dream up you can automate using kOS. So while I agree that more advanced PID "lock steering" is a good thing to leave as a high level exercise, it still makes sense to have some level of tuning or advanced options for other users. Users like myself who have more interest in the math of orbital mechanics than the math of PID for 3d vectors. I don't want to come off as either ungrateful or as requesting the feature. I cannot imagine using RemoteTech without kOS, and I've gotten to a point where I balance my ships and burn nodes to make sure that I can use the built in features. Some times I need an extra loop to fine tune things, but overall I haven't had a need to write a more accurate implementation. I just wanted to point out a second point of view that might help with the focus of the autopilot discussion. Thanks to all who develop and contribute to this mod!

From my use it is fairly stable. As with anything, I've run into a few quirks, but nothing I couldn't work around. The event-driven operation is very limited, and doesn't function the way most people expect it to in today's multi-threaded environments. It's essentially just like a hardware interrupt on most micro processors: it truly interrupts the running code, and nothing else is executed until the completion of the operation. So even if some "kids" focus too heavily on the events, they'll find out real fast that it's a bad idea to include more than some simple logic in the event loop. The "run" command throws an exception if you try to execute it from inside the loop, and in my experience an exception gets thrown if you do too many operations. It's not the most up to date, but I used this resource to get started: http://kos.wikia.com/wiki/Tutorials_and_Example_Scripts Some of the scripts use depreciated variables, but they give a good foundation on how to implement some of the math.

Just compiled with the revised assembly name for RemoteTech, seems to work without issue for me. I forked and submitted a pull request on the master branch. (Tell me if there is an issue with the pull request, it's my first try).

Actually, I think I tracked it down from the source on github. RemoteTech appears to have changed assembly names to "RemoteTech" from "RemoteTech2". So your check in RemoteTechHook.cs returns a null instead of loading the new assembly. If you don't have anything funny in your build configuration, I'll compile it myself tonight (probably late) to see if changing the assembly name fixes things.

Loss of local control (as expected), but also the kos script stops running (just like it did before I turned on the RT2 in config). So on a rocket with no antennae, I hit the 3000m mark and then the throttle goes to zero, automated control fails, and I cannot recover using local control. I even tried to renable the RT2 flag at the beginning of the script execution. I didn't notice any exceptions in the debuging log, but I would have to run it again to confirm (can do tonight). Thanks for the quick response!

Very grateful for adding the rotational period, that will be very helpful for setting up generic geosync orbits. One thing I've noticed in the newest update, support for remote tech doesn't seem to be working any more. It worked great in the previous version of both. I wonder if it's a collision related to the remote tech 1.5 update. I absolutely love this mod though. So very useful. Really give you full control of the vessel and lets you do complicated maneuvers without relying on a tool like mechjeb.