Speed and vector matching between ships

Wilhelm shared this feedback 20 days ago
Not Enough Votes

Old topic I'd like to revisit

https://support.keenswh.com/spaceengineers2/pc/topic/46243-speed-and-vector-matching-between-ships

Basically this is the ability to set relative dampeners (outside the ship or from the flight seat) to your locked target. Target a ship, set relative dampeners active and now the ship's dampeners (or your space buddy's) have zero set to match the target's motion. If they speed up or slow down or turn, the ship's motion adjusts automatically like the relative dampeners do when you exit your own ship.

Once set, closing distance and docking with the target should be a simple matter.

Replies (4)

photo
1

Try disabling a moving ship and then 'trying' to maintain any sort of eyeballed vector and speed matching. It can be done, but last time I checked the technology level of the game included computers, which could do this automatically for you. It would be a massive improvement compared to 'shoot at enemy ship, it spins out of control away from you at 256m/s and you have the choice of 'should I take a half hour and try to catch up with that before it despawns, match everything perfectly, board and loot some stuff only to come out and find your own ship has drifted away since you had to leave your dampeners off to have it even stay close.

Or...accelerate, push a hotkey and the ship will dampener itself to maintain its exact distance from the ship at the point you hit the button, and you can accelerate manually to close the gap while the ship maintains a relative speed otherwise. Boy the second one sounds preferable having had to do the first one hundred of times on SE1.

photo
1

KSP used a navball. You had your orientation on the navball, prograde, and retrograde markers. Then, when you got a target, you got the targets orientation, prograde, and retrograde marker put on it, as well. Helps out with that stuff. Also allows a 'baseline intercept' plot for combat. Like a pure, lead, or lag pursuit, based on ATA angles.

photo
1

And also, how is this useful? Two concepts are in there, maybe I can illustrate why it is important, from my admitted lay-persons understanding: This Navball is used for Orbital Rendezvous mechanics in space, and the other Intercept one is for starting on Basic Fighter Maneuvers.


1. Navball - The prograde/retrograde are self explanatory, but usually the orientation marker for your target is also key. This allows you to dock with a moving ship, connector to connector, Everytime. In pitch darkness. And lights out. Pretty handy for that, I think.


2. Intercept - The geometry solutions to gaining a stable position behind your moving target, with different speeds, closure rates, and aspects. Useful, but you need more information from the target to plan those solutions with any precision. The WW2 eyeball method can be used, to.


3. Rotating target - You need to cancel that out, though, as Wilhelm pointed out. How? AI does the math lol. Human directed? Two ways I can think of, mechanically or electric energy manipulation. Mechanically would be cables (post just came by Deon B for grappling lines, neat idea), landing gear, etc. Energy manipulation...tractor beam? Too 'woo-woo', how about using gravity generators to project an inertia dampening field? Drains rotational energy from the target, same idea on using them for setting up anti ballistic shields, via inertia dampener 'planes' as arranged by you.

photo
1

I get the 'better way to represent the relative motions of the two grids', i.e. navball. There is a fine balance in video games between 'creating manual interfaces to do things in order to gamify actions' and 'this is something that even with our current level of technology could easily be accomplished by computers with a push of a button'.

Having done this extensively on SE1, a 'better representation via UI' wouldn't really improve this, matching speed and vector between two grids is just (frequently) not worth the time and effort. Well over 90% of the time after I destroy enemies I watch their hulks fly off in random directions and just 'meh, not worth it'

We have relative dampeners in the game because people decided it was a PITA to match your own motion with the ship you've just exited. This would simply allow you to expand that to a targeted grid 'shift my relative motion to that thing over there', and add the same to a ship.

I've lost count of the number of times I've gone through the 'sometimes' twenty to thirty minutes of riveting gameplay where I catch up to and close with a drifting ship to try and touch my landing gear to it to 'stop it', only to have the gear auto-lock not lock and instead push the ship off in another random direction to force another ten minutes of 'exciting' non-action trying to get lined up with it again. While that's going on all the other drifting grids are so far away that none of them will ever be found.

There is another thread that is asking for expanded dampener logic to account for gravity wells and the like. I'm on board with that too, more dampener logic please.

photo
1

and to be clear, if the intent from the devs is to 'gamify' this sort of function and keep it a manual PITA process, you're absolutely right that a better UI representation (navball?) is essential. My point is more that this is the wrong sort of thing to force as a manual process.

photo
1

isn't this something that should be done with scripts or programmable blocks?

photo
1

I'm not aware of anything remotely like this in prior releases(i.e. SE1 feature-wise), so they'd have to plan to allow this sort of support either way, but this would also be a feature for a space buddy outside the ship so it would need to be done without a block.

No issues if they want to make that capability into an AI module feature.

photo
1

Not sure about the scripting/mod question, but this feels like something that should be in the base feature set, given the absolute end to every ship to ship encounter (that doesn't involve retreat) involves one of those ships drifting uncontrollably and the other trying to catch the other. Literally the lack of this feature largely has driven me to just not bother with ship to ship encounters as it's generally only a negative result (I have to fix my stuff and have to spend upwards of an hour trying to catch/stop the other ship to even replace the damage with salvage from the other ship) The rewards are usually not nearly worth the time/effort. So either increase the rewards from such encounters, or reduce the time/effort. The latter is probably a better choice, since too many rewards has its own dilution of gameplay.

photo
photo
1

I think this should be implemented as a more advanced autopilot feature rather than a simple "Match Velocity" command.

At the moment NPC ships mostly travel in straight lines, so matching velocity is often enough. However, I expect NPCs in the full release to have proper maneuvering capabilities and actively attempt to evade players. In that scenario, matching velocity once would no longer be sufficient, because the target could immediately change its course, acceleration, or orientation.

Instead, I would like to see a "Follow Target" or "Pursuit Autopilot" mode. The autopilot would continuously calculate the target's relative position, velocity, and acceleration vectors and adjust the player's ship accordingly to maintain pursuit or a desired standoff distance.

Of course, such a system should not guarantee a successful chase. The pursuing ship should still be limited by its own thrust, acceleration, and maneuverability. A target with superior acceleration or turning performance should be able to escape, while a ship with equal or better flight characteristics could successfully intercept and follow it.

In my opinion, this would be more future-proof than a simple velocity-matching feature and would remain useful as NPC behavior becomes more advanced.

photo
1

Oh yeah, I wouldn't mind better AI block logic (using SE1 blocks) though I've had a few cases with the AI block where I put it into pursuit-ish mode and it decides to crash into the ship when it tries to compensate for a maneuvering enemy.

Being able to set the relative dampeners though to a target also avoids the AI overthrust issue (the SE1 Ai block issue where the ship is constantly fine tuning by thrusting in every direction to maintain course (burning fuel). If the relative dampener 'zero' is set to match the drifting ship then the AI or pilot only has to use thrust to close the distance, otherwise it would maintain distance. It just allows a much finer closing control than the AI block logic.

photo
1

I think part of the issue was that many mechanics in SE1 were affected by the technical limitations of the game engine. Looking at SE2 so far, even though it is still in Early Access, we can already see that some of the blocks and systems are starting to improve and address problems that existed in SE1.

Because of this, I am cautiously optimistic that a more advanced autopilot and navigation system could achieve much better results than what we are used to from SE1. At the same time, I don't think we can fairly evaluate this potential yet, since many of the systems that would support it are still under development.

For now, the only way to truly see how well this will work is to wait and see how the systems are completed and how the game continues to develop over time.

photo
1

Agree completely, however in a beta testing 'early access', it is far better to provide use cases for 'how you think it should work' wherever you can to help influence their decisions as they implement features so that they can include that in their underlying design. Wait and see runs the risk of them locking in underpinnings that make it 'more work' to do later, reducing the likelihood that your later feedback can be done.

photo
Leave a Comment
 
Attach a file
Access denied