Jump to content

huin

Members
  • Content Count

    66
  • Joined

  • Last visited

Community Reputation

46 Excellent

About huin

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yep, I think that's what I thought you meant. I don't know how easy that is to do with Unity's GUI library components - they're a little bit... Interesting, shall we say? Whilst the design as it stands doesn't rule out camera panning, the initial idea for "pathing" the camera's direction is to have it look at a particular position. The original KerbCam worked by interpolating the camera orientation (via "slerping" - spherical linear interpolation), which had some jarring effects when transitioning from one "segment" (i.e the time between keys) of the sequence to another, and it also didn't tra
  2. Zooming and dynamically changing zoom is already on the design doc. Interesting, I hadn't thought of that sort of control system. It's not likely something I'd do in a first version, but maybe something to incrementally add later. The fiddly thing with a touchpad (?) style control is that it's inherently two dimensional, and another axis needs to be available. The particularly interesting point that I think you're suggesting is making it an analogue control rather than digital. Does that interpretation make sense?
  3. Not to worry, tracks wouldn't be connected with saving and restoring paths. Tracks were intended to be a user interface element to group operations together onto the same row in the user interface. The thing that would be saved and restored would be the "story" concept. I haven't put saving and restoring on the design doc, but there aren't major blockers to having it.
  4. So one revision to the design right now is the tracks concept. I think that I'll be removing that concept and make the UI display exactly one operation per row below the timeline. This simplifies a number of things from a development perspective, and I have come to the opinion that it would only force users into a fiddly situation of annoying restrictions as they change things having to manually bin pack operations into tracks - which would suck.
  5. Agreed. It was already in the design as a maybe, although wasn't obviously worded as such without knowing KSP internals. The "camera visible layers" is the thing that would do that. I've clarified that a little.
  6. Ah yes, I've heard that that feature doesn't work. I'll add the "control time speed" feature to the list of example operations.
  7. Timeline I don't think it's going to be feasible for Kerbcam to be able to rewind/replay the universe state. In the limited KSP filming I did I tended to use quicksave/quickload quite a bit to achieve that rewind, so I imagine that's how a video maker would do it. Am I correct in understanding that the following might be a typical workflow? Create a story with time keys, one of the time keys initiates an action 5 seconds after playback starts, and you want that action covered from multiple camera angles. Quicksave shortly before UT 5:10:2:32 (5 days, 10 hours, 2 minutes, 32 seconds into a n
  8. I've created a Kerbcam2 WIP/RFC thread for any input into what might go into a "version 2". (aka a complete rewrite)
  9. First up - no promises. I've made attempts to work on Kerbcam in the past, and have found myself not delivering - at least in part because of a lack of energy/enthusiasm/time and a codebase that got nasty and hard to change. So the intent is for a rewrite, leveraging the lessons learnt from the original Kerbcam, and maybe selected code, but leaving the bulk of it behind. What I'm doing right now is experimenting with ideas for a rewrite. Even if I never execute on this, then maybe it'll be of use to someone else that might want to do this. This post is intended to be an RFC (request for commen
  10. In _theory_ KerbCam shouldn't interfere, provided that you don't try to use both mods to control the flight camera at the same time.
  11. (KerbCam author here) I agree - KerbCam needs quite a bit of love. I've found myself out of time or energy to attack the codebase as it stands for anything but clearly important bugfixes. Camera Tools (mentioned above by falken) looks like a pretty good mod (and I've linked it from my own KerbCam thread). If I find myself with copious time to write code, I would likely just rewrite KerbCam from scratch - but no promises on timescale for that. One thing that would be useful to me (or anyone else writing a KerbCam-like thing) would be to distil down to a few features that are wanted. I've had th
  12. The latter, with fewer files. There was a build of KerbCam which accidentally copied the KSP core DLLs into the distribution, and I didn't notice. Since it was probably (accidentally) violating copyright and also just messy and grr I replaced it with the same build, sans the KSP files. I imagine either downloaded file would work, but rather wish that the first/larger one had never happened (and it's possible that including the extra KSP files might mess things up, particularly in versions of KSP other than that I built against.).
  13. Unfortunately it's simply being ordered lexographically rather than numerically, and I'm not really in favour of putting padding zeros in version numbers. - - - Updated - - - Ugh - well spotted, thanks. Removed. - - - Updated - - - Please do
×
×
  • Create New...