hvacengi

Ah, in those instance we might be able to make some slight adjustments, but it's a pretty fine line when trying to surface mount a part that is as thin as the KAL9000. That MK1-2 pod loves to eat parts, and the colliders on the 2.5m tanks tend to be funny too. I'll mention it in our dev chat.

I've been testing the KAL9000 part for well over a month at this point and haven't noticed anything that I would call z-fighting. On some models where the collider is not flush with the texture I've seen the part hidden or partially obstructed by the texture. Can you say what you mounted it to when you observed the z-fighting? Do you observe it no matter what it is mounted to?

Announcement: There have been 2 major breaking bugs reported for kOS-v0.19.0 (one regarding InfernalRobotics and another regarding renaming files). We are looking at potentially making a quick maintenance release "tonight" (EST) March 4. We are asking that any one who has found additional new major breaking bugs please try to make a github issue for them so that we can get them in to this release, instead of needing another rapid release in a couple of days. Thanks!

You can actually already download a zip file of the html files directly from our KOS_DOC repository: https://github.com/KSP-KOS/KOS_DOC/archive/gh-pages.zip The sphinx software that we use to generate the documents has some kind of a pdf output option, as well as a variety of other formats (like Windows help files). I don't think the pdf generation worked when I tested it last on my windows machine, but I don't mind trying it again to see if we can provide a downloadable pdf.

Oops... It was on my clipboard, I swear! http://www.braeunig.us/space/orbmech.htm#plnchng

That value is not directly exposed by kOS. You can solve for it using orbital parameters though. Here is a good link to the math involved. Remember to pay attention to radians/degrees and that the LAN is in universal longitude, which is based on the solar prime vector. Yes, it can be any decimal value between 0 and 1, including 0.1. You'll have to experiment to see what values correspond to what you're looking for. Could you please swing over to github and create an issue for this? I know we already have an issue submitted with issues for different case of letters in file names, and this should get fixed too. Did you test it using string literals as well ("anyfile" and "othername")?

My first commit for the steering revamp was August 8, 2015. My final non-review commit (so my last major change that wasn't doing house keeping) was October 13, 2015. But I didn't have a working deterministic version to work from, I was adapting generic PID's instead. Oh, and that was my busiest stretch of the year at work If you're interested in the math behind the pitch rate controller (which I really need to get into our documentation) check out this imgur album with notes from Matt that were the basis of our tuning: http://imgur.com/a/UScQf

Hi there. Some one over in the kOS chat mentioned seeing this pop up in the thread. I'm the dev who contributed the current steering manager in kOS and would be happy to discuss how it came to be, as well as ways that we can make it better! My code isn't well documented at this point as released, but I have a development copy that is progressively getting better documentation (and fixing a few nagging bugs). I can also point you to the source for the math we used in the torque tuning, which I will take no credit for since that was with the help of another contributor with a much better understanding of control theory than I have The rational for the two controllers per axis is mostly an attempt to improve predictability. We were able to relatively "easily" create a auto-tuned PID for torque based on angular velocity, but it was more difficult to go straight from angular error to torque. So, we created an intermediate step. It's actually how most of my controllers in kOS itself are implemented as well. The MoI adjustment stuff was an attempt at improving the "learning" of the code. There seems to be some value I cannot account for that reduces the effect that torque has on the vessel in low MoI applications. So there were two theories, that the MoI needed to be tweaked, or that the Torque needed to be tweaked. It turned out that tweaking the "available" torque was more stable than the MoI, but I didn't want to remove it completely so I just disabled it. When compiled in Debug mode you can turn torque and MoI adjustment on or off (both are independent settings) to toy with it. I've since found an additional equation which accounts for angular velocity about the other two axes which may explain the observed difference in resultant torque. You can see our "basic" explanation of the steering manager's logic here: http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#cooked-steering-s-use-of-pid-controllers This section wasn't really written to explain the underlying code to another programmer, but it at least will help you with some of our logic. I'm also planning on writing a documentation page that includes the math and logic in a more in-depth manor (if for no other reason than for me to not be the only dev writing steering code in the future). The ` findLocalMOI` method is indeed exposed by KSP. Sorry for the "uglyness" of the available torque calculation. There's a lot that goes into that calc, and a lot of checking to see if things are turned on. As near as I can tell, there is no way to get the total information out of KSP itself. When they go through the physics update, it iterates through each part and adds the appropriate force/torque based on the control ratio, but the "available" total isn't stored anywhere that I could see. Please feel free to reach out if you have any questions. I'm not on the forums very often (I'll try to check in for the next couple of days at least) but you can always reach out via github, the kOS reddit, and I have started lurking in the #kspmodders IRC channel on esper.

The development team wanted to share a trailer video for the upcoming kOS release (v0.19.0). You can see it here:

I've kind of become the "steering" guy for the project, since I wrote the new `steeringmanager` code. Those small MoI values really mess up the math. I can't quite figure out how unity manages them, but there is some kind of a scale factor applied to keep the values in "reasonable" ranges. Since I couldn't figure out how to predict that, I wrote an adaptive section of the code that will try and adjust your "available torque" based on the observed angular acceleration. The problem is, the "epsilon" value used to try and reduce very small fluctuations can also prevent the steering from trying to stop. I hadn't run into this prior to the last release, but I found it as I was doing some other testing in the last month or so. I'm working on an update to the steering so that staging/docking events will be tolerated a little better. And in that branch, this appears to be fixed. But that fix probably one be in the next update, but rather the one after. So, since it looks like you're comfortable compiling on your own anyways, here's what you can do to fix it locally: Change the value of EPSILON on line 154 of "SteeringManager.cs" from "0.00001" to "1e-16". We don't want to ignore the epsilon value entirely, but it can be much smaller and still have good results. For the ship I was testing, this change fixed the rotation immediately. Let me know if you end up having to tweak it further, it would be good to have a chance to test out that value before I push it to the public. Sorry for my delay in response. I spend a lot more time on github than here, and I ended up having a busy weekend that didn't leave me a lot of time to work on kOS.

I've got 14 tests done already. While none of them win, I can at least get one turned in within a 5 minute window apparently

Do you have an intended "limit" to submissions? I'm going to modify my kOS scripts to work with this design (it's a bit out of my own normal parameters) but figured it would be good to know a realistic "deadline" (also, my ADHD does better with deadlines...).

Based on the testing I've done so far, I'd bet it's an issue that will be solved when we recompile against v1.0.5. I know that the name tag editor wasn't working properly until we updated the compile. I'll have to go test with 0.18.1 to verify though.

Can you post your script that goes along with the exception, and possibly the ksp.log or output_log.txt file? That will help us see what's going on under the hood leading up to your error.

It's official. I'll be streaming tomorrow at 2PM EST: http://forum.kerbalspaceprogram.com/calendar.php?do=getinfo&e=231&day=2015-11-7

I wrote the new steering code, and based on your above comment I'm not sure you fully understand the differences between the new code and the old code. So let me try to help with that. Previously: Steering was handled using a "guess" at what the turning angular velocity should be based on angular offset. Then the available torque was calculated for the vessel, based only on torque wheels and a rough calculation of RCS torque. There was no feedback to the control loop, and in fact is was implemented statically so that it did not remember anything about even the previous setpoint. In some instances, this was close enough to work well, while in others (most notably instances without RCS or torque wheels). In every experiment I conducted, the old cooked steering was an epic failure when using either control surfaces, or gimbals as the primary source of torque. I'm happy that these values worked well for you in all instances, but that was by no means the norm. Now: The new system is not just a PID loop with some tuned constants. The first modification I made was to add a calculation of engine gimbal torque, allowing the calculation to remain accurate when the available torque from the engines dwarfed that from reaction wheels and RCS (for example a gimbaled launcher, with a satellite on top). Next, I worked with another contributor on an accurate model for calculating required/target torque to achieve a desired angular velocity. After that, I implemented a total of 6 PID loops to calculate the target angular velocity and torque about 3 different axes. Finally, I wrote an algorithm that analysis the observed change in angular velocity, and automatically adjusts the "available torque" based on a running average. I agree fully that installing blind PID controls that require the user to tune them would defeat the purpose of cooked steering (to be a fairly simple default default steering control). In an ideal world where we have access to all of the variables and computing power is infinite, a fully deterministic calculation would be far superior. However, that calculation is what the physics engine behind KSP is already doing and we cannot practically replicate or approximate it without taking some short cuts (otherwise the control calculation literally doubles the execution time). What the new steering code does is blend the two choices as practically as possible. Because we (all of the KSP developers) agree that this calculation will not be perfect in every instance, it was important to us that the tuning parameters be exposed to give the user the choice of how the steering should perform. It is important to note that the old steering code was not in any way a fully deterministic calculation for steering. It ignored several more factors than today's code does. If failed miserably when there were small values for available torque, as well as when the available torque was significantly larger than it needed to be. When using gimbaled engines, it often oscillated wildly. These are all things that were supported by a variety of issues posted to github, posts on reddit, comments made by streamers and youtubers, and in this thread. It was not broken for all ships, but it was indeed broken for some ships, and it provided no way for the user to fix this. The stock SAS is not perfect for all ships either (it creates oscillations in the orbit itself when torque is very high for small mass ships), nor is MechJeb's (I've had instances of uncontrollable pitch oscillation on more than one occasion, and I never could make it work well for planes). I wanted to pull this quote out separate from the rest, so that I could address it directly. Maintainability is a valid reason for removing a feature, especially a broken feature. When code becomes as complicated and patched together as the old steering code was, it becomes very difficult to trace out bugs. Add the fact that no one who wrote that implementation is currently working on the kOS, and you have a receipe for disaster when something breaks (and something always breaks). By re-writing the code, I was able to compartmentalize the code to some degree, putting features into their own classes and methods, which could be both reused elsewhere in the code and tested/debugged separate from the steering code itself. If we had chosen to maintain two tracks of steering, the answer to any issue with legacy steering would be "use the new steering". All of this being said, we do want to get feedback on default tuning. We are already preparing to adjust a couple of default parameters in the next patch. There has even been discussion of adding some "recommended" tuning scripts to KSLib for different shapes/classes of ships. The easiest way for us to give the users a good default performance is to get feedback on what values work most often for most users. The existing default values were found to work well in initial testing, but there the devs have since found a few places where we want change things up a little bit. We want to invite every one to help with figuring out the tuning by submitting values that worked for you, along with an image of the ship design (or a link to the craft) and preferably the csv output files from the steering manager: http://ksp-kos.github.io/KOS_DOC/structures/misc/steeringmanager.html?highlight=steering#attribute:STEERINGMANAGER:WRITECSVFILES Help us help you... help us... help you? I should be setting up a stream tomorrow afternoon to go through the new features in 0.18.0 and help with issue as well as real time feedback/discussion. I'm also planning on writing a tuning FAQ of sorts, and doing a video to walk through some of the behaviors. - - - Updated - - - Well if it wasn't dependent on it before, the new steering code made it so that the part ID is used to differentiate between "subscribed" parts for the steering provider. I do want to fix that by using a "VesselModule" to manage the once per ship objects (like steering manager and flight control). That was too much of an additional undertaking to make this release, but it will probably be in a future release if I can dedicate enough time to figuring out the life-cycle. Honestly, the execution should be tied directly to the "module" itself, rather than the part, which would enable the operation you're expecting. It will probably happen after the revisions to volumes and files in the next "big" release. I'll look into it a little closer though. Cause it may be that the part tracking should be OK with multiple modules and we just don't have it enabled. - - - Updated - - - Welcome back. I actually had to write a "moving average" class to accomodate some of the other things in the steering code. That might be something that we could consider exposing as a structure in a future release as a way to filter out some of the jitter.

CKAN maintains some of the files, but the developer is able to manage it themselves as well. KerbalStuff is supposed to also have an option to automatically list on ckan (which your mod appears to have enabled since the title says "ckan" after it). In my experience new mods take a few days to get listed however. As for the MM patch, maybe make it rely instead on the part having the docking node. I previously had a similar feature working on a branch of Tarsier so this modified version of the could should work: @PART [*]:HAS[MODULE[ModuleDockingNode]] { @MODULE { name = DockingCameraModule allowedDistance = 1000 nightVisionArgs = 0.5,0.7,0.5,0.5 noise = true } }

It looks like we forgot to include KSPAPIExtensions.dll in the zip file that we released earlier today. That caused the errors that @idPhobos reported in the log file. Since we have to correct an issue with PIDLoop anyways, we'll get this dll included in the same update. Don't expect the release yet tonight, we'll want to make sure there are no other small fixes to publish at the same time. For the time being, you can copy the dll out of the zip file for 0.17.3.

I too noticed the issue with red text labels in other mods (and stock windows). I don't know if you prefer issues here or on github, but I posted a potential solution in a github issue: https://github.com/DennyTX/DockingCam/issues/1

The issue is that you are steering with SAS turned on. Remote tech negates the stock SAS control, and so it fails to steer correctly. The documentation appears to only call this out for setting SASMODE (see here: http://ksp-kos.github.io/KOS_DOC/commands/flight/systems.html?highlight=sasmode#global:SAS) I will modify the documentation to identify that lock steering using SAS is also limited in remote tech. If you turn off SAS, it should start to work. If you vessel is unstable using the current kOS steering code, I'm working on pushing an update to that code as quickly as possible which is significantly more accurate. Let me know how it goes with SAS turned off.

You should be getting a PM to coordinate contact info. As for C#, we can help with that. It's probably not to hard to pick up. It isn't that far off from Java, or C++, but it has it's fair share of unique elements. If you're coming from a language like python, it can seem restricting.

Yes please! Any help you can provide on it would be awesome. We've had lots of discussions internally, but we haven't been able to move beyond the brainstorming phase. The quick and dirty way to help out is to clone the source on github ( https://github.com/KSP-KOS/KOS ) and then submit a PR. The current steering implementation can be found in this file: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/Utilities/SteeringHelper.cs but in our last discussion we thought it might be messed up and confusing enough that it could warrant starting from scratch. If you're willing/able to fix the current version though, I don't think any one would turn you down. (I can already tell you that each reference to `vessel.transform` needs to be replaced with `vessel.ReferenceTransform`, but I haven't dug in much more than that). Let us know if you need any help getting the development environment setup. The stars must have aligned just right. It was yesterday afternoon that we were talking about not being sure how to go about fixing the steering, and today you offer to help!

The heading suffix gives the direction from the cpu vessel to the selected vessel. So if you target another vessel and then use target:heading it will give you the absolute direction to that vessel: http://ksp-kos.github.io/KOS_DOC/structures/vessels/vessel.html#VESSEL:HEADING

I'll double check the list code when making a new list, but I know that the current version is able to iterate over a list without throwing an error (the first thing my boot script does is look for kOS processors and toggle their display). As for the build environment, I think that the primary devs just use Visual Studio on windows to build the files. I think that mono will compile the solution as well.

Just wanted to let you know there seems to be an issue with the ckan file/repository. First, it doesn't list the updated version in the ckan gui. I haven't dug into the logic of ckan, but I wonder if this is related to the change in version conventions (0.12 > 06.01, but maybe the program doesn't recognize that). Second, it is installing the entirety of your OTHOABtextures directory into the GameData folder. This results in the following folder structure: [KSP root]/GameData/OTHOABtextures [KSP root]/GameData/OTHOABtextures/GameData/OTHOABmisc [and its contents] [KSP root]/GameData/OTHOABtextures/Optional The contents of each directory is copied out of the zip instead of just copying OTHOABmisc into [KSP root]/GameData. I'm not sure if kerbalstuff is automating your ckan submission, but you might want to look at it's options or check your ckan/netkan file. It works perfectly when not installed with ckan though. Thanks again for sharing!