There are a few Blocks like the LCD, motion sensors and the lights that could be transformed to Textures, so i could have a LCD on a Wall and still a chair or teleporter infront/below. Also a special texture could be used to make the modular containern not connect. For example i paint the left side of a container controller in the not connect texture i can put another controller right next to the other one.
We can't collide with textures, they're on a different layer from blocks/ geometry. They are 2 different and unrelated data sets, they are not "gameobjects" we can interact with. The LCD were "supposed" to be replaced by decals at some point because they're heavy on performance while decals are not. You could do almost the same with decals, they can be put anywhere even inside other geometry, and use the control blocks to switch decals/ text/ effects. For lights and other non full blocks items and devices, same as for LCD : we can't interact with non-objects. It's tied to the engine, not the game. One possible solution though might be via the "voxelize" parameter for some blocks, which tells the game to consider all or part of the space occupied by a block, but I didn't see clearly what this does. We can put more than I block inside another object's space under certain circumstances, but we can only interact with 1 object per "space occupied" even if another object is visible. This is because we interact with (invisible) colliders, and they are tied to the "block space" occupied by an object, so another collider can not be placed in the same space.
ok, always the engine limitations... then maybe save the idea for the next empyrion game... I still wonder if different modular containers touching would be possible with some kind of trick like connecting and non-connecting sides and different variants (like 1 connect sides up to all sides connect); Or just select the controller and the next modules connect just to this one. (I hate it to have 50% empty space in my storrage warehouse)
Well I doubt even using another game engine would solve the problem, because textures still need an "object" to be mapped on, which can then be interacted with. We can see them as "visual only " components that can't be "touched" and require an invisible "game object" or any kind of 3d "physical" object which can be used to detect when a player's collision volume intersects with the other volume. Textures have no volume, they are mapped on a volume though, so players interact with the 3d object and not it's color/ texture. BUT... One possible solution would be to give these special interaction attributes to decals, since they are 2-dimensional planes but still have "collision". There are a few missing options from decals to be able to use them as blocks replacements (fake walls/ floors) : they don't make any sound when we walk on them. This requires decals to have the "material" attribute, which then tells the game what footsteps sound/ bullet impact to be used for this "solid". Although decals are flat (no real "volume") they still have a "position/ rotation" like any other game object (its center) so that's what makes then useable, while textures use the block's face they are mapped on as "coordinates" and thus don't have their own 3d space coordinates. Another option that could be used for decals is the collision detection just like the "motion sensor" to be able to send a signal for logic circuits/ scenarios/ dialogues. "Invisible" decals could be used like simple "triggers" like what's used in other game engines, for all kinds of things. Visible decals could be placed anywhere, even intersecting other blocks/ parts of blocks in their space, and be used as switches/ triggers. Then it would be very close to your "function to textures" suggestion, but in fact it's the decal's collider that is used, just a tiny offset from a block's surface so it can intersect with the player's collider, for example to generate a "Use X" prompt/ message to be displayed. Only thing I see related to this "restriction" in the BlocksConfig.ecf is this line which is not seen in other block's parameters : { +Block Id: 1682, Name: ContainerControllerLarge (...) IsDuplicateable: false # keep false to avoid exploits when placing several blocks in a line and connect two or more CCs I did not test it but you may try changing this to "true" and see if you can put several controllers next to each other...
Regarding the container issue (and this could apply to some other devices), why couldn't we selectively attach extensions to controllers like we do linking containers and constructors or fridges with food processors? They don't have to touch or even be in the same room. I realize, at this stage, extensions must be in contact to increase capacity/volume. In the same vein, why not link a specified repair module to a specified console thereby allowing multiple repair modules on a given BA/CV?
I can only speculate. It's a fact that container extensions don't show up in the control panel, they don't have "individual identifiers" like other regular devices (ex. container1, container1(1), container1(2) for 3 "container1" units). The container controller/ extensions were made long after the initial fridge/ constructors/ regular containers, and were supposedly part of the wider "automation" and "logistics" scheme, which some players asked for with various degrees of "realism" regarding requirements. I remember some players arguing that all machines/ weapons in a vessel or base should have "connectors" because matter/ energy (fuel, ammo, etc) needed physical travel routes, while other players argued that it was not required in a game, it would just make things unnecessarily complicated, etc. I speculate that the devs just cut the piece in the middle to try to satisfy both groups. But by making container extensions as structural blocks, it can save on computing power and avoid device cluttering in the control panel, since we can put a whole lot of extensions as parts of a ship's hull if we want. So by making extensions the way they are, they just require a check to see if there is contact with a controller at any point along the chain of extensions (if many), on any of the 6 faces (no diagonals or corners) and then it only adds 8k to the total volume capacity of the controller. This requires less memory space than having each individual extension as a unique device. This also means that all cargo is "shared" so if one extension is lost and there is still enough storage, no need to keep individual cargo lists for each extension like it is needed for regular containers. That's surely possible, but I have no clue on this one. I suspect that there could be problems if a ship is in range of several repair bays, for example, and there needs to be a mechanism to prevent players from starting 2 simultaneous repair jobs on 1 same ship, but honestly I can't say. Sometimes simple additions to features look easy to do, and somewhere down the road it becomes clear that many problems were not expected and will generate lots more work on the feature than what was previously planned. It's a bit like the dock everything-to-everything feature : it was not made for this initially, and was more complex to achieve because it was not originally designed like this.
the thing with adding functions to surfaces could still work, but maybe not in this engine: just add dummy interfaces to each surface and a function to one of the interfaces with an tool. linkting containers to container controllers manually and not by contact could really help in building some structures where you always have to have different blocks as dividers I'd imagine having just a reference to the controller in each extender would not be too much overhead, and the contact check would just check if there is a path thru containers with the same tag.
Generally speaking, this sounds like hell to code... ^^ At that point, why not simply use the regular containers ? They don't require a controller, the game already supports them, and they all can be identified. What's the point of recreating "individual containers" with extenders ? Remember we can mod values, so obviously if there's any problem regarding regular containers that can only be "solved" because (for example) extenders can be "textured" then first question is why do we need so much storage, and why not simply mod the regular containers to contain more and then just use regular blocks for structures. This game already has too much "overhead" and when looking at various proposals that all rely on adding a little bit here and a little bit there makes a whole lot of "little bits" in the end...
Well, about the containers I play with volume active and already filled some (a lot) 320k container controlers, so having more of those in the same space is better. and the coding I dont know if it really is so hard if done object oriented, but I might be too optimistig there.
It's not a question of difficulty as much as a question of quantity : having each extender to represent a simple + or - 8k storage capacity to a controller is far less demanding than assigning a string variable to each and keeping track of these at all times, just for us to be able to link them manually to a specific controller. To better illustrate this, imagin how easy it could be to have each structural block have a string identifier : they already have a unique position relative to the core inside the "voxel grid", so the code can simply use that to match the string variable with. They also have individual shapes, so they are clearly "individually" indexed in some way. But what would be the performance impact to track string variables for each structural block ? So here it's not the coding that is difficult, it's the "benefits vs penalty" regarding "gameplay addition vs performance cost".
