Jump to content

HebaruSan

Members
  • Posts

    4,991
  • Joined

  • Last visited

Everything posted by HebaruSan

  1. I think the OP is asking about videos from real life. These are what some Discord users offered when I asked the same question: So indeed, applicable reference images are quite scarce, given the difficulty of stationing a camera a steady 50m from a reentering object, and much extrapolation has to be done. The one thing that seems clear is that the trails are many many kilometers long, which I haven't seen reflected in the WIP screenshots thus far.
  2. Fingers crossed that this the developers of KSP2 never attempt this. The constraints that it would impose on the sequel would be extremely severe and unwarranted.
  3. Some of them probably also prefer to start fresh new innovative projects rather than parachuting into other people's disasters to clean them up. Why put yourself in a position to get harassed for your work on social media if you could be widely adored like Shigeru Miyamoto instead?
  4. Checking some mods' code, I'd try finding fields with both the KSPField and UI_Label attributes, with the left half of the text from KSPField.guiName and the right half from the value of the field. https://www.kerbalspaceprogram.com/ksp/api/class_u_i___label.html
  5. Yes, it depends on the direction from which you approach the other ship. If you come at it from the prograde or retrograde directions, then you'll be at almost exactly the same altitude with the same inclination, so 0 relative velocity is a good indicator of identical or extremely similar orbits, and it will probably hold like that. If you approach from radial-in or radial-out , then you're either higher or lower than the other ship, so the orbits will be different regardless of whether the relative velocity is 0, and you'll drift out of that arrangement. The normal and anti-normal directions are special; here you can use the drift to your advantage! An approach from these directions starting from 0 relative velocity means your orbits are the same in everything except inclination, which means they intersect at ascending and descending nodes. So as you approach the next such intersection, the motion will be towards the other ship, and if you're patient, you can use it to complete the docking maneuver!
  6. What's interesting is that the version file says 1.10 or greater, which means the clearest expression we have of the author's intent says that it is still expected to work on 1.12: "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 10, "PATCH": 0 } However, that version file wasn't actually included in the last two release ZIPs, so it got indexed without any compatibility info at all. @EnzoMeertens, are you still here? If so, can you clarify whether this mod should be listed as compatible with KSP 1.12? @linuxgurugamer, did you end up adopting this mod as per the last page of its forum thread?
  7. "Break" doesn't describe the scenario I was imagining: Artist mocks up some screenshots in photoshop, which look great, and hands them to developers, who struggle to implement some of the ideas fully in Unity without additional assets and eventually end up at the current mess. Moot if those are from videos, though.
  8. Oh dear, that looks like they're hand-editing those in some kind of GUI designer in Unity without a library of shared components. You can see that some consistency was attempted by the common "TITLE -----/" pattern in the headers, but the background colors alone make it obvious that there isn't yet a common "dialog prototype" to be re-used. Are we sure those weren't just mock-ups? Maybe the current state is just what happened when they tried to make the transition to functioning code.
  9. First, thank you for doing this! We can expend as much effort reporting and analyzing issues as we like, but unless someone does the work of gathering, summarizing, and presenting it to the folks in the trenches, it's all for naught. Frankly, so many things are wrong with the current UI that I doubt that a one-fix-at-a-time approach can be successful. A root cause analysis of what went wrong is needed to determine how to move forward. Is there no UI/UX designer in-house? Hire one, pronto! Is there one but their advice was ignored or bypassed? Give them more authority within the team, such as mandatory reviews and sign-offs before feature branches get merged. Is there one and their advice was heeded but poor? Replace them (carefully!). It's essential that interfaces be designed competently before they reach the point of end users giving feedback, because at that point you're going to get an overwhelming mass of bullet points as users pick the dozen nits that irked them individually (see above and below!). Before specific gripes, a general rule: Never prevent the player from doing something unless it is impossible or will 100% ruin something. You may think you have a good reason to disallow an action, but if the player thinks they have a good reason for wanting to do it, the player should win that argument every time, especially in a creativity-focused sandbox game with a "learn by failing" ethos. Give feedback or ignorable warnings if you think there's a high chance of unintended outcomes, but never just refuse to comply with a comprehensible request. This rule of thumb has been tripped over in several instances already (time warp limits, maneuver delta v limits, entering the Tracking Station from the VAB), but it's important to get clear on the general principle to avoid repeating the same fundamental error in future features. Workspaces! I can't tell what they're for. The fact that the name "workspace" is in the UI instead of just "vehicle" or "craft" implies that they do something in addition to just holding a craft, but I can't figure out what that is supposed to be. The save dialog says "SAVE VEHICLE" and "EXISTING SAVED VEHICLES", and the first thing it prompts for is "Workspace File Name", are you starting to see why this is confusing? (Note to readers: Past this point I am going to type questions, but I am not seeking answers for them! They are my attempts to represent my puzzled reaction to this feature and how it could be made clearer. Please do not answer them here!) Is a workspace meant to represent: one craft? one category of crafts, like all of my spaceplanes? one project, like a multi-part space station? Is it supposed to contain multiple revisions of one craft over time? What exactly is supposed to be grouped within a "workspace"? Why am I prompted to enter two names, workspace and craft? At a glance it seems redundant. The existence of two names suggests that a workspace can represent multiple craft, but that's contradicted by the fact that each workspace can only have one craft name. What is the use case in which they would be set differently, and to what? In the loading and saving screens, I see previous revisions of my current craft, which suggests I'm looking at older versions of it within the current workspace, but I also see completely unrelated crafts, which suggests this is a listing of all my crafts. But the current craft shows up multiple times, because...? The description of my workspace says "AutoSaved workspace" with a timestamp, but I've saved over it manually. Maybe don't default in that string, or clear it when overwriting manually? The message after a vehicle is destroyed sounds passive aggressive / snarky ("That could have gone better" or somesuch?), which compounds irritation and depletes goodwill when a bug is involved. It reads like the character is commenting on your failure as a disinterested third party, from the outside. Instead they should be commiserating like a team member dealing with a shared trauma in the first person plural (maybe something like, "Oh, no! Well, don't worry, I'm sure we'll figure out what went wrong there!"). When making a maneuver node, I have to click it again to edit it (I think?), just open it by default since that's what I want every single time. The majority of the info the Parts Manager displays is useless and unrequested; if I right click a command pod, I don't need to see a non-interactive list of all the fuel tanks as well, and the cost in valuable screen real estate is stupendously high when it covers the craft I'm editing. An easy fix without starting over would be to only show parts in the Parts Manager that the user has right clicked on. If I right click one part, show just that one part, and only add more if I right click more parts. Remove them if I right click again (or click an X within the PM). Bonus points for auto-sizing the window to fit. I'm in the VAB, and I want to go to the Tracking Station. Why can't I? The option is disabled in the Esc menu: Others have commented on the ugly frame header text in the flight UI; I'd suggest simply removing those and making sure it's easy to tell what the content is without them. Is anyone going to have an "Oh, I get it!" moment after squinting at "APPS" for several seconds to be able to read it? What could "APPS" even mean to a player? On a partially-occupied vessel, the seat cameras show empty seats by default, requiring scrolling to find the crew, and I think that even resets itself to empty seats in various cases. Show the seats that have crew in them first!
  10. You can configure CKAN to launch KSP2 via Steam: Settings → Game command line steam://run/954850 (← this also works from the OS's run dialog) ... by default that will run the launcher, but any of the available methods for bypassing that should still work:
  11. Depends on the mod. Some mods are hosted on GitHub instead of SpaceDock, some have fallback URLs at archive.org, and some are actually unavailable till SpaceDock comes back. ... which it just seems to have done.
  12. There's a particular day in December when people tend to give each other gifts. I think it's called "Steam Winter Sale" or something like that. Expect the update to be timed to take advantage of that.
  13. Hey @VITAS, the site's down. Refusing connections since about 4:09 PM UTC. Looks like ATS, since I can still ssh in?
  14. Soon™! It's currently held up by a syntax error in the version file; a comma is missing between PATCH and BUILD: Please let me know if there's someplace you'd like me to submit a fix pull request.
  15. Yup, this is a big problem for precision rendezvous/docking (I submitted a duplicate of this before, not sure of its current status). Engaging timewarp resets the markers, a telltale sign that rotation is playing a role it shouldn't, since timewarp also currently arrests rotation. ... found it:
  16. Thanks for the book recommendation. I suspect it has already been gift-purchased off my wish list.
  17. Critical bug fixes: Don't explode on docking (possibly related to landing gear phantom forces) Don't fall apart on switching to vessel from tracking station (also possibly related to landing gear phantom forces) Make the target-relative nav ball markers stop wobbling around when you rotate the craft Quality of life: Make the parts list in VAB less wide or collapsible No limits on time warp if periapsis is out of atmosphere/surface Make "workspaces" less confusing (A fresh UX consultant should be able to give you several pages of feedback based on a few minutes of user testing.) The VAB has a lot of popups and manages them poorly. Make sure the newest one opens in front, try to avoid overlapping them, make them take up less space, make them auto-hide when you're done with them, etc. (Maybe another task for the same UX consultant.) Display time till ascending/descending node in map view Interactive IVAs Overflow in case bug fixes weren't meant to be included here:
  18. If you let the forum software censor the original word, then we can figure out what it was.
  19. I don't remember, is it also gradual if you click the warp bar section to jump to 1x directly?
  20. In case this helps anyone else: My frustration with VAB2 mostly ended after I realized I could middle-click a part to center the camera on it.
×
×
  • Create New...