in 2003 maybe.You know that 1.2MB/s is quite fast?
I have something that would be called below average internet speed in some parts of the world and I pulled the update at 3MB/s
Patch Notes Update Update 1.1.02 Incoming - 4pm GMT
- Thread starter Michael Brookes
- Start date
- Status
I have something that would be called below average internet speed in some parts of the world and I pulled the update at 3MB/s
2mb is fast according to the UK government, it like none of them have ever heard of Google fiber and its 1000 Mbps internet.
Last edited:
1.2 MB/s is almost 10Mbit/s, which is still more than some people in rural areas can get. For big cities of course it's kind of slow. So it depends on where you live.
anyways. Downloading a ~20 MB hotfix with 1.2MB/s can't really take long, right?
If it does, something else s' wrong.Does this also include insurance? I lost my anaconda yesterday while undocking just for slightly scraping another ship......
almostpilot
Banned
No, I have not had
Same here. This is most distressing.
My status has risen from "mildly amused" to "terribly vexed".
I shall go spend the evening with my gorgeous better half and a bottle of wine.
My hopes are with you other stalled explorers, that you may see a hotfix as soon as possible and free up some space on your overflowing Cartographics Storage Devices.
very happy , all controllers working as before , with the added bonus that i can now use my thrustmaster MFD boards directly with ED , thank you so much ,
Okay, now that I've had a chance to play more since the original 1.1 update, I just have to say... the new route planning is amazing. The lightning-fast route plotting to anywhere within 1000 LY is amazing enough (500 LY took 2 seconds, anything up to 200 LY seems to take about 1 second on my ancient CPU). But it seems to affect standard route displays as well. Previously I'd have to wait 1-2 minutes for it to start displaying routes out to systems 90-100 LY away. Now, by the time I type in the name of a destination 60 LY away, click find, and the camera finishes focusing on the new target (that recentering could really use a "fast" mode BTW, and an option to NOT forcibly reset the zoom level every single time, please), it's already displaying routes out to that distance and beyond. This is such a vast improvement!
Other pluses: Interdicting ships showing up as hostile so you can easily select them to decide if you want to submit or try to escape. That was a huge gripe. The "sell page" button for scan data is extremely welcome, as is the readout of what was scanned and what it's worth. I hope it gets fixed so everyone can sell their data soon. Oh, and being able to sort your huge list of possible internal compartment fittings so you can actually find the type of module you're looking for without knowing the prices by heart is SO much nicer. The only way to improve this now would be a second drop-down menu selection to optionally filter for a module type instead of having type as yet another way of sorting them - you're better off sorting alphabetically, because then you actually know what part of the huge list to scroll to.
One new nuisance I've noticed: The bright glaring white backgrounds of bounty voucher entries on the transactions tab is ugly as sin and irritating to look at, not to mention they take up a lot more space now. And while you're fixing that painful color choice, can we please someday soon have a way to recolor specific GUI elements instead of having to apply a global RGB mapping that affects all elements on the screen equally? I'd love to have a blue HUD, but every mapping I've seen which gives you one produces a blueish color for hostile targets and the messages "slow down", "FA Off", "Prox", and so on, with "Safe Disengage Ready" and sometimes even friendly stations and ships becoming orange or reddish. The normal colors for those are all perfect just as they are and I don't want to change them, but avoiding that leaves me stuck with something approximating the default HUD color.
---
So my biggest issue with route planning is now off the list, but it leaves a rather annoying #2 in its place: The false dichotomy between "economical routes" and "fastest routes". If you're within your maximum jump range and paying for refueling at every port of call, say on a regular trade route, fastest is certainly fastest. But if you prefer to scoop fuel as you go, whether to navigate between distant systems in a ship with a limited jump range or when out exploring, or simply to save money on fuel, the time spent scooping is increased dramatically by jumps closer to your maximum jump range. On the other hand, selecting economical routes frequently turns a 5 jump route into 20 or more jumps going far out of your way in order to use the absolute minimum possible amount of fuel, to the extent that you're spending a ridiculously excessive amount of time just waiting for the hyperdrive process and as little as a fraction of a second scooping at each stop.
Replacing the buttons representing these two extremes with a slider (similar to the cargo load slider below them) to bias route generation by placing greater weight on fuel efficiency, jump distance, or your preferred balance of the two would be an amazingly useful improvement to this situation. You can already achieve a similar effect, but only if your cargo is not full, by setting the route planner to calculate as if your cargo was actually full and your jump range more limited. But this places an absolute limit on the jump length the route planner can use, rather than simply biasing it against such longer (but still possible) jumps.
I think you would find that instead of a 5 jump fuel-hogging sprint or a 20-jump miserly meandering scenic route to get to the same destination, an 8-12 jump route balancing fuel consumption with number of jumps, avoiding the excessive overhead of long fuel scooping sessions or numerous cumulative hyperjump delays would save a significant amount of time compared to either of the current choices. And for those who really do want to arrive in absolutely as few jumps as possible (such as traders who don't scoop fuel), or those who actually don't mind hitting as many star systems as possible and saving fuel in the process (such as those interested in scanning lots of systems along the way), the far ends of the slider would have identical results to the current two buttons.
I'd say #3 on my list is probably the extreme distances you are sometimes required to travel in super-cruise. For example, it takes something like an hour and a half to travel from Alpha Centauri to the station at Proxima Centauri, and leaves an Asp with a tremendous integrity repair bill. Many stations go almost completely unutilized simply because of the vast travel time required to reach them. I read in an old post made during beta, which apparently linked to an early design document, that micro-jumps between locations within a system were originally planned. And even before I read that, I thought being able to jump from a system's primary to other stars within the system would be an excellent way of resolving this problem. I do think it should be limited to stars, though, because as someone pointed out in that thread, being able to go directly to any location in the system would make the risk of being interdicted practically nil. Having to travel from, say, the second star of a binary pair to the stations orbiting that star's planets (after hypering into the system, and then hypering again from star A to star B) would be no worse in terms of potential interdiction than going from the primary to planets and stations orbiting the primary, and suddenly, a significant number of stations would undoubtedly see a nice increase in traffic due to being actually accessible in a reasonable timeframe.
And if anyone's still concerned about such an ability reducing the chances to interdict targets, consider this: It's impossible to interdict traffic that simply isn't there, due to a station in your current system being effectively *more distant* (in terms of time required to reach it) than another station in a system 50-100 LY away. And even in systems where the large distances aren't large enough that nobody makes the trip, most interdictions still occur on the approach to a station, while the target is at 75% throttle or less and decelerating, not on the long, long stretches in between where it's impossible to catch up because everyone's running at 100% of the maximum frame-shift for the local gravitational gradient.
Other pluses: Interdicting ships showing up as hostile so you can easily select them to decide if you want to submit or try to escape. That was a huge gripe. The "sell page" button for scan data is extremely welcome, as is the readout of what was scanned and what it's worth. I hope it gets fixed so everyone can sell their data soon. Oh, and being able to sort your huge list of possible internal compartment fittings so you can actually find the type of module you're looking for without knowing the prices by heart is SO much nicer. The only way to improve this now would be a second drop-down menu selection to optionally filter for a module type instead of having type as yet another way of sorting them - you're better off sorting alphabetically, because then you actually know what part of the huge list to scroll to.
One new nuisance I've noticed: The bright glaring white backgrounds of bounty voucher entries on the transactions tab is ugly as sin and irritating to look at, not to mention they take up a lot more space now. And while you're fixing that painful color choice, can we please someday soon have a way to recolor specific GUI elements instead of having to apply a global RGB mapping that affects all elements on the screen equally? I'd love to have a blue HUD, but every mapping I've seen which gives you one produces a blueish color for hostile targets and the messages "slow down", "FA Off", "Prox", and so on, with "Safe Disengage Ready" and sometimes even friendly stations and ships becoming orange or reddish. The normal colors for those are all perfect just as they are and I don't want to change them, but avoiding that leaves me stuck with something approximating the default HUD color.
---
So my biggest issue with route planning is now off the list, but it leaves a rather annoying #2 in its place: The false dichotomy between "economical routes" and "fastest routes". If you're within your maximum jump range and paying for refueling at every port of call, say on a regular trade route, fastest is certainly fastest. But if you prefer to scoop fuel as you go, whether to navigate between distant systems in a ship with a limited jump range or when out exploring, or simply to save money on fuel, the time spent scooping is increased dramatically by jumps closer to your maximum jump range. On the other hand, selecting economical routes frequently turns a 5 jump route into 20 or more jumps going far out of your way in order to use the absolute minimum possible amount of fuel, to the extent that you're spending a ridiculously excessive amount of time just waiting for the hyperdrive process and as little as a fraction of a second scooping at each stop.
Replacing the buttons representing these two extremes with a slider (similar to the cargo load slider below them) to bias route generation by placing greater weight on fuel efficiency, jump distance, or your preferred balance of the two would be an amazingly useful improvement to this situation. You can already achieve a similar effect, but only if your cargo is not full, by setting the route planner to calculate as if your cargo was actually full and your jump range more limited. But this places an absolute limit on the jump length the route planner can use, rather than simply biasing it against such longer (but still possible) jumps.
I think you would find that instead of a 5 jump fuel-hogging sprint or a 20-jump miserly meandering scenic route to get to the same destination, an 8-12 jump route balancing fuel consumption with number of jumps, avoiding the excessive overhead of long fuel scooping sessions or numerous cumulative hyperjump delays would save a significant amount of time compared to either of the current choices. And for those who really do want to arrive in absolutely as few jumps as possible (such as traders who don't scoop fuel), or those who actually don't mind hitting as many star systems as possible and saving fuel in the process (such as those interested in scanning lots of systems along the way), the far ends of the slider would have identical results to the current two buttons.
I'd say #3 on my list is probably the extreme distances you are sometimes required to travel in super-cruise. For example, it takes something like an hour and a half to travel from Alpha Centauri to the station at Proxima Centauri, and leaves an Asp with a tremendous integrity repair bill. Many stations go almost completely unutilized simply because of the vast travel time required to reach them. I read in an old post made during beta, which apparently linked to an early design document, that micro-jumps between locations within a system were originally planned. And even before I read that, I thought being able to jump from a system's primary to other stars within the system would be an excellent way of resolving this problem. I do think it should be limited to stars, though, because as someone pointed out in that thread, being able to go directly to any location in the system would make the risk of being interdicted practically nil. Having to travel from, say, the second star of a binary pair to the stations orbiting that star's planets (after hypering into the system, and then hypering again from star A to star B) would be no worse in terms of potential interdiction than going from the primary to planets and stations orbiting the primary, and suddenly, a significant number of stations would undoubtedly see a nice increase in traffic due to being actually accessible in a reasonable timeframe.
And if anyone's still concerned about such an ability reducing the chances to interdict targets, consider this: It's impossible to interdict traffic that simply isn't there, due to a station in your current system being effectively *more distant* (in terms of time required to reach it) than another station in a system 50-100 LY away. And even in systems where the large distances aren't large enough that nobody makes the trip, most interdictions still occur on the approach to a station, while the target is at 75% throttle or less and decelerating, not on the long, long stretches in between where it's impossible to catch up because everyone's running at 100% of the maximum frame-shift for the local gravitational gradient.
Last edited:
Tell me you flew into a station to see if it blew up?
OK... So I'm on my usual bounty hunting route in Cupis, heading to the Nav Beacon. I get interdicted by a CMDR in a Viper - which I thought would now be a crime anyway. I let myself be interdicted so I can see what this guy's up to (I'm in my Cobra, armed with Plasma Accelerators). He attacks me, I respond appropriately (i.e. he's destroyed). However I am the one who got the 6000 Cr bounty!
Has anyone seen anything like this before?
Has anyone seen anything like this before?
After the latest fix i really start to enjoy it!
Sort function in outfitting is great,
City lights are awesome,
New music is really good,
decals are nice,
map route planner is finally user friendly!
Good work and happy you keeping us informed!!!
+ just noticed... I can finally see the rank oft other cmdrs!!!
Last edited:
I'm glad I was careful. Dodged type 9 wreckage floating inside a station, thinking that touching it could mean death.
- Status