Stick Recipes.zs would be the name of the file, doesn't always mean it will contain a stick in the recipeIs that the entire scipt? If not, can I see the entire scipt? Because I don't see Stick anywhere in that line.
Stick Recipes.zs would be the name of the file, doesn't always mean it will contain a stick in the recipeIs that the entire scipt? If not, can I see the entire scipt? Because I don't see Stick anywhere in that line.
ah. But still, the rest of the scipt would be nice.Stick Recipes.zs would be the name of the file, doesn't always mean it will contain a stick in the recipe
Yeah, I wanted to ask for it but seeing as no values were used, it's not that important... just the imports and the line that is erroredah. But still, the rest of the scipt would be nice.
#Bundled Sticks Recipe
recipes.addShapedMirrored
(
<customitems:bundled_sticks>,
[
[
<customitems:crude_rod>,
<customitems:rubber_band>
],
[
<customitems:rubber_band>,
<customitems:crude_rod>
]
]
);
#Ladder Recipe
recipes.addShapedMirrored
(
<minecraft:ladder>.withTag
(
{
CanPlaceOn:
[
customitems:coarse_dirt
]
}
),
[
[
<customitems:bundled_sticks>,
<customitems:crude_rod>
],
[
<customitems:crude_rod>,
<customitems:bundled_sticks>
]
]
);
I don't see why an import would even be necessary. NBT just doesn't work like that. You ca n put whatever stuff you want into the NBT data, as long asit's written out properly. And if a mod looks for certain NBT data, like adventure backports looks for canPlaceOn, then it will. Using NBT data like this, you can have vanilla items that behave in special ways with modded mechanics, but still retain their data when the mod is removed and replaced. A brilliant example of this is the vanilla seeds in @InfinityRaider's agricraft.Yeah, I wanted to ask for it but seeing as no values were used, it's not that important... just the imports and the line that is errored
That's probably it *facepalms*And try putting angle brackets (<>) around customitems:coarse_dirt.
#Assume there are proper variables defining each of these terms higher up in this scipt.
recipes.addShaped
(
pulveriser,
[
[
null,
piston,
null
],
[
flint,
frame,
flint
],
[
gear,
coil,
gear
]
]
);
#Assume there are proper variables defining each of these terms higher up in this scipt.
recipes.addShaped
(
pulveriser,
[
[
null, piston, null
],
[
flint, frame, flint
],
[
gear, coil, gear
]
]
);
#Assume there are proper variables defining each of these terms higher up in this scipt.
recipes.addShaped(
pulveriser, [[null, piston, null],
[flint, frame, flint],
[gear, coil, gear]]);
Personally I do it all on one line as it makes debugging easier for meBesides the issue here, I'd like to say a few words on making minetweaker recipes more readable.
For a normal programming language, giving each encapsulator its own line is jus expected. With them, it makes everything much cleaner and easier to read. This is not the case with Minetweaker, however. Methods are explaining a recipe in a space. That's how you see Let's take the recipe for Thermal Expansion's pulverizer for instance. If I used what you're using, it would come out long, ugly, and harder to understand at a glance:
You sort of have to flip around the words in your head a bit. Now let's try putting each item on a line for its row, like this:Code:#Assume there are proper variables defining each of these terms higher up in this scipt. recipes.addShaped ( pulveriser, [ [ null, piston, null ], [ flint, frame, flint ], [ gear, coil, gear ] ] );
See? Now it's much easier to understand what's going on in the recipe at a quick glance, while still keeping the traditional spacing rules. I'm perfectly fine with everyone using this method. However, this is my prefered method:Code:#Assume there are proper variables defining each of these terms higher up in this scipt. recipes.addShaped ( pulveriser, [ [ null, piston, null ], [ flint, frame, flint ], [ gear, coil, gear ] ] );
Nice and compact. Easy to read. It looks like a crafting recipe. It also looks really clean to me.Code:#Assume there are proper variables defining each of these terms higher up in this scipt. recipes.addShaped( pulveriser, [[null, piston, null], [flint, frame, flint], [gear, coil, gear]]);
recipes.addShaped(pulveriser, [[null, piston, null],[flint, frame, flint],[gear, coil, gear]]);
recipes.addShaped(pulveriser, [[null, piston, null],[flint, frame, flint],[gear, gear]]);
That's also perfectly valid. My only concern with that way is it tends to get really cluttered-looking really fast. I mean just look at phoenixReborn's scipts. It's a massive block of text.Personally I do it all on one line as it makes debugging easier for me
So that everything is in one place, so that I can see instantly is there is a missing input e.g.Code:recipes.addShaped(pulveriser, [[null, piston, null],[flint, frame, flint],[gear, coil, gear]]);
But then I can also go along the line saying to myself "bracket open, square bracket open, square bracket open, square bracket close, ..."etc.Code:recipes.addShaped(pulveriser, [[null, piston, null],[flint, frame, flint],[gear, gear]]);
and then when those two checks are out of the way it's checking is stuff named right, did I forget to encase non-defined values e.g. putting "minecraft:string" not "<minecraft:string>"
I guess it depends how many values you set, and use... if you have stuff that has a lot of long IDs it's bad, but 20 characters or less is fine (for each item)That's also perfectly valid. My only concern with that way is it tends to get really cluttered-looking really fast. I mean just look at phoenixReborn's scipts. It's a massive block of text.
And try putting angle brackets (<>) around customitems:coarse_dirt.
#Ladder Recipe
recipes.addShapedMirrored
(
<minecraft:ladder>.withTag
(
{CanPlaceOn:[<customitems:coarse_dirt>]}
),
[
[<customitems:bundled_sticks>, <customitems:crude_rod>],
[<customitems:crude_rod>, <customitems:bundled_sticks>]
]
);
recipes.addShapedMirrored
(
<minecraft:ladder>.withTag
(
{CanPlaceOn:["customitems:coarse_dirt"]}
),
[
[<customitems:bundled_sticks>, <customitems:crude_rod>],
[<customitems:crude_rod>, <customitems:bundled_sticks>]
]
);
Goreae beat me to itCode:#Ladder Recipe recipes.addShapedMirrored ( <minecraft:ladder>.withTag ( {CanPlaceOn:[<customitems:coarse_dirt>]} ), [ [<customitems:bundled_sticks>, <customitems:crude_rod>], [<customitems:crude_rod>, <customitems:bundled_sticks>] ] );
Um,
ERROR: Stick Recipes.zs:16 > Cannot cast minetweaker.item.IItemStack to minetweaker.data.IData
ERROR: Error executing Stick Recipes.zs: null
It worked! Thank you for the help.Alright, I think I got it now. I looked at the adventure backbort Curseforge page, and I used the commands provided and /mt hand to get this. customitems:course_dirt has to be in parentheses. So the recipe looks like this:
Code:recipes.addShapedMirrored ( <minecraft:ladder>.withTag ( {CanPlaceOn:["customitems:coarse_dirt"]} ), [ [<customitems:bundled_sticks>, <customitems:crude_rod>], [<customitems:crude_rod>, <customitems:bundled_sticks>] ] );
I believe you can either put null, or remove that field. If that doesn't work do <minecraft:air>Greetings again. Need a bit of help.
I am trying to set up a casting basin recipe that doesn't require anything to be in the basin in order to pour the block.
The <???> is where I'm getting stuck, because I can't figure out what to put there. Every variation I am trying is requiring me to have a block in the casting basin.
mods.tconstruct.Casting.addBasinRecipe(<Metallurgy:base.block:2>, <liquid:manganese.molten> * 1296, <???>, false, 100);
What Jordan said. Look at the example recipe in the wiki:Greetings again. Need a bit of help.
I am trying to set up a casting basin recipe that doesn't require anything to be in the basin in order to pour the block.
The <???> is where I'm getting stuck, because I can't figure out what to put there. Every variation I am trying is requiring me to have a block in the casting basin.
mods.tconstruct.Casting.addBasinRecipe(<Metallurgy:base.block:2>, <liquid:manganese.molten> * 1296, <???>, false, 100);
I believe you can either put null, or remove that field. If that doesn't work do <minecraft:air>