

NavyFish
Members-
Posts
372 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by NavyFish
-
I wasn't aware 1.1 was out so if nothing else, this serves as notification of such. I'll recompile with the new binaries tonight... But I have a feeling more will be required for compatibility. If that's the case, I may need to ask the community for help as this week is particularly busy for me. No offense taken, although other authors may feel differently. Edit: "Why isn't this stock?" I often wish Squad would contact me to 'naturalize' this mod. I love this community and game, but really don't have the time needed to support it as much as is necessary.
-
I don't know much about KCAN... I enabled integration with it via the KerbalStuff mod hosting, but don't use KCAN myself, so am pretty clueless about it. Did it ever get fixed? @WuphonsReach Thanks for the bug report! TBH, the way DPAI selects ports has always been quite hacky, so I'm not surprised a bug finally crept in. Hopefully the KSP API now supports proper module targeting so I can implement a proper solution. Lots of crazy and undocumented code behavior takes place in KSP right at 200m. Very frustrating to work with, but again I haven't visited that chunk of the API since ~0.22,so maybe it's been improved upon. Regarding port compatibility... That's a feature that should already be implemented... Check your DPAI settings. Non compatible ports won't show up in the cyclable list of targets. If not, bug. Let me know. *Edit* Actually maybe I'm smoking things. Can't find that feature mentioned in any of my change logs, so it's possible I haven't implemented it yet, despite having a fairly distinct memory of doing so, lol. If not, I'll try to get it into the 7.0 release (shooting for sometime shortly after 1.1 is out).
-
Yes, and yes. The gauge will line things up so two ports mate face to face with each others 'up' vectors aligned - ie on a clamp o tron, the yellow handle is considered to be in the 'up' direction relative to the port's center. Perhaps he wants it so that the ports are naturally mated at a different roll alignment, which is not an option in the mod, but the same effect can be achieved by rotating thhe target port in the editor. Still, I think that chase cam is what he's looking for.
-
That's not it either. The gauge aligns to the targeted docking port, so it doesn't matter how that port is oriented on the targeted ship. And as long as you select control from here, the gauge is perfectly aligned to your controlling ship's docking port. I think he's confused by the fact that up on the gauge is not necessarily up on the screen, but that will be resolved if be uses chase cam.
-
It was an aesthetic choice for the cinematic, albeit a poor one in my opinion. There are countless other videos where ships burn to a particular velocity and then cut engines to coast. Having played the ICP (predecessor to Battlescape) and being a regular on their forums, I can assure you the flight model in space is fully newtonian. Flight assist is provided but can be disabled. In-atmo, I couldn't tell you exactly because it's relatively new to see. But the devs have stated repeatedly that atmospheric density and the cross-section of a vehicle all affect lift and drag to produce semi-aerodynamic flight modeling. They use more of a lifting body approach + thrusters rather than using wings with active control surfaces.
-
Thanks hope you like it! DPAI development has been on hold for a bit, mostly due to commitments in my professional life. But please don't hesitate to report bugs or present feature requests, as I do read each post in the thread and appreciate the collaboration. I expect the next update will come around the time of the KSP Unity 5 integration update. Cheers!
-
@Kiro - Thanks! Glad you like it. That mod you saw was "Lazor Docking Cam", which I believe is now defunct (not sure). "Docking Cam" is an increasingly requested feature. I'll add it to my list of things to explore, but it's not a high priority because the perceived payoff vs effort isn't too high. I can't imagine that implementing a render target in a plugin is too easy. Then again, I don't know - I'd have to look at some of the external camera mods etc to see what that would take. But I still don't understand what it buys you as the player. If you're doing EVA view, you can see the port with your main camera. If you're IVA you can use RPM to display a view from your docking port. So other than perhaps a touch of atmosphere or 'cool' factor, what does it buy you? Not trying to be negative. But I have to asess the cost-benefit of all changes because this is very much a tertiary hobby for me, and time is money :/
-
As the tiltle asks, do we know if the shift to Unity 5 will break support for mods which have GUI elements? I can only imagine it will. If this is the case, can you throw us modders a bone in advance of the release and describe at least some of the larger API changes? Would be wonderful not to have to 'cram' the night of the UE5 update release to restore compatibility for our mods. Thanks for your time!
-
So, yes, that ^ If I implement the requested feature, it would be flashing red text across the center of the display saying "Port Size Mismatch" or something to that effect. No indication of larger/smaller, and definitely not a permanent part of the indicator. Less is more. Plus I'm not sure if you can reliably determine the relative sizes of two ports. I'll have to dive back into the docking module logic to figure out what makes ports copacetic. Thanks for the reference to Universal Docking Ports, as I can probably look at that code to figure it out. ---- The problem I'm facing at the moment is that due to unity 4's sheetay GUI support, I had to create two completely separate rendering pipelines in order to support RPM. RPM draws to a texture, while the normal gauge uses deferred rendering unity GUI functions, and the two pipelines simply do not talk to each other. So any change made to the display has to be made twice. This gets really finnicky because the display sizes aren't uniform (RPM displays can be any size, for example), etc. Anyway, it's a hassle and I've been thinking of ways to improve it. Particularly if I ever want to put the code up on github - right now it's not very fun to look at. And, DPAI seems to be sticking around, so, might as well keep it well-maintained! Then comes along the Unity 5 announcement. This is good and bad. Bad: unless Squad decides to completely 'emulate' the Unity 4 GUI pipeline for backwards-compatibility of mods (I doubt they will), certain chunks of DPAI (and most other mods) will require a re-write. The Good: The new GUI system should allow me to unify the rendering pipelines. Hurray. So I've been hesitant to write any updates to DPAI prior to Unity 5, as it's going to require a re-write at that point anyway. If the switch does break mods, i just hope Squad sends out a development version or something to allow modders to fix their stuff in advance. Again, doubtful. Maybe I can get on the experimentals team. Anyway. Hope everyone (in the northern hemisphere) is having a nice summer!