Dont Judge I've got a custom config.ecf I've built over time and I swear at one point I was able to use the "AllowPlacingAt:" in it to let me put some HV stuff on SV's, like the tool turret, Medic Station etc. I was also able to put the Deconstructor and Furnace on CV's but it is not working anymore. Here's a few of the items from my config.ecf #Hover Tool Turret on SV { +Block Id: 1104, Name: TurretGVTool, Ref: TurretDrillTemplate AllowPlacingAt: "GV,SS", display: true } #Medic Station on SV { +Block Id: 1584, Name: MedicStationHV AllowPlacingAt: "GV,SS", display: true } #Deconstructor on CV { +Block Id: 1371, Name: Deconstructor AllowPlacingAt: "Base,MS", display: true } #Furnace on CV { +Block Id: 1132, Name: Furnace AllowPlacingAt: "Base,MS" display: true } Was this ability removed in a recent update or I'am I just missing something? Thanks.........
Well that's a bummer. It was nice to have everything in one place. Kinda would like to see that added back in......
In fact they could make just 1 file "to rule them all", and keep hidden all the stuff we can't modify. That would make things much easier and less error-prone. Right now there are many dependencies from one file to another, and no clear pointers that changing something in one can break things if not changing something in another related file.
That's supposed to still work, nothing in the release notes that I saw, although the notes are terrible long. what does the logs say console log, not the file. Why the file does not also contain the console log escapes me. (I already complained once about the log level not being settable to verbose, because there is never much to go on.)
I saw a recent bug report from Astic (in German) telling about a mismatch problem with the config.ecf numbers, but can't say if it has anything to do with the matter here. In the past, there were instances where we could "try" adding parameters in the config.ecf and it would work, but not for some items or blocks. My recent experience is that the config.ecf will not accept parameters that were not already in the ExampleConfig.ecf, so we have to mod the "parent" files anyway. At that point, and having all configs now in a scenario, sheltered from updates, it's more reliable to simply mod the BlocksConfig and ItemsConfig, and this avoids mismatch problems with the Config.ecf.
I would like to see them setup something where you can make a folder called "Custom" and any .ecf file you put in there will override the default ones, kinda like a mini scenario. It would work like the config.ecf does now where you don't need to have an exact copy, just put in the changes you want, you would have one for ItemsConfig.ecf, BlocksConfig.ecf etc. etc. Maybe some day
I also suspect that the AllowPlacingAt issue is config item number related. The devs have been a bit closed in publishing details, bigger fish to fry I guess. Do keep trying. "Proper" Scenarios are not that hard to create, however even so there are other problems when maintaining scenarios, we probably just have to be patient, and keep experimenting at the same time. It's not an easy problem.
I think the developers tried to simplifiy things and divided a big file Config.ecf to small but managable ones. Also things are still in developement and changes are expected. It is easier to look up to edit lets say an item in the ItemsConfig.ecf rather than browsing a big file. Modern search tools can help you locate terms in multiple files. Geany for example is a favorite editor of mine that can open multiple files and search in one session for a term or word and even replace in all files that word is found with one click.
