These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Information Portal

 
  • Topic is locked indefinitely.
 

Dev Blog: Long-Distance Travel Changes Inbound

First post First post First post
Author
Previous Topic Next Topic
KIller Wabbit
MEME Thoughts
#4321 - 2014-10-02 21:45:10 UTC
CCP Greyscale wrote:
Planned new feature to address new player movement:

For players less than thirty days old, once per player corporation joined, and
For all players, once a year

You may push a button in your corp interface (while a member of a player corp and docked) that:
- Moves your medical clone to a station designated by your corporation, and
- Automatically moves you to your medical clone

Exact method of corporations designating target station still being ironed out, but it will involve at the very least being able to designate a default station for all corp members, and will likely be allowed for *any* station with a corp office, regardless of system sec status.


This seems to us like it solves the "I want to recruit people to nullsec" concern, and also gives non-nullsec recruiters an easier way to get genuinely new players to the right location easily.



Thoughts? Pasting this into the FAQ and also trying to get it into the blog proper.


Common - For all players - a few times a year at least. 3?

Limited movement of corp office. Say 4 times a year?
Kassasis Dakkstromri
State War Academy
Caldari State
#4322 - 2014-10-02 21:46:26 UTC
Solo Wulf wrote:
CCP you are bad at EVE... Stop potential silliness



Side note: This is nao my new signature!!!

CCP you are bad at EVE - this is not the behavior of a "Steward", this is small time devs that got a defacto promotion, and CSM's that should be impeached, trying to make a name for themselves and pad resumes about how they did all this awesome development.

And after the Phoenix dev thread, as well as what I'm seeing so far in this thread, I have little hope that these protests will be taken seriously...

Did Burn Jita not teach you Devs anything???

CCP you are bad at EVE... Stop potential silliness ~ Solo Wulf
Obsidian Hawk
RONA Midgard Academy
#4323 - 2014-10-02 21:46:35 UTC
I will keep saying it over and over. Jump range and fatigue should be scaled based on the ship you are flying. Not a flat rate.

Range
Black ops > Rorqual > jf > carrier > dread > mom > titan

Why Can't I have a picture signature.

Also please support graphical immersion, bring back the art that brought people to EvE online originaly.
Kun'ii Zenya
Hogyoku
Goonswarm Federation
#4324 - 2014-10-02 21:47:38 UTC
Mc Cormeg wrote:
Endo Saissore wrote:

I agree it gimps JFs, but if you wait 15 minutes between jumps then you don't accumulate fatigue. Not the end of the world and the trade off is worth it IMO.

This is assuming that you gain 1.5 fatigue per jump. I would quote me with those numbers. I'm not the best with math.


As i understand you only have to wait 1 minute per ly you had traveled with your last jump because if your current jump fatigue is below 1 and that's the case you want to have, you only gain a fix 1+ly for the next one.



Bzzt wrong.

You jump 1 light year. Your fatigue was 0. After the jump your fatigue is no 2 (1 light year + 1). Fatigue reduces by 0.1/minute. So to reduce fatigue to zero it will take 20 minutes. To reduce it below 1 to avoid the multiplicative effects you have to wait 11 minutes.
Lord TGR
Brutor Tribe
Minmatar Republic
#4325 - 2014-10-02 21:48:14 UTC
Komi Toran wrote:
Yes, you can have scouts. Yes, you can have escorts. But, you can't have these things all the time (Unless you're telling me to buy another account, in which case, #$%& you as there's too much of that BS in the game already; if CCP wants to require multiple alts to play the game, then that's what the base subscription should cover)

I hear this is a "massively multiplayer" game. Maybe you should utilize that.
Sieonigh
Sebiestor Tribe
Minmatar Republic
#4326 - 2014-10-02 21:48:44 UTC
TimeDrawsNigh wrote:
Counter proposal for the jump delay timer.

Link below is a google excel doc. of cumulative delay timer that incrementally gets longer with each jump.

http://bit.ly/1rOpzTs

It’s a logarithmic scale.

So when you jump you get two timers.

First timer is the jump drive timer; the second timer is jump drive activation delay.

The jump drive timer is a base 30 minutes and every time you make a jump it will record the amount and add +1 to the "Jumps Made Since Timer Began" value. The jump drive timer will reset back to 30 min every time you make a new jump.
The jump drive activation delay is the timer you get once you have jumped. It’s the time you have to wait till the next jump can be made.

The equation for this is below.

http://i.imgur.com/EQpv4Cv.png

The principal of what happens here is that your delay timer gets bigger with each jump. The increment between each subsequent timer gets smaller, causing the graph to plateau out into a logarithmic curve. Eventually after so many jumps the delay timer will reach the same value as the jump drive timer, at which point it’s better with it out entirely and then start the process over.

Initially we found a problem with the function where doing three really short distance jumps would make the times later overall shorter but that has been fixed with the “Jump Amount Modifier.”

So e.g.
Jump 1 > 4.19 LY > delay timer of 6.42min > cumulative time 6.42min
Jump 2 > 4.7 LY > delay timer of 9.72 min > cumulative time 16.14min
Jump 3 > 4.206 LY > delay timer of 11.73 min > cumulative time 27.86min
Jump 5 > 4.564 LY > delay timer of 13.28 min > cumulative time 41.14min
Jump 6 > 1.855 LY > delay timer of 14.15 min > cumulative time 55.29min

Notice the increase in time getting smaller but the time overall still get longer. Bit like the diminishing returns of stacking nerf.

This Post and Equation was worked on by Sieonigh and myself.

Edit: We made this formula under the assumption that Jump Freighters and Rorquals do NOT have the 90% reduction, rather we think Black Ops should have this reduction (which we're implementing).


+1
McBorsk
Multispace Technologies Inc
#4327 - 2014-10-02 21:48:55 UTC
218 pages? Calm down, people.
Querns
Science and Trade Institute
Caldari State
#4328 - 2014-10-02 21:49:10 UTC
Just wanna chime in here and remind everyone that they are terrible at reading the changes, and every single spreadsheet that has been posted in this thread is incorrect.

I'd correct you, but the information I know is too valuable to share.

This post was crafted by the wormhole expert of the Goonswarm Economic Warfare Cabal, the foremost authority on Eve: Online economics and gameplay.
Endo Saissore
Afterburners of Eve'il Inc.
#4329 - 2014-10-02 21:49:17 UTC
TimeDrawsNigh wrote:
Counter proposal for the jump delay timer.

Link below is a google excel doc. of cumulative delay timer that incrementally gets longer with each jump.

http://bit.ly/1rOpzTs

It’s a logarithmic scale.

So when you jump you get two timers.

First timer is the jump drive timer; the second timer is jump drive activation delay.

The jump drive timer is a base 30 minutes and every time you make a jump it will record the amount and add +1 to the "Jumps Made Since Timer Began" value. The jump drive timer will reset back to 30 min every time you make a new jump.
The jump drive activation delay is the timer you get once you have jumped. It’s the time you have to wait till the next jump can be made.

The equation for this is below.

http://i.imgur.com/EQpv4Cv.png

The principal of what happens here is that your delay timer gets bigger with each jump. The increment between each subsequent timer gets smaller, causing the graph to plateau out into a logarithmic curve. Eventually after so many jumps the delay timer will reach the same value as the jump drive timer, at which point it’s better with it out entirely and then start the process over.

Initially we found a problem with the function where doing three really short distance jumps would make the times later overall shorter but that has been fixed with the “Jump Amount Modifier.”

So e.g.
Jump 1 > 4.19 LY > delay timer of 6.42min > cumulative time 6.42min
Jump 2 > 4.7 LY > delay timer of 9.72 min > cumulative time 16.14min
Jump 3 > 4.206 LY > delay timer of 11.73 min > cumulative time 27.86min
Jump 5 > 4.564 LY > delay timer of 13.28 min > cumulative time 41.14min
Jump 6 > 1.855 LY > delay timer of 14.15 min > cumulative time 55.29min

Notice the increase in time getting smaller but the time overall still get longer. Bit like the diminishing returns of stacking nerf.

This Post and Equation was worked on by Sieonigh and myself.

Edit: We made this formula under the assumption that Jump Freighters and Rorquals do NOT have the 90% reduction, rather we think Black Ops should have this reduction (which we're implementing).



Are you waiting until fatigue hits zero between each jump?
Halenark
Sorry We're In Your Space Eh
Seventh Sanctum.
#4330 - 2014-10-02 21:49:38 UTC
TimeDrawsNigh wrote:
Counter proposal for the jump delay timer.

Link below is a google excel doc. of cumulative delay timer that incrementally gets longer with each jump.

http://bit.ly/1rOpzTs

It’s a logarithmic scale.

So when you jump you get two timers.

First timer is the jump drive timer; the second timer is jump drive activation delay.

The jump drive timer is a base 30 minutes and every time you make a jump it will record the amount and add +1 to the "Jumps Made Since Timer Began" value. The jump drive timer will reset back to 30 min every time you make a new jump.
The jump drive activation delay is the timer you get once you have jumped. It’s the time you have to wait till the next jump can be made.

The equation for this is below.

http://i.imgur.com/EQpv4Cv.png

The principal of what happens here is that your delay timer gets bigger with each jump. The increment between each subsequent timer gets smaller, causing the graph to plateau out into a logarithmic curve. Eventually after so many jumps the delay timer will reach the same value as the jump drive timer, at which point it’s better with it out entirely and then start the process over.

Initially we found a problem with the function where doing three really short distance jumps would make the times later overall shorter but that has been fixed with the “Jump Amount Modifier.”

So e.g.
Jump 1 > 4.19 LY > delay timer of 6.42min > cumulative time 6.42min
Jump 2 > 4.7 LY > delay timer of 9.72 min > cumulative time 16.14min
Jump 3 > 4.206 LY > delay timer of 11.73 min > cumulative time 27.86min
Jump 5 > 4.564 LY > delay timer of 13.28 min > cumulative time 41.14min
Jump 6 > 1.855 LY > delay timer of 14.15 min > cumulative time 55.29min

Notice the increase in time getting smaller but the time overall still get longer. Bit like the diminishing returns of stacking nerf.

This Post and Equation was worked on by Sieonigh and myself.

Edit: We made this formula under the assumption that Jump Freighters and Rorquals do NOT have the 90% reduction, rather we think Black Ops should have this reduction (which we're implementing).
Sentenced 1989
#4331 - 2014-10-02 21:49:57 UTC
https://forums.eveonline.com/default.aspx?g=posts&m=5078831#post5078831

Get rid of your capital today so you don't have to worry about new changes

The Incursion Guild

Epic Arc Guide
KIller Wabbit
MEME Thoughts
#4332 - 2014-10-02 21:50:24 UTC
Grant Sirus wrote:
Isha Subula wrote:
baltec1 wrote:
Ninteen Seventy-Nine wrote:


Maybe in your eyes.

But then again, you're wrong about basically everything, always.


Feel free to ask red frog what they think of this change.



Yes Red Frog pretty much looking at packing it in. Just to hard to keep a service like that up. But, was the service ever really a good thing? Being able to get 500 Caracals delivered to deep null in 20 min with fits from jita? Was just to easy before.

These services will still exist just be way more expensive. I think this has a indirect impact on the isk printer that is ishtar ratting in null. The influx of isk has devalued everything. Just check PLEX prices. Too easy to get 1 bill with 3 accounts afktaring all day.



Plex prices will drop because no one is buying them.


Well not for a while. People will be buying a few to put in accounts they are mothballing so they can jump start the account if something interesting finally happens. Even more will be bought as inflation hedge for those feeling they really aren't going to be back for a long time.
Sheeana Harb
Deep Core Mining Inc.
Caldari State
#4333 - 2014-10-02 21:50:51 UTC  |  Edited by: Sheeana Harb
Kun'ii Zenya wrote:

Nobody has shown that the proposal will prevent entities from defending their space.

These constraints apply to EVERYONE who wants to use a capital....defenders AND ATTACKERS.

Attakers will likely have farther to travel. Unless they deploy nearby (and thus advertise their intent and give the defenders time to deploy/shift assets) they'll likely suffer even greater fatigue.


If the attackers want to live/use the space, why do they have to travel farther? As you said, they simply deploy as close as possible and attack systems they want. Your example assumes only one attacker. That most likely won't be the case. And defender won't be able to effectively move capitals around to respond to everything.

And mind you, we haven't seen the whole picture (SOV changes) yet. Maybe capital ships won't even be needed for a successful assault.


Kun'ii Zenya wrote:

Christ, can't believe I had to explain such an obvious problem with this in terms of breaking up the current power blocks.Roll

Oh I'm sorry.
Komi Toran
Perkone
Caldari State
#4334 - 2014-10-02 21:51:21 UTC
Roman Lynch wrote:
I think that is kinda the point.
And if you are going to use the gates... why not do it in a Charon and NOT a Rhea?

Because you still have 20 jumps to go through Null/Low? Even waiting, using a JF is going to be both safer and faster than using a normal freighter.
Arrendis
TK Corp
#4335 - 2014-10-02 21:51:28 UTC
McBorsk wrote:
218 pages? Calm down, people.


No no, 300 pages by midnight!
Sizeof Void
Ninja Suicide Squadron
#4336 - 2014-10-02 21:52:51 UTC
I'd like to hear what CCP Greyscale thinks of the "Pony Express" system, which some players have been kicking around, as a counter to the "jump fatigue" feature.

I'm not certain what the SP reqs are for training an alt to fly a cap these days, but the toons which are being used to just "shuttle" the caps into position for the combat toons would only need to be able to fly the ship, not necessarily fight with it.

So, if you setup a series of alts as relays, it should still be possible to move caps around fairly quickly, esp. since they will be able to use gates, as well.

Gotta love the sandbox....
Sieonigh
Sebiestor Tribe
Minmatar Republic
#4337 - 2014-10-02 21:53:10 UTC
Endo Saissore wrote:
TimeDrawsNigh wrote:
Counter proposal for the jump delay timer.

Link below is a google excel doc. of cumulative delay timer that incrementally gets longer with each jump.

http://bit.ly/1rOpzTs

It’s a logarithmic scale.

So when you jump you get two timers.

First timer is the jump drive timer; the second timer is jump drive activation delay.

The jump drive timer is a base 30 minutes and every time you make a jump it will record the amount and add +1 to the "Jumps Made Since Timer Began" value. The jump drive timer will reset back to 30 min every time you make a new jump.
The jump drive activation delay is the timer you get once you have jumped. It’s the time you have to wait till the next jump can be made.

The equation for this is below.

http://i.imgur.com/EQpv4Cv.png

The principal of what happens here is that your delay timer gets bigger with each jump. The increment between each subsequent timer gets smaller, causing the graph to plateau out into a logarithmic curve. Eventually after so many jumps the delay timer will reach the same value as the jump drive timer, at which point it’s better with it out entirely and then start the process over.

Initially we found a problem with the function where doing three really short distance jumps would make the times later overall shorter but that has been fixed with the “Jump Amount Modifier.”

So e.g.
Jump 1 > 4.19 LY > delay timer of 6.42min > cumulative time 6.42min
Jump 2 > 4.7 LY > delay timer of 9.72 min > cumulative time 16.14min
Jump 3 > 4.206 LY > delay timer of 11.73 min > cumulative time 27.86min
Jump 5 > 4.564 LY > delay timer of 13.28 min > cumulative time 41.14min
Jump 6 > 1.855 LY > delay timer of 14.15 min > cumulative time 55.29min

Notice the increase in time getting smaller but the time overall still get longer. Bit like the diminishing returns of stacking nerf.

This Post and Equation was worked on by Sieonigh and myself.

Edit: We made this formula under the assumption that Jump Freighters and Rorquals do NOT have the 90% reduction, rather we think Black Ops should have this reduction (which we're implementing).



Are you waiting until fatigue hits zero between each jump?


no waiting for the delay between each jump, there is no fetegue in this idea just a bace 30 min timer
Summer Isle
Autumn Industrial Enterprises
#4338 - 2014-10-02 21:53:36 UTC
Polo Marco wrote:

a system with less than 5 active players (docked or in space..avg for 24hrs) and no industry/military/strategic index of at least one should cost ONE THOUSAND TIMES the base for every CONCORD sov bill to be paid.

ACTIVE systems, on the other hand...... with lets say.. over 30 pilots and with ANY index at 4 or higher, would pay the base costs for all facilities.

On something like this (not that I'm agreeing or disagreeing), instead of using arbitrary numbers, you could simply use a sort of inverted form of the industry index: As activity occurs that would generate fees, bounties, or anything else paid out either to or from NPC activity, the cost of a system is decreased (lore-based reason: CONCORD takes its cut to pay for communications systems, etc, so with lower activity, CONCORD needs more ISK from the alliances to cover everything).

 Talk is cheap, but Void S and Quake L are cheaper.
Mc Cormeg
Caldari Provisions
Caldari State
#4339 - 2014-10-02 21:53:38 UTC
Kun'ii Zenya wrote:
Mc Cormeg wrote:
Endo Saissore wrote:

I agree it gimps JFs, but if you wait 15 minutes between jumps then you don't accumulate fatigue. Not the end of the world and the trade off is worth it IMO.

This is assuming that you gain 1.5 fatigue per jump. I would quote me with those numbers. I'm not the best with math.


As i understand you only have to wait 1 minute per ly you had traveled with your last jump because if your current jump fatigue is below 1 and that's the case you want to have, you only gain a fix 1+ly for the next one.



Bzzt wrong.

You jump 1 light year. Your fatigue was 0. After the jump your fatigue is no 2 (1 light year + 1). Fatigue reduces by 0.1/minute. So to reduce fatigue to zero it will take 20 minutes. To reduce it below 1 to avoid the multiplicative effects you have to wait 11 minutes.


If you had jumped 1ly you would gain a fatigue of 1+1ly*0.1 becaus of the JF 10% Bonus. But yea. You are right in respect that you have to wait for (lyrs traveled) in minutes +1 (!!!!) because you whant to reduce your jump fatigue below 1 for the next jump.
Kassasis Dakkstromri
State War Academy
Caldari State
#4340 - 2014-10-02 21:53:41 UTC
RasTrent wrote:
in before plex for fatigue reduction.



Sooooo mudderfugggin' THIS!!


CCP you are bad at EVE... Stop potential silliness ~ Solo Wulf