Jump to content

Draco T stand-up guy

Members
  • Posts

    199
  • Joined

  • Last visited

Posts posted by Draco T stand-up guy

  1. On 6/5/2021 at 7:34 AM, Lisias said:

    This is not going to happen.

    The only mod I use ATM is MechJeb and I don't use all of it but the Maneuver Planner is pretty much essential and is one of the tools that should have been in game as standard from the word go. I note that 1.12 has just introduced a limited version of it (I was over-joyed at it finally being done only to find that its so limited that it's almost useless).

    On 6/5/2021 at 7:34 AM, Lisias said:

    One size does not fits all

    As far as necessary tools go it pretty much does. A spade is a spade, after all, because it simply cannot be anything else.

  2. 13 hours ago, K^2 said:

    They do. Net mass of the ship under warp has to be zero. I know a lot of theoretical work is missing out on that requirement, but they're also working with bare bubbles with no source of curvature within it. At a minimum, you need amount of negative energy to cancel the ship's mass.

    Maybe not:
     

    Quote

     

    Abstract:

    The Alcubierre warp drive is an exotic solution in general relativity. It allows for superluminal travel at the cost of enormous amounts of matter with negative mass density. For this reason, the Alcubierre warp drive has been widely considered unphysical. In this study, we develop a model of a general warp drive spacetime in classical relativity that encloses all existing warp drive definitions and allows for new metrics without the most serious issues present in the Alcubierre solution. We present the first general model for subluminal positive-energy, spherically symmetric warp drives; construct superluminal warp-drive solutions which satisfy quantum inequalities; provide optimizations for the Alcubierre metric that decrease the negative energy requirements by two orders of magnitude; and introduce a warp drive spacetime in which space capacity and the rate of time can be chosen in a controlled manner. Conceptually, we demonstrate that any warp drive, including the Alcubierre drive, is a shell of regular or exotic material moving inertially with a certain velocity. Therefore, any warp drive requires propulsion. We show that a class of subluminal, spherically symmetric warp drive spacetimes, at least in principle, can be constructed based on the physical principles known to humanity today.

     

    GR isn't the end of knowledge. Like Newtonian physics its just a step and is likely incomplete.

  3. On 5/15/2021 at 10:20 AM, The Aziz said:

    One of the reasons many people never go further than the Mun. Because interplanetary journeys are a mysterious concept the game fails to explain.

    I think that it's probably more the lack of tools to do it, specifically, the lack of MechJeb, launch windows, needed dV and an alarm clock (otherwise collectively known as Mission Control).

    Yes, you can manually play with the maneuver node until your projected path intercepts the target planet but that can have you finding out that you don't have enough dV because you launched at the wrong time and only doing one mission at a time as doing more only results in failed missions due to excessive use of time lapse.

  4. On 8/11/2020 at 12:17 PM, catloaf said:

    Because if your going to buy a PC you want to spend at least 200 dollars so it turns on, and most people can't justify spending that much on a single game.

    Why would anybody be using a single game to justify buying a PC?

    The PC does so much more than a console that I've never been able to understand why anyone would buy one as its simply a waste of money. Better off spending the same amount on a PC and be able to do more.

  5. 4 hours ago, Incarnation of Chaos said:

    Also you don't want to run a full server client just for a display utility, so you'd have to at least remove it's network functionality and the like.

    But you do need to for multi-player and, as I said, it looks to me like they're doing it that way to get the better performance on the physics. If they are running a server model then it doesn't matter how many windows are open - the performance will only be affected minimally.

     

    4 hours ago, Incarnation of Chaos said:

    Which is why this is the most useless statement in tech support

    It wasn't tech support - just showing that your issues are, pretty much, unique to you.

    Really, if things were as bad as you say no one would be using multiple monitors.

     

    15 hours ago, linuxgurugamer said:

    If a game or program has multiple windows, then it automatically has multi-monitor support.

    Actually, it isn't. If an app creates a window then creates windows that are children of that first window they, usually, can't leave it. That is often a consequence of the development environment.

  6. 19 hours ago, Incarnation of Chaos said:

    But in practice; unless it's basically free to implement and doesn't suck up too much developer time and resources i wouldn't want it.

    As I implied elsewhere - multi-monitor support is pretty much endemic to multi-player and, if I'm reading what the developers said in an article accurately, how they're getting better performance on physics calculations.

    19 hours ago, Incarnation of Chaos said:

    But Windows couldn't clean up the virtual displays afterwards, both AMD and Nividia's drivers are absolute trash at handling multiple displays.

    And yet, in nearly two decades of using multiple monitors I've never had a problem. I presently have a 24", 16:10, 1920x1200 main display and a 22", 16:9, 1920x1080 running perfectly on an AMD Radeon RX550.

     

     

  7. Well, I see it as having two options:

    1. Time skip as we have now or
    2. Wormholes.

    Which would be better for game play?

    If time skip is used and we have a decent Mission Control that makes progressing multiple missions possible then we could have Kerbin progress while the ship on its interstellar flight doesn't. Even if ships are sent after the first its still going to be lagging thus producing a dynamic between the two.

    Wormholes would skip that aspect and I can't actually see any benefit except that the irritating time skip would be missed.

  8. 6 hours ago, DStaal said:

    Overall, I could see some very good uses for it in KSP (being able to see both the ship and the map view, for instance)

    It does depend a lot on what the second screen is used for.

    I'd like to see Mission Control on it (Replacing MechJeb), my orbital information, the orbital information of anything targeted, as well as a real-time representation of the Kerbol System. That's while in flight.

    In the VAB to be able to see the mission plan (from Mission Control), the specs of each stage and its dV so that I can compare the capabilities of my design in relation to the mission parameters.

    In Mission Control I'd like to be able to see Tracking. In fact, I think a full function Mission Control would be where having two screens would really shine. Especially in designing missions.

  9. 8 hours ago, swjr-swis said:

    It doesn't, actually. The way to answer those potentially-overlooked 'combinations' is not by gathering WHO is giving the answers... it's done by asking MULTIPLE questions and then counting if and how many times each specific combination of answers is chosen. Which you already did. The names of those answering being PUBLIC or not makes exactly ZERO difference and adds nothing to that particular differentiation.

    Now if 44 out of 100 total answers picked answer combinations C and D, we would have a reasonably objective confirmation of an oft-quoted notion that 'less than 45% of people would  be interested actually using more than one monitor'. That particular statistic would still be true, for this set of data, whether you know WHO each of those 45 voters are or not.

    1. Not seeing any names in the poll. Of course, the people who have access to the back-end of the site probably can if they're so inclined.
    2. I am seeing, at this time, 5 people saying that they would use this feature even though they presently have only one monitor.

    Screenshot for clarity:

    OLHypOb.png

    So far, 53% of respondents would use this feature.

    Of course, that can't be assumed to apply to all who play KSP or even all who would buy KSP2 as not everyone is here commenting on the forum. The majority of players probably don't even come to the forum.

  10. On 7/19/2020 at 3:13 AM, king of nowhere said:

    but there is one thing they all have in common. they will capsize. in low gravity, they will capsize. a good rover must be able to deal with it.

    I've been learning to do barrel rolls in mine &)

    Doesn't always work :(

  11. 7 hours ago, Incarnation of Chaos said:

    The issue is that wouldn't be the case for a "Map view" people keep asking for; you would need to build the functions to call KSP and fetch the required information, and some of that may incur additional overhead. And you'd need to synchronize some things between the main session and the view, which is more overhead.

    Depends upon how they're doing whole thing. It may even depend upon how they're implementing multi-player.

    They could run a physics engine in its own thread chewing CPU cycles, effectively a server. Next to that in another thread would be the graphics which takes data from the physics and displays it on screen and gets input from keyboard/mouse/controller and sends that data to the server thread. Doing so should give more consistent, and possibly higher, frame rates.

    And this is why I say it may depend upon how they implement multi-player because multi-player is going to need a server. World of Warships runs like this as the game is actually played on the companies servers and only the graphics are displayed on the local machine.

    A server model, which already has built in messaging as you describe, is hypothetically easy to give multiple windows that can be spread across multiple monitors.

    Now, the reason why I bring this up like this is because over here the lead developer says:

    Quote

    For the original Kerbal Space Program and this game, rigid body physics calculation is a CPU intensive process and traditionally the higher your part count, the worse your frame rate. So we put a lot of thought in to optimising the way that we’re calculating rigid body physics, working with ideas like basically a LOD system for those physics calculations.

    Obviously there will also be some part count threshold beyond which you will start to see impacts to the frame rate, because we’re not going to give you a hard limit. It ultimately comes down to how fast your computer is and how far you’re willing to push it. But we want you to be able to build the things that you’ve seen in the trailer for example, without a noticeable frame rate hit.

    Which, to me, implies that they've split the two. Especially when I consider that in KSP1 my GPU, when in close, is running full out while my CPU is barely ticking over. Seems to me that there's a lot of space on the CPU for running the physics simulation and having it much better without having it limited to how often the frames are updated on the monitor.

  12. 9 hours ago, linuxgurugamer said:

    Actually, there is a lot more work involved than you might imagine.  Besides the coding work, there is UI development, QA of the UI, QA of the window, QA of the data being displayed in the window, etc.

    I do have some idea - its similar to the work I did for my degree in CompSci.

    The UI that you're talking about is the same UI that will be in game for whatever windows (Map, orbit info, tracking data, CommNet, etcetera) are used. I'm not talking about anything more than what's going to be in the game. Just want those windows to be able to un-dock from the main game screen and shifted over to my other monitor.

     

×
×
  • Create New...