Autopilot disabled after every jump

[OperationDx]

Describe the bug Bug - Autopilot disabled after every jump even when set to continue in the map settings.

To Reproduce Steps to reproduce the behavior: Set a destination in the map or in the search window that is at least two jumps away. In map settings set auto pilot to continue and not disable after each jump. Activate auto pilot. This will warp you to the first gate but will not auto jump the player. If you manually jump through the gate the auto pilot will disable.

Expected behavior When you set a destination a few jumps away auto pilot should take you all the way to your set destination auto warping to the next gate and auto jumping to the next gate.

Screenshots Only a video would be helpful here.

System Details (please complete the following information):

• Server OS: [Ubuntu]
• Docker - Latest Staging build 0.8.5 as of 7/31/23

Additional context Nothing extra to report.

[fishscene]

What is needed to triage this?

I'll note I have a slightly different experience in that I autopilot will activate the gate, but upon loading the destination system, autopilot disables.

This is what the server outputs to console after autopiloting through the gate:

20:50:27 [Service] invbroker::MachoResolveObject()
20:50:27 [Service] invbroker::MachoBindObject()
20:50:27 [Service] dogmaIM::MachoResolveObject()
20:50:27 [Service] dogmaIM::MachoBindObject()
20:50:27 [Service] LSC::JoinChannels()
20:50:27 [Service] beyonce::MachoResolveObject()
20:50:27 [Service] LSC::LeaveChannels()
20:50:27 [Service] config::GetDynamicCelestials()
20:50:27 [Service] beyonce::MachoBindObject()
20:50:27 [Service] stationSvc::GetSolarSystem()
20:50:27 [Service] beyonce::GetFormations()
20:50:27 W CheckBallparkTimer(): BallPark Time remaining 1478ms
20:50:27 [Service] sovMgr::GetSystemSovereigntyInfo()
20:50:27 [SovInfo] SovereigntyDataMgr::GetSystemSovereignty(): Faction system 30004285 found, Sending no SovData.

[OperationDx]

The client has an option to continue to destination. Maybe this is not connected in the server? I can provide a screenshot if necessary.

[ZyenDomani]

from my testing, the entire system boot sequence and client data packets would have to be rewritten to enable ap system. the client uses system data to determine location and destination, but so does evemu. however, they use the same data in different ways, and i have not found a compatible workaround to keep things working properly and in harmony. i have been able to get ap to work from 3-15 jumps, but does weird things with solSystem and other workings.
and that is for a single player in the server. once you add clients, shit gets even more weird. so, this has been triaged. i've been working on it for >13y.
there is no quick or easy fix.

also, even watching packet caps while running ap doesnt show anything different than what we're already doing. the whole problem is evemu.

@fishscene at that point in your log, the client isnt in a system. its the limbo between systems when jumping. beyonce::GetFormations() verifies the ballpark timer is set (which should be done by another call earlier in the trace), then 'CheckBallparkTimer(): BallPark Time remaining 1478ms' shows you have ~1.5s left before the ballpark is sent. this will be when the system data is sent to the client, and the client will use this data to determine if ap is being used and update it's status. if you watch client logs, you'll notice the ap is shut off immediately after bp data is sent.

@OperationDx that option is client-side only and determines how the client processes the data used by ap system. has nothing to do with server, and is not sent nor requested by the server.

those that play on my server will see ap works on occasion, but not consistently or reliably.

Allan

[jdhirst]

Same issue as #263. Closing this as duplicate as the same fix to destiny would resolve both.