Devoblue

Current version is 1 point ten, going to 1 point eleven. 1 point two was ages ago.

Nice, the current ones were so heavy for tiny craft. Hoping for new RCS engines too. The 0-10 being the only choice makes monoprop awkward to use.

Looks cool, but, I visit bugs every time I play. Bop not so often. so can you please fix bugs . And fix bugs. Also, fix bugs.

A simple way I've done this before is have the deployable script count the KOSProcessors on boot, identify the S2 processor, and FOR eachModule IN SHIP:MODULESNAMED("kOSProcessor") { LOCAL eachPart IS eachModule:PART. LOCAL tag IS eachPart:TAG. IF tag:STARTSWITH("mission/s2") { SET processorS2 TO eachModule. } } IF processorS2 <> 0 { WAIT UNTIL processorS2:PART:SHIP <> CORE:PART:SHIP. } The way that you have described involves CORE:MESSAGES - being a message queue and commands around that. Useful if you want to invest in understanding everything around it, but more complex for your simple use case.

Same as before, while waiting for the 1.10 update, copy the 1.9 in place. Goto \GameData\Trajectories\Plugin Copy paste Trajectories19.bin. Rename the new file to Trajectories110.bin

I agree that looks weird. Not being a Unity guy this one is perhaps beyond my expertise. I've tried a high and low graphics settings, looked at using other shaders, I can't reproduce the disappearing cross. The cross being above the ground in map view is something that occurs in 1.7.3 with the released Trajectories 2.2.3, so nothing new here. It might be worth you doing some testing yourself. Does changing your graphics settings fix the problem? Does an install without any visual enhancement mods have the problem?

I've created a pull request that fixes 1.8, but breaks earlier versions. I suspect I can avoid the earlier version break. It also fixes the ArgumentNullException Until that fix is merged or superseded, a work around is to install 2.2.3 and then download the 18.bin from the pull request on github and place it in GameData\Trajectories\Plugin https://github.com/neuoy/KSPTrajectories/blob/7c1ca247675d8bc4e649aaa63834d7f7fe9c682a/GameData/Trajectories/Plugin/Trajectories18.bin

The issue is in a file copied from mechjeb (GLUtils.cs). The fix is the same - line 15. Shader.Find("Legacy Shaders/Particles/Additive") https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/GLUtils.cs

On a fresh install of 1.7.0 this mod (v2.2.2) doesn't work, but after copying the file \GameData\Trajectories\Plugin\Trajectories16.bin to Trajectories17.bin, limited testing indicates it still works fine.

Can do. Where do I get it?

This is great, it wasn't exactly what I was expecting but I can see why you've done that and I can make it work. I need to bind Enable with Rotate Clockwise, and Disable with Stop - and then it turns out just fine. Thankyou. In relation to making it better with kOS, kOS can interact with any of the events/fields/actions in the part menu. This is all the information that we can get, so the better and clearer the information there, the easier it is to manipulate via code. Although it is possible to read the "angle" field and parse it to guess as to what the port is doing, DockRotate would be a bit easier to manipulate in simple scripts if menu options were disabled when they don't make sense to be enabled, and the angle field was perhaps split into several fields. For example, Stop Rotation only makes sense when the part is moving. In continuous rotation mode, being able to see the Rotate Clockwise (+) when already rotating clockwise I think does nothing, so if it wasn't available it would be an easier indication of current state. Take a look at a retractable solar panel for how the Status field gives useful information, Sun Exposure and Energy Flow are separate fields, and the Extend and Retract options are only available when they make sense. If "angle" was replaced with for example "Current Angle", "Current Speed", and "Status" (Stopped|Stopping|Started|Starting) it would be simpler. That said, none of this stops me doing what I want with Dock Rotate presently.

I have a brief kOS script that watches the craft throttle and changes the rotation speed of the rotors so that the rotor speed is effectively controlled by throttle. This works fine for simple craft. But, now I have a more complex craft that has other engines, I want to be able to action group the on off so I can be throttling engines, or throttling rotors, or both. I could work around this by toggling the rotors through an action group via kOS. This is not elegant as it means the generic rotate-by-throttle script now needs to be action group aware for the specific craft.

Is it possible to toggle Rotation enabled/disabled via action group? Perhaps I should elaborate. If I several parts that are rotating through an action group, I want to stop the rotation of some of those parts but continue to have the remaining parts respond to action groups. So If I disable rotation on a part that is rotating, I'd like it to come to a stop and not respond to further actions that rotate it until it is enabled again.

But https://ksp-kos.github.io/KOS/structures/vessels/crafttemplate.html#attribute:CRAFTTEMPLATE:FILEPATH

I'm trying to make use of CraftTemplate:FILEPATH but I get suffix not found? I hadn't tried using it before. Is this a new problem related to the latest release? For my test vessel "aaa 3.1" which is in "aaa 3_1.craft" and also for "aaa" which is "aaa.craft" This works: PRINT KUNIVERSE:GETCRAFT(SHIP:NAME, KUNIVERSE:ORIGINEDITOR). This doesn't: PRINT KUNIVERSE:GETCRAFT(SHIP:NAME, KUNIVERSE:ORIGINEDITOR):FILEPATH. In any event, I was just looking for an escaped name to save a log file as, so don't need the whole path.

Thanks for your work on this. Much appreciated. The first thing I noticed with this was that my ascent script progressively turned ksp to glue, slowing down the simulation so much that phys warp 3 was approximately real time by the time I was a minute into flight. I guessed that this was because I was locking steering and throttle every pass through a loop, so I optimised these and performance went back to expected. This was a gradual process of slowing down so I wonder if there is some loss or inefficiency in LOCK that worsens over time.

I use the latest trajectories - downloaded manually instead of from CKAN because CKAN thinks the latest version is the second latest. I use kOS from CKAN, but replace the plugin dlls with versions built from source using visual studio. These work fine.

The body lift on tanks has completely disappeared too. It's not just space plane parts. A 1m rocket that I used to be able to glide back to launch pad and steer (slightly, but enough) by tilting now makes no changes to its trajectory. I can turn it sideways and it slows down to 60 m/s, but this makes no change to where it was going to land. It lands where the boost back burn leaves it. There was no mention of this in the changelog. I can only assume it was not intentional. Otherwise great update, but sticking with 1.4.5 now until this is fixed or I redesign my rockets to use the stock gridfins

Thank you, was just about to report exactly this.