My proposal is about to be deposited to the credit of the common bank which would be bound to account something like a binding Cartel Coins to your account.

give you an example: I have to figure xyz 2,000,000 credits but for playing the character maintenance, etc. need only 500,000 credits thus increase the credits saved in the bank, and if we need credits to another character so their selection from this bank.

advantages to the player's clarity how much the player has to build credits, scrap forwarding credits from character to character, further less time searching for the right to obtain the necessary amount of financing operations which the player needs since the waste hladanie credits to build

server will probably be less load requirements regarding sending mail

The new service could be activated in Legacy where they bought it

P.S .: Sorry for my English, it's not my native language

My proposal is about to be deposited to the credit of the common bank which would be bound to account something like a binding Cartel Coins to your account.

 

give you an example: I have to figure xyz 2,000,000 credits but for playing the character maintenance, etc. need only 500,000 credits thus increase the credits saved in the bank, and if we need credits to another character so their selection from this bank.

 

advantages to the player's clarity how much the player has to build credits, scrap forwarding credits from character to character, further less time searching for the right to obtain the necessary amount of financing operations which the player needs since the waste hladanie credits to build

server will probably be less load requirements regarding sending mail

 

The new service could be activated in Legacy where they bought it

 

P.S .: Sorry for my English, it's not my native language

If only there were a forum search tool, and people were not too lazy to actually use it.

A legacy credit storage has been brought up may times before, even before the legacy storage was implemented. BW stated even before legacy storage was implemented that they would NOT be enabling a legacy credit storage. IIRC, they did not give a "reason", just the statement that credits would NOT be able to be deposited into the legacy storage.

I can only guess, but I'm guessing it has to do with the credit restrictions that apply to F2P and preferred.

To date, NO ONE has been able to suggest a way to implement legacy credit storage that maintains ANY AND ALL credit restrictions that apply to F2P and preferred, while also NOT holding any credits in legacy storage hostage should a player drop from subscriber to preferred.

pity that it can not solve, but I have forgot to add that that bank credit would apply the same rules as the Credit Bank on the figure only a little, I would moreover limit for F2P and preferred as it would were a credit bank account

Once again, please provide a suggestion as to how to implement a legacy credit storage in such a way as to maintain ANY AND ALL credit restrictions which apply to F2P and preferred, while not holding hostage any credits in legacy storage should a subscriber drop to preferred for any reason.

Don;t get me wrong. I am not opposed to a legacy credit storage PROVIDED it can be implemented in such a way as to maintain ANY AND ALL credit restrictions which apply to F2P and preferred, while not holding hostage any credits in legacy storage should a subscriber drop to preferred for any reason.

As it stands the current mail system DOES maintain ANY AND ALL credit restrictions which apply to F2P and preferred, while not holding hostage any credits in legacy storage should a subscriber drop to preferred for any reason.

Once again, please provide a suggestion as to how to implement a legacy credit storage in such a way as to maintain ANY AND ALL credit restrictions which apply to F2P and preferred, while not holding hostage any credits in legacy storage should a subscriber drop to preferred for any reason.

 

Don;t get me wrong. I am not opposed to a legacy credit storage PROVIDED it can be implemented in such a way as to maintain ANY AND ALL credit restrictions which apply to F2P and preferred, while not holding hostage any credits in legacy storage should a subscriber drop to preferred for any reason.

 

As it stands the current mail system DOES maintain ANY AND ALL credit restrictions which apply to F2P and preferred, while not holding hostage any credits in legacy storage should a subscriber drop to preferred for any reason.

Loosen your definition of "transferring credits" so that "put money in shared storage from character A, end subscription, remove money to character B" is NOT a transfer, and it is easy. (And of course if you send mail from A, end your subscription, then collect the mail on character B, that, too, should be considered a transfer by your definition, except that you do some sort of handwaving to call that not a transfer because somehow the money is transferred at the moment of sending, even though the other character doesn't have it yet - and might never have it if you let the mail just sit there until it is sent back.)

For reference, with that particular thing removed from the definition of "transfer":

* Only subscribers can put money in.

* Subscribers can freely take money out.

* Ex-subscribers can take money out, but will be subject to their normal credit cap.

Loosen your definition of "transferring credits" so that "put money in shared storage from character A, end subscription, remove money to character B" is NOT a transfer, and it is easy. (And of course if you send mail from A, end your subscription, then collect the mail on character B, that, too, should be considered a transfer by your definition, except that you do some sort of handwaving to call that not a transfer because somehow the money is transferred at the moment of sending, even though the other character doesn't have it yet - and might never have it if you let the mail just sit there until it is sent back.)

 

For reference, with that particular thing removed from the definition of "transfer":

* Only subscribers can put money in.

* Subscribers can freely take money out.

* Ex-subscribers can take money out, but will be subject to their normal credit cap.

What is, IS. People can wish otherwise, but wishes do not make reality.

Loosening the definition of transferring credits so that it meets what those who wish to have legacy storage wish the definition were would be like loosening the definition of a rose so that it meets what those who wish their dandelions were actually roses wish the definition of a rose is.

BW made the decision not to implement a legacy credit storage, not me. I am simply putting forth my theory as to why they made the decision they made.

Unless I am mistaken, you, yourself, freely admit that without "loosening the definition of transferring credits", it is impossible to implement legacy storage in such a manner as to maintain ANY AND ALL credit restrictions that apply to F2P and preferred while not holding hostage any credits in legacy storage should a subscriber drop from subscriber to preferred.

It sounds to me like some people freely admit the impossibility of implementing a legacy storage system in such a manner as to maintain ANY AND ALL credit restrictions that apply to F2P and preferred while not holding hostage any credits in legacy storage should a subscriber drop from subscriber to preferred, so they want to "loosen (read CHANGE) the definition" of transferring credits.

It sounds to me like some people freely admit the impossibility of implementing a legacy storage system in such a manner as to maintain ANY AND ALL credit restrictions that apply to F2P and preferred while not holding hostage any credits in legacy storage should a subscriber drop from subscriber to preferred, so they want to "loosen (read CHANGE) the definition" of transferring credits.

It occurs to me, now that I'm thinking some more about this, that character-to-character transfers are a red herring.

No, the more serious point is that it would be equivalent to creating a freely-tappable pool of credits beyond the current credit cap for ex-subscribers. That is, if we imagine for a moment that I have only one character:

* Oh, look, I can't afford to renew for some reason. I'll stuff all my over-cap credits in the bank, leaving my character at 350K with 20,000,000 in the bank.

* Now I'm preferred. Any time I need credits, I'll tap the bank. I won't ever take enough to go over-cap, but I will be able to access all those millions and millions of credits without buying escrow transfers.

* Sure, to buy over-cap things I'll still need escrow tokens, but merely to access the credits I don't.

So there you are. A convincing (well, I'm convinced, anyway) argument for *not* implementing a legacy bank that doesn't invoke the contentious and red-herringish point of exactly how you define transfers. It *isn't* about a weird border case of (or not of, depending on your definition) transferring credits. It's about having access to a pool of credits that today are locked behind the escrow wall, but wouldn't be (unless you require a "legacy bank withdrawal token", but that would be "holding the credits hostage", I guess) if they introduced this feature.

The key point is: I was already against implementing it, but didn't have a clearly articulatable and *good* reason until just now. Saying that "well, you can already just mail credits around so you don't need this" isn't good enough. People are looking for an increase in convenience, and you have to explain why the change does bad things whose badness outweighs the benefits. The "interesting" bad thing is the credit pool, but not because it allows a form of character-to-character transfer. No, it is because the pool allows a way to access, at a below-cap level, credits that would otherwise be locked behind the paywall called "escrow transfers". I presume that requiring a mechanism like an escrow transfer would also be considered "holding the credits hostage".

Can we agree that what I propose above is, by itself, a convincing argument for not implementing a legacy bank?