Jump to content

StarManta

Members
  • Posts

    139
  • Joined

  • Last visited

Everything posted by StarManta

  1. This is one I'd also love to see discussed! If it's been in development as long as I suspect it has, though, I doubt it - ECS only came out less than a year ago. That said, as long as they're not needing to be concerned with backwards compatibility, it might not be too big a job to change parts of it (e.g. all the ship parts) to use ECS and take advantage of that performance bump. That would be exciting!
  2. No, they're making a clean break. If they supported backwards compatibility they wouldn't be able to do half the new stuff they're planning.
  3. The announcement post mentions a pair of binary planets, so there's SOME level of upgrades from the current system. I'd be surprised if it was true N-body, but I'm not gonna rule out being surprised.
  4. I have a feature to add to this: Undo. If you have dragged it too far in one direction, or dragged it until you realized it was the wrong direction to drag it, you can undo.
  5. I disagree. If this function is available on every part, it doesn't even need a "label and button" like standard actions - it could be just a tiny button with a little eyeball icon in the corner of the context menu. (Since it's a non-destructive action it doesn't need to be labeled - it's safe for users to discover it by trial and error) In fact, I would say that limiting it to certain parts would dramatically reduce clarity, in addition to utility. The probe cores and cockpits already have a lot of options, and another "text and button" option would simply get lost in the list.
  6. The problem is that forces can still translate and feed-back through the docking ports, and that's what prevent them from being on different cores. For example, imagine you have a big space station, and a tiny capsule, connected to the station by a docking port. Now, take another ship, and ram the tiny capsule. The physics engine must not only calculate how hard the capsule pushes back against your ramming ship, it has to calculate how hard the entire station pushes back. The mass of the station, not to mention how it's configured, all factor into the "pushing back" factor - if said docking port is on the end of a flexible 'arm' of the station, it won't push back as hard as if it's in the central area of a solid, rigid station. That "pushing back" calculation is nearly impossible to split into threads, and it has to be calculated a lot, even for non-ramming purposes. That's probably the main reason for not being able to split it into different sections. Some games (I think Space Engineers does this?) get around this sort of thing by having the core of the station be 'static' - it doesn't flex and doesn't move no matter how hard it's pushed. So when the 'pushing back' calculation reaches a static part, it can stop, and doesn't have to care about anything that's connected beyond that part. Thus, each connected part that is physics-simulated counts as its own independent vessel, and can be simulated on a different thread. Possibly, in a future update to the game, the rails physics might be updated to simulate the station core itself and make it static, under certain conditions (e.g. it's not rotating, it has enough solid rigid parts that it wouldn't flex, etc) - but such a system would be prone to its own bugs and problems unless extremely carefully handled, so it might be kind of a long shot.
  7. Maybe you get upgrades to the Tracking Station not by just spending money on them, but by getting X number of GPS satellites in orbit?
  8. I'd like to see the bug report on that one. Expected behavior: house remains intact. Observed behavior: house is on fire. Priority: Medium
  9. Well, it would be if you could see the number without having to keep your mouse over the thing. (This seems to be one of the interface quirks that's getting retooled for 1.1, FWIW) MAYBE if you have an extremely high-ranked Pilot (like 4-5 stars), AND have docked before a certain number of times. But having an auto-docker that newbies can use instead of learning how to dock would remove one of the most satisfying challenges from the game. (Go check out the KSP subreddit sometime, and see how many of the posts are "This isn't much, but I just docked two things and I'm SO PROUD". A widely available autodock would rob people of that sense of accomplishment.) We could certainly use a better UI for docking (more or less what Docking Alignment mod does).
  10. I would probably put up BitTorrent links.
  11. Rockets? I got nothing. But KSP is far more than just rockets: Solar panels. The foil on the LEM. The skin of the Command Module, as posted earlier in the thread. Spacesuit helmets. Windows on every module and capsule.
  12. Right now, KSP is still using the older shaders/materials, and probably will for a while. Unity 5 introduces new Physically Based Rendering materials, which have "shininess" builtin - you could literally write a slider to make a part more matte-finished and less shiny, and vice versa. With reflection probes*, these would properly reflect the world around them, at least in terms of planets and the cosmos. (self-reflection is still a pipe dream for realtime graphics) Even better, even matte-finish parts would benefit - they would reflect Jool's green or Duna's red without the need for a PlanetShine-like workaround, and they would even correctly (and subtly) reflect greenish or blueish as you fly over grassland or ocean on Kerbin. And it does all of that pretty darn efficiently - it's definitely slower than the classical shader model, but overall you probably wouldn't be looking at more than 10-30% more work per frame for the GPU. (And GPU's are almost never the bottleneck for KSP performance anyway.) At worst, I'd expect that your 30fps game would drop to 25fps, but if you have a good video card, you probably wouldn't notice any change in framerate. Every part could be a seamless blend or matte and shiny bits and everything in between. Your solar panels could have shiny blueish glass bits, metallic bits, and matte plastic bits, all rendered in a single material. Same for capsules. Also, Unity's material supports masking out a smaller repeating texture/bump map in specific areas, so you could have e.g. a highly detailed wrinkly aluminum foil look (yes, including the gold tint) integrated seamlessly into the broader texture map. And it would look incredible. There's no two ways about this. It's probably one of the few aesthetic choices that universally looks better, with the only possible exceptions being cartoon-like games. (And even then, a lot of modern cartoony games have realistic aesthetics that would look great with PBR, so "but Kerbals are cartoony" does not qualify as a reason not to use PBR - the Kerbals would look better with PBR, too.) * Reflection probes aren't cheap to render, but on this scale reflections don't change very often - Squad could set reflection probe re-renders to happen at any interval they like, and might even be able to spread the work over several frames. "So flip the switch already, Squad!" I can hear you saying. But, there is a catch. PBR materials use none of the same input textures as the classical shader model. The normal maps are almost the same, but even they would undoubtedly require tweaking. In order to take advantage of PBR, Squad would have to redraw every texture in the game. (Technically they could do it piecewise, but that would look pretty darn awkward to combine the two aesthetics.) This would probably occupy one artist for years, so in order to get this done without crippling other visual tasks, my guess is they'd have to hire more artists just for this (I don't think Squad has multiple texture artists on staff, but I could be wrong). Squad have probably considered all of this, and I'm sure they've made their own decision on whether the improved look would be worth the design time. I can only guess - I suspect it'll be something they do as part of a larger graphics pass on the game as a whole... eventually.
  13. #3 and #4: Wheels have been overhauled for the upcoming 1.1 - wait for that, then revisit. That said, jwbrase is correct, and "broken wheel" can cause some serious trouble if it happens while moving. There's a reason that IRL autonomous rovers on other worlds max out at around 0.1 mph. Exploration in KSP is largely about the challenge of getting there and back, and aside from the little ones, every planet is wildly different on that front.
  14. I am assuming most of the people in this thread have never seen the Delta IV Heavy.
  15. I think a visual marker in the main camera view makes a lot more sense than anything you could possibly put on the navball.
  16. I think the thought process was: 1) "Mission control" is a cool word associated with realistic space travel, and we should have a building called that. 2) We need a place so someone can accept contracts 3) Missions and contracts are kind of the same thing
  17. A few features you would do in Mission Control if I were the one designing it: 1) Plan your mission - (whether a new launch or a new mission for an existing craft) Most of this would be setting up a bunch of maneuver nodes; the main difference between this and doing it in the flight is that this would not require the craft to already be built and launched (so you can build one with the right amount of ΔV). This would require some improvements to the maneuver node system, most notably the ability to make a maneuver node from being landed. Using this, you would be able to approximate the amount of ΔV you need to budget for. (Hopefully, this feature would go hand in hand with 2) View your overall timeline. This would be a pretty good place for something like this feature to live. By default, it includes all the maneuver nodes you've placed. After upgrading the building once, it includes things like SOI transfers and impact times with the surface. After another upgrade, it could include transfer windows. 3) Basic information on a large number of ships simultaneously. One display would list all of your active flights; in each flight, you could go into a menu and choose which information you want to appear. The amount of electricity on your probe? The amount of Ore in the tank of your miner? The amount of Science processed by that research lab? The height over terrain of that one ship you have in an unnervingly tight orbit around Minmus? The distance between ship A and ship D? All viewable on one big display, so you can keep watch over all the missions that matter most to you. With an upgrade of the building, any of this information that's represented by a number (including all the examples up there I could think of), can be recorded and graphed over time. With another upgrade to the building, maybe this window can be pulled up during flight. 4) Sending remote commands to probes that support it. No direct control of the vessel - that'd be redundant - but if your probe supports the advanced SAS modes, there's no reason you shouldn't be able to send it the command "aim prograde, burn for 2 minutes".
  18. While this is wise and true - doesn't Besieged do pretty much exactly what KSP does in terms of its heavy processing? Large groups of rigidbodies and colliders (mostly primitives), attached by joints? Pretty much all KSP adds to the formula is patched conics and the rails physics, but that's hardly a performance hog. Personally, I'd been fairly reserved about the performance improvements to be expected until now, for all the reasons you enumerate - but if Besieged can improve by a factor of 10x in optimal situations and 4x in normal ones (based on their 'advertised' performance increase), that bodes extremely well for estimating the performance improvement we might see in KSP. The common wisdom on these forums has been that a doubling of framerate would be foolishly optimistic - but honestly, now, that seems almost conservative.
  19. This just gave me an interesting thought. If the "single-ship = single-thread" principle is true, then I could have a game crawling at 5fps when I have a giant space station... and then jump to 40fps when I smash into that space station and break it into a dozen pieces. Players might start to get concerned if there is a sudden framerate increase.
  20. Reading the dev notes, they have mentioned fixing a LOT of the long-standing bugs that we've just learned to live with. For example, yesterday's devnotes mentioned the one where moving symmetrical objects in the VAB would break their shortcut key configurations, and some bugs with craft that are splashed down - and there have been similar updates in the devnotes for months on end now, indicating that they are putting serious effort into killing these long-standing issues. The update to Unity 5 and 64-bit should singlehandedly resolve memory crashes on modern machines, which are far and away the leading cause of crashes on modded installs. The accompanying update to PhysX 3.3 is likely to fix a couple of physics glitches. The UI has been rebuilt using the new UnityUI system instead of OnGUI, and I can say from my own Unity experience that UnityUI is not only more stable/bug-free than OnGUI, it's also far easier to debug issues when they do appear, so I expect the UI to become a lot more stable. They've also updated the line-rendering package used to display orbits and patched conics, which seems likely to resolve a few issues there. Long story short: Yes, there is good reason to expect 1.1 to be a lot more stable than any version before it.
  21. The old GUI functions had the font sizes all but hard-coded into them. In order to have text at a larger size, every UI element would have to be written with that size in mind. It's virtually impossible to support multiple pixel densities well with that system. (side note: The Unity IDE itself is built on that older GUI system, and the IDE still doesn't have proper retina display support. Unity has copped to that being one of their bigger regrets in designing that system - they're had to spend a LOT of developer time working around it.) The UnityUI system that KSP 1.1 is using has a built-in component called CanvasScaler, which essentially forces a given UI canvas to simulate a predetermined resolution - if you designed your UI at 1920x1080 and you want it to look about the same on all screen sizes, you just add a CanvasScaler, set it to that resolution, and it'll scale up or down with the screen size as if you were just viewing an image fullscreen. And it'd be trivial to customize, too - if your eyes suck and you want large text on your not-that-big display, you could do that. I don't know if Squad has plans to expose that customizability to the end user, but even if they don't, I strongly suspect it would be trivially easy to mod that - like FindObjectOfType<Canvas>().gameObject.AddComponent<CanvasScaler>(), and then you're good to go. So I wouldn't worry about it until after we see how 1.1 behaves.
  22. Start thinking of (and suggesting) the prerequisites that would be needed for such a thing to be viable. Most significantly: IVA Improvements out the wazoo. KSP's IVA is nowhere near ready to be an exclusive gameplay mode. Yes, some Youtubers have done it, and we're so in awe of them precisely because KSP makes it so hard. (and every single one of those videos was done on a tried and true spacecraft and very simple, straightforward flight plan - never one they're trying for the first time in that view, and never anything harder than landing on the Mun) - Most or all of the IVA views simply don't offer enough information in a readable way. A lack of map view is key. No fuel gauge or staging views. No overheating status warnings. The navball doesn't show sufficient information either, if you can't augment it with the external view. In short, we need a lot of different ways to view information in IVA. Basically we need little screens in the IVA that we can change to show whatever we need at any given time. - As a corollary to this, we definitely, absolutely need external mountable cameras that can be viewed in the IVA. - It would be very jarring, I would think, to have the IVA throttle in one position in VR but your actual throttle is in a different place (and having a hardware throttle/joystick is still going to be the best way to control this - those general-purpose 3D controllers aren't going to cut it for precision maneuvers.) So we need the ability to create our own IVA layout to match our cockpit to what's on our desk. - Many components are impossible to control in certain scenarios without right-clicking on them in external view and choosing stuff from the menu. We need to be able to control things like science experiments, air intakes, fuel transfers, docking nodes, and so on from buttons in the cockpit. (and I don't mean control groups, they are woefully inadequate as a standalone control method.) Basically, imagine playing KSP without a mouse, and everything you can't do, needs to be added to IVA Those are off the top of my head, but there's probably more design considerations. If Squad decided to add VR to KSP today, all of these things would have to be added first, and IMHO each one of them is big enough for its own release version. That said, these are all good things to suggest whether we want VR or not, so let's focus on the prerequisites before trying to jump to the end!
  23. The color of a vessel's orbit could be changed in the same menu where its name and icon get changed, and as mentioned, this menu ought to be available from more places.
  24. I've mentioned a concept like this on several other threads - this is a really good concept. As mattinoz said, logarithmic time scale would be better than linear (or both an a toggle switch). It should also show things like predicted time to hit surface, time to enter atmosphere, etc - all important events like that for all vessels (so we don't have a ship that gets pulled from orbit by Tylo while we're paying attention to Duna). I've been curious about getting into KSP mod development, but I'm reluctant to start a solo effort - if anyone's keen on making this a mod and wants some help on coding, get ahold of me!
×
×
  • Create New...