Recipe outputs should never be ore dictionaries, because it should require specific items.
And to use ODs in machines that just are not compatible wrap the recipe add in:
for [i]item[/i] in <ore:blockIron>.items {
}and replace the OD with item.
Recipe outputs should never be ore dictionaries, because it should require specific items.
And to use ODs in machines that just are not compatible wrap the recipe add in:
Codefor [i]item[/i] in .items { }
and replace the OD with item.
Yeah, I worked around it, got two scripts up now and am constantly committing changes to the git pages for each of them. Took a lot of example surfing, but I got the method(s) down pretty well now for how I like coding this stuff. I love MT3 so much after making the ExtraBiomes scripts, made some things that should be in config or in the base mod possible.
I've got a new issue. I'm trying to edit a gregtech centrifuge recipe to take ic2 rubber (fits in with the rest of the changes I've made in my script) and spit out the same as the current sticky resin recipe (i.e. 3x wood pulp [iirc], 1x plantball [50% chance], and 100mB of liquid glue). I've basically made it so sticky resin is just used in an IC2 Extractor (like it used to), and converts to ic2 rubber instead of rubber ingots (which I made available to craft via putting rubber into a furnace). However, I can't get the output variable to work for liquid glue. I've had to stick with outputting a glue cell (but it contains 1000mB, 10x more than it originally outputted) instead. The script I have now that puts out glue cell is: Centrifuge.addRecipe([<gregtech:gt.metaitem.01:2896> * 3, <gregtech:gt.metaitem.01:30726>, <IC2:itemFuelPlantBall>,], null, <IC2:itemRubber>, null, null, [10000, 10000, 5000], 300, 5); When I use the meta id for liquid glue (forget what the name was, something like _displayFluid:13, or along those lines) it would not take it as a usable variable. It works for now, I just would rather it not be as OP on the glue output if it doesn't need to be (basically want to clean it up a little bit and add the functionality that it should have). I tried looking for similar scripts everywhere, but can't find a single example using gregtech's fluid registry...
Are the script sets you provided so kindly seven months still usable in their state? I am too lazy to check everything manually by hand. Anyone using them?
Are the script sets you provided so kindly seven months still usable in their state? I am too lazy to check everything manually by hand. Anyone using them?
You mean the collected scripts or the Pack scripts?
Are the script sets you provided so kindly seven months still usable in their state? I am too lazy to check everything manually by hand. Anyone using them?
All of the recipes he's provided that I've viewed fit the criteria to work in the 1.7.10 version of minetweaker. I've only pulled two specific recipes for my larger script (mainly to debug and use as examples), and those were for gregtech/ic2 machines, so I'm betting the rest work as intended still.
Hi folks! I've got some problem here with MT3. So....
I decided to cook some Certus Quartz (AE2) from Certus Quartz Seed and Distilled Water in Autoclave (GregTech 5.09). So here is my script:
Autoclave.addRecipe(CertusQ, CertusQSeed, <liquid:ic2distilledwater> * 200, 10000, 1000, 24);
It's look like everything is all right, after "/mt reload" there is no any errors, but the recipe does not appear in NEI.
At the same time these line:
Mixer.addRecipe(FluixCrys * 2, null, [ChargedQ, NetherQDust, RedstoneDust], <liquid:ic2distilledwater> * 500, 60, 10);
works perfect.
So, gentlemen, whats my fail? 
P.S. Sorry for my English, it isn't my native language.
I don't think "/mt reload" works correctly with GT recipes (or OreDict recipes with GT installed), due to GT optimizations that prevent late modification.
I used your github as a base for a private pack but made some changes to fix broken things and cover missing nerfs. I think the most notable changes were to thermal expansion. Caches and tesseracts were nerfed. The cache nerf assumes JABBA is installed. The tesseract nerf requires EV transmitters and receivers. Also I added a europium plate to the ZPM transformer recipe so that a ZPM doesn't break the entire tech tree. Should I diff my changes with the current github, compare differences, and make a pull request with changes I think fit? I only want to spend the effort if I know it will be helpful and not hurtful.
I'm dipping my toe in Minetweaker, and I ran into a wall almost immediately.
I was trying to re-add the Railcraft Shunting Wire to my game of Gregtech 5 Unofficial, using just the relevant section of the Railcraft.zs script from Github. It didn't work. Minetweaker says "gregtech is not a member." Naturally, attempts to call Assembler() failed. This happens whether I use "import mods.gregtech.Asssembler" or I replace Assembler() calls with mods.gregtech.Assembler.addRecipe().
I'm using Minetweaker 3.0.10B for 1.7.10.
EDIT: Oh, never mind. Turns out that I missed the other thread. Once I downloaded and installed GTTweaker my errors went away, and the shunting wire recipe showed up in the assembler.
OK, a better question - I was looking over the recipe replacements for the Railcraft circuits, which normally feel off because of things like colored wool. The recipes on github require some items I find indecipherable because they're gregtech metaitem id's. Where would I find a list of these id's, if I'm trying to decipher recipes like this, or gods forbid write my own?
The simplest way to decipher GT meta-ids is to have GT loaded in the background (with f3 + H on) and look up the meta-id in NEI, it is a long process.
It would probably be best if you updated the git with ore-dictionaries instead, if you are going through the effort.
Also, pure ore-dictionary scripts are, mostly, usable in both GT5 and GT6, but meta-items are not, because Greg changed meta-items.
The simplest way to decipher GT meta-ids is to have GT loaded in the background (with f3 + H on) and look up the meta-id in NEI, it is a long process.
It would probably be best if you updated the git with ore-dictionaries instead, if you are going through the effort.
Also, pure ore-dictionary scripts are, mostly, usable in both GT5 and GT6, but meta-items are not, because Greg changed meta-items.
Many of the GT metaitems are not registered to the ore dictionary by default (at least in GT5; I haven't checked GT6 recently). NEI Integration has a config option to see ore dictionary entries in the NEI listing, without needing to manually use "/mt hand" on each item. Please clarify: are you suggesting the GitHub scripts should start adding them to the ore dictionary? In terms of readability, it seems to me that using some "val" statements to give those items more descriptive names in the scripts would work just as well.
The recipes in the main folder are mixed collect recipes long times not updated. Only my pack recipes I Update recently(Gt new horizons)
The recipes for the Railcraft circuits in your modpack (signal, controller, receiver) use gregtech meta-id's as well. I think what Mauve Cloud said is spot-on, the scripts could use more vals for clarity. I notice there are a handful of gregtech vals defined for items like copper wire, which would also otherwise be meta-id formulations.
It turns out the meta id's are already visible via WAILA. I did not know that was what I was seeing. The format is <name> <id>:<meta id>. The second number never meant anything to me before.
The items in question turn out to be Gregtech parts - the appropriate vals would be
val BasicCircuitBoard = <gregtech:gt.metaitem.01:32710>;
val MachineControllerCover = <gregtech:gt.metaitem.01:32730>;
val SensorLV = <gregtech:gt.metaitem.01:32690>;
Now that I've actually looked at the recipes from your mod pack in-game, only the Receiver Circuit recipe makes sense. "Controller Circuits" aren't actually controllers in the lever sense, they're wireless transmitters. A Gregtech LV emitter <gregtech.gt.metaitem.01:32680> would match the receiver recipe. Signal Circuits aren't lamps; a signal block already requires a signal lamp, and the current recipe effectively makes you build two sets of lamps into every signal block. The signal circuit's supposed to be the electronics controlling the lamp. Which would be.. what? A RS latch from Project Red? I'm not sure of the proper scripting name of that item.
EDIT: Thinking further, those signal circuits aren't latches, they're receiver/transmitter pairs. Those are the links to the other signals, which is why the original relay box included 2. An expensive, if logical solution would be to create signal circuits by combining 1 controller and 1 receiver circuit. It's a wonder that in the original recipe, substituting yellow wool for red made such a difference.
Many of the GT metaitems are not registered to the ore dictionary by default (at least in GT5; I haven't checked GT6 recently). NEI Integration has a config option to see ore dictionary entries in the NEI listing, without needing to manually use "/mt hand" on each item. Please clarify: are you suggesting the GitHub scripts should start adding them to the ore dictionary? In terms of readability, it seems to me that using some "val" statements to give those items more descriptive names in the scripts would work just as well.
I am saying that f3+H shows the GT meta-id and that, if the item has an appropriate ore-dictionary than use that, because if a script only uses ore-dictionaries for GT items, then it may work with both GT5 and GT6, and that if it doesn't than it certainly won't, without modification.
Using "val" naming is also very good for intelligibility, but if an appropriate ore-dictionary exists, than that would probably be better for the reasons above.
Using "val" naming is also very good for intelligibility, but if an appropriate ore-dictionary exists, than that would probably be better for the reasons above.
If the ore dictionary registration already exists, I totally agree. Except for outputs or machine-processing recipes. I was mainly asking about the items that do not get registered to the ore dictionary by default. Sorry if that wasn't clear.
Hello,
Im trying to push forward forced compatibility between GT5U, RotaryCraft and few other things. For example: ive got nether titanium ore from Nether Ores, which i can put inside RC extractor for extra drop. It produces nether titanium flakes which needs cooking in furnace. In that way I will get titanium ingot, but i wish to receive only titanium dust.
Thats why im looking for names of gregtech things - ive already gathered knowledge of maitaining ores (f.eg.: gregtech:gt.blockores:828 for sheldonite); now i wish to know how to check proper name for titanium ingot, titanium dust, nether titanium flakes and those type of things. Any ideas?
Here is a first version of a recipes in AE2 for GT6.
AE2-GregtechRecipies.zs.txt adds the new press recipes to the GT6 press, Note: Requires MTUtilsGT (from the thread "Gregtech 6 Minetweaker"
AppliedEnergistics2-configFolder.zip is a custom AE2 zipped configs folder and changes AE2 to:
make AE2 energy 1:1 with EU
make power acceptors take an HV laser
make Illuminated Quartz take Lumium
make quartz fiber take GT LU cable
make formation and annihilation cores take 2 Crystal processors each
make storage cells take Crystal processors
make terminals take a crystal processor
make the (trash) condenser take a GT trash bin
and more!
Yes, though keep in mind that the majority of the changes are directly in the configs, not the .zs file.
The .zs file only does GT machine recipes.
