Agreed!
Travel Methods
- Thread starter avarusbrightfyre
- Start date
you never can see everything - a human life is about 2.5 billion seconds long - and there are 400 billion stars in ED.
I was just making a point that making a deal about how much we've seen isn't really the point. It's all about the exploration itself, not how much of the galaxy we've seen.
Sometimes the meaninglessness of the universe is frustrating - pretty much uniform in any direction, expanding with increasing speed, If it continues like this it will end up with just virtual particles isolated from each other, where each flies through it's own space, which expands faster than those particles could fly through it. No further interaction possible. And in between this vast time span a brief period, where life is possible - but all what this life aspires is destroying each other to maintain their meaningless lives.
And ED isn't different - we destroy each other - and new implementations are for just that - again destruction.
well, it's off topic - just ignore it.
And ED isn't different - we destroy each other - and new implementations are for just that - again destruction.
well, it's off topic - just ignore it.
Last edited:
Wow, that was dark, lol. True, though.
So sorry I made a post SUPPORTING your travel method suggestion.
You sure showed me!
Sorry, didn't mean to come off as rude as it sounded looking back at it. My point was that it seemed that your comments were focused on how long it takes to get somewhere, whereas my focus is on how involved I have to be in the process. I may have been a bit confused by your post.
The bottom line that I am trying to improve in the game, is getting rid of the unneeded Grind Loops.
This one is about having to Babysit Jumps, where a Auto Pilot would do just fine.
As to the Time it takes to go from point A to B, is a different ball of wax altogether.
I think there is more chance of adding Auto pilot, than changing or adding a new method of travel.
But I would support a new method also.
This one is about having to Babysit Jumps, where a Auto Pilot would do just fine.
As to the Time it takes to go from point A to B, is a different ball of wax altogether.
I think there is more chance of adding Auto pilot, than changing or adding a new method of travel.
But I would support a new method also.
The only reason I disagree is because I read somewhere that the developers have an issue with full on autopilot due to something related to bots. I didn't really understand it, but it seems they're not keen on putting in too much automation. That's why my attention is mostly focused on a new manual method. I'm not saying autopilot is a bad idea, I just feel like they have a few reasons to be against it.
You know, I was just thinking that a long jump version calculation doesn't have to be quite as complicated as I set it out before. All we're really looking for is to consolidate all the jumps we would normally do on a single tank of fuel into one long jump that takes about the same amount of time. So to do that, we don't need to worry about speed or any of that. All we have to do is just use what would normally be the max jump range and just add an arbitrary hold in the witch space loading screen for a set number of seconds for each multiple of that base jump range you're travelling.
So for example, you might normally have a max jump range of 20 ly with the regular FSD, and let's say your fuel on board will give you five jumps for 100 ly between refuels. The only change to the programming for the long jump version would really be to use the max fuel range (which is already calculated when route planning in the existing navigation system) as the new max jump range. Then all they have to do is use the normal jump range as a counter to measure how long to hold us in the jump animation. So if you're jumping 20 ly or less, you just jump like normal. If you're doing 20 to 40 ly, it holds you in witch space for an extra 50 seconds to account for the time you'd normally spend preparing for a second jump. For every multiple after that, you just add another 50 seconds to the hold time until you hit your max jump range based on fuel. So a full tank would get you 100 ly and take about 250 seconds to complete the jump, just like doing it the way we do now. But instead of having to manually jump five times, you just sit in witch space for a few minutes.
The awesome part is that I don't think it would require any real restructure to the way everything works already. You could still engineer the drives and use existing modules to increase the regular jump range just like we do now, and because that regular jump range would be used as the counter for the long jump part, everything should work out pretty much the same. All they'd really need to do is just create a new module that tells the client to use the long jump calculation instead of the basic one. If you have the module equipped, it uses the long jump version of the calculation. If you don't, it works just like it does now.
I think it could really be that simple.
So for example, you might normally have a max jump range of 20 ly with the regular FSD, and let's say your fuel on board will give you five jumps for 100 ly between refuels. The only change to the programming for the long jump version would really be to use the max fuel range (which is already calculated when route planning in the existing navigation system) as the new max jump range. Then all they have to do is use the normal jump range as a counter to measure how long to hold us in the jump animation. So if you're jumping 20 ly or less, you just jump like normal. If you're doing 20 to 40 ly, it holds you in witch space for an extra 50 seconds to account for the time you'd normally spend preparing for a second jump. For every multiple after that, you just add another 50 seconds to the hold time until you hit your max jump range based on fuel. So a full tank would get you 100 ly and take about 250 seconds to complete the jump, just like doing it the way we do now. But instead of having to manually jump five times, you just sit in witch space for a few minutes.
The awesome part is that I don't think it would require any real restructure to the way everything works already. You could still engineer the drives and use existing modules to increase the regular jump range just like we do now, and because that regular jump range would be used as the counter for the long jump part, everything should work out pretty much the same. All they'd really need to do is just create a new module that tells the client to use the long jump calculation instead of the basic one. If you have the module equipped, it uses the long jump version of the calculation. If you don't, it works just like it does now.
I think it could really be that simple.
That's so wrong it's not funny, fuel use is an exponential factor, not linear. If I jump 20ly in my current setup it takes X fuel, if I jump 40ly it takes X to the power of four, so a 20ly jump will take 5 tons of fuel, a 40ly jump would take 20 tons of fuel, an 80ly jump would take 80 tons of fuel. In the system you are proposing that 80ly would only take 20 tons of fuel which is not how fuel use is calculated. In your example for instance if we used proper fuel calculation, with that 20ly jump taking a 1/5th of the tank, a 40ly jump would take 4/5ths of the tank, and an 80ly jump would require a fuel tank 3 times the size of the current tank.
You simply can't calculate fuel use and jump range based on a linear exponent in ED.
Yes, but if 20 ly is your max jump range, then you're already at your max fuel consumption rate per ly. For anything past that, the module just holds that same fuel consumption rate over a set period of time, and would be the equivalent of making five manual jumps instead of this one long one. We can justify this because we're basically making it so that this one long jump takes exactly the same amount of time and fuel as if you manually crossed the same amount of distance in five jumps. The IRL reason is to make sure travel times are consistent whether you're using the long jump module or not. The in game explanation would be something like reduced interstellar speed to get better fuel economy, keeping your fuel consumption per unit of distance the same as it would be if you were jumping normally.
But none of that takes care of the "Jump Babysitter" loop.
It significantly reduces it, though, and that's all I've really been asking for. If you're only having to perform the jump action once to cover the same distance in the same amount of time as five jumps the way it is now, you're doing a fifth of the work for the same result.
Even so you still have to Babysit the Jumps, I want Freedom from being locked down to the loop.
There are too many other things I could be doing, that would keep my head in the game.
After 2 min of jumping I feel like punching something, or getting a pillow to prop up my hand.
Yeah, I get you. This is just where we move into differing acceptable degrees of repetition based on personal opinion. In my current exploration ship, I have a max jump range of like 60 ly and I think I get at least ten jumps out of a tank of fuel. I think it might even be fifteen. With this long jump system, if it takes 1 minute per 60 ly, I have ten to fifteen minutes of witch space in which to do whatever I want while my ship is travelling to the destination.
I'm mostly focusing on the long jump personally because I feel like it's much simpler than developing a complex autopilot system. If I were the developer and had a choice between making a minor change to an existing system, or developing a completely new automatic pilot from scratch that avoids stars and automatically fuel scoops and all of that, I know which option I would pick. I figure distilling an idea down to the simplest possible execution that's as easy as possible on the developers makes it far more likely that they even bother to think about it, much less implement it.
Of course, I'd be surprised if they are even following this thread at all, much less open to doing anything about it.
I watched a stream lately about the history of elite and fan made games like Oolite (that is where your "witchspace" is coming from, in Elites it's hyperspace). The old games had time dilation to speed up time - this is of course not possible in an MMO, that is why there is supercruise as an automatic way to speed up time. Seen from the past of theses games there was never any automatic other than the docking computer and even the SC assist is just a replacement of time dilation. I really doubt therefore, that FDev has any interest in making space travel any more automatic than it already is.
Yeah, that's why I'm personally sort of avoiding autopilot. The long jump idea is still fully manual and would work almost exactly the same way as the current method does, it just consolidates a bunch of individual jumps into one long one and spreads that jump out over time so players using the option don't get an unfair advantage over those who aren't. It wouldn't really change the physics of the jump mechanic much. I think I've mostly settled on it being an additional module you equip that adjusts how the existing FSD functions. That way it's just an item you equip if you're going on a long trip and you swap it out for something else like your docking computer, which you probably wouldn't need if you're going out into deep space anyway.
dude i got 55 notifications.
didi you really reply to most posts in this thread?
It wouldn't be a conversation if I didn't respond. For the most part it's been a very thoughtful and respectful discussion, so it's been easy to participate.