huin

To content creators using Kerbcam: As a general comment (as the creator of the plugin), I'm somewhat worried that the 0.23 release might break the current version of Kerbcam, given some things that Harvester has said about changes in the camera system in KSP. Time-permitting, I will be attempting to fix Kerbcam accordingly, but be warned: it'll depend on my free-time availability around the time of release, and what changes will be required. Of course, things might not break, and I'll be interested in reports either way, especially with clear steps to reproduce problems, and what the actual versus expected behaviours are. Edit: So 0.23 has been released, and the timing is unfortunate, as today was the last day I could conceivably work on (or even test) Kerbcam for at least a week - I hope it's working :/

Replied to you on the issue you raised on Github: https://github.com/huin/kerbcam/issues/6

There isn't a direct download link from the first post. I've drawn more attention to the first link in the post, which links to the Spaceport page for it (it possibly wasn't as clear as it could be what that link was).

So do I

Excellent, thanks! I'll bump the thread title.

I don't *know* that there's anything that would have broken it in 0.22 - but I haven't tested it, I'm afraid, and no time this weekend to test it. But let me know if you run into any problems.

It's the top-requested feature on the poll on this thread. That's where I ran into my pain points listed above in trying to implement it. Possible: yes. Probably not in the near future, as I'm taking a break from working on this mod, as it's been such a massive time sink.

I can't even begin to imagine why it would switch camera view mode :/ Can you come up with an exact sequence of steps that reproduces this?

Chrome seems to be having issues with quoted replies, so here's a reply/update without quoting (yay): TL;DR: I'm not sure when I'll next do any major updates to KerbCam. @Elliptical Orbit & @alacrity: Yes, I've had similar ideas to those and would love for them to get implemented. I occasionally work up the courage to hack on the codebase some more, but each time I do, I run into several mental blocks on how best to progressively change it towards something more flexible that would serve more general use-cases (that and I have several real-life things to interrupt me). I'm beginning to wonder if a rewrite is in order, but I'm not sure if I have the time or inclination to undertake that effort. My previous efforts at fixing/feature-adding to KerbCam have often taken many times longer than I anticipated, owing to a combination of factors, such as: Meddling with KSP's internals in ways that they are not suited to be meddled with (i.e messing with the cameras) often leads to subtle and hard to reproduce bugs. Lack of documentation on KSP's APIs is a pain, but understandable. Failing that I could use an up-to-date version of the public/protected class metadata for searching across. Debugging the mod is difficult, in that stack traces don't contain line numbers, and I have been unable to attach a debugger to the KSP process at anything other than a assembly-language level (i.e not a Mono/.NET level). (I can imagine that even if this were possible, the KSP developers wouldn't be too happy about the internals being reverse-engineered to that degree - which would be fair) Due to a lack of debugger, the only other alternative is to introduce logging statements to attempt to discover more about a problem, which means recompiling the mod. To introduce a newly compiled version of the mod means a complete KSP restart, which takes upwards of a minute or two to get back to a testable position. This gets frustrating. I suck at coding in C# (this is the only codebase that I work on that is in C# or .NET). I also suck at making GUIs. (you may have noticed) The coding part of my brain is often exhausted from work-related coding and other occasional minor side-projects. If anyone knows ways to overcome some of the above, please let me know! So the current status is that I'm not sure if/when I can see myself doing anything other than making KerbCam work with KSP updates (which is itself by no means a sure thing). I would *love* to implement many features and get rid of some bugs, but I feel the need to explain why I've so far been failing to do so - I've been feeling guilty at taking this long to progress any further. I love the videos that I've seen made with this mod, and I would love to take steps to make even more things possible. Right now: I don't have the energy. Sorry about that

The bug itself should be fixed - for now I've taken the easy option of just switching back to the active vessel when the relative-to vessel is destroyed. Thanks for the report!

I'll have to press you for specifics... How does that differ from what is possible with a path at the moment?

Pretty sure that's my fault, and I suspected this bug, but there was a bigger more common bug I wanted to fix in the last release, so I didn't delay it. In Unity3d (and therefore KSP) there is a hierarchy of objects, with transformations tracking child/parent relationship. One thing that KerbCam does when changing the camera to be relative-to an object is reparent the flight camera to that object. If that object gets destroyed, I believe it destroys all of its descendents (children, children of children, etc.) - thus destroying the flight camera - which has a number of wonky effects. I was attempting to test for this prior to the last release, but couldn't quite figure out which event hook to attach to, and what was to happen then. (One could argue it as being a KSP bug, but I think that would be unfair, as I'm moving objects around in a way that breaks their assumptions about how objects interact) One question I'd have to users of KerbCam is: what should be the correct behaviour of the camera when the object it is tracking is destroyed? My initial answer would be to pin the camera in place relative to where the object was last, at the instant when it is destroyed. Thoughts?

Huh, that's rather curious. I guess I'll repackage next time without the source. There's links to the source on github in the program. Thanks for finding that out!

Thankyou for that video, it was very helpful! I've just managed to reproduce that specific problem, and extract useful debugging information. Found some very silly and fragile code that I'm surprised wasn't broken before. Basically the code that works out where it thinks the camera is and is pointing was using the "main" camera, and its root. I think it was the switching to the map view changed the "main" camera, even when returning the the flight view. The fix is simple, I should be using the FlightCamera instead (seems kinda obvious, right?). Edit: ...and fixed! Hopefully that's all the show-stoppers fixed. Let me know of any more trouble, and thanks again!

Can you reliably trigger the bug (i.e what steps do you take?), and what happens when it is triggered? I've managed to isolate the problem causing the stack trace that you pasted, but I'm not convinced that that was the only thing going wrong. I managed to get that stack trace also, but it didn't seem to lead to anything very bad. (I experienced weirdness on the map screen - but I'm not having much luck trying to reproduce it) Edit: I've treated the symptom that I can find in this cut of KerbCam (not an actual release as yet): https://googledrive.com/host/0B8pOEbkBskJGRDAzMGZYYjdDY0E/KerbCam.dll however, I've got lingering suspicions of remaining troubles.

Thanks for that. I've just now experienced some weirdness myself with the plugin. Clearly something is still very broken >_< (the stacktraces in your first quote are the trouble. the latter stuff about the config file is okay)

If you press Alt-F2 to bring open the debug log window, does it show any exceptions before or during the time when you experience problems, especially any log entries containing "KerbCam" in them? If so, can you copy the log message(s) out from KSP.log and show them here for me? Thanks.

When enabled for a path, and values other than 1 are set on keys for the "timescale" it should slow down/speed up down game time as the path is played. (In theory at least, I haven't tested it extensively)

Hurrah! Nailed the problem down and fixed it. Now I've got to do some tidyup work, but things are looking good. Edit: Oh, and lots of testing before I release, I think! Edit 2: Ugh, subtle bug, not as bad as the one I've just fixed, but annoying nonetheless. If I can't fix it soon I'll release 0.10 with the major fix, and state the workaround. Edit 3: Done. Tried to fix one last annoying thing with camera behaviour when the focused/active vessel is destroyed, but seems non-trivial, and is probably an existing and less serious problem. Released 0.10 with the important fix. Thanks for all the reports!

First bit of good news, I've figured out the weirdest part, that being the staging breaking. I had attached to an event handler that fires when a vessel is switched to, and an error in my code seems to have broken that event handling following a scene change (e.g reverting the flight). More to work out before I can say that I've root caused it, but it's a start.

Excellent, thanks for making the effort to writing down your experience, and bringing in the stack trace. That will be *very* helpful in tracking this down! Thanks also for the report. I'm more hopeful that I'll be able to track this down, but am only just about to start! I'm rather confused about some of the other effects that are mentioned, but I'm pretty sure I'll be able to track down some of the oddness, if nothing else.

Ugh, that sounds pretty bad. I'll try to take a look at that this evening after work. Thanks for the reports!

There, 0.9 is out! That should fix some more stuff.

Thanks! I had wondered this as well!

That's weird... So you create a new path, move the camera, press "new key", and it display random symbols and things? Could you post a screenshot?