Offtopic, but that's going to be a thing? It was really a nightmare when he made variables to only be known within the same script. Great to hear its coming back.
PhoenixConfig - Modular Configs for 1.7.10
- Thread starter buggirlexpres
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Offtopic, but that's going to be a thing? It was really a nightmare when he made variables to only be known within the same script. Great to hear its coming back.
Also, this so a libfile like the PhoenixConfig one could work
Is there a branch that is supposed to be working? I looked at the main branch and two of the sections I tried are not loading because of syntax errors. I haven't looked at the dev branch yet but its not clear where I should be looking for the most updated versions.
These have a lot of issues, because many PT members have their own projects. I might update a few when I have some free time.
What sections have you tried? I know some scripts are not finished as we are waiting for MT 3.1 to work on his again
Yeah, we'll probably end up having to rewrite all of the code when it is released, but we'll have a dictionary file we can pull from which will be amazing.
Oh I meant to say that as a reason why the project is currently frozen. If we did update it right now, it would just have to be rewritten when 3.1 is done.
Last edited:
I saw you were waiting on the update after I started looking at it. I was trying to look at a diff for the files from the development branch but with the file paths being different it was not really easy. I started looking at the Botania based changes, specifically kill them with flowers because I'm working on a Botania based magic pack and wanted to see what was out there. If I look through any of them and see fixes to just make them load I'll fork them and mark pull requests.
Thanks for the help
We just haven't been wanting to put the effort into this since we will be switching to MT 3.1 as soon as it comes out for a myriad of reasonsTo make sure I understand:
The goal of this is to have a library of known, constant names that is user-meaningful, rather than mod_id:block_name:meta-value. So, for example, Geologica_BrownLimonite, instead of pfaa_geologica:clay_ore:4 (or whatever). Is that correct?
And, the current wait is for this to support multiple files of declarations -- so that each mod can ship an "official" such dictionary, without having to wait for centralized updaters to update a single giant file that then needs to be modified for the local modpack
Do I understand this properly?
The goal of this is to have a library of known, constant names that is user-meaningful, rather than mod_id:block_name:meta-value. So, for example, Geologica_BrownLimonite, instead of pfaa_geologica:clay_ore:4 (or whatever). Is that correct?
And, the current wait is for this to support multiple files of declarations -- so that each mod can ship an "official" such dictionary, without having to wait for centralized updaters to update a single giant file that then needs to be modified for the local modpack
Do I understand this properly?
Many mods use [midid]:resource:[meta], like thermalexpansion:resource:5 could be invar. ingotInvar looks so much better. Having a dictionary also makes writing scipts so much easier, as you can just type ingotInvar instead of having to use /mt hand to get the name.
And the dictionary is one reason we're waiting. Another is the mod is being totally reworked. We don't know what's going to be changed or added, and if we did start making new stuff, we would have to rewrite the entire package to work on the new version.
The dictionary will be a great help to us and we do have a large file that is our dictionary. However, currently we have to copy-paste it all into the script we are making. And that is a drag. Although having mod-specific dictionaries would be nice
Also, with MT 3.1, we don't need to separate the dictionary into 1 file per mod! We could have one file that says "If mod A is loaded, load this scipt. If Mod B is loaded, load this scipt..." and just include that as a requirement for all of the scipts.
yep. It works pretty well. We will have to do some fixes to the current file structure though
S
Solarkoid
Guest
I have made some Botania/Magical Crops dependencies but IDK if it is finished or not yet :/
but I recommend making tinkers a little hard from beginnings like this right here.
This is for my modpack but IDC and happy to share
That should be a little harder if one log makes 1 plank or 2 planks..
but I recommend making tinkers a little hard from beginnings like this right here.
This is for my modpack but IDC and happy to share
//Removing Recipes NORMAL CRAFTING
recipes.remove(Stencil);
recipes.remove(Builder);
recipes.remove(Station);
recipes.remove(CraftingStation);
//Shaped Recipes NORMAL CRAFTING
recipes.addShaped(Stencil, [[patternBlank, patternBlank, patternBlank],
[woodPlanks, null, woodPlanks],
[woodPlanks, null, woodPlanks]]);
recipes.addShaped(Builder, [[patternBlank, patternBlank, patternBlank],
[logs, null, logs],
[logs, null, logs]]);
recipes.addShaped(Station, [[patternBlank, patternBlank, patternBlank],
[woodPlanks, CraftingStation, woodPlanks],
[woodPlanks, null, woodPlanks]]);
recipes.addShaped(CraftingStation, [[patternBlank, craftingTable, patternBlank],
[woodPlanks, null, woodPlanks],
[woodPlanks, null, woodPlanks]]);
recipes.addShaped(patternChest, [[woodPlanks, woodPlanks, woodPlanks],
[woodPlanks, patternBlank, woodPlanks],
[woodPlanks, woodPlanks, woodPlanks]]);
recipes.remove(Stencil);
recipes.remove(Builder);
recipes.remove(Station);
recipes.remove(CraftingStation);
//Shaped Recipes NORMAL CRAFTING
recipes.addShaped(Stencil, [[patternBlank, patternBlank, patternBlank],
[woodPlanks, null, woodPlanks],
[woodPlanks, null, woodPlanks]]);
recipes.addShaped(Builder, [[patternBlank, patternBlank, patternBlank],
[logs, null, logs],
[logs, null, logs]]);
recipes.addShaped(Station, [[patternBlank, patternBlank, patternBlank],
[woodPlanks, CraftingStation, woodPlanks],
[woodPlanks, null, woodPlanks]]);
recipes.addShaped(CraftingStation, [[patternBlank, craftingTable, patternBlank],
[woodPlanks, null, woodPlanks],
[woodPlanks, null, woodPlanks]]);
recipes.addShaped(patternChest, [[woodPlanks, woodPlanks, woodPlanks],
[woodPlanks, patternBlank, woodPlanks],
[woodPlanks, woodPlanks, woodPlanks]]);
That should be a little harder if one log makes 1 plank or 2 planks..
Eh. The only real difference between the original recipes and these ones are the original recipes you have to chop down 1-3 trees to get started. With these, you just have to chop down 6-10 trees. If you're forcing tinkers, then I'd say don't do this. All you'd be doing is forcing users to limply slap more trees than usual to even get some basic tools. That's not fun or difficult, that's just an unneccesary grind. If you aren't forcing tinkers though, then I'd say take it a step further and make the pattern recipe only give one output (assuming that the recipe was unchanged) so that the player has to essentially raze a forest to get started in tinkers, but they can always use vanilla tools until they get the resources to do so.
S
Solarkoid
Guest
Hon Iguanas tinkers tweaks are already forcing tinkers (Tools Disabled except sword and hoe). I just made recipes more realisic bcs you have to agree, that is how they look and plus it is not that hard to chop down 1 tree with veinminer...
If logs still give 4 planks then yeah your recipes can give a bit of immersion. I agree they do look better than the originals. And nobody mentioned veinminer.
Chopping down 10 trees with veinminer is a piece of cake. Takes less than a minute. Without veinminer and armed with just a fist, it'd take forever just to get started, which is the unneccesary grind I was talking about.But yeah if your goal is prettier recipes, you nailed it.