1. The forum will be closing soon permanently. Please read the announcement here

    Note: User registration has been closed. We do not accept any new accounts.

Jump Drive Problems

Discussion in 'Suggestions and Feedback' started by elkdragon23 2, Jan 8, 2016.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. elkdragon23 2

    elkdragon23 2 Trainee Engineer

    Messages:
    96
    Hey as a suggestion is it possible you can have the astronaut travel with the ship even if he isn't sitting down in his seat? I've lost a ship because I wanted to look out the view port while the ship was jumping.
     
  2. Grit Breather

    Grit Breather Junior Engineer

    Messages:
    874
    AFAIK this is not currently possible in SE due to how the game engine is written.
    I'm also not entirely sure it's a change I'd like. Using a jump drive should be exciting and dangerous, not safe and mundane.
     
    • Disagree Disagree x 1
  3. Maegil

    Maegil Senior Engineer

    Messages:
    1,633
    Erm... Look at my link in my sig.
     
  4. CheeseJedi

    CheeseJedi Apprentice Engineer

    Messages:
    382
    The FTL mod, that must surely have influenced Keen's implemetation of the Jump Drive, did exactly this. A bounding box around the jumping ship moved everything within it including other ships/grids, floating objects and players. To me this seems like the better way of handling it.

    Edit: Punctuation.
     
    Last edited: Jan 8, 2016
    • Agree Agree x 1
  5. Grit Breather

    Grit Breather Junior Engineer

    Messages:
    874
    Well, if we combine this suggestion with the Relative Reference Frames one that @Maegil likes so much, I suppose the game could take the entire RRF with it for an FTL jump.

    More Battlestar Galactica and less... I don't have a scifi example for needing to strap in to jump. So just more Battlestar Galactica!
     
  6. CheeseJedi

    CheeseJedi Apprentice Engineer

    Messages:
    382
    You don't need RRF to move items within a bounding box - the FTL mod proves that. You just move all items within a bounding box by applying the same transformation matrix to each item's world position. Unlike linear or rotational motion (i.e. flying somewhere, where RRFs would be very useful), a jump like this would move all items together, relative to each other, not some external frame of reference.

    Besides the whole RRF concept has sorta kinda been started to be implemented with world chunking, which (hopefully) will eventually allow separate Havok threads handling different chunks and massively improve preformance. One day. Ok, it's not quite the same thing, but it's certainly a big step in the right direction.

    Edit: Another issue with Keen's current approach is that it needed specific code adding to allow for rotor/piston/landing gear attached grids to be jumped with the main grid, which was originally a problem when the jump drive was released. The bounding box approach would have eliminated this from the outset. It seems strange that it wasn't implemented this way.
     
    Last edited: Jan 8, 2016
  7. Maegil

    Maegil Senior Engineer

    Messages:
    1,633
    It's different in that the chunking reduces the size of the local world but every grid and player is still individually tracked (and must be kept synchronized, spazzing out at high speeds due to Havock's limits) while RRFs make each ship into a reference grid that travels within the world carrying its contents with it (any motion inside is measured from the RRF's center, making synchronization much easier).
     
  8. CheeseJedi

    CheeseJedi Apprentice Engineer

    Messages:
    382
    The chunking system, AFAIK, has processes for splitting a large chunk in to smaller chunks, and recombining them, and transitioning objects between chunks, one of the (many) requirements of an RRF system. The chunks are calculated dynamically, and as needed.

    This was done primarily for reducing the 'numbers' size for world positions, as they tended towards the large end the floating point precision was lost, causing the bouncing around relative to multiple objects in close proximity. The calculations were producing different results on each calculation run, for the same object, let alone other objects. End result - objects bouncing back and forth relative to each other. Not fun.

    Interesting point: the Jump Drive (and the FTL mod) would occasionally jump your ship in to 'oblivion' where the ship was lost - I believe this was caused by a bug that prevented the jumping object from being placed in a new chunk at the destination, but the ship was still removed from the starting chunk. I'm pretty sure this has been resolved now.

    Essentially the chunking system was implemented to attempt to tackle similar issues to the proposed RRF system, and there's a fair bit of overlap. What is missing however is the chunking system is still 'anchored' to world coordinates, rather than some arbitrarily chosen movable object (like the largest grid in a certain area etc.). This to me seems to be the missing link.

    Players who've been with SE for some time now may remember that Gravity Generators originally behaved differently to how they currently do - you could walk around the ship because your frame of reference was the ship. This got changed (maybe to do with problems with ladders) and now the game calculates walking players and ships independently, relying on (sometimes rather dodgy) Havok friction to keep you in the right place. Floating point errors here will amplify the problem at high speeds and/or distances from the chunk centre.

    I think extending the current chunking system to be able to cope with dynamic/moving 'centres' would go a long way to resolving bounciness/jitteryness on moving objects, however there has to be willingness and an understanding with both the programmers and game designers at KSH without which no amount of drum banging will ever make this happen. I'm hopeful, but realistic: it's possible that this will never be implemented in the way it really ought to be. And that's a real shame.

    Long live RRFs.
     
    • Informative Informative x 3
    • Agree Agree x 1
  9. YtramX

    YtramX Apprentice Engineer

    Messages:
    238
    I really wish they hadn't implemented the jump drive as the teleportation it currently is. I'm okay with the fast travel, but they could have represented it as a high g-burn way above the speed limit, which would allow for significant travel distance and also explain why everyone needs to be in a seat(crash couch). Then they just do a direct line of sight determination for static grids and voxels to make sure no collision occurs, and zoom off.
     
  10. CheeseJedi

    CheeseJedi Apprentice Engineer

    Messages:
    382
    Jumping is considerably 'cheaper' in terms of calculations - is the destination area free vs is every point in a straight line between start and destination free? Then there's the not actually having to 'move' the ship in each update frame, just a single move.

    It's a little bit cheaty (from the game lore, and the 'realism' claims), but it was brought in to get around the issues with massive distances and a max speed that WWII aircraft can exceed (104.4 m/s is approximately 233.5 mph).

    Regarding the speed limit: I gave up on the stock speed limit a long time ago. On my DS we've used Midspace's (script based) Unlimited speed mod and never had any issues with it. It helps that it was a white-listed server with fairly sensible players on it - we all knew that a high speed crash would result in loss of the grid(s) involved.

    It also makes planetary landings much more interesting and real orbiting possible (with a modified Gravity Falloff constant in the planet's setting) :woot:.
     
  11. extraammo

    extraammo Senior Engineer

    Messages:
    1,015
    How does a ^2 dropoff work out for you guys?
     
  12. Malware

    Malware Master Engineer

    Messages:
    9,867
    There is already a GitHub pull request which allows this I think. So no, it isn't impossible :)
     
    • Like Like x 1
  13. Maegil

    Maegil Senior Engineer

    Messages:
    1,633
    Sorry, are you talking about gravity falloff or RRFs?
     
  14. Malware

    Malware Master Engineer

    Messages:
    9,867
    Pulling people along like OP asked :)

    I severely doubt Keen would ever pull something as complicated as an RRF pull request... :p
     
  15. Maegil

    Maegil Senior Engineer

    Messages:
    1,633
    That's nice to hear!

    As for RRFs... Planets were much more difficult, and they pulled it off with flying colours,; besides RRFs could solve a slew of problems at one stroke... Sorry, back on topic!
     
  16. Malware

    Malware Master Engineer

    Messages:
    9,867
    I haven't made any other claim. All I'm saying is, they wouldn't accept any 3rd party doing such a complicated job.
     
  17. CheeseJedi

    CheeseJedi Apprentice Engineer

    Messages:
    382
    I understand the falloff constant needs to be set at 2, rather than the stock 7 - this was from some posts that may have originated pre-planets release based upon investigations of the Github source, but the conversation had continued post planets release. Apparently values more or less than 2 will result in unstable orbiting with either a tendency to decay or a tendency to escape, but I don't remember which gives which. A value of 2 gives Newtonian falloff (follows inverse square law) and is what's required for stable orbiting. Plus a speed mod, in most cases.

    With that being said, I've not spent enough time personally to exhaustively test this due to personal situation recently and offer this more out of morbid curiosity. The ability to 'properly' orbit, rather than having lots of GPS points for autopilot to follow is certainly an exciting prospect.

    I have tested a lot of orbiting pre-planets using Digi's Natural Gravity mod and a fairly large asteroid and achieved some reasonable results with not too much difference between periapsis and apoapsis over the space of several hours with only minimal corrective burns. Certainly interesting attempting an orbital rendezvous for docking...:stare:
     
Thread Status:
This last post in this thread was made more than 31 days old.