[GregTech-6][1.7.10][Website][Patreon] Info, Support and Suggestions

  • Uhhm the Rocks help with finding the Copper Veins?

    I don't say, your "insert whatever" is bad. I'm only showing ways for making it better.
    GregTech Website
    Patreon really helps me out. If you consider funding the development of GT, so I might be able to do it fulltime, why not?
    GregTech 6, the Main Thread, Bug Reports go here too.
    I'm also on #gt-dev on irc.esper.net, if you don't want to make a Forum account just to contact me.
    (I'm there almost every day, when I'm at my own computer. Yes you can drop bugs and suggestions there too)

  • It's random as well. If you find a 12x12 vein of tetra, another will find a 96x96 vein of tetra and say it's too easy still.

    Not every vein is the same size. And not every vein will spawn where you want them to. ;)


    I'd still say, it's working as intended and the rocks you find on the surface and/or in caves are pretty good precursors to what vein is in the chunk. (EDIT: cluster)

  • All veins have a guaranteeed 16x16 minimum size, and can only be cut smaller if the Terrain shape doesn't allow it to generate fully.

    I don't say, your "insert whatever" is bad. I'm only showing ways for making it better.
    GregTech Website
    Patreon really helps me out. If you consider funding the development of GT, so I might be able to do it fulltime, why not?
    GregTech 6, the Main Thread, Bug Reports go here too.
    I'm also on #gt-dev on irc.esper.net, if you don't want to make a Forum account just to contact me.
    (I'm there almost every day, when I'm at my own computer. Yes you can drop bugs and suggestions there too)

  • As for the FPS and game engine discussion... Discussing that further is pointless

    Except that Greg is also planning "GregoriusT: Modder Unleashed - The Game"

    and, as fun as Minecraft is, if "GT:MU-TG" runs at 20 FPS that will be sad....


    Most current thinking in software development is poison to gaming, and

    much current thinking in game development is abandoning the focus on run-

    time in favour of developer-time, maintainability, and other business concerns.

    The assumption being that modern games are dumb, flashy, logic-anaemic,

    GPU-bound interactive movies and modern CPUs have spare cycles to burn.

    Or else, modern games are simple mobile clones of classic tile-matching games.

    GregTech sooooo does not fit either model, I'm hoping "MU" won't either,

    and if Greg can avoid some of the limitations baked into Minecraft from the

    start, then that might make the world a better place...


    (Especially if you consider what happens when some Greg:TNG modder takes

    your new "Vanilla" and mods it beyond recognition - they'll need the headroom)

  • Hrm... this second tetra vein appears considerably larger than I first thought so i may end up with enough copper after all. That is the best source right? There are no just straight copper veins right?

  • Hrm... this second tetra vein appears considerably larger than I first thought so i may end up with enough copper after all. That is the best source right? There are no just straight copper veins right?

    If you look in WorldGeneration.cfg, there's a "copper" mix vein that includes Chalcopyrite, Hematite, Pyrite, and Copper ores, and generates between layers 10 and 30.

  • Except that Greg is also planning "GregoriusT: Modder Unleashed - The Game"

    ...

    I meant discussing perception of FPS further was pointless. Not actual performance stuff.


    And i agree that modern games have focused too much on "see my game" rather than "play my game".

    But i don't agree with the maintainability aspect. You can write maintainable code and still have it run great. It's just that developers easily forget about putting heavy processes where they don't belong. Such as updating a whole chunk when only one block changes state.


    It's like telling every application to update their video buffers just because one application changed it's contents. There's dirty regions for that, the same way a single block should be marked dirty and only as often as necessary and that dirty region should be all that's affected.


    Minecraft has always had trouble with it's chunk handling.

    As for GC, a properly used GC is just as efficient as a manual one. It's the same amount of processing time except one does it on the spot and the other does it in batches. You can still do "on the spot" GC with managed languages. But better still is if you never have to do GC in the first place when something is to be used again unless you absolutely have to. And that's where an unmanaged language forces developers into thinking twice about their own GC. It's simply too easy to forget that leaving something out of scope (which would be a fatal memory leak in unmanaged code) will cause it to be GC'ed only for a new, pretty much identical instance to be created elsewhere.


    A constantly growing and shrinking memory pool is indicative of poor GC usage.

  • Lol I would never artificially perma-limit FPS in my own Game, sure I would likely default VSYNC to be ON, and also have a 60 FPS Limiter as Default that can easily be turned OFF or set to another Number (because Computers do eat much more Electric Energy if you just set it to unlimited), but definitely no hardcoded Limit of some sort.


    Edit: There would be an Options Menu before Game Start, in case the Graphics Options crash for some reason btw. That way they could be changed beforehand to see what crashes and what doesnt.


    But remember, that Game comes after I consider GT6 to be finished enough to leave it (I would still maintain it from time to time), so this can take till 2019.

    I don't say, your "insert whatever" is bad. I'm only showing ways for making it better.
    GregTech Website
    Patreon really helps me out. If you consider funding the development of GT, so I might be able to do it fulltime, why not?
    GregTech 6, the Main Thread, Bug Reports go here too.
    I'm also on #gt-dev on irc.esper.net, if you don't want to make a Forum account just to contact me.
    (I'm there almost every day, when I'm at my own computer. Yes you can drop bugs and suggestions there too)

  • It's just that developers easily forget about putting heavy processes where they don't belong. Such as updating a whole chunk when only one block changes state.

    I had no other choice on that one btw. The only other choice would have been TESR, and that would have lagged far more in most cases. (see RotaryCraft and other Mods from Reika that exclusively use TESR, and that in the most inefficient way possible).

    I don't say, your "insert whatever" is bad. I'm only showing ways for making it better.
    GregTech Website
    Patreon really helps me out. If you consider funding the development of GT, so I might be able to do it fulltime, why not?
    GregTech 6, the Main Thread, Bug Reports go here too.
    I'm also on #gt-dev on irc.esper.net, if you don't want to make a Forum account just to contact me.
    (I'm there almost every day, when I'm at my own computer. Yes you can drop bugs and suggestions there too)

  • I wasn't blaming you greg. It happens to everything in MC.


    But at the same time, yes, i was pointing out that updating something on every tick is madness as far as MC is concerned.


    Last time i played RotaryCraft though, animations themselves were not an issue. But machines that updated every tick definitely were.

    Caching is of great importance.


    As for FPS limiters, i am yet to see one done properly. In a perfect world, FPS limiters would operate in such a way that it would cut out all other processing IF a frame is going to take more than 16.666 ms. (or whatever timestep one chooses) That is, render and input would be done first and foremost, then as time permits do everything else after that.

    This would mean that when someone like me has enough power to run at 300 FPS most of the time, i would have about 5 times as much processing time for other things. But when something HEAVY happens, it would be distributed over several frames rather than handled in one single frame.


    And of course, multithreading where it's needed as well as using the GPU as much as possible aside from just rendering stuff.


    But most every games i've played... Most every applications i've used... They all tend to do things "NAOW" when they really don't have to. It's like old Windows doing defragmentation of harddrives in the middle of a gaming session, whereas these days it's set up to defragment when i am not using the PC and as soon as i start using the PC in the middle of a defrag (which doesn't happen anymore because i have SSD's now) it would pause the defrag.

    That's what i want from other games... Sharing the load. And if for some reason there's still not enough time to run the game, then it would slow the game down rather than the renderer. And if that's not something i want, i would have to reduce the renderers priority myself or increase my processing power.

  • just a little bug report, in the glue recipe, for the listing showing gregtech's sticky resin being used, when you mouse over it, it spazzes out rapidly switching between the gregtech sticky resin and the ic2 classic sticky resin every frame, while not switching at all prior

  • I've run into an inconsistency with the Sluice compared to the Crusher and Sifter.

    Auto Item input/output doesn't seem to work the same way.


    32e991433d.png

    The crusher pulls and pushes items out of and into the crates just fine, no need for covers.


    But for the sluice...

    d2436086d0.png

    No items are pushed, no items are pulled. Unless i use conveyor covers.

  • The Sluice is a LEFT->RIGHT Machine regarding Items, TOP and BOTTOM are for Fluids. The Textures indicate what Face has what automated. Most Machines have an Automatic Item Input and a Non-Automatic Item Input (that is where the Automatic Fluid Input is) and vice versa. The Tooltip only shows what Side would accept Input if you piped it in for example.


    As for the Resin thing, I have my Resin Items autoconvert to the IC2 Variant. Seems like somehow there is a GT6 Resin visible somewhere, that I need to hide.

    I don't say, your "insert whatever" is bad. I'm only showing ways for making it better.
    GregTech Website
    Patreon really helps me out. If you consider funding the development of GT, so I might be able to do it fulltime, why not?
    GregTech 6, the Main Thread, Bug Reports go here too.
    I'm also on #gt-dev on irc.esper.net, if you don't want to make a Forum account just to contact me.
    (I'm there almost every day, when I'm at my own computer. Yes you can drop bugs and suggestions there too)

  • It's just that developers easily forget about putting heavy processes where they don't belong. Such as updating a whole chunk when only one block changes state.

    I agree.

    But i don't agree with the maintainability aspect. You can write maintainable code and still have it run great.

    You *can* write maintainable code and have it run great, and you can also write what

    has come to be accepted as "maintainable" code and have it run, well..., "well enough"

    (which should read "well enough for now, with the current feature set, and no mods").

    Today, "maintainable" typically means, at least, SOLID + tests (and probably also full

    TDD). Now SOLID has its virtues, but it also has its costs, and over-use of the "D" for

    Dependency Inversion Principle is a recipe for pure gaming poison and sluggish code.



    As for GC, a properly used GC is just as efficient as a manual one.

    Sure. But (at least as I understand it) it performs better at throwing stuff away

    and worse at keeping hold of it. For something with lots of semi-persistent

    state (like a game), the solution is to gradually migrate long lived stuff to another

    region of memory, where a different garbage collector is better at keeping hold

    of it and worse at throwing it away. When it eventually is thrown away, that's

    when you get the momentary lag spike. I'm guessing that both chunks and mobs

    are long-lived enough to royally fragment this "Old Generation" region when

    they expire.


    But anyway, "new"/"delete", "malloc"/"free", and garbage collections of all varieties

    are all vastly inferior to the large, pre-allocated, unmanaged, contiguous array.

    Dress it up in a pretty Entity-Component-System, praise Posixeidon/Thurideos

    (delete as appropriate), and move on to implementing something more fun.

  • I don't say, your "insert whatever" is bad. I'm only showing ways for making it better.
    GregTech Website
    Patreon really helps me out. If you consider funding the development of GT, so I might be able to do it fulltime, why not?
    GregTech 6, the Main Thread, Bug Reports go here too.
    I'm also on #gt-dev on irc.esper.net, if you don't want to make a Forum account just to contact me.
    (I'm there almost every day, when I'm at my own computer. Yes you can drop bugs and suggestions there too)

  • can someone help me out with the math here? i seem to be missing something. this is a very simple beginner electrolyzer setup for testing if i am able to electrolyze (x dust type x) the output is 256 RU which is the maximum input for the dynamo. the dynamo says it outputs 88 EU, but with the efficiency it comes out to 60.5 EU. with the 2 EU/m loss this should come out to 58.5 EU. i tested a dust that takes 32 GU and it worked fine, but when i went up to pyrite (48 GU) it stopped working. am i mathing incorrectly somewhere?


    EDIT: does it have to do with the efficiency of the burning box and steam turbine?


    i've worked out that my RU output is 217.6, but i don't quite understand how that correlates to the average output (88) of the dynamo or it's loss due to efficiency

  • Is that the image you meant to upload? It looks like the output of the Bumblelyzer?

    can someone help me out with the math here? i seem to be missing something. this is a very simple beginner electrolyzer setup for testing if i am able to electrolyze (x dust type x) the output is 256 RU which is the maximum input for the dynamo. the dynamo says it outputs 88 EU, but with the efficiency it comes out to 60.5 EU. with the 2 EU/m loss this should come out to 58.5 EU. i tested a dust that takes 32 GU and it worked fine, but when i went up to pyrite (48 GU) it stopped working. am i mathing incorrectly somewhere?

    The efficiency has already been applied in the stated figure of 88 EU/t output (it's 68.75% * 128 RU).

    Except, you've used the upper figure for input, and the central figure for output...

    Your dynamo should actually be outputting 68.75% of 256 ===> 176 EU/t

    You are also using a second tier electrolyser, so are experiencing the overclocking penalty of 4 * recipe cost.

    (for each tier of machine over the tier of the recipe, the speed doubles and per tick cost quadruples)

    32 * 4 = 128 EU/t (which is less than 176 EU/t, so works)

    48 * 4 = 192 EU/t (which is more than 176 EU/t, so doesn't work)

    So there's good news and bad news: you're generating FAR more EU than you thought,

    but the electrolyser you are using is screwing you over....


    EDIT: also, if you ever have a recipe right on the limit of your dynamo's output, I'd be worried about the

    stability of steam flow though those BC pipes....

  • so because the tier of my recipe is T1 (16-64) because i'm using a T2 setup it's using quadruple the tick cost?


    the B.C pipes are from extra pipes addon and are rated for 2000units/tick haven't had much of an issue so far


    also thank you very much for explaining how the G.T infograph works i understand WAY better how to calculate my output


    Edit: so from HU to steam it's always double, and steam to RU it's 1/3 (even though it states 66.66 efficiency, 768 steam becomes 256 RU, 33.33 efficiency) then you take your RU output value and multiply by efficiency rating? (256*.6875=176EU)

  • Think of HU, KU, RU, EU, etc. as forms of energy, whereas steam is just

    a volume of steam. The actual volume of steam is completely arbitrary.

    Imagine changing the units from litres to cm^3 - we'd have 1000x as

    many units of steam, but the boiler wouldn't be 1000x more efficient.

    The turbine efficiency is expressed in terms of the energy efficiency,

    and is expressed as simple dimensionless number because the units on

    both energy in and energy out cancel. If the turbine were "33.33" efficient

    then it wouldn't be "33.33% (dimensionless)" but "33.33 EU per 100 steam",

    because the units are different and don't cancel.