@Milo
Flight to sun from main planet requires more time compared with flight same distance from main planet in opposite direction. It is hardcoded effect of game engine per se - Torus flight velocity actually is not fixed 32 * maxSpeed ratio. Torus flight velocity increases with distance from nearest celestial bodies.
If you have Navigation MFD you can see acceleration/deceleration affecting ETE (Estimated Time En-Route) value.
NPC ships never uses Torus drive so you'll always taking mass-locks from forward direction. In any case Torus will engage after contact leaving scan radius and it is a matter of few seconds to build enough distance for "clear" Warp velocity. So I think it is no reason for additional direction check.
I also observe a strange phenomenon during torus mode where sometimes ships behind me will appear to fly rapidly forward in the direction I am traveling, and disappear into the far distance ahead.
Never observe this phenomenon. Hope you'll investigate reason of this problem.
Thank you for feedback!
I noticed that the Warp Drive script initializes variables in startUp that could change at other times, for example service level or other configurations (if using Ship Configuration). I suggest moving all of the code currently in the startUp handler to shipWillLaunchFromStation.
I noticed that the Warp Drive script initializes variables in startUp that could change at other times, for example service level or other configurations (if using Ship Configuration). I suggest moving all of the code currently in the startUp handler to shipWillLaunchFromStation.
Sorry for long delay - I was busy with other projects.
Hard Way version 2.8.0 - code redefining player ship dynamics divided onto two blocks.
Transferring all code onto shipWillLaunchFromStation event handler will cause circular reference loop. So I realized such decision:
Basic variables (not changing during game) remains in startUp handler.
Dynamically changing variables, depending of ship serviceLevel, transfered onto separate function, called from shipWillLaunchFromStation and shipExitedWitchspace event handlers.
Possibility of interference with Ship Configuration is still open. I'll appeciate any considerations if this issue really exist.
Thank you, Milo, for proposal to improve code!
I have a 4-axis joystick, so I set the fourth axis as throttle, associated with speed - very convenient to change speed quickly in combat.
Then I installed Power to Engines and Masslock Compensator OXPs, but whatever the circumstances, when I slide the throttle to max I only get the nominal max speed for my ship, no bonus form the OXPs.
I put some traces in the OXPs' code, printing player.ship.maxSpeed to the Latest.log, and it was being set to higher values... then as an experiment, I changed the setting for increasing decreasing speed from the joystick fourth axis to buttons, and now I can reach the bonus speeds...
I did not look at the code, but it behaves as if the joystick 4th axis is being mapped directly to 0-maxSpeed (at startup or launch time)... wouldn't it work better if mapped to 0-1 and used as a multiplier to whatever value maxSpeed has at the time?
__________________________________________________________________________________________________________________
by dybal » Sun May 10, 2020 3:16 pm
Yesterday I was doing a binary search of OXPs looking for the culprit of another problem, and suddenly I could accelerate with the joystick into the speed bonus from Power to Engines OXP.
So this problem was caused by an OXP , HardWay.
Sorry for crying wolf... I should have done a test without any unnecessary OXPs installed before reporting a bug
I'm not sure if the May 19th post was a response to this (HardWay.oxp + Power to Engines.oxp + Joystick):
I hope latest Hard Way release fixed this specific issue.
It is hard to avoid conflicts with OXPs changing game mechanics. If OXP B affects OXP A - well, sometimes conflict is caused by logical flaws in OXP B and issue can be fixed improving code. But sometimes OXP A and OXP B just changing game mechanics in incompatible ways. It this case OXP B affecting OXP A is not wrong per se - you'll just select A OR B, not both.
