The autopilot is a standard piece of equipment aboard every ship built and sold at trade stations, cities, and carriers. It has two main functions. (1) within a single sector, it orients the pilot's ship toward a designated navigation point and uses the ship's engines to travel at normal speed. (2) for interstellar travel, the autopilot does for space what canals did for Venice, Italy (old Earth): it uses the ship's jump drive to create a "canal" through space.
We will concentrate the rest of our discussion on the second use of the autopilot. A detailed description of its first use can be found here: The Navigation Console, in Section IIA.
For those who will accept most any explanation (whether they understand it or not), here is the best possible reason for why the autopilot has earned the nickname of zig-zag.
[align=center]
Diagram illustrating how and when the autopilot decides to include altitude in its calculations[/align]
Basically, it works like this: the autopilot ignores the altitude until the length of the SY axis is about equal to the number of jumps it takes to get to your destination. Ergo, using the example above and assuming the pilot has a Mantis Drive installed aboard his ship (10 sectors per jump), the autopilot will continue to jump horizontally until the remaining distance is about 400 sectors (give or take a couple jumps). Why it does this is uncertain except maybe because the autopilot refuses to acknowledge any distance which is less than a whole sector.
This theory is substantiated by the fact that, even when traveling along a "canal" in space which has no vertical component, jump points can zig along the X axis and then zag along the Z axis, depending on how you round off the square root* of X squared plus Z squared.
* Known colloquially as the square root canal.
The original tests were done flying for about five hours (or until I ran out of fuel ... having outfitted the ship with a really big fuel capacity) along the X axis ... conducting the same test for each class of jump drive. Afterward, I realized that the error would be greater when flying diagonally across the X-Z grid ... and even greater if flying in three dimensions, diagonally across the X-Y-Z grid. So I made another long trip, setting a destination which would propel me in autopilot on an angular vector ... but only tested it using the Mantis Drive. I then calculated the fudge-factor and applied the same factor to all the other jump drive classes.
I kind of get it but I'm still a bit confused. Was it only the fudge factor (slop value) that you adjusted as a result of the later (diagonal) tests ? or did you adjust the base engine values as well ?
Just curious really, as while I'm sure the value doesn't matter too much I'm still convinced the class 4 engine isn't correct from a theoretical point of view, but I'll think more about changing it when I get around to adding in figures for a class 1 drive - which I figure I'll eventually do just for the sake of completeness.
Anyway the latest version with those changes I mentioned is attached and I've included a readme file in the zip. Feel free to comment / recommend any changes / fixes to the readme as, documentation isn't exactly my favourite or strongest area.
You do not have the required permissions to view the files attached to this post.
It's difficult to get an accurate estimate of either 'time en route' or 'fuel required' because of the way the autopilot computes jump points. If you're traveling along one of the cardinal headings (the base line), each jump will be the maximum allowed for your jump drive. For example, the Mantis will always jump ten sectors. But, depending on your pitch and heading, the number of sectors won't always be the maximum. Quite often, the autopilot will compute a jump of only nine sectors for the Mantis.
Consequently, you can't simply divide the distance to you destination by the number of sectors per jump to find out how many jumps it will take to get from one place to another. And, if you can't accurately determine the number of jumps, neither can you calculate the amount of fuel (each jump uses an additional amount of fuel in slowing down) or the time it will take to get to your destination.
Ergo, the reason for a fudge factor. It was added instead of trying to re-compute the base line (which really hasn't changed). But the fudge factor has changed since I first tested all six jump drives ... and, due to the recent changes made to autopilot speeds, probably should be tested again.
Now I understand what they represent, i.e. the Engine value (base line) is representative of jumping 10 sectors every time, and the slop (fudge factor) accounts for jumping at a 45 degree angle which results in 9 sector jumps.
I guess I'll have to readjust the displayed values as currently assuming I've not misunderstood, the current values which are displayed like:
format1: Estimate +/- slop
format2: min - max
aren't actually true in that format1: "Estimate" value is the actual minimum value (since you can never jump more than 10 sectors) while the slop value is how much time to add to the "Estimate" to get the maximum time, so format2: "max" value is accurate, and format2: min value is a theoretical minimum which will never actually be achieved.
Easy enough to fix i.e add slop/2 to "Estimate" and make halved old slop as new slop - which will make the format2 values accurate (well as accurate as can be expected for the time being).
This is also how the refuel time estimate should probably work (currently it is the pre-fix method but I was already aware of this discrepancy for that calculation) - I'm also inclined to leave the refuelling with a "slop" as there is a small delay between reaching full energy and the fuel transferring, (just like there is a small delay for energy reaching full and and then autopilot activating when jumping).
BTW I'm not sure about the fuel consumption stuff just yet haven't really looked at it in any detail - but my guess is this will be the thing that has changed most with regard to changes in autopilot speed.
The minimum fuel/time can probably be ignored ... it's not likely that a number which is less than base line will ever show up.
The more I think about it, the more I'm wondering how the new autopilot behavior can be affected by throttle settings, engine size, or IDS multiplier. Prior to the change, I usually set my throttle to zero and engaged inertial to transit from gate to gate ... allowing me to coast through and past each gate at a respectable speed. Now, I need to keep the throttle full forward.
When using autopilot and inertial, it seems that I can maintain zero throttle but, nonetheless, coasting speed is affected by whatever is set in the IDS multiplier. And the max speed I can set in the multiplier is dependent on the engine class installed on my ship. All these factors need to be tested again.
Okay, I spent the day testing to see if engine class makes any difference in fuel used or time en route. I tested two engines, C1 and C10, using the same ship for both.
Hyper-jump drive: C4 Fulcrum
Heading & pitch: due east (090 … a cardinal heading) & 0 degrees
Throttle setting: off
IDS multiplier: x5
Shields / Energy setting: -5S / 5W
Inertial: on
The Set Velocity listed at 1084 for the C1 engine and 1971 for the C10 engine. After flying for approximately five hours, I got the following results:
C1.
Fuel used per hour: 896.494
Distance flown per hour: 896.306
C10.
Fuel used per hour: 910.956
Distance flown per hour: 908.297
These can be considered baseline numbers for the C4 Fulcrum. The C1 and C10 results are close to each other … but no cigar.
Well that sort of makes sense, class1 engine is kind of what I expected with fuel... although perhaps not depending on the actual times. And C10 is likely outside of the bounds I expected but maybe within them, I don't suppose you still have the raw data ? It would be easier to see number of sectors jumped, fuel used & time taken as the missing time taken component could explain the discrepancy with regard to fuel.
To explain "the discrepancy", I've done a bit of fuel testing stuff too and also been looking at the times but from a completely different angle, i.e. building it from what I already know to be true. For example similar to you I've been working in cardinal directions but with a mantis and class 6 engine (just what I happen to have installed in the profile I've been using, and I'll also mention I'm at a planet in a remote system).
With time I was missing one piece of the puzzle, and it seems I'm getting reasonably consistent results of 6.6 seconds from jump start to jump completion (i.e. jump engaged to exit of jump with zero power) - this is the most error prone figure in the equation though as this is taking place like I mentioned in a remote system. I've noticed previously that this time is quite a bit longer when the system name changes - and that time difference is essentially machine (i.e the computer running the game) dependant as it loads/calculates new system data. I've determined that If I use a figure of 7 seconds it undershoots the current base line time estimate values by approx .025 of a minute per max range sectors. And I'll have to test how long it takes on a cross system jump to see what to apply to the maximum time figures. This method I'm testing is calculating min / max jumps needed and applying the time it takes i.e.
time = (NumJumps*(7+ Recharge) - Recharge)/60
where:
Recharge = 120/(10+Weapon power setting) ; power setting is whatever is before the W in -5S/5W
NumJumps is calculated twice once for min number and again for max number, essentially dist/maxDrvRange and dist/(maxDrvRange-1), but also made into an integer where any fractional component of each is added as an extra jump. The second part will also only be needed for drives which can't jump max range on a 45 degree angle eg not for fulcrum class 1 Jump drive.
Anyway getting back to fuel, fuel I've noticed is essentially just 1 unit used per sector jumped (under inertial) there may be a time component as well where 1 drops off every hour or so ?? which could explain the engine class 10 figure you've come up with while the difference between the two figures in the class 1 is essentially conforming to this. Another thing I've noticed with fuel use is that when you reach the destination, the autopilot changes direction to face the nav point and this uses an addition 2 to 3 units of fuel (class 6 engine, class 13 wings), i.e. I think it's more slight course corrections that uses extra fuel en-route with Inertial on, but I'm inclined to think any fuel use calculation should add a bit of reserve for safety reasons (like RL flying a minimum of 15% is typical in this country and I think is a pretty standard practice for civil aviation in most countries).
For both tests (C1 and C10) I started in Sapphire, at coordinates 0-0-0 and set a destination point beyond my fuel capacity (SX: 10000). This allowed me to run the entire time and distance without, at destination, burning fuel while the autopilot hunted for the exact Nav point.
C1.
Fuel at start: 4997
Fuel at end: 216
Time en route: 5 hrs, 0 min, 20 sec
Distance flown: 4780
C10.
Fuel at start: 4995
Fuel at end: 197
Time en route: 5 hrs, 0 min, 16 sec
Distance flown: 4784
It would've been impossible for me to stand around, watching my computer, counting the number of jumps for over ten hours. But, for the period of time when I did observe the transit, each jump covered 4 sectors ... as indicated by the fact that both 4780 and 4784 are divisible into whole numbers by 4. One factor I did not test was how much difference it would make if, instead of setting the IDS multiplier to x5, it was set to x1 ... which would probably reduce the Set Velocity and, therefore, force autopilot to decelerate to a lower speed between jumps ... resulting in more fuel burned per jump.
From post: 170978, Topic: tid=11400, author=Noesis wrote:I've noticed previously that this time is quite a bit longer when the system name changes - and that time difference is essentially machine (i.e the computer running the game) dependant as it loads/calculates new system data.
Vice has said previously that when the game has to create a new system - ie when you jump - the jump time is extended until the new graphics have been calculated. The more complex the system being created the longer the jump takes - not a ship equipment techy answer but a matter of game code requirements!
Callsign: Incoming
Life is like a sewer... what you get out of it depends on what you put into it. - Bob Newhart
Hell is being in a pure platinum asteroid field... with a diamond mining beam
Thanks for the raw data, I can use that to calculate what the average jump time was for those numerous jumps, and since it's from Sapphire where there is a fair number of planets around, it should show an increased time for this component, but without it being too great as it will incorporate both jumps with & without a sector name change.
From post: 171006, Topic: tid=11400, author=Marvin wrote: I don't remember reading that. Does it also happen when you've opted to pre-generate your planets?
Without actually testing it I'd have to say yes, as regardless of how this is done (procedurally, or pre-generated) it still needs to be done. Only the pre-generated data will use the disk drive to fill some of that data instead of using the processor to calculate it all. Which method is quicker will depend on the hardware components in the machine being used.
From post: 171006, Topic: tid=11400, author=Marvin wrote: I don't remember reading that. Does it also happen when you've opted to pre-generate your planets?
I think so - planet generation is more about the planet textures isn't it?
Callsign: Incoming
Life is like a sewer... what you get out of it depends on what you put into it. - Bob Newhart
Hell is being in a pure platinum asteroid field... with a diamond mining beam
Intriguing... the C10 engine did an extra jump in 4 seconds less time.... either you flew close to a star with high gravity and it caused you to time travel or perhaps the C10 engine recharges power slightly faster than a C1 engine, must be a pretty small amount though.
Incidentally the jump times worked out to be 7.079497908 for C1 and 7.063545151 for the C10.
From post: 171014, Topic: tid=11400, author=Noesis wrote:Intriguing... the C10 engine did an extra jump in 4 seconds less time....
I think I'd consider that to be the "margin of error" ... a couple seconds difference between the two tests when initiating autopilot and hacking the stop watch ... and another couple of seconds when disengaging autopilot/inertial, waiting for the ship to come to a full stop, then stopping the watch.
Updated versions have been posted on Seejay's site with source. v3.0 & v3.1 in same file, 3.0 is what was posted above with updated values for the C4 Fulcrum drive as per Marvins posted test, v3.1 is using different travel time calculations using number of jumps instead of number of sectors - should be slightly more accurate, see the included readme for more on change details.
Callsign: Incoming
Life is like a sewer... what you get out of it depends on what you put into it. - Bob Newhart
Hell is being in a pure platinum asteroid field... with a diamond mining beam
As quoted from the H2GE, here's the problem:
I don't remember reading that. Does it also happen when you've opted to pre-generate your planets?