1.4.2 build 3266 I'm seeing that a config.ecf file placed in the Vanilla folder (by renaming config_example.ecf to config.ecf) is not even loading settings from the file. Is this a patch note I missed? I get the impression that even scenarios are not getting unloaded and re-loaded on the main menu anymore and that you have to terminate the process completely. I was playing a scenario that adds a new techtree earlier, and I loaded Project Eden (RE), and some of the techtree from the previous game scenario showed up in my Eden game. Am I just having a bad debugging day?
There seem to be issues with the config.ecf file currently. Some claim it doesn't work at all while others claim it does work under certain circumstances. The config files from previous scenarios not getting unloaded properly is also a kind of new issue. On one hand you should be happy your scenario loaded at all but on the other hand you shouldn't even attempt it as it often breaks savegames to the point of it getting corrupted and not even showing in the Resume Game options anymore. For me it always ended up in CoQ error coming up and the savegame not loading at all.
Ah, good to know. I'll give up and wait for a bug report to be raised. I hate raising bugs, I raise so many bugs IRL every week, it's a emotional drain. Well, the complete lack of verbose logging (I have complained about this previously, and been rightly rebutted) makes seeing what is going wrong in a scenario far harder to do than it needs to be, hope that can be addressed. I fully understand that Eleon don't want Intellectual Property to be leaked via the log files, nor for that matter private data either. But it means unless you have the patience and know how to attach a debugger and get more information, creating engaging game content is far harder than it needs to be for people with not that much free time. Will give it a break until fixed. Do share link to the ticket if one gets raised. ...truss blocks? Whaaaa? (DM me about the truss blocks, I might be interested in helping work on that while the rest of the game is in flux.)
Its known, but not sure if we will fix it. The Config.ecf got changes so modders who write CSharp Mods could read it again for there mods. This only broke it for others. As you have the ItemsConfig.ecf and BlocksConfig.ecf there is no need for a player to only use the Config.ecf anymore
I had suspected it would happen that this support changes, for some time. Glad I did ask. Frustrating to get help when you do not have regular internet access like I do, cannot spend time searching for answers if things are not shared in a place internet searches might work. Is there a chance we can make some kind of accommodation for people who only got told late in the day about the change. I feel I wasted 2 weekends on this. 1. Can we update the markup in config_example.ECF to note the deprecated support?
It seems like items don't work in config.ecf anymore. Blocks (and I assume everything else) should still work for now. I hope config.ecf is kept updated because it is a very useful way to make small changes to a game.
Yes its only when you use the Items from the ItemsConfig. This wont work anymore Ill make sure a note gets added if we indeed deside to stop useing the Config.ecf
Yeah if it's no longer supported in the config.ecf it should be removed from the config_example file. That way we are actually aware it's no longer supported. It would have been nice to at least be told about the change and what it actually meant is all I'm saying, since a large portion of the community used it. To say there was no need for players to use Config.ecf anymore is just plain wrong. For one it doesn't get overwritten by game updates when playing the default scenario. That's a pretty major reason to use it.... A lot of players used it to make minor adjustments to the default scenario and now those players are basically forced to create a scenario. Another good reason to use it is so we can give players multiple options in scenarios by simply choosing which Config.ecf file to change the name on and activate, since it was loaded last.
The blocksconfig and itemsconfig can be set to a different directory aswell so they dont get overwritten. Some versions back we added a note you can copy them either to a scenario or to the mods directory. Mods directory doesnt need a scenario Non of thise get overwritten either
But now you need to reapply your changes everytime the game updates the config files or port the changes from the normal config files to your modified ones. Using the config.ecf was just fire and forget so to speak. You didn't have to care if one items mass got changed by 5kg.
True, but it's the price of progress. If you do copy all the files into a scenario, then you don't actually need to do updates, unless something breaks. The entire ECF loading order is actually quite a complicated problem. Hats off to the guys (and gals of course) for making it work for so long, people forget that a lot of code in games starts out as an idea and not as something an architect sat and through about for a whole week. Small teams don't have that kind of time. Small notes here and there are going to have to do, I do try to leave notes as I go in the guides I write too. I wrote a old guide on this ages ago, but it's outdated, I just need to update/rewrite it, I just wish I could get people help review the guides and wikis.
Given the opportunity of a discussion about .ecf files I would like to express again the need of a new special tab in the settings of the game that manages .ecf activation and usage. That would help the player for example to use itemxconfig.ecf from one scenario i.e. "Craftable Epics" and blocksconfig.ecf from another scenario i.e. "Reforged Galaxy", or just the vanilla one. Some moders might not use a scenario to provide their config files to the rest of the players. Also this helps with debugging in case the moder tests the progress of file editing comparing with the vanilla files. Finally I think we need a console command to re-load a specific config.ecf (as that set in path in the new settings tab) or just all the files set altogether.
I think the whole "modding" and merging of mods is non trivial. as we have seen with the way Project Eden merged with Reforged, it's hard stuff. I had hoped to learn to program properly in C# to write a merge tool of sorts, but learning to program in C# is not easy. It's a good tool for the job, but not easy. Ad for having UI in the game, I think that is really a Nexus Mod Manager thing, I think it's complicated at best, and fragile at worst. I would like to kick this topic down the road until Christmas or at least until we see more people writing scenarios. I would like to see more debugging trace in the console/logs to help scenario makers though. Would also like to see more than one or two people publish guides, there is not much choice when it comes to learning this stuff. We all know that learning to do something is not the same for everyone, so choice is important. I do agree with you @Myrmidon , but the timing for mod managers talk is a bit early. The workshop has only got a dozen current updated scenarios published. When that becomes 50 or 60 scenarios, then we must talk. I'm happy to try keep driving this, Vermillion and Ravien as well as Rexus have done a good job of the socializing of the scenario as a storytelling tool already. We need to write a few now. If Eleon are as serious about players building scenarios as they are about players making blueprints, then the logging needs more love.
My edited config file is half-working? All the recepies I changed (to get more ammo for ships, have concrete require water, etc..) works, but the weapons do not, as it claims the ID are not correct (but they are). So if I understand correctly, ItemsConfig needs to be edited, not config anymore?
Its half working yes. But as the rest might break aswell at some point or we complete remove it. The answer is stop useing it and start useing the other files If you make the changes there now then you dont have a problem when this happens
This is ridiculous. I was under the impression this file was still usable and so went about trying to simplify my personal quality of life modifications into config.ecf overrides. Awesome, I'll finally get to stop stressing over updates and simply override what I want. Disaster! Now I have no easy way of merging my changes back into the full files because merging software doesn't recognize the syntax of an ecf file and treats it like a standard txt file. That means any missing content will override any thing in the other config file that is missing on the other end. I can't tell it to treat items that are unique on both sides as separate items and let me merge them to new lines. Now I have to go through each object by hand and merge manually. I cannot do this without an easy way to simply override specific parts. The files are too messy with commented sections and strange spacing at random (such as entire blocks that are all indented by a single space, or closing brackets that all have a single extra space in front of them) and all the different ways of putting comments in them to easily write a program to parse it all. Don't even get me started with the fact that all the files use the proper "\r\n" carriage return except for items.ecf which uses only "\n" so using regular expressions can be a nightmare... I need config.ecf or an external tool to mimics the behavior of it. Otherwise this is a nightmare that I wouldn't with on anyone.
You only have to do this ONCE to modernize using the active game data files. Thereafter the comparisons and merging becomes simpler. Modding the game is still not a breeze, far from it, but you over-dramatize the modernization issue. You should have abandoned using config.ecf once the active data files were exposed. The writing was on the wall, and there are numerous things that can't be done at all with config.ecf.
Finally upgraded my graphics card this week, so splitting up the files and the reboot of the project is on again. https://steamcommunity.com/workshop...73709551615/3470604115214348462/?appid=383120
