Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Adding relativity to space.

Discussion in 'Suggestions and Feedback' started by Masked Death, Mar 9, 2017.


How do you think relativity should work in Space Engineers?

  1. Relative to a point in the universe (don't change it).

    3 vote(s)
  2. Relative to a selected entity only (my proposed change).

    0 vote(s)
  3. Relative to a selected entity if there's one, otherwise the universe (mixed).

    4 vote(s)
  4. Allow the player to choose this as a world setting.

    1 vote(s)
Thread Status:
This last post in this thread was made more than 31 days old.
  1. Masked Death Apprentice Engineer

    So as the most basic of physics classes teach velocity is relative, so it's meaningless without a point of reference. In space you don't really have a point of reference, you must choose your own (e.g. a star, a planet, a vessel).

    I think it'd be great if velocity was relative in Space Engineers as well. This would allow for working on ships using inertia dampeners in a really easy way. But how would it work to consider the limitations of a game engine?

    In fact quite unchanged. The base code wouldn't change at all and everything would move relatively to the 3D grid. The differences would be only visible for the player. First of all, you'd need to choose a point of reference. Valid points of references would be: all kinds of ships and stations, asteroids and planets, other players, floating objects, GPS coordinates. You'd select one either by aiming at it and pressing a hotkey (not aiming at anything and pressing the hotkey would remove the selection) or selecting it in the GUI (for coordinates, ships, etc.).

    After doing so, your displayed speed would be in relation to the point of reference. This would also affect inertia dampeners, which is pretty much the main point. That way when a ship is drifting in space and you're following it, you're actually able to do so without drifting apart (currently you can disable inertia dampeners, but manual tuning is never perfect and you need to constantly correct your course). You could use that either to work on a moving ship or dock your ship with another ship without having to stop or drift to the side during your attempts.

    If asteroids (and/or planets) are ever changed to not be static anymore, this would also allow you to work on them painlessly.

    In addition it would add realism (which is one of the aims of the game) so that you wouldn't be able to just make everything static and unless you synced using the targeting system and inertia dampeners, everything would be in constant motion relative to other things.
    • Agree Agree x 1
  2. Malware Master Engineer

    The physics engine don't handle high relative speeds very well, and also high speeds on lower end computers have trouble rendering things in time. So, if you move too fast, you risk either clipping through something you're supposed to hit, or hit something you didn't even see.

    I.e. the speed limit is not arbitrary, it's a technical limitation, and making the speeds relative won't help with that problem. Havoc is actually capable of higher precision collisions. The problem is, that requires much more computing power. And it doesn't solve the rendering problem for lower end computers. Given the higher computing requirement, it'd probably just exacerbate the problem...

    Given how long you've been a member, I'm kinda surprised you didn't already know this, given how much discussion there has been on this particular topic. :) Surprised enough to wonder if I have misunderstood something. If I have, I apologize in advance.
  3. Acolyte Apprentice Engineer

    It might be possible to make displayed velocity relative to a selected entity, and even make inertial dampers work relative to that entity. This would give the appearance of relative velocity control which would be quite useful.

    Though not the same as relativity methinks.

    Also a great opportunity to add some sorely needed bugs to the game :p
  4. Bleuhazenfurfle Apprentice Engineer

    I didn't get "wanting higher speeds" from the OP. I got "want inertial dampeners to track moving objects" instead — something like this would make it a heck of a lot easier moving around moving targets, as long as it doesn't change velocity faster than you're able to match.

    As the other two jumped in with, the speed ceiling will come crashing down a heck of a lot quicker if the object you're trying to track is travelling at anything close to max speed already. However, having the ability to synchronise with a secondary reference frame, is an excellent idea in itself, and I've raised a very similar discussion to this several times in the context of Waypoints for the Remote Control block, always being relative to something else — the standard reference point being the fixed point from which GPS locations are derived.

    The same issue exists there, too, although a ship autonomously chasing a moving waypoint doesn't care if it's travelling at close to the speed ceiling, it'll just keep cruising along at it's best effort till it catches up. In this context, you'd want to keep your physical speed front and centre just as it is now, and have this is as a secondary information point — players might be a little confused if their maximum speed in one direction is 10m/s, and approaching double K (the speed of Keen) in the other. (Some kind of directional display might be rather handy?) But having your inertial dampeners automatically track another object would be fantastic.

    The only wrinkle I come across, is what should it be allowed to track? Do we assume the suit and general ships control systems carry the hardware necessary to follow random world objects (after all, they do have the ability to track GPS), or do we make it so you can only reference GPS and friendly antenna's? If we're going for the antenna option, I'd include anything you have any kind of sensor data for, including your ships weapons systems, and the Sensor — or that pesky Radar block — as well. This would mean missiles could be set to travel to a point <0,0,0> relative to the target vessel,
  5. sioxernic Senior Engineer

    Deleted my post, I was drunk last night -.-'
    • Funny Funny x 1
  6. Masked Death Apprentice Engineer

    Sorry for abandoning the thread, didn't see notifications cause I didn't notice I got auto logged out.

    Yeah, I didn't mean for the speed limit to change. As I said,
    So if you were following an object moving at 0,75keen, you could only speed up to 0,25keen.

    So first of all since GPS in this game is relative to the grid, adding realistic relativity might make it even less fitting (since GPS needs a reference point like antennas or such).
    I thought that targeting should require an antenna or perhaps an added new radar block or such. Then you could target any object in the block's range. And yeah, then allow anything to be tracked on a ship. Maybe to avoid clutter one drop-down with the general target (planet, ship), and one drop-down that is empty but fills up with blocks when you select a ship or station. You could use it to target custom-built weapons, too. That'd make taking out ships' antennas more strategic since small ship type missiles only have a limited antenna range.
    Perhaps only allow ships without the antenna/radar to target beacons.
  7. [flux] Trainee Engineer

    I like the idea.
    Seems like you want to designate an entity as a fluid zero point. Allowing your inertial dampeners to match that zero. I see how that would be helpful. But if that ship is in a rolling spiral that would make an awfull lot of auto maneuvering.

    I understand its usefullness and where your coming from but in practicality allowing this bandaids stressed and chaiotic tasks and undermines propper planning. Or rather handing you a paper towel with your poo sandwitch. Just dont order the sandwich in the first place.
  8. Bleuhazenfurfle Apprentice Engineer

    If you're trying to path-plan to the relevant point, sure, that would be insane, and not viable without a significantly smarter planner (I have written one, a long long time ago when I actually knew this stuff). But without path planning, it shouldn't make any appreciable difference at all — except to your fuel supply.

    What will happen, is that if you're following another grid that's doing some weird roll, your ship will waste velocity (and that fuel) following a vaguely spiral (depending on how frequently the game engine recalculates the path) course unnecessarily. And worse, if that path happens to pass through the grid you're tracking, then bad things will happen. Boo hoo. That's called Darwinism, SE style.

    It might be interesting, though, to have the option to select your angular reference frame independent of the position one. Giving the same object as both reference frames, would give the normal result you expect. However, substituting a either yourself or GPS as one of the reference frames would allow some useful options.

    No. And in fact that last sentence, I find rather offensive and unnecessary.

    The reason this is needed, is that the game core can do these calculations with massively less overhead than a script ever could. First, you need to run the script, which involves interraction between two distinct blocks. Then, the API's through which you retrieve the necessary information, and the ones through which you issue the commands to perform your movement actions, aren't exactly built for efficiency, and will involve a bunch of validation checks. Next, most — if not all — of the information you'll need during the calculations required for the task, the game engine already has for it's own internal use, and will require more of those API calls to figure out (some of which may well have to be figured out and provided by the grid you're trying to pursue under the current API, using the antenna messaging API, which is itself a whole new set of blocks getting involved on both grids).

    Compared to the game engine doing a few checks at the start, perhaps rechecking at certain times when tracking data availability might have changed, and otherwise just tossing a few extra terms into the calculations it's already doing.
    • Disagree Disagree x 1
  9. [flux] Trainee Engineer


    S sandwich is the situation trying to be resolved: automatically moving synchronously to a moving object. In scenarios where the referenced object is spiralling, the radius of yourself to the object would influence your speed. And its unlikely that this would be effective with the current speed threshold.

    And i was emphasizing that the situation should be under controll before attempting to do your tasks.

    I do see how this is helpful. For example having a mothership moving about and trying to attack or execute repairs.

    Having this would be a nice and clean (paper towel) way to do this.

    But its not necessary to order up these scenarios.

    Its a good metaphor. Every mechanic has eaten an engineer's s sandwich before. And smiled afterwards. Its part of the gig and part of life.

    But the more i think about it the more i like it. Perhaps have an auto alignment velocity max at 25 or 50. That would leave room to maneuver, set a cap to unwarrented chasing, and make it so this function would automatically break off.
    Last edited: Mar 17, 2017
    • Disagree Disagree x 1
  10. Bleuhazenfurfle Apprentice Engineer

    It goes without saying, that this system won't — and should not — stop you from doing stupid things. But it should make it easier to do useful things, without dragging the entire game to a grinding halt. (Trying to use scripting exclusively for stuff like this, is like trying to type on your smartphone while wearing boxing gloves. It's possible, but the world has to slow down to a crawl in the process.)

    Yes, I said that already. Changes nothing, though. In fact, it doesn't even mean there isn't a plausible reason for wanting to tell your ship to do so — just because you don't know what it is. And irrespective of that, being able to do so at slower speeds and close distances, is very much what this is about.

    There's also a few other points I addressed to some degree.

    This has mostly been about the grid-to-grid case, because it's the more general. There's also the player-to-grid case, which while being simpler in some ways, has some other interesting complexities — notably mixing player controls into the grid following behaviour. But I don't see why that can't be solved for both cases within the same system, and doing so could provide an efficient solution to some annoying (and arguably unrealistic) problems people keep having to fudge their way through with flying on planets.

    Then, within the grid-to-grid case specifically, there's two distinct situations here: one, is docking with a spinning object, the other, is moving to a stationary point relative to a moving object (imagine a shell of satellites — they don't need to rotate with the grid, they just need to hold their relative positions). A combination of the two can be used to efficiently approach (by making a straight-line approach to approximately where the docking port will be when you get there), and then docking with the spinning grid. My response also addressed that distinction, by allowing the offset to be a vector rotated by an independent frame of reference. But mostly, it's a lot of bang for relatively few bucks.

    … and should be handled by scripts. Assuming the information and necessary control is available, a script shouldn't have too much trouble determining if the target grid can be reached, and then setting the appropriate approach. Where this can't presently be done by scripts, is where we need new discussion threads.

    Further, there's too many options on how to handle an out-of-bounds situation, to expect the game engine to just magically take care of it. This discussion is about a tool to enable functionality, not an entire game solver.

    Having said that, some time ago I talked about the ability to "script" by attaching conditionals directly between block parameters and settings. (Something not entirely unlike a player-oriented version of the graphical scripting system, though I preferred a more familiar inventory-like interface.) That feature could help in this situation also, by setting a trigger on the target grids observed velocity exceeding some threshold, or the distance to the target dropping below some threshold, and performing appropriate actions in response (switching to another relative waypoint). That, too, is a different discussion, however.

    Oh, and by the way, not sure what you're eating, but my sandwiches are most definitely baloney and cheese. You can keep the poo ones to yourself. Thanks.
Thread Status:
This last post in this thread was made more than 31 days old.