Posts by Namarius

    Did you test in Multiplayer, Bloody? And is the Server running Forge 1286?

    Some reportet texture issues with newer Forge version. I'm using Forge 1286 for weeks now and never saw any problem. So it is likely a problem only occurring in special cases.

    I am doing the same as Blodd Asp and can't see any problems at all and I am running a small server on 1286 with a few mods.
    Never had any problem with Forges above 1263 and always used them.

    Does anybody have problems with fastcraft 1.16 and opencomputers robots? Because I've got some ConcurrentModificationException and destroyed robots on my server.

    To be fair, almost all our players do. In fact, two of them have bases in the 33k and 48.5k regions specifically. Considering there's only 3 players active right now, and two of them are that far off, that kind of says something. (There used to be 7. I even upgraded internet and doubled the server's RAM and put in an SSD and RAID0 all to make the server super fast and stable. It now goes to waste! It is nice to have 953μs average tick time, though!)

    I would like to have a server like that. What are the specifications?

    Namarius thx you! It is help me so hard. How can I'm reward you? :thumbsup:

    Well it was a test and your reaction answers my original question. So here comes my warning to you.

    It is not safe to disable autosave because your world will not be saved and therefore not safe against failures. So that's why Minecraft saves so often to make your progess safe.

    Back to Greg: Could it be that Gregtech itself increases the CPU load for saving to an ridiculous amount? Saving 2000 active chunks shouldn't take that much calculation power. (I smell some kind of too deep function calls [and I think I have to blame Forge for this])

    @Serious7 try to disable autosave with /save-off and look if the lag is still there. If its gone away, wait 2 or 3 minutes and make a manual save with /save-all if its lags horribly then you have the same problem as I am. You should activate autosaving after this testing with /save-on.

    I have tested this over some time and I think the real problem relies anywhere in the saving of the world. Every other source had been thrown out by the way.

    Does somebody have any to solve this problem without some workaround like view distance reduction?

    I wouldn't say its "realism", it's more like the basic idea behind the minecraft universe where a block is an will be always a block with a length of 1 on all sides. Just look at hoppers they have the same problem.
    And I hate it when I stand on a bounding box which is not high enough to jump on the next block layer.

    Gregs implementation of bounding boxes is future proof. So he doesn't change it. You can always dismantle a pipe and configure it somewhere else and place it back in.
    There is another nice thing with his bounding boxes when it comes to Mobs, they behave as they should and doesn't jump around as they get mad by smaller boxes.

    You can use the equivalent. Several vanilla blocks have "variant" states. For example, dirt is minecraft:dirt with variant=dirt. Podzol is minecraft:dirt with variant=podzol, rather than being minecraft:podzol. It's even more dumb than before.

    Did you ever tried to use XML? It's the same problem. There is no right answer to multiple data definition ways, their all wrong in some way.

    "Q: I cant fix all of the Problems in my Multiblock for starting it, HALP!A: Go start the Multiblock anyways. It will run as long as there is at least one solved Problem. And when you reach MV Tier you can use Duct Tape. Also the next people who ask that get banned for two reasons, 1. Didn't read Q/A and 2. You didn't check if it would run with that Problem being still there."

    i have read q/a, machine won't start at all that's why im asking in forum. please do not respond if you have nothing to say

    But to get an advanced assembler he needs aluminum which needs an electric blast furnace.

    But he never said anything about the electric blast furnace. He said just "THE MACHINE". So without any more info we know only one thing. Is was a bad designed question ^^

    I use G1GC since ages now even that some say that minecraft does not work with it. As a general rule of thumb Java shoundn't get more possible memory than the long living and short living object actually need so that the gc runs short and frequently.

    Beside of that, FastCraft solved some unexplainable long term pauses (>=0.5s) at chunk loading at least I think so because it wasn't the gc.

    I don't understand the EBF problem. All you need is 4 (2x Tin cables), 4 Basic Steam Turbines, 4 Small Coal Boiler and 2 LV Energy Hatches. Both Input Hatches will be feed by two Turbines each. Now you wait till the Boilers and Turbines are full of Steam. After that you use one of this things to create Aluminium nugget:
    Ruby (32000EU easy but costly)
    Green Sappire (32000EU easy but costly)
    Sappire (32000EU easy but costly)
    Ruby Dust (40000EU possible and less costly)
    Green Sappire Dust (40000EU possible and less costly)
    Sappire Dust (40000EU possible and less costly)

    I think that using the High Pressure Boiler could be more save but I didn't tested it.

    Every time I see the veins in their pureness I think to my self: Is is intended that they have a special direction? I mean all of them seems to align to one axis. Its like the randomization isn't normalized distributed over all axes.

    So I smell a bad RNG or a dirty use of RNG ;).

    I think video tutorials are bad by design and the reason for this is the huge amount of redundant information aka transition frames. Another problem relies in searching though videos for a specific part which is really painful. So I always prefer text plus pictures against videos.

    I try to make Ores less NEtwork intensive and then THAT happens

    Mmmh network optimization...
    Lets try the test world again. Same seed, same spawn.
    Well 67066 Byte for 123368 GT Ores. This would actually make ~0,54 Byte per Ore a reduction of nearly 24 times based on my previous research.
    Have tested it online and it works. GT is playable again.

    Thanks Greg

    It is byte (ID of Packet), int (X), short (Y), int (Z), short (Data) on my Side + the Netty prefix to say that it is my Channel (either Byte or Short, or at least I hope it is that nowadays).

    Sounds reasonable.

    Made another test with a fresh new world. The default view distance of 10 results in 21 chunks squared or 441 chunks.
    In these chunks are 123,391 GT ores using our data structure as it would result in 123391 * 13 Byte = 1,604,083 Byte or ~1.5298 MiB without netty prefix. This result is nearly the same as OPIS states: 1.529 MiB.
    Seems like OPIS only counts data payload.
    Another interesting thing is that the packet (S26PacketMapChunkBulk) only need 1.223 MiB.

    Conclusion: Does somebody knows a method to reduce the view distance on the server side by player?