I'd like to see more realistic doors, the armored ones look good but with the forcefield, it doesn't make sense, I'd really like for the forcefield to be revamped for a more plasma/ion/static animation-like look, is this a possibility?
We changed doors to all be automatic on BA/CV, so removing the manual doors, which are possible using a dummy signal to force a "latch" a door so that it works like manual door again...... and recently also notice that doors ALL (with the exception hilariously of the vertically opening doors) have a forcefield, which kinda screws with screenshots. Was this all intentional, and can someone clue us in on the internals to be able to turn the forcefield animation off?
The "forcefield" effect can't be removed, as far as I know, unless the base/ ship power is turned off. There are some doors without the forcefield effect (airtight : false), if this is important for "screenshots"...
I am tempted to just edit my config to IsOxygenTight: false, display: true But that does not have the desired effect anyway , it still shows the force-field. And more interresting, airtight doors are not "GREEN" when using the airtight block debug menu, so that's a bug?
Yup. I tried the config file trick too and it has no "visual" effect, but I did not test if the block kept or lost its "airtight" property. If "airtight" is changed to "false" and the block does not show green in the 02 debug mode, then it means the config works, and that the "field" is part of the door model / unrelated to the "airtight" function, and can't be changed with a true/ false. It's a bit like the grav gen and generators that have a rotating part animation that is triggered with the structure power on/off : strictly cosmetic. Would be funny though to be able to crank the power in/ out of a generator and see it spin like a turbine with a high-pitch sound, just before it blows up...
Would just love if one of the modders could see this question and help us all out a bit more. So often I ask about ecf file formats, and I get given the explanation intended for 8 year old kids. Too few people know how this works well enough to really grow the modding ecosystem. We just want more worked-through examples. I don't think we want a Skyrim modding community, but would like to get thrown a bit more info.
The "modders" would not be able to do more, unfortunately. What we have in the configs are simple switches or values, that point to internal functions. We can not change these functions, just like we can not change models or textures, because these are compressed in archives. To access them would require to use "hacking methods" or many trials and errors in Unity, for example, because we don't know how the archives were made. So this equates to reverse-engineering and is (most probably) prohibited by the EULA. And just a word about "modders", since many players don't seem to make a distinction between "modding" and making "config modifications" : "modding" requires using the modding API, it is like building external scripts that interact with the game's internal functions, and "mods" operate in real-time during gameplay. Modifying config files is simply adjusting "flavors" of some game objects prior to launching the game, and has nothing to do with "scripting" or "coding". Config modifications are only taken in consideration when the game starts and read initial values. "Mods" are loaded at game start and operate alongside the game like any other game script.
Yeah, thanks for that clarify about the difference there Kassonade. I'm probably going to borrow the term "Builders" to refer to the modification of the static game parameters in yaml and ecf as "Builders". Although we differ a lot from the ship and base builders, I'm definitely not one of them. But we do need a name. Does "World Editors" fit the job? In terms of the door, would love to keep this on the radar. Although us "world-editors" have many other things we are doing.
lol ! I think "world editors" will have people wondering if that's some piece of software to edit the maps... The distinction was more to show the difference between "editing" and "scripting". In fact "scenario makers" are much closer to "scripting" than playfield makers or ecf "tinklers" where there are no conditional statements, polling and managing events from the game, etc. As for the doors, since they can be displayed without the "forcefield" when turned off, it could probably be available as option in the configs if it's a simple model swap when turning the device on/off. Right now it's like we only have access to the "on" model and not the "off" model.
I still want to come up with a good name. LOL. It's not easy to do the hard things. I think the blocks config lets you swap meshes about. I know some people have messed with these internals, but it's out of my area of expertise and patience. Would be great if they devs could just assign new block IDs instead of changing the old ones. But then we would have many many blocks, which is not a really bad thing. Anyone know how these meshes are swapped?
That is not the same thing. Let me explain is differently. The "forcefield" effect is a tranluscent blue-ish "mesh" that is "spawned" when power is turned on. That is the "code rule" for all "objects" with the "forcefield" mesh/model. Each model has its own "forcefield" mesh/model because they all have different shapes and sizes. We do not have access to these "forcefield" individual meshes, we can only swap the "main" model file (the door), which may include other "meshes" or not. The models that we can swap are the main ones that may/may not contain other meshes. They are written like this in most of the config files : For a "parent" object, there is no "shape" or "model" as it is only a class that defines the general characteristics of all objects derived from it. The "parent" object declares the possible variables, but some may be left empty/ null as they are not required by the parent to serve its "function" = defining a group of objects. Ex. for the "forcefield" objects, the parent "object" is : { +Block Id: 1500, Name: ForcefieldEmitterBlocks Material: metallight ShowBlockName: true Shape: Invisible << this block is not shown since it's only a ''definition'' block # Model: @models/Blocks/Mothership/ForcefieldEmitter1x1Prefab << commented -out (not active) At the end of these parameters defining the ''parent'' block we can see the ''children blocks'' that will use all the same ''parameters'' defined by the parent : ChildBlocks: "ForcefieldEmitter1x1, ForcefieldEmitter1x2, ForcefieldEmitter1x3, ForcefieldEmitter3x5, ForcefieldEmitter3x9, ForcefieldEmitter5x11, ForcefieldEmitter7x12" Then if we look in a ''child'' block's definition, we can see it has a ''visible'' model : { +Block Id: 1501, Name: ForcefieldEmitter1x1 # Group: cpgForcefieldEmitter Material: metallight ShowBlockName: true Shape: ModelEntity << shape is a model ( not ''invisible'') Model: @models/Blocks/Mothership/ForcefieldEmitter1x1Prefab << name of the model The model name ForcefieldEmitter1x1Prefab ends with the word ''Prefab'' a this is the model that can be swapped, with another model with a name ending with ''Prefab''. We still have to be careful not to replace a model with something that will not work, like a weapon to replace a block, because these are not of the same category (entity vs block). And here, the model is not a simple block, it has another "hidden" model, since this block has an on/off function (forcefield visible when power is on) and the game will look for this alternate model when power is turned on/off, and might throw an error in some cases. Given the number of objects we can swap around, the amount of possibilities makes it hard to test each and every combination, so we must proceed with care.
It's possible to build the hierarchy of objects I'm not perfectly sussed on that bit. I get a bit lost, because there are "references" and "groups" like the ChildBlocks property in the inheriting of properties, is the "ChildBlocks" property the counterpart of "ref" ? { Block Id: 1497, Name: SolarPanelHorizontal, Ref: SolarPanelSlope ... (I need to learn how to paste code into this forum, Steam markdown is much less fun.)
The "childblocks" is only for the "blocks groups", the ones that we have to right-click in game to see what the group contains, displayed in a separate window/grid (like regular blocks, right-click show all "child" blocks/ shapes, or "ramps" > right-click to see all ramps). The "ref" is pointing to the "parent" class that a block/ entity is derived from. All items/ blocks have a "ref" except the "parents". An example is the { Item Id: 2100, Name: 50Caliber with all "derived" bullet types like { Item Id: 2101, Name: 8.3mmBullet, Ref: 50Caliber.
Aha, now groups make a bit more sense. Was puzzling this when I was trying to hack the door shield so it was invisible/translucent again. You must be incredibly patient to have learned all these attributes.
