[GregTech-5][1.7.10-FORGE-1355+][Unofficial but approved Port][Stable] Even GT5 Experimental is slowly getting stable.

  • just a quick question, is it possible to run gt6 and gt5u concurrently without a complete overhaul for either mod?

    I had the idea just now when I was thinking about my current mod loadout.

    I just tried that as an experiment (using 5.09.31 and 6.05.48), and without any changes, Forge stops me with an error message saying "You have mod sources that are duplicate within your system" (because both mods use "gregtech" as the mod id, though iirc GT6 includes a secondary mod in the same jar with id "gregapi"). Even if you were to change the mod id for one or both of them, they both do so much to world generation that I think you'd still have serious problems, and need to do something along the lines of a "complete overhaul" for one or both mods.

  • Well, I think there are a few outstanding bugs with GT6 compatibility with TFC, (but I haven't checked recently):

    GT6 tools are too fast compared to TFC tools

    GT6 weapons don't multiply their damage to account for TFC's health rebalancing

    At one point GT6 axes were doing strange things to TFC trees (no tree-capitation, even though both mods do it, but taking the durability anyway, etc.)

    Plus more I can't think of off the top of my head.

  • yeah I've figured out most of the issues between them, my major issue right now in this pack is figuring out why I can't add spawn eggs to RLD dungeon loot correctly, but I have four more tests to do and any one of those could be successful. I get my GT stuff out of the twilight forest so like I said, worldgen isn't an issue.

  • It seems that in version 5.09.32 you changed methods in lang file (I'm looking into new lang file, created by pre1 from beginning).

    As it was before:

    1. Material = Bronze,

    2. Material Dust = Bronze Dust

    3. Material Small Dust = Small Bronze Dust.

    Now:

    1. Material = Bronze.

    2. Material Dust = %material Dust.

    It's nice, but becomes impossible to translate into russian correctly, because we have a lot of variants of ending for materials.

    Please, don't change algoritms in lang file...

    And sorry for my bad english, it's not my native language.

  • This also makes English impossible aswell. Wood Pulp is the proper name for Wood Dust. And even if you go for the Dust ending on it, it would be Sawdust!

    I have a lot of special cases like that in GT6, and those are the reason why I kept it like that. Otherwise "Paper Chad", "Bonemeal", "Gunpowder" and similar aren't possible!

  • GregoriusT

    Well... The auto-generated entries are sth like this:

    Code
    #Tiny Pile of Gunpowder:
    S:gt.metaitem.01.800.name=Tiny Pile of %material
    #Tiny Pile of Blaze Powder:
    S:gt.metaitem.01.801.name=Tiny Pile of %material Powder
    #Tiny Pile of Wood Pulp:
    S:gt.metaitem.01.809.name=Tiny Pile of %material Pulp
    #Tiny Pile of Chad:
    S:gt.metaitem.01.879.name=Tiny Pile of Chad
    #Other trivial cases. Take redstone for example:
    S:gt.metaitem.01.810.name=Tiny Pile of %material Dust

    DarkForce It's not necessary to use the placeholder. If a localized string doesn't contains the "%material" placeholder, it will be used directly as the name of the item. Thus it's even compatible with the lang file in earlier version.

  • Ok.

    But how can i understand what to translate?

    I will generate file from the begining and it will contains "S:gt.metaitem.01.810.name=Tiny Pile of %material Dust" without any description of material.

    Yeah this makes it insanely hard to read the Lang File, since the Material that is being translated is not part of the Line you translate at all, meaning you have to search for that one first, wasting shitloads of Time, making it inconvenient for Translators, resulting in people not WANTING to translate GT, meaning you wont get any Translations thanks to this "feature" being so inconvenient!

  • My suggestion for "Materails" block (But use true json).

    Atm i created (for 5.09.31) specail MSSQL Database with some stored procedures - which helped me in translation, because - i'm wasted a lot of time in searching common strings in a whole lang file.

    This kind of lang file will speed up translation by "hands", as for me (example) - i will create json>sql converter for it.

  • Sorry to bother again but currently i'm having a hard time figuring out how to gregtech inventory unification works, the problem occurs when gregtech is turning compressed tin from galacticraft to simple tin plates which is making it hard to use galacticrafts recipes, i tried turning all galacticraft items in the unification file to true and it seems to work on every other compressed plate but tin

    any ideas why?

    thanks

  • Were any new ores or progression necessary worldgen added in 5.09.28-31? I migrated a base from .28 to .31 using the same seed but noticed that ores didn't spawn in the same locations and I had already spent hours finding good veins so I'm currently just playing in my .28 genned world. I'm not far enough along to see what implications this has for ores or oil. Will I have to migrate to a newly generated world?

    Edit 1: To answer my own question: it does not seem like the default ore generation configuration has changed at all so no new ores were added. I haven't experimented with oil yet.

    The issue of gallium being difficult to obtain pre HV remains valid though. The only source of it is small zinc ore. It would be nice if it could be rebalanced. Something like adding it as a rare earth byproduct seems reasonable. I'll probably do this myself with GTTweaker.


    Edit 2: Hmm well I tested this and it does work if rare earth is not the ingredient (I used neutronium dust to test). However GTTweaker's centrifuge class does not have a method for recipe removal. The documentation says the machine classes do but the source code says otherwise.

    Edit 3: And the final hack to get this working is here.

    Change config/Gregtech/Recipes.cfg line 16933

    from

    Code
    I:dustRareEarth_64=64

    to

    Code
    I:dustRareEarth_64=0

    For reference the processing time was increased from 64 to 80. This is close multiplying by 6/5. This seems fair since a 6th output is being added. Also in case anyone has issue with Gallium not being classified as a rare earth metal: in real life I don't see europium being made exclusively from fusion as opposed to rare earth processing. I also don't see pockets of plutonium in our perfectly flat crust. From a balance standpoint this makes sense since the best source of rare earth is monazite. That only takes a single MV machine to process so it’s easy to move into it. If you don’t have small ores enabled you can still get first gallium from thermal centrifuging many ores.


    Finally a better change would to make it a bauxite mix byproduct since that is where we get it from in reality and a player will be processing aluminium ore when they’ll be needing gallium.

    Edited 10 times, last by willis936 (January 23, 2018 at 3:12 PM).

  • Small zinc ore is pretty easy to find in nehter (height around 40-60), with drill it is fast process. You can get plenty until you advance to HV (only macerator needed which can operate on 128V anyway) and get more from bauxite.

  • I swear machine controller + shutter module functionality is busted in 5.09.31. I can’t get it to work on pipes using redstone signals. The shutter does open and close as expected when the machine controller setting is changed but the shutter doesn’t seem to ever change based on redstone signal even when a lever is put on the machine controller.

    Edit: nvm in single player I was able to fix it. There must be some other redstone source nearby messing with it.

  • I haven't quite worked out what's going on with oil extraction rate. I got somewhere in the range of 280 L per cycle for like the first five to ten thousand cycles then it dropped to 262. After another roughly five to ten thousand cycles it's up to 314 L per cycle. This doesn't match what the wiki says. I assume it's been balanced since that page was last updated since I calculated being able to get something like trillions of EU before expecting a drop below 200 L per cycle, which seems excessive.