Posts by Uristqwerty

    Rather than all players, one option is to send the sound events to a square of chunks, and when a player crosses a chunk boundary, check if the newly added row (of the, say, 5x5-chunk active sound square, not the far larger player view/chunkload square!)) has any active sounds in it. The client would be in charge of the final radius check for whether a sound is actually audible at the moment, and for discarding the sound source when they cross a chunk boundary out of its update square. That also gives players a more-or-less intuitive way to fix ghost sounds, if any future bug or poorly-timed exception could ever leave one around.

    Your idea about the stack size limit is great, but I think that the accept limit is better to be (64 - N) * one craft, and the output threshold (63 - N) * one craft, otherwise only 1 upgrade is enough.

    Each upgrade reducing space makes sense if you assume that a) the upgrades are less expensive than letting one extra input/output accumulate in a single machine, and b) that the player knows about the upgrade and is willing to go to the trouble to make them at all. If the incremental advantage of a single upgrade is too small, it would never advance beyond a very niche feature. So I figure that the common case should be one upgrade, and allow multiple as an advanced option. It's also easier to reason about how much space there is when you have 5 upgrades and a recipe like 1*A + 2*B = C.

    Players generally don't like the idea that if they set up a component production line, it will consume inputs until every machine input and output along the way has a full stack of intermediate products. As a result, they tend towards overly-smart logistics networks like AE, where the network is in charge of putting exactly the right inputs in so that nothing gets wasted, but I think that it would be nice to have the Factorio-like option of letting full inputs produce natural backpressure with an acceptably-low overhead, so everything can pull directly from storage.


    So, I suggest a "stack size limiter" upgrade. If N > 0 are present in a machine, then it will only accept N * one craft items in each input, and will not process if any output has more than (N - 1) * one craft items. Having modes to only affect input or output would also make sense.


    I don't know how best to handle cases where different recipes take different counts of the same input item, perhaps a "recipe lock" upgrade would also be useful.

    (There are a few old topics on similar ideas, but none of them are in the suggestion forum. They are also old enough that I feel re-visiting the idea might be worthwhile)


    Unfortunately, a nontrivial portion of people playing IC² are only doing so because it's required to progress in a modpack that they are playing. Many of them are used to being babied by other mods, do not care to RTFM, and then go whine to each other when stuff breaks because of their lack of knowledge, creating a negative impression of IC² to players who might otherwise enjoy the mod but haven't tried it yet.


    I propose that when you first place machines down, they *don't* draw power yet. When you first open the GUI, there is a slot with an angry-red background and a bubble of text explaining the situation (and giving a moment to shout RTFM! to those players that didn't):


    In order to connect the machine to whatever wires touch its casing, you need to insert a fuse (or fuse substitute):

    • A fuse, but for gameplay reasons those are fairly expensive (especially at higher tiers). Still cheaper than having a machine explode, but not something to take lightly, especially since the fuse is completely destroyed in the act of saving the machine.
    • An (un/insulated?) wire of the appropriate tier. Far cheaper than a fuse, but because it's enclosed within the machine, there are no guarantees that it will burn out fast enough. 50% chance of saving the machine, and the text can hint that in-world cables are a better alternative to fuses.
    • Any metal item. If you really just need EU to flow, and don't mind the occasional shower of sparks coming from the GUI while it's open, you can stick any metal item in the slot. Absolutely no protection, though. Maybe there's even a chance that the current flowing through will weld the item into place, making it hard or impossible to remove? If you want to cause havoc for somebody else, throw a literal wrench in the works, then crank the voltage!


    The fuse slot would only be accessible to players, so if they mess up they will have to go to every affected machine and insert a new fuse. As a small bonus, it might encourage structure designs that put some thought towards maintenance access.


    That crash is caused by CCC, actually. It is trying to modify BlockDynamicLiquid to enable finite water, but MCPC+ has already made its own, incompatible, changes to BlockDynamicLiquid. Disabling infinite water through MCPC+ instead of CCC would probably fix it, though there may be other issues due to MCPC+.


    Although, maybe GregTech is enabling CCC's finite water which is causing the crash, so it might still be indirectly due to GregTech.

    Possible reasons to prefer litre:

    • Litre is shorter than milliBucket, so fits in GUIs better.
    • They are both equal to 1/1000 of a cubic metre. (a bucket exactly contains a 1 m³ source block, unless there is some sort of magical space compression)
    • Certain YouTubers are less likely to be confused by the (lack of a) prefix, such as saying "3000 milliBuckets" when "3 Buckets" would mean the same quantity, with less than half as many syllables.
    • "milliBucket" can be seen as a leaking implementation detail when displayed directly to users, though by now they are used to seeing it.
    • An excuse to call 1000 buckets a megalitre?

    From what has been mentioned in this thread already (I might be misinterpreting some of it, though):


    1) Every 3x3 chunk has exactly one vein
    2) A vein is generated by replacing stone with ore (vanilla mechanics, at least; stone or the biome's stone-equivalent)
    3) Veins are generated at a random height, even far above the surface
    4) A vein can successfully generate 0 blocks of ore, if there isn't any stone to replace at the randomly-chosen height (like the old iridium ore)


    It sounds like, for the hypothetical <y10 ore, you would have an equal chance of finding it in any chunk searched, regardless of the terrain height, so the advantage of mining in extreme hills is that even if it doesn't contain the ore you are looking for, there is less air for 0-block veins to generate in, so you are more likely to find something.


    Since you would have to mine 48 blocks horizontally, plus a vertical shaft roughly in the centre anyway, it wouldn't be much harder to just dig entirely vertical shafts from the surface, and note the coordinates if you find something that might be needed in the future on the way down to <y10. Also, if you encounter a vein of something-you-don't-need-right-now after the first 20 blocks down, you can stop there and move on to the next 48² area with less than half the blocks dug than you would require to proceed horizontally. On a server, you could even trade coordinates of unwanted veins as a piece of valuable information.

    On the subject of floats from a few pages ago, there's also fixed-point integers, where you simply do all the calculations in units of 1/2n (multiplication and division take a bit of extra work, though). Turning a 32-bit int into a 28-bit int with a 4-bit fraction (or a 64-bit long into a 60-bit long with a 4-bit fraction) would allow for significantly more precise cable loss without all of the downsides of using floats.


    Might cause too much complexity, though. (especially from a user's perspective)

    I've noticed a relevant similarity between GregTech and BTW. In both of them, crafting one of all the machines isn't the end of the tech tree, the tech tree extends to automating all the machines, which usually requires many of each, as each automated setup becomes increasingly single-purpose.


    GregTech would feel most tedious if you have a single wall of one of each machine, and spend most of your time waiting for your only industrial centrifuge to finish processing.



    On an unrelated subject, based on what has been said of the new ore distribution, wouldn't the most efficient mining method for them be to make 1x2 or 2x2 shafts (1x1 abusing open hatches or ladders as platforms to safely dig straight down from also would work) from the surface at regular intervals, looking for a cluster of the material you want?

    Deal with it. 8) No, seriously, once you get into it, it's an improvement, apart from having no source attached so you have to manually include that, which sucks a little. But hey, at least you dont have to look at obfuscated Minecraft code :P


    I doubt it's an improvement if you a) want to (potentially) support a non-Forge loader, b) have any reason to temporarily edit some debugging code into vanilla or Forge code, or c) have an idea to improve Forge, but do not have a dev environment set up to make custom builds of it.


    Also, it is possible to compile without Gradle, though it takes a lot more work. Search Searge's twitter for a link to MCP (903, I believe), then find some way to get at least Forge's field and method signatures to compile against. Proceed as normal for pre-1.7 Forge development.

    Vanilla 1.6.4 already has the scoreboard sidebar GUI, so it might be possible to make an entirely serverside mod/plugin for it. (for example, quietly /playsound a few notes, pop up the sidebar with a list of players currently recording for 10 seconds, and send a chat message stating who just started recording)

    http://i.imgur.com/zbTd05W.png
    Its one hopper that I have to use, since I can't afford an electric filter in my survival world (this is my test world). It shouldn't be a redstone problem, as just placing an item into the hopper works fine. It has something to do with the pipe.
    If anyone has a better suggestion for separating two items in a pipe, I'm all ears :P.


    You can reduce the size of that redstone, from 4x4x1 to 3x4x1: http://i.imgur.com/9pCN9Of.png (also, one less strong signal on the bottom, so less likely to accidentally power something below.)


    Without a chest cart, you CANNOT send something up


    Sure, you can send items upwards.


    Using the newer collision mechanics is possible, but takes a lot of space (due to random x and z velocities) and/or requires a moat to catch items that don't make it all the way to the top: http://i.imgur.com/Dm8JvVS.png


    A tower of droppers also works, and can even be fairly compact (3x1xX, with the occasional bit sticking out to strengthen the signal for towers over 16 tall): http://i.imgur.com/YCbABlv.png

    Would it be practical to implement a config system similar to Forestry's gamemodes, where the difficulty options are separated into a directory containing different presets (plus user-made difficulties), and you only need to edit one line of the main config to set which one is used?


    I think that it would be useful for FTB, since they could put both the easy and hard configs in the same pack (and take less effort for players to switch between them), and it would also permit an official easier or harder config to be available by default.

    One difference I have seen between Direwolf and Etho (at least from the videos I have watched so far) is that Etho seemed far more willing to cut out long stretches of time spent building, or otherwise working on stuff, while Dire seems to try to put as much as possible into the actual videos, and make each video interesting at the same time, which makes some of the larger constructions you see elsewhere impossible.


    Also, Dire doesn't use nearly enough spruce in his buildings. (spruce logs make nice support pillars/beams, and adding a pattern of spruce planks to an oak plank floor (or a pattern of oak to a spruce floor) makes it look far nicer (birch planks also work))

    From right before the massive rush of almost-at-page-1000 posts:



    http://benchmarksgame.alioth.d…=gcc&lang2=java&data=u64q
    C is about twice as fast on average, meanwhile Java uses WAYYYY more memory than C. However, as people have mentioned, the major determining factor is simply the ability of the programmer.
    In my experience programming, the #1 thing killing performance was always memory related stuff. Too much naive creation of objects quickly kills performance, no matter what language. At the very least C++ encourages the usage of objects on the stack rather than the heap, so you don't have as large of a cost allocating objects.
    For those complaining about how unsafe C is, C++ lets you be as safe as Java, and without the horrendous garbage collection. Of course C++ is also much harder to learn, never mind use properly, but that would at least stop Mojang from making utter idiots work on Minecraft. At the very least they'd hire people who knew a thing or two about proper optimization.


    Disclaimer: I am an expert C++ programmer who may be biased towards C++.


    JVM heap allocation is rather fast, though, as all it does is take the next N bytes from a large chunk of memory. Deallocation is handled by the GC simply moving all objects there that are still in use to a slightly less temporary chunk of memory, and setting it to allocate from the beginning again.


    For safety, the JVM guarantees that a reference is either null or points to a valid object, and is able to check whether the referenced object is the right type at runtime. Due to the GC, you never have a case where the object pointed to by a pointer was just deallocated elsewhere (perhaps another thread, even?), and now refers to an invalid chunk of memory. Getting similar results in C++ is probably possible (I don't use C++ very often), but likely takes extra work (so lazy or less educated people are likely to do it incorrectly).


    Summary: Java heap allocation can be less expensive than C/C++ heap allocation, and the GC allows more built-in pointer safety (though, since it is built-in, it can't be omitted selectively where doing so would improve performance).