26 Reply by Yojimbo

(34 replies, posted in Feature discussion and requests)

Stranger Danger wrote:

you really "get use" to the travel times in game.

also with autopilot now working, and all of alpha 100% safe, autopiloting to terminal (use interact to auto dock) is more or less like a hearthstone with a charge time based on how far you are from terminal. Make use of autopilot.  ...

With respect, I think you just proved my point.  Any time I hear someone say "you'll get used to it" it means that many, if not all people, dislike the feature but must learn to live with it in lieu of a better solution.  Nor has a valid reason of game mechanics/balancing been cited as justification for NOT teleporting to terminals.

I do use autopilot, extensively.  Instead of spending time droning on autopilot, we could be engaged in activities that are far more fun.  Currently, while autopiloting I can:
- do sets with weights
- practice a musical instrument
- trim nose hairs
- study lunar geography

My point is that if I am logged in to the game, I want to actually play the game.  Anything, like teleporting to terminals, that would eliminate the wasted time/droning, would be a very good thing.

Go to forum: Feature discussion and requests

27 Reply by Yojimbo

(13 replies, posted in Feature discussion and requests)

I agree with the OP and want to reinforce what Ville has posted as well as others. 

I have returned after a long hiatus and I find the client is now far more resource hungry.  It's okay with two clients running but sends my upgraded P/S into hyper drive constantly.  Three clients are no longer possible.

I like to run a miner just sitting there extracting, then harvest with my Symbiont guy while my combat guy autopilots to assignment locations.  So really, I only need/want high end graphics during combat for the pew pew visuals.  It would be nice to be able to tone down client resource needs for the non combat toons.

UPDATE :: I did some empirical testing by comparing P/S temp (work) with graphics "as is" (maxxed) versus all graphics to min values except draw distance - I got about 25% reduction in average P/S temp with spikes consistently present when leaving terminals, teleporting, i.e., when ever mass changes to data or graphics ensue.

Now, my graphics card and P/S were high end upgrades two years ago.  I'm thinking the real answer is to upgrade my whole system.  Since I can't do that right now ($$$ issues) I guess I'll have to live with wimpier graphics.

Go to forum: Feature discussion and requests

28 Topic by Yojimbo

(34 replies, posted in Feature discussion and requests)

I'm sure this topic has come up before.  I am equally sure that there would have been debate on both sides.  And I'm puzzled why such an obviously useful feature is not implemented.  Most games have the equivalent of a Hearthstone, well, EvE's Hearthstone is only activated upon death...

Advantages that I see may not represent the bigger picture:
1) we can turn assignments around more efficiently, rather than slogging slowly to and from from the assignments dots and the terminal.
2) It speeds up game play and solves the issue of boring slow trudging around convoluted maps.

For example, I wrote half this note while auto piloting to an assignment location.  I ran the assignment, then finished this note while auto-trudging back to the terminal.  Now, wouldn't it be more fun to have spent that time actually engaged in the game?  I mean, I spend far more time getting to and from the action, compared to being in the action itself ...

So why can we not teleport directly to terminals or at least 500m away?  At least on Alphas?  Restrictions could be set on Betas and on Gammas when they come back.  Or why are the terminals NOT part of the teleporter system to begin with, as in a "central node" ?

I'm just trying to understand why this limitation exists and why we must trudge all over the map wasting a lot of time that could be spent in the action, rather than meandering to and from the action.

Enlighten me please as I'm sure there is a reason other than "because the Devs say so."

Thanks and I appreciate your comments.

Go to forum: Feature discussion and requests

29 Reply by Yojimbo

(36 replies, posted in General discussion)

I would vote for the ability to re-assign EP for each individual skill at the cost of NIC.  The way account resets are now is for the birds IMHO.  As many have said previously, we should be afforded this flexibility for many valid reasons, shifting between PvP and PvE builds is one obvious example. 

For those worried about role play factors like a persistent world, guess what?  Our avatars are robots.  Any robot I know of is reprogrammable within the limits of hardware.  Re-assigning EP is in keeping with the nature of our robots-on-an-alien-world game, if you really think about it.

The Dev Team can make alterations painfully expensive as a disincentive.  For example, each point "bought back" would cost the initial NIC value - so if initial cost=125K and you want to buy back 3 points, it would cost you 375K.  ---OR---  The higher the point's value, the more it costs to buy back, so buying a level 3 point costs less than a level 6 point.  This would make complete alterations impractical if not impossible, but fixing a mistake would only be painfully affordable.  And for the hard core players who feel regular respecs are a necessity for max performance in every Field Op, let 'em grind the NIC and have fun.

Go to forum: General discussion

30 Reply by Yojimbo

(82 replies, posted in News and information)

Alfredson wrote:

why not just reset everyone's ep, and make all accounts follow the new character features. minimize lots of headache tbh

This is what WoW does whenever they revamp things, although usually on a class by class basis following "balance adjustments".  I think it is a really good part of the revamp plan that allows players to take full advantage of new changes. The clueless will remain clueless, but the savvy player can optimize skills to match changes.  If players want additional alterations beyond the freebies, then they can pay NIC/EP as outlined.

Go to forum: News and information

31 Reply by Yojimbo

(4 replies, posted in Resolved bugs and features)

Norrdec wrote:

We can only hope that this will be fixed when the cans are going to be persistant and an SQL object, not a thing that sits in the memory (I am still not sure how this works atm, but I am pretty sure is more a hack in the code than something real big_smile )

A fix ould be appreciated.  As it is,  they either need to make cans 0 (zero) size when being transported, so you can haul spare cans with no cargo space penalty (as a workaround), or maybe they should just fix the bug.

Go to forum: Resolved bugs and features

32 Topic by Yojimbo

(4 replies, posted in Resolved bugs and features)

I deployed a field can today, entered the password when prompted, then the can simply disappeared.  Yes, I have my filters set to view containers.  The guys in Help chat said it was a bug.  So is this really a bug?  Anyone else experiencing this ?  Is this just a fluke that should not / will not happen again ?

Whether or nor this is a bug, it is rather annoying.  Field cans are supposed to allow you to gather large amounts a stuff far from a terminal.  If you drive out miles from nowhere, then the can disappears, your operations are essentially scuttled at that point.  Not fun.  Not efficient.  Nor is it feasible to take a spare can in case the first one vaporizes...

Go to forum: Resolved bugs and features