Is Station container is "Planck" container?

Case is when I trying to jettison a station container from the ship - there’s no such option. But there’s “Lauch for self”…
When I trying to do it it telling me “it cannot be moved to space”, meaning, as I got - it can’t be expanded in a space…
Ok. Then I just jettison something else to the space creating a cargo container, with cargo amount of 27500mc, but when I trying to move a packaged station container to the cargo container it just says “Planck container can’t be moved inside another planck container as…” . But why?
Station container has a volume of 2Mmc. and d cargo volume of about 1Mmc. It’s not planck at all as I got what is “planck container” in the game (meaning it “squeeze” a space inside it making, for example 100mc volume container a container with 120mc cargo hold).

So, Is station container a planck container and if not - why it (packaged) can’t be moved to another container that have appropriate (more then 10kmc) cargo hold?

Containers cannot be nested, period. It doesn’t matter which type of container it is - any non-ship object capable of holding other objects cannot be placed into another non-ship object capable of holding other objects.

This includes MTUs - they cannot be placed into containers, even when repackaged.

1 Like

First: You are not right. Courier package(s) inside a double-wrapped courier package is exactly ‘double-nested’ ‘non-ship object capable of holding other objects.’ that you telling about is ‘not possible in the game, “period”’.
Second: That doesn’t have a sense.
If packaged ship can fit to ship cargo hold. Then why (similar) packaged container (NON PLANCK! where no physics awareness exists) can’t fit to other container?

And if that’s so much a problem - why can’t I “lauch as self” a station container to a space? And why then it “fits” into a hangar container (it’s the same as nested ‘non-ship object capable of holding other objects.’)? And not ‘throwing away’ while POS destruction “as is” and not as nested into hangar container?

You’re right that courier packages can break this rule, via the unique mechanics involved in plastic wrap. However, those aren’t containers in the normal sense - you cannot create plastic wrap outside of the courier contract process, or add items to a plastic wrap package - so I wasn’t counting that as a container object.

Edit to respond to your edit:
A lot of things in EVE aren’t based around what makes sense from a real-world perspective, only what makes sense within the restrictions of the game. Nesting containers is something CCP decided they don’t want in the game, so we don’t get to put containers inside each other, even if they would fit. Similarly, barring the Plastic Wrap process from a courier contract, an assembled ship isn’t able to be carried outside of a ship bay, or stored in a container, even if the ship is small enough to fit - because CCP wants to restrict gameplay in that fashion.

As for the’Launch for Self’ on your container, do you have anchoring skill trained? If not, you cannot deploy a container in space - jetcanning is entirely separate from deploying.

1 Like

I see, but I think that’s not right.
Case is while numerous stations become “abandoned” and for a while - destroyed - there are numerouns hangar containers in space exists that contains only that station/freighter/etc… containers that can not be “fitted into” standard container (27,5k) - where everyones take all items from hangar containers to faster become non-suspected and get it away from already owned by them standard containers… Number of such hangar containers containing only other containers that cannot be fitted inside standard containers (besides it have much more less space while packaged and not being planck containers as no squeeze a space inside it) is huge… and every system become littered with hangar containers expire time of which is unknown but believed to be not less then 30 days and number of which is doubled number of ships in the solar system that make overall game behaviour little dizzy… If’d mechanics would be changed (about such containers possibility to get inside other containers) there’d be no such number of hangar contaners anymore as capsuleers could first just move such containers to ‘thir owned’ containers. and then - after suspeted status 15 min expired to take it to the stations and sell… Instead of (as I said) littering a space…

Hangar containers from destruction of a station are, like Plastic Wrap, unique objects that players cannot create. Same goes for wrecks. These items aren’t containers you can buy or manufacture or use for yourself.

Ok! Let them (CCP) then to make some… story - about why they are planck… and cannot be fitted inside other ones…
Or to be fair - let them to restrict double-wrap courier packages (that will be funny for haulers I think $)))
But as game is a fantasy… It have to have a logic in its behaviour that fits some storyline… and not just “we don’t want - we will restrict”)…
imho for sure…
Lauhch for self - it just says: ‘station container can’t be launched into space’. Anchoring is not the case… that case.

So then… numerous hangar containers containing only other station/hauler/etc… containers are still littering a space with legion of it… Why?

And game is stuck with that strange ‘containers logic’

Oh, duh, you said station container. Key there is station. They cannot be launched in space - they are for use inside stations only.

IIRC, if courier package contains has a container inside it - it cant be double-wrapped.

i know… but that was just example to let you understand anchoring is not the case.
Case is WHY if I can move packaged station container from hangar container to the ship cargohold I cannot move same packaged (not ‘as self’) station container to the space (same as moving it from hangar container to ordinary standard space container with 27,5k carohold) as it packaged. and it’s not planck?.. And while container is paclaged it’s just some raw thing that have not to have any attributes except it’s current volume (as no any ‘generator’ even if it would be there is ‘not online’ and can’t affect anything).

Hmm… Never tried ) Cute. ) But case is it’s break the rule because double-wrapped courier package is already a double-nested object.

‘Why’ is because that’s how CCP coded the game - they elected to not have nested containers. That’s the reality we have to live with.

If you are trying to craft a suggestion to change this, I recommend cleaning up your first post to outline the issues itself, without all the circumstantial stuff about ‘here is how I discovered this behavior’, and provide a use case for the change. Declare the problem/impediment to play you want this change to address, what change you want to see, and how that change will address the problem/impediment.

1 Like

on contrary - it enforces the rule of no allowing multi-nested containers beyond 1 + a wrap. Afaik it is done that way so players cant avoid cargo scanners and for (evil) players to not break kill mails with infinitely nested stuff. To prevent further abuse - each container has a limit of 600 items with unique IDs (600 “slots”)…

Good idea.
And post where?

You are in the right place, just not really structured as a feature/change request at present. Your original post currently reads like a request for information, not a request for a change in game mechanics.

Woow!
You’r storehouse of knowledge ) DId you check it yourself (600 slots)?
I still don’t see any problem in nested containers (if that’s not planck - with “squeezed space” inside) because there’s no any possibility to set (take 2 it’s cargohold) there more volume then highest-in-nest container’s volume. Maybe just (for not allowing infininite nest) developers have to add some 0,01m (or some 1% from overall container volume) additional volume to any container if it have been put inside other container…
For example - if there’s 2 standard (with no squeezed space inside) containers both 30000 m.c. unpackaged volume they won’t fit inside each other because if it will be fitted inside other container it will add to it’s volume that 0,01 m.c. and will have 30000,01 m.c. that won’t fit (inside) same cargo volume container. BUT! If it’s packaged (for example having 300 m.c. packaged volume) it (and more 98 of it) obviously HAVE TO FIT inside same unpackaged one counting:

(300 m.c. + 0,01 m.c.)*(1+98)=29700,99 m.c. that obviously fits to 30000 m.c. (unpackaged container cargohold) container.

I don’t see any problem doing it as PACKAGED container IS JUST AN ITEM and NOT CONTAINER (it can’t have anything inside as it already packaged) as it known in the game.

But somewhy packaged container (that’s just like some wrecks) have been perceived by the game as NOT item but as some nest-possible object besides it’s not at all (repeat - packaged NOT-PLANCK container have not to have any limits about placing it inside other - assembled - container, because it’s ORDINARY ITEM OBJECT).

Is it good enough?

I remember that i wasnt able to create a courier contract with more than 600 items without using a container for some of them several years ago. IT might be contract limitation and not a container one.

Logically, it seems as if it easy to do. But then it comes down to having to alter 17-years-old spaghetti code and the way server deals with items. Introducing a change for the sake of change is bound to create a ton of problems along the way (dont fix something that aint broken).

That’s why after product has being released it’s good time to start optimizing a code (sure it’s good @beta stage already but… if not… at least after release) )))
And fixing a code errors what (i want to believe) CCP do right now hardly and not just ‘sucks in’ their spaghetti [code] and feast it others with just spicing it with some graphics.

Still can’t see a problem to make packaged containers a ‘just an item object’ (and not nested-one) making them possible to place it inside another (nested one object) container, because it literally (different image, different name, why not different attributes and category? for example: ‘packaged containers’) totally other object then nested-object itself…

Packaged items dont have any attribute other than item ID and quantity. The whole stack of them has a unique ID in database (that can be changed if you split stack several times and stack it back together in different order). I assume that limitations inside containers work with itemIDs and server doesnt differentiate between packaged and assembled containers.

In theory it should be possible to specifically re-check restricted IDs whether they are assembled or not. It may be possible explain the situation about packaged containers to devs and file it as bug report. As for assembled containers - i think they are fine as they are now.