SirJodelstein

I have a problem with how KSP decides where to focus the camera on after destruction of the root part of a ship. Does anyone have a working solution for this kind of setup? I basically built my probe inverted, so that i can attach the probe to a mothership. Problem: As soon as the root part burns up (intended!), the camera stops tracking the remaining parts of the probe. They are still in the map view, and i can switch to them, but obviously they are moving on rails until i get the chance to switch to them, making everything worse decoupler<<<root tank + radial drive (intended to burn up) heatshield heatshield (yes, another one just to be safe, first one might burn up) probe chute (no radial chutes available)

I just noticed that at warp rates 1000x and more, probes without power (no panels/rtg, depleted batteries, opened scanner device) can still scan and update the map. At 100x and less, no scanning happens and a "no power" status is displayed correctly. Is this a known issue? Is there a way to close the panels or prevent scanning in such a case other than safe-file editing? Edit: It seems that even safe-file editing does not help here. I set the scanner modules to "isEnabled = False" and "scanning = False", and still the scanning happens.

No, thats not possible, and would be a very far stretch, because the playback vessel is mostly geometry only. However, we have plans to make the camera follow the playback vessel, maybe something like this could be used to create a fixed camera view from the vessel.

how about an extra category or multiplier for not using the thrust limiter? Landing on Gilly or other low-grav moons might be a challenge because of too much thrust for controlled descents then? Wait, i gotta try that on Minmus now

Sure enough, but its really not more than what i posted before: The FigaroGPS mod gives you two new parts, a transmitter and a receiver. To get the benefits of a useable GPS receiver on the surface, you need to put enough satellites with transmitters into orbit, and arrange them in a constellation so that >=4 sats are always visible in the sky (more sats = more precision). Mine looks like this, after the European Galileo GNSS, but there are plenty other constellations to achieve global coverage. Thats FigaroGPS. Integration with PersistentTrails is optional. With PT1.1, if (and only if) you decide to put a GPS receiver on your vessel, the "start new track" and "continue track with active vessel" buttons will not be clickable unless the receiver sees four or more transmitter satellites. If you have not enough transmitters in sight, the button will display "[- NO SIGNAL -]" and be disabled. If you dont put a receiver on the vessel, or you dont have FigaroGPS installed, or you have an old version of FigaroGPS, recording will be available just like before. So its just an optional "hard mode".

Addition to previous post: If i create a node; - if the first edit is via the 3d handles, the changes are not reflected in the PreciseNode window. all numbers read zero. - if the first edit is via Precisenode controls, any change via the 3d handles resets the maneuver node. Also, the dV-Meter (right of the Navball) is not adjusted during the execution burn, which screws up the maneuver prediction

Please note that the default scienceDefs.cfg in .23 has lowered scienceCap values for most experiments. If you merge the files, it would be nice to get the new values into the shared file as well.

Version 1.1 is out and confirmed to work with 0.23! Changelog: - Integration with blizzy78's excellent Toolbar plugin. It is included in the download. - FigaroGPS support. If (and only if) you have a FigaroGPS receiver on your vessel, track recording will not be available unless at least 4 transmitters are visible. - Changed icon folder structure. - Fix: Ignore Launch Clamps, struts and fuel lines for replay vessels If you are having issues with the icon not showing up, please make sure your Gamedata folder looks like this: 000_Toolbar ... PersistentTrails ... Squad , and that there is a folder called "Icons" directly under the "PersistentTrails" folder. If you already have the 000_Toolbar folder from another plugin, only overwrite the Toolbar.dll if the delivered version is newer. If you are still having problems, please post a section of the Debug Log (Alt+F12) and list the mods (+versions) you are using.

Another vote for integration with the toolbar mod.

Russel's Teapot exists! I have found it floating between Kerbin and Duna.

success! congratulations china!

Success! Launch video: here. Thanks to the Hull camera plugin, the launch almost looks like a launch webcast :-)

Got it. I always tried to feed an absolute file path + Filename + fileExtension to the texturepath. Using the Gamedatabase obviously makes things different (root is "GameData", no file extension). Oh dear, that took way too long to figure out. Anyway, thanks for your hints, I'll release an update soon!

I dont see why that would be a hinderance - the "load craft" dialog has a "invalid/unresearched part detection" check as well, same could be used for the subassemblies. And yes, i know that its possible to do manual copies. Like i said in the OP, this is the way i am currently doing it. Its just feels like unneccesary overhead, and leads to the "maintain consistent state across multiple copies" problem.

Unfortunately, that did not help. Moved the icons from GameData/PersitentTrails/PluginData to GameData/PersistentTrails/Icons. Still getting the error. Moving the code to OnGui helped somewhat, atleast now it draws an empty clickable button instead of just the toolbar frame.

I think it would be immensely useful to make subassemblies optionally savegame-independent. For me, the subassemblies tend to be lifters, stages, rovers etc that i want to use across various savegames anyway. Currently, i regularly copy subassemblies from my "Testing" sandbox game to a career mode savegame. Also, whenever i modify or update a subassembly in one savegame, i need to copy it to my other saves, etc. This could easyly be improved by optional global subassemblies. Maybe this could be realized as a a simple checkbox for each subassembly that marks that subassembly as "global", and moves the subassembly from the local savegame folder to another folder that can be accessed from each savegame.

Hmm, i must be doing something wrong or missing something. The one button i created shows up, but without an Icon, and the debug log shows a warning [Error]: error loading button texture: C:/Spiele/KSP 0.22 DEV/KSP_Data/../GameData/PersistentTrails/PluginData/Main-NoRecording.png I double-checked the file existence and correct size (24x24 png), but the error persists. Next: Whenever i click on the button, the toolbar jumps around a little. It repositions itself to place the clicked button centered below the mouse. But perhaps thats just because the button is not actually there? Toolbar text doesnt show up either. Here is my code for the button. I have placed it in the Awake function of my plugin. Or do i have to call that block in each "OnGUI" call? mainWindowButton = ToolbarManager.Instance.add("MainWindow", "mainWindowButton"); mainWindowButton.TexturePath = GUIResources.IconNoRecordingPath; mainWindowButton.ToolTip = "Persistent Trails - toggle main window"; mainWindowButton.Visibility = new GameScenesVisibility(GameScenes.FLIGHT); mainWindowButton.OnClick += (e) => { Debug.Log("button1 clicked, mouseButton: " + e.MouseButton); mainWindow.ToggleVisible(); };

What an amazing thread. From thought experiments to construction planning and fundraising. The KSP community never ceases to be awesome. The though of actually mounting a bus on a rocket is pretty hilarious Working on a solution.

challenge accepted. Very cool thread btw, totally recommended for an entertaining read full of geekdom. Edit: This is fun. Sneak peak: Yeah, and difficult. The rocket is not even remotely centered below the 35t bus, so some more engineering is required to prevent tipping over. Working on it.

Exactly. If you activate the colliders for replay (track edit window), you can even crash into the on-rails replay vessel. The replay ghost is of course no real "flight", so you can't switch control to it etc. Formation flying, mission NPCs, racing vs. other players ghosts, moving fly-through gates - lots of stuff you can set up with this.

That icons position is hardcoded currently. Waiting for the release of a generalized solution from this promising thread instead of trying to come up with the N+1th custom implementation of this feature.

Very interested in this. Will definitely use this (whatever you come up with in the release) for the the Persistent Trails plugin.

As Snjo has already indicated, here goes the official release statement: Snjo and I are very happy to announce a successful code merge of Flight Path Recorder and this plugin. Development will continue on this plugin with joined forces! Version 1.0.1 is out and delivers a ton of improvements and new cool features to play with: - Vessel playback. Boring spheres are a thing of the past. The current vessel geometry is saved automatically upon creating a track, and will be used for replay - Physics colliders playback. You can enable physics colliders in the track edit window. This allows you to crash into playback vessels - "Off rails" at playback end: Activate this to let the phyisics engine take over the playback vessel at the end of the playback record - Playback looping: Enable to automatically rewind and restart playback at the end of the record. Set the "loop closure time" to determine the duration of the interpolated missing link from end to start. - Smart node placement. The "recording interval" buttons are a thing of the past. Instead, nodes are placed as necessary depending on change of orientation, velocity or speed. Three modes (high/medium/low precision) for setting the tolerances. Can be changed in-flight or during recording - New save file format. Orientation and velocity data is stored with each node, and the header has a new format. Backwards compatibility is in, but vessel replay wont work because of missing orientation information. - Moved to Spaceport Now show us what you can do with this! And stay tuned, because we have a whole lot of plans for the future :-)

Progress in inevitable. Cool stuff is about to happen. This is a preview of whats coming out of cooperation with Snjo. Yep, thats an actual (geometry-only) model thats flying the recorded track, and no longer a boring sphere. Racing/Dogfighting just got a whole lot more interesting :-)

Excellent ideed!