@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.
The one thing which spells almost instant death with Hard Way loaded is a Fuel Leak.
I wonder if there might be some sort of fix? I seem to recall that a refill from one of the many auxiliary Fuel Tanks merely pours more fuel into the leaky tank - and that is then lost too.
I guess it might be possible to add a "Silicon sealant" equipment item that, when used, will stop the leak for a certain amount of time. Limited number of uses. But it will need conditions on it, to prevent it from being purchased before a certain mission is completed. Thoughts?
I guess it might be possible to add a "Silicon sealant" equipment item that, when used, will stop the leak for a certain amount of time. Limited number of uses. But it will need conditions on it, to prevent it from being purchased before a certain mission is completed. Thoughts?
Sounds like a fix... but would I have time to put on a protective suit, open up the fuel tank, crawl inside, locate the leak and then clobber it with sealant in the 2 seconds before my Cobra explodes?
Playing the harder start (Start Options: no money, no fuel) in Hard Way, I never had enough time after launch to find asteroids to shoot for money before my Adder exploded due to lack of fuel/energy - never mind return to the station (but, really, I should not have been able to launch in the first place, I suppose!). But now that I know it is a matter of editing the Save File at start-up, I can just tweak that to add the fuel.
Sounds like a fix... but would I have time to put on a protective suit, open up the fuel tank, crawl inside, locate the leak and then clobber it with sealant in the 2 seconds before my Cobra explodes?
Depends on how long it takes you to prime the equipment and activate it!
Getting a prototype working at the moment. Should have something to show shortly.
I guess it might be possible to add a "Silicon sealant" equipment item that, when used, will stop the leak for a certain amount of time.
If my theory that quirium is in fact a hyper-dimensional element, which is dimensionally unstable in our spacetime, is correct, it would take a little more than silicon sealant nothing could stop a quirium de-containment event.
I seem to recall there is already an equipment item that involves rapid quirium de-containment.
"There are large, white swans, and there are small, black swans," he explained, "But there are no medium-sized swans, and there are no grey swans. The non-existence of grey swans mitigates against belief in Mr Darwin's theory."
If my theory that quirium is in fact a hyper-dimensional element, which is dimensionally unstable in our spacetime, is correct, it would take a little more than silicon sealant nothing could stop a quirium de-containment event.
But silicone fixes everything! It's the handy-man's best secret weapon!
But I guess we could call it something else. I'll leave you to come up with a suitably appropriate tech-sounding name. Or I could just say that the material has been specially treated in order to (a) work in the vacuum of space, and (b) work as a plug for a quirium fuel leak.
