The purpose of the EVE Online forums is to provide a platform for exchange of ideas, and a venue for the discussion of EVE Online. Occasionally there will be conflicts that arise when people voice opinions. Forum users are expected to courteous when disagreeing with others.
In order to maintain an environment where everyone is welcome and discussion flows freely, certain types of conduct are prohibited on the EVE Online forums. These are:
Sry, don’t believe that for a second. There is absolutely no evidence that this feature would create any significant serverload, because the steps done are exactly the same as if the user had done it manually and they do not need to be synced with anyone else.
So,
Why does TiDi exist?
How does TiDi work?
Why is Jita on its own server node all by itself?
Why does an item have to be packaged to be on the market?
Why can dozens of systems in different areas be affected by TiDi all at once from 1 single battle in 1 system somewhere in game?
I’m reading this thread wondering why it’s seemingly too much effort to select all your containers, right click and select “invert selection”, then right click the new selection and click repack before you start organizing. Why does CCP need to do this for you?
Can someone answer that?
That’s before we get into the hardware issues of checking every item to see if it meets the qualifications to repack every time every item is put into every container in every station on the server. But of course they’re right when they say all those process calls won’t slow the server down, and we’re the trolls who can’t understand how awesome this idea would be.
Not going to play your questionspamming games, what you do is simply doom-mongering. There is absolutely no reason why the server should suddenly break under additional workload (where exactly should that come from?), because there simply aren’t more operations to proceed compared to a manual “select all, rightclick, repackage, stack, move to container”. Even the stuff you do manually is still processed by the server.
This suggestion is a prime example of an easy and useful QoL option that can even easily be tested on Sisi by CCP to make sure it doesn’t cause performance issues (which I bet any sum it won’t). And then they can decide if and how they want to implement it, for all hangars or only for certain containers.
Yes there is. It’s called limitation of resources. There’s a limit to the number of calculations per second a computer is capable of, and a point at which increasing those resources provides a reduced return on the investment.
Yes, but at the moment it’s only processed by the server when requested of it. Not every single f*cking time someone moves something into a container.
No, this suggestion is a prime example of the laziness of the current generation of gamers. Five f*cking clicks is not a QOL improvement. Developing better organizational habits on your own is a QOL improvement.
Your argument is really stupid because (if TiDi can be really caused by the actions you specified) players can already do it without this feature. If the feature is implemented then the only thing that changes is that they can do it slightly faster, that is all.
If you are against this for some reason and want to shut it down, find a better counter argument than this.
container variations seem unnecessary, why not just have one kind of container of various sizes that have all the features of current cans? including the ability to auto pack and stack! I also really dislike that I cant repack a audit log can that has a log within the last 30 days.
It’s just an option to “test” if the feature would cause any trouble if many people use it. If it works fine, a general option for hangars/containers to auto-stack or auto-repackage+stack would of course be better. But with such a large and intervoven database system, I’d be rather careful and go in small steps.
Another way to implement the idea step-by-step would be to begin with an option to auto-stack items that have no “assembled” state anyway, like blueloot, redloot, salvage parts, minerals, ores etc… If that works fine and causes no issues, the rest can be included as well.
Not only that. Currently everytime someone wants to “clean up” a container or hangar, he will move hundreds of item stacks out of it, repackage these hundreds of items in their main hangar, stacks these items in their main hangar and then move those hundreds of stacks back to the container. This floods the server with a high burst of hundreds of database changes within a small timeframe. This entire action would be completely unnessessary if a container or hangaer stays “clean” all the time because everytime an item is put into it, it is just auto-stacked. The database queries would be the same in amount, but over a MUCH larger timespan, because they would simply “tickle in” one item by one item whenver one is added to the container. For a server, this kind of “load” is FAR easier to handle and for the users it is much less noticable then having peak loads from burst-queries every now and then. Additionally, the system would simply free memory, since a container with 243 different assembled items requires more database entries than a container with 92 stacks of items, because not only the number of items to “save” is lower, stacks also have a lot less attributes than assembled items. It’s a clear win-win situation if implemented properly.
And again, it is absolutely no problem to auto-disable the feature anytime the server is coming under high stress from any kind of space-battle, so it would have simply no effect on the ingame server performance, but increases QoL for many users quite a lot.
