Coming soon ... Recipe Editor

[BloodSlinger]

An initial release will exist soon and I'll create a dedicated thread for it.

 

In the meantime a quick shot of its current interface and rough feature set:

 

 

General features that exist:

• Automatically loads elements including ingredients and attributes from the file so when the game patches recipes any new things added, incuding any new attributes or types should be supported.
  
• Provides a filter against recipes and ingredients. Simply start typing the name of it and it will filter in real-time making it easier to locate something quickly.
  
• Provides automatic recipe grouping so a single list (on the left) for a recipe name exists. Selecting one drills in and provides all recipes of that type in the top.
  
• Selecting a recipe from the top loads that for editing.
  
• Editing (bottom left) is provided by a text editor which is the most effecient way, for me anyway. Since I've been using NP++ before working on the tool I'm already used to doing it that way so, that's the way it is in this.
  
• Validating (bottom right) occurs in real-time. As you make changes during edit the result is immediately validated. If it's valid you'll see the recipe duplicated on the right, and you'll see the recipe ingredient grid pattern for it too, if it has a grid entry and isn't a recipe for cooking for example.
  
• Provides lists (right) of all element and ingredient attributes found. These can be used as reference.
  
• Provides list (right) of all distinct ingredients that exist in the file. These can be used as reference. This list can be filtered just like the recipes list.
  
• Provides a scratch pad tab for capturing chunks or making notes. This is useful because selecting recipes will immediately update the edit view. The scratch pad will contain whatever you put in it until the program is closed.
  

 

 

General features needing finished for an initial release:

• Add serialized settings for the program including root location for the game. All used paths will be relative from the root.
  
• Capture scratch pad to a simple plain text file and load it on program load.
  
• Provide support for custom recipe files. This will be a place to create custom recipes so when the game patches and obliterates custom edits of the main file, these can then be easily re-imported to the main file.
  
• Provide a custom attribute to signify a custom recipe. This could be used to precisely identify actual custom recipes apart from official recipes. I'll probably use guids for it but I'll need to confirm my current theory is good to go / compatible with the engine parser.
  
• Provide actual saving of changes. Still need to perform structure validations and compatilbity with game 100%.
  
• Provide mechanism to create new recipes, including cloning existing recipes as new and ready for edit.
  
• Complete the re-parse system so at any point all view models, views and core data can be easily refreshed while the program is running.
  
• Enhance a custom cache system I've made. The program should stay generally under 300megs max memory if every recipe, sub recipe, view and vm has been loaded at-least once. It uses the cache instead of creating dynamic objects unnecessarily over time. I'll probably add a configurable purge for the cache for those with incredibly low system resources.
  

 

Believe that's about it at this point. Once I've got an initial release where I want it, I'll make a dedicated post for it.

[brostoevsky]

Pretty cool. I've been wanting to write a web based interface for this same thing for a while, I just haven't had the free time between work and 7DTD to do it

[BloodSlinger]

Yep time is always the problem. For games that show me they're not a piece of ♥♥♥♥ and have dev teams that actually listen to the community to improve, I try to add. Biggest thing I see here at the moment may be the board itself. We need to be able to properly edit original posts for mods otherwise revisions would be buried somewhere in thread posts and that's a nightmare for frequent updates. Was chatting with someone and they said it was because retards kept coming in and posting stuff then deleting it.

 

Anyway on the editor I'm using an MVVM pattern (though not 100% pure) so after the recipe edit system is complete if other files turn out good candidates / "needed" then systems for those could get created.

[Red Eagle LXIX]

I was the one who told you about the edit issue, but I don't think I phrased it exactly like that. Not my wording for how I'd described the problem user.

[grimreefer24601]

Just do like I've done with UAE. Keep a general post with updated links on the first post. I have some minor releases, and bug fixes throughout the thread, but final releases are always on the first post. You can make a post with your revisions if you want, but it doesn't need to be at the top. I keep my detailed explanation in the readme file. It's really not too bad if you plan for it. I didn't with UAE, and now I wish I could change some of the description and title to reflect the new v0.2, but it's not a big deal, and if I were remaking it I'd write it generic enough that it didn't need to be changed.

[BloodSlinger]

I was the one who told you about the edit issue, but I don't think I phrased it exactly like that. Not my wording for how I'd described the problem user.

 

You didn't phrase it that way, that's why I didn't name you.

 

That's my wording because that's what I think about anyone coming in and disrupting or damaging the ability of other people that are genuinely trying to improve a game.

 

Edited: By the way thanks again for the information we discussed. Allowed me to get a jump start in here quickly.

 

Now if I could delete the post below and paste it into here instead... that'd be nice.

[BloodSlinger]

Just do like I've done with UAE. Keep a general post with updated links on the first post. I have some minor releases, and bug fixes throughout the thread, but final releases are always on the first post. You can make a post with your revisions if you want, but it doesn't need to be at the top. I keep my detailed explanation in the readme file. It's really not too bad if you plan for it. I didn't with UAE, and now I wish I could change some of the description and title to reflect the new v0.2, but it's not a big deal, and if I were remaking it I'd write it generic enough that it didn't need to be changed.

 

Good food for thought I'll try and keep it in mind to account for it when the initial release is ready to go.

[Aphaia]

So far i love 7 days to die but its limited to basic shooting zombies, looting or pvp style games. Will it be expanding in items to construct?, craft? ect. blocks - tan decay bricks, food, tree's, tech. Be great when the recipe editor is available but if we add our own recipes will they be wiped on the next update or remain?

[BloodSlinger]

Changes by users to the games main recipes.xml file are lost (overwritten) when the game updates and that file is included in the update, which is extremely frequent and should be expected for a long time as they implement new stuff, which they're doing a lot.

 

The quickest manual method at present is simply create your own xml file with your custom recipes. When the main file is officially updated, put yours back in, done.

 

One of the intended features of the editor is to natively support seperate files containing custom recipes, and not just one, but any number of them. It can easily go as far as creating a custom set with custom sets or sub categories. Anyway in its simplest form I intend to make it fairly easy to deal with from the ui. May also add command line support so it could be scripted to do it and not even load the ui.

[grimreefer24601]

The quickest manual method at present is simply create your own xml file with your custom recipes. When the main file is officially updated, put yours back in, done.

 

Sorry, but this is not a good idea. Any update that changes the xml would be rendered useless or even cause a crash by doing this.

 

The best way to keep you changes is to add your recipes to the end of the xml, and keep a back up. Then when a new game version comes out you append only your edited recipes to the xml. Even then if something changes your recipe may not work, but using the old file in the new build would have caused you to have no armor recipes.

 

Always append your additional recipes to a new recipes.xml.

[BloodSlinger]

Sorry, but this is not a good idea. Any update that changes the xml would be rendered useless or even cause a crash by doing this.

 

The best way to keep you changes is to add your recipes to the end of the xml, and keep a back up. Then when a new game version comes out you append only your edited recipes to the xml. Even then if something changes your recipe may not work, but using the old file in the new build would have caused you to have no armor recipes.

 

Always append your additional recipes to a new recipes.xml.

 

 

Sorry I wasn't clear. I didn't mean overwrite the officially updated file with your custom file. I meant take your recipes from your file and put them inside the recipes file. Guess I was in a hurry and assumed it was implied. But, for someone that hasn't done it, they wouldn't know that, so good catch on my missing chunk of information for them.

[BloodSlinger]

Status 3-15-2014 - General features needing finished for an initial release:

 

Add serialized settings. Program root from where it's launched will be assumed.

 

- Core plumbing and checks done.

 

- Needs final DIT.

 

-- Needs auto browse when invalid default game root path.

 

-- Done. Includes on load.

 

 

Provide saving of program settings.

 

- Done. Significantly enhanced including validations.

 

 

Capture scratch pad to a simple plain text file. Include auto load.

 

- Saving done.

 

- Loading done.

 

 

Enhance a custom cache system.

 

- Done. Needs extensive hammering.

 

 

 

Provide support for custom recipe files.

 

 

Provide a custom attribute to signify custom recipes.

 

**************

 

- Recommending <customized = "True"/>

 

 

 

Example:

 

   <recipe name="miningHelmet" count="1" scrapable="False" craft_time="20" customized="True">

       <ingredient name="ironHelmet" count="1" grid="0, 0"/>

       <ingredient name="potassiumNitrate" count="1" grid="1, 0"/>

   </recipe>        

 

 

The customized attribute will simply be ignored by the game engine because it's not looking for it.

 

The editor (or anything else) however can look for it, so this could be a simple approach at tagging custom recipes so the community knows it / tools, whatever.

 

It can be used for both edited and new recipes.

 

**************

 

 

Provide auto custom recipe import.

 

 

Provide saving of game recipe changes. Still need to perform structure validations and compatilbity with game 100%.

 

 

Provide creating new recipes. Include cloning.

 

 

Misc.

 

- Provide data reload.

 

-- Done.

 

- Provide auto select on successful load.

 

 

　

 

Bugs:

 

- Offloading data load to task allows multiple queued execution / duplicates in item sources.

 

-- Fixed. Reload command binding tied to new DP.

[BloodSlinger]

Current state of the UI:

 

[BloodSlinger]

Editor not ready yet but just ran it on latest 7.6 patch and I see there's an error in the official release.

 

They created a duplicate:

   <recipe name="gasCan" count="6" scrapable="False" craft_time="30" >
       <ingredient name="oilBarrel" count="1" grid="0, 0"/>
   </recipe>
   <recipe name="gasCan" count="6" scrapable="False" craft_time="30" >
       <ingredient name="oilBarrel" count="1" grid="0, 0"/>
   </recipe>

 

Definitely assuming this wasn't intentional.

[BloodSlinger]

Initial concept of customized. Easy to see in recipe group and if the element in the editor is. Any change to an element in the editor of any kind tags during validation.

 

 

... and speaking of empty Jars I recommend these 2:

 

   <recipe name="emptyJarMold" count="1" scrapable="False" craft_time="5" customized="True" >
       <ingredient name="clayLump" count="1" grid="-1, 0"/>
       <ingredient name="bottledRiverWater" count="1" grid="0, 0"/>
       <ingredient name="clayLump" count="1" grid="1, 0"/>
       <ingredient name="clayLump" count="1" grid="-1, 1"/>
       <ingredient name="clayLump" count="1" grid="0, 1"/>
       <ingredient name="clayLump" count="1" grid="1, 1"/>
   </recipe> 
   <recipe name="emptyJarMold" count="1" scrapable="False" craft_time="5" customized="True" >
       <ingredient name="clayLump" count="1" grid="-1, 0"/>
       <ingredient name="bottledWater" count="1" grid="0, 0"/>
       <ingredient name="clayLump" count="1" grid="1, 0"/>
       <ingredient name="clayLump" count="1" grid="-1, 1"/>
       <ingredient name="clayLump" count="1" grid="0, 1"/>
       <ingredient name="clayLump" count="1" grid="1, 1"/>
   </recipe>   

 

And until there is one, if there ever is one:

 

<recipe name="miningHelmet" count="1" scrapable="False" craft_time="20" customized="True">
 <ingredient name="ironHelmet" count="1" grid="0, 0" />
 <ingredient name="shortMetalPipe" count="1"  grid="1, 0"/>
 <ingredient name="potassiumNitratePowder" count="1" grid="2, 0" />
</recipe>