• 0

    posted a message on Journeymap (1.10-5.2.4)- optimal settings for fast mapping?

    I've been doing a mapping service for the server I play on. It's an essentially Vanilla server, but people are allowed to use clientside mods as long as they're not hacking the server. I like to have a very thorough JourneyMap, so I figured I'd release it to other people.

    Thing is, now people want a map of the overworld, which is 8000 blocks out from 0,0 in all directions. A lot of territory to cover, even in spectator.

    So now I'm trying to map the server in spectator - I can't get access to the world data, so running the automapping option on a single player version won't work. I've got the mapping radius cranked way up, but I can't seem to find a way to get it to take a map update more than every few seconds.

    Anyone more familiar with the settings have any suggestions as to how to optimize JourneyMap for map updates? (If it can be cranked to the point where frames suffer, that's fine; I can use more reasonable settings when playing normally and just use the insane settings for dedicated mapping sessions.)

    Posted in: Mods Discussion
  • 0

    posted a message on Biome color comparison

    I'm looking for leaves, not grass, and kinda want in-game views since textures can be misleading...plus that way i can check it out on the resource packs the server tends to use as well.

    Posted in: Discussion
  • 0

    posted a message on Biome color comparison

    I'm trying to figure out what biome I want to do a build in. It's supposed to be Yggdrasil, the Norse world tree, so obviously, biome type matters a lot - plenty of leaf blocks involved in this build. What I'd love to be able to do is get a 1 block wide strip of each biome, side by side, that I can see each leaf block type in, side by side.

    Does anyone know of a good way to make this sort of comparison? It's a personal choice so please don't say "use jungle" - jungle is already ruled out as being too vibrant to fit the Norse theme.

    Posted in: Discussion
  • 0

    posted a message on What is your dumbest death ever?
    Stupidest recent one: Flattening out a desert area during the day waiting for night so I can kill Endermen with my looting 3 sword. I hear bubbling lava under me, wonder where the lava is, keep digging, and gleefully throw myself into the lava pool 3 blocks below with my brand new looting sword.

    Or maybe it's getting ganked by pigmen because I shot a golden sword thinking it was a blaze's...appendage.
    Posted in: Survival Mode
  • 0

    posted a message on Enchanting Statistics Project
    For those who don't like reading: This is presently a survey gathering data on the information an Enchanting Table gives you and the results of completing an enchantment. If you want to contribute, go here and answer the questions: https://docs.google.com/forms/d/1k_M20nd0iUNW165TyopORysc-PUBg_UuceSCK-RviQM/viewform?usp=send_form A link to the results will be posted here when available.

    According to the statistics on effective enchantment of diamond equipment as presented by the folks at www.minecraftenchantmentcalculator.com, it is safe to say that enchanting at level 30 will generally produce ideal results. While there are a few areas that do not have peak probabilities, the difference between the peak and the level 30 probability is never more than a couple of percentage points. This, combined with the vastly reduced cost of high level enchantments, means that the old tactic of manipulating bookshelves around the enchanting table is no longer all that useful.

    Instead, we have a new system that gives us a sneak peak at the first enchantment that will be selected on a given item at a given enchantment level. This data provides an opportunity to statistically model what other enchantments are likely to be present. In turn, this would allow players to make an informed decision about their enchantment choice.

    Enchantment possibilities are primarily controlled by a random value known as the Enchantment Seed. This Enchantment Seed is saved with your game and will only change when you make an Enchantment. While there is an extremely large number of possible seeds, the data on the first selected enchantment provided by the game can help model what manner of secondary enchantments will be available.

    There are several levels of analysis that could produce increasingly detailed models. At the first level, we can record what Enchantment we were told to expect, what the item being enchanted was, and what enchantments the final product actually had. At the second level, we can record what the level requirement and expected enchantments were at the lower 2 levels of enchantment. Higher levels would involve recording data from other enchantable items, but this is impractical because checking a list of items other than the one being enchanted would be a tedious process, and would be needed not only for the initial data collection, but also when applying the results in regular gameplay. As such, I will only be collecting data for the first 2 levels of analysis.

    If you want to contribute to this project, simply bookmark this page and bring it up when you are doing enchanting in-game. All questions related to the first level of analysis (as described above) are considered required, but those extra questions relating to the second level of analysis are optional. And deciding to contribute is by no means binding - make contributions whenever you feel like it. The more people who contribute to this, the faster there will be enough data to compute usable results. I'd like to have several thousand points of data at least; a daunting task for one person, but a trivial one if the entire Minecraft community were to contribute.
    Posted in: Discussion
  • 7

    posted a message on Skin Protrusions...wait, that sounds bad.
    One thing that would be really cool, especially for the youtube community in Minecraft, would be having the second layer of a skin (or even doing a third layer) that is visible even through armor.

    The intent for this is not to conceal the level of armor you are wearing (indeed, it might be a banned feature in the PVP community because of that possibility), but for things that would logically be outside of the armor to be visible. For instance, my skin is a fairly classic image of Odin, complete with the epic grey beard (which Tolkien made famous when he gave Odin his eye back and called him Gandalf). However, when I'm fully armored, he looks like a guy with a mustachio and an eyepatch. Long haired characters would similarly benefit - how many long haired women (and men, for that matter) have you met who leave their hair tucked inside their jackets?). It would also allow for use of a tabard, hood, or other such outerwear. (If you're wearing a waterproofed cloak under your plate mail, your plate mail is going to rust and you are going to be very uncomfortable).

    Given how skins are processed - being hosted on Minecraft.net - it might be rather difficult for this to be done as a mod. But it would be a cool upgrade to skins.
    Posted in: Suggestions
  • 0

    posted a message on Help with efficient delay circuit (signal in, wait 12 minutes, signal out) for mass production smelter
    Sounds like it'll do the trick. I'll have to mess around with it a bit to figure out how vertical I can make it...and what the devil it's doing internally. My redstone skills are pretty rudimentary, so I can't just look at that and piece everything together.

    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Help with efficient delay circuit (signal in, wait 12 minutes, signal out) for mass production smelter
    I'm working on a mass production furnace contraption that takes one input chest (trapped to minimize potential for jamming due to improper input) and

    • sorts coal out using a hopper-sort
    • feeds other input into furnaces for smelting
    • feeds sorted coal into furnaces for fuel
    • draws all product from all 16 furnaces and pipes it back up to the output chest
    • disables the chest-minecarts from running while empty to minimize entity lag, prevent glitches from moving unloaded minecarts, and cut down noise in the vicinity of the smelter.
    Because of how compact my design is, I can't fit in a circuit that detects when the input chest has been emptied. Instead, I've decided on a delay mechanism that starts the minecarts 12 minutes after putting items in the input chest. This gives enough time for the chest to drain completely into the minecarts, and prevents the sorting hopper from overflow. Unfortunately, the only way I can come up with for implementing a 162 minute delay is a clock circuit that repeats indefinitely, which is not even remotely effective - sure it'll wait until the end of the latest 12 minute cycle, but it might be 11 minutes into that cycle when I put the coal in - thus, coal backs up into the sorter and ruins it. Oh, there's the other method. The one that requires 1750 repeaters all set to 4 ticks of delay. Not going there.

    The delay I'm trying to produce is at least 700 seconds long - this gives enough time for the first hopper to drain the input chest completely, plus a bit of leeway for draining through the few hoppers in the stream and fully into the minecarts. (Alternately, if anyone could come up with an alternative to my build that will release the minecarts only when there is something in the cart and nothing in the stream above the sorter mechanism, that would be even better, but I can't see how I could do that without going back to my old sprawling prototype.)

    Does anyone have any suggestions? If you want to know the positioning of input and output, here's a picture:

    Since the signs are a tad hard to read, the top right is the input, the bottom left is the output - 2 blocks down and 3 blocks across. There's also a later part of the circuit running along the bottom of the screen from the left into a repeater right below the output, then up the torch tower - this is the only space constraint - the build can't interfere with those. But you've got nothing on the other side, so it's not much of a concern.

    If you want the entire framework already built, here's a link to my testing world: Testworld - there's also a pad I've built for testing purposes next to which I've mirrored the actual position of the input/output streams for easy testing.

    If you're looking around, use /kill to get to the spawn pad. You'll see:
    • To the Northeast - my compacted version of Mumbo Jumbo's simple blaze farm (less its blaze spawner, which goes at the lower end of the little hanging pillar in the center. The objective was to use 1.5 block drops instead of 2 block drops so the killing floor was within spawning range of the spawner.
    • To the West-southwest - my in-progress enchanting experiment. I'm trying to get some hard data on how the enchanting forecast thing can be used to one's benefit. Unfortunately this means numbing amounts of time just cranking out enchantments (and keeping track of what the guaranteed enchantment was), so it's a long, slow process. Lots of chests denoting different things, and the floating enchantment chamber with its hopper chain running to a lava disposal for all the enchanted books I burn.
    • Under the aforementioned floating enchantment chamber: A better designed enchanting room that could, conceivably, be incorporated into a survival world workshop.
    • Next in line sweeping toward the South-southwest: A minecart loader that will fully drain the input chest and only release the minecart when the cart has stuff in it and the hopper between the input chest and the minecart does not. This would lead up to an unloader that would lead to a storage facility.
    • Due south: my first attempt at a smelter design, with awkward sprawly wiring and such.
    • Further south: my second/current attempt at a smelter design - much more viable and efficient...if I can get this 12 minute delay thing sorted out.
    • To the southeast, my steep stair design that uses slime blocks to move players up quickly, if they have a good enough computer. (It's reliable on my gaming-grade laptop, but not my cheap little second hand laptop.)
    So, any suggestions?
    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on 500% slope rapid-climb staircase (high slime block cost)
    I just tested it on my laptop (a much more modest machine - I never intended it to do anything more complex than play a video, surf the internet, or do word processing, plus I haven't done anything to optimize Minecraft on it), and found it had much more trouble because of lag. Walking forward helps a lot, though, running even more so - can get up high enough that the ground is not visible due to render distance, so probably good enough for all practical concerns.)

    If that doesn't work, filling in the back might help - I deliberately left that space below the block that pushes you forward open so I could pull out of the escalator by stepping backwards - no point in going all the way up when testing timing for the first half dozen steps or so). And that's usually what happens when there are lag issues.

    If it still doesn't work, turn the repeaters up to 4 ticks. A bit more delay doesn't effect the speed that much, but might give a computer enough breathing room to run it properly

    And if all else fails, with the steps completely enclosed you should at least be ending up on one of the steps. It should be possible to wire in a button somewhere without too much difficulty that lets you trigger the mechanism from that step up to the top - power the piston you're sitting on and the rest of the circuit will take it from there.

    I'd definitely recommend Creative mode testing so you can decide just how much modification is needed for your computer. SMP builds would probably benefit from having the reset buttons wired in every few steps (if you're not on one, you can go down a step or 2 and reach the last button), since lag tends to be less predictable in online play.

    Edit - another thing you can try if you're having lag issues - the piston that pushes you forward doesn't need to be timed the same as the one that pushes you up. I originally built it with 3 ticks for the forward piston, and 4 ticks to push up - giving the game enough time to register your change in position on the X-Z plane. Having them timed the same is faster, but only if it doesn't break the system.

    Edit 2: Further testing with the laptop and these anti-lag options is now complete. Without any movement, I had to enclose the elevator and turn the upward facing pistons to a 4 tick delay. With this delay, using the default resource pack and a render distance of 9 (with fancy graphics, clouds, and particles all on), it worked just fine. Turning render distance way up or switching to my preferred texture pack (a 128x128 resolution pack I built out of pieces of Chroma Hills and MojoKraft, which I can't use publicly because of ChromaHills' legal stuff) both made it drop me back down in fairly short order. Most people playing Minecraft will have computers at least on par with that laptop (it sometimes has trouble getting youtube's flash program to work), so those measures should be sufficient. If not, it may be necessary to redesign the wiring such that you can fit a 5th tick in on the upward facing piston, in which case you can experiment with 3 tick/5 tick and 4 tick/5 tick versions as well.

    Final Edit: It seems that the Hermitcraft people have come up with a different solution for lag - for whatever reason, the game seems to keep track of minecart positons much more reliably than it does player positions. So, if it's not going to work for you, put a minecart at the bottom and trigger it with a button. Devising a return circuit to drop the minecart off at the bottom again should be a simple process.
    Posted in: Redstone Creations
  • 0

    posted a message on 500% slope rapid-climb staircase (high slime block cost)
    Thanks for the praise, MrDiamond and Captain.

    What specs is your computer to get that fps while recording and running that machine?

    Short answer, a recently purchased gaming computer. Plus, I did a bit of optimization, and ZDSoft's recorder is pretty awesome not eating resources too badly.

    Long answer:

    • CPU: AMD A10-6800K apu @ 4.1 Ghz (x4 cores)
    • Graphics: Radeon R9 270x with 2GB of video RAM
    • RAM: 8 Gigs (7 dedicated to Minecraft when playing, done by editing your profile and turning on JVM arguments at the bottom with "-Xmx7G" as the first argument. I think the default has the arguments on, but with only 1 gigabyte (-Xmx1G) dedicated
    • Task Manager set to give Minecraft "realtime" priority (it's funny how MS decided they'd make that processing priority option actually work when they were making Windows 7 - it's the first time I've ever seen a difference in how a game plays.
    I think that's all the relevant stuff - it's on a basic 7200RPM HDD, so nothing fancy there. In all, including the SSD that Minecraft doesn't run on since it runs out of the Users folder, case, power, etc, the build cost me about $1200. My main plan in designing it (yes, I build my own computers from components) was to have something that outclassed the PS4 in every way. It doesn't quite manage to outdo the 8 gigs of shared RAM on the video side, but it's close enough that I'd rather save the 200 dollars for a crossfire-compatible secondary video card for actually buying a PS4 (as there are purposes to consoles as a secondary gaming system).

    For recording purposes, I also turned off everything fancy I could - no fancy graphics, particle effects turned down, simple lighting, VBOs on (since that's an efficiency booster, not a resource hog.

    And I still couldn't get it 100% perfect - the long elevator spat me out backwards (onto the pusher pistons) about halfway up consistently while recording if I didn't keep walking forward, (which made landing on that top block a little tricky - I've got about a dozen takes that I cut because it looked like the build was spitting me a lot further forward than it actually does). Still, I doubt it'd have worked without that ZDSoft trial program - way more resource efficient than fraps.
    Posted in: Redstone Creations
  • 0

    posted a message on Automated Crafting?
    Lots of good options here. Thanks, guys.
    Posted in: Requests / Ideas For Mods
  • 1

    posted a message on 500% slope rapid-climb staircase (high slime block cost)
    I've gone through a couple of failed and semi-functional versions of this idea, but I've got everything ironed out now (short of the possibility that extreme lag will cause the design to leave you halfway up the stairs. (This is the kind of lag you see when you're loading 300 chunks and trying to record in fraps at the same time, though, so unless you're used to dropping into single digit FPS or play on a completely overwrought server, it shouldn't effect you much at all.

    This design has been tested to carry a player up 250 blocks and forward 50 blocks in 25 seconds. For vertical travel this makes it vastly more efficient than the default flying options in Creative mode. Furthermore it is possible to build a circuit so the next step is to the left, right or behind your direction of travel without using anything more than a few more pieces of redstone dust and a few blocks to put them on.

    Best of all, once you've stepped on to the stairs, the build takes care of things for you - you need not walk toward the next step or do anything to keep yourself in position (after walking over the pressure plate at the bottom of the build). I will producing a youtube video of this in the near future, and Mumbo's come up with a of this and asked for suggestions in turning it into an elevator, so he might be doing one as well. (We might both be inspired by xisumavoid's system in HermitCraft, where he uses a single piston-slime launch to shift between floors of his base.) However, for now, text, screenshots, and a world download will have to suffice.

    First off is the world download, so you can opt to follow along the explanation below using a more dynamic view than just my screenshots. It's posted on my public Dropbox page here. Feel free to abuse my bandwidth limits; it's only a 343kB file. If you look around, you'll see 2 builds - one straight build taking you up 250 blocks (y4 to y254 - as close to sky-to-bedrock as this build can manage), but going forward 50 blocks, and one oddly deformed shape where I worked out the necessary wiring for a left turn, a right turn, and an about face.)

    You'll need the following materials:
    1 stone (or wood) pressure plate - to get the party started. (A button reachable from within the elevator will work too.
    Solid blocks - anything you can wire redstone on - I'm using the fancy new prismarine bricks
    Fixed position blocks - anything that a slime block won't glue to - if you don't have the obsidian, try furnaces.
    Slime blocks - if you don't have a running slime farm, you're not going to be building this very high.
    Redstone dust - 0 tick wires
    Redstone blocks - power that can be moved by slime blocks
    Redstone Repeaters - for timing purposes
    Sticky Pistons - because it needs to move to be an elevator.

    I just finished a video showcasing the build and explaining its redstone, and posted it on youtube. Unfortunately, I don't have a mic, so you'll have to read signs.

    The best way to build this contraption is from the bottom up. You could, in theory, do a top down construction project, but only if you're really sure you're getting the redstone right (not that challenging) and aren't gluing any slime blocks to bits of the build they shouldn't be glued to (much more difficult until you get used to it). So I'm going to start at the bottom, with the activation circuit.

    This circuit activates the whole process. There's a stone pressure plate on that obsidian block in the middle. When the player walks or runs over that, it powers the redstone dust directly below it. This powers the repeater, whose 4 tick delay gives even the slowest player a chance to get onto the next block (hidden within the frame from this angle.). Then the piston next to that repeater activates.

    This is the back of that same circuit - notice the pressure plate within the h formed by the obsidian there? The piston is directly under that h shape, by the way - over is a trio of slime blocks in a horizontal line (one next to the pressure plate, one further away to pull the slimes around the obsidian. The chain of slime blocks then goes left 2, forward 1 and up 2 more (from the screenshot's perspective) and is capped with a redstone block. This is the only one that offsets 2 slime blocks back to connect across to the slime tower and redstone block - this is simply for aesthetic purposes, since you'll actually be able to see into the hole - opening it wider just makes it look ugly.

    This is the top of that redstone block in the previous image (or one much like it - the wiring up here doesn't change unless you need to turn the stair/elevator). A player having walked into the elevator will be facing toward the bottom right corner of the image. Off to the upper right, there is a repeater with a 4 tick delay on it - this leads to the next piston in the series that will push the player further up. On the upper right is a 3 tick delayed repeater leading to the wiring for a piston that forces you to land on each block in sequence. That's all this image is for - the 2 repeaters and their delays. It takes 3 ticks for the player to reliably reach the appropriate height, and a 4th tick for that piston to knock the player into position for the next stage upward.
    Actually - further experimentation shows that 3 ticks for both blocks works just fine, and the geometry of the build prevents the slime blocks from attaching to things improperly. So use 3 ticks for both and save yourself the tenth of a second per stage of the build. (It has the added benefit of synching the piston activation sounds, making it less noisy overall) The world download now includes this improvement.

    This is the rest of the pusher circuit - the redstone wire goes up and over until it reaches the piston that actually pushes you onto the next step (with a non slime block). A couple of things to note - you can see just up and to the right of the piston there's a block one level higher within the area the player will be going up in - this prevents the player from being bounced so far up that he's gone out of reach of the next block's upward push. This can also be used by raising the module by one block every few steps, but the pattern is not very consistent, and 5 blocks up is a good round number for design purposes. Additionally, you'll want to fill in the walls around these pusher units, because it can occasionally squeeze you out the side somehow instead if there's only air there.

    These are the slime blocks connected to each piston in the series - one on the piston, then one back, 2 left, and 2 up. A redstone block goes on top of this last slime block,

    On the right, you can see 3 full stages and the bottom of a fourth stage of the forward-propulsion design described above. The slightly chaotic one on the left is designed to show a circuit that will that the same slime block to redstone block configuration off the direction of travel, and either turn you left, right, or reverse your movement, all while maintaining that 3 tick delay and continuing to provide power onwards to the next construct. The wiring for these is a bit too complex to concisely explain using screenshots and text, so if you want to use them, have a look at the wiring in the world download. There's nothing hidden - all the circuitry is exposed. (Oh, except the repeater-circle connected to a command block that keeps it daytime - that's buried in the stone brick stairs around the edge of this area.)

    For these turning choices, I'm pretty sure there are more redstone-efficient methods; my concern was keeping the timing right, not conserving redstone. If you want to experiment with alternatives, I suggest you place:
    -the upward facing piston and slime block 4 and 5 blocks up from the previous step, in the direction you want to be pushed
    -the horizontal facing piston and solid block needed to push you, on the side opposite where you put the upward facing piston, 7 blocks up and 1 and 2 blocks over from directly above the previous step.
    -and a solid block 8 up from you at the previous step, leaving a 7 block gap for you to get pushed up through.
    From there, add all the wiring the way you want to try it. Just remember that you need 3 ticks of delay so they don't fire too early.
    Posted in: Redstone Creations
  • 0

    posted a message on OptiFine HD (FPS Boost, Dynamic Lights, Shaders and much more)
    Does anyone know how to set AMD's Catalyst Control Center to work with the multi-core chunk loading mode? I can't seem to find a setting for that. Is that just nVidia that lets you tinker with the multi-core usage?
    Posted in: Minecraft Mods
  • 0

    posted a message on [v3.7] AMIDST - Strongholds, Village, Biome, Etc. Finder. [1.7.4]
    Quite an excellent tool. Thank you. It's nice to get a bit of direction for exploration (in terms of looking for nice biome combinations and the like) without having a full map ruining all the surprises.

    Any idea how long it will be before you can add the Ocean Monuments to the list? And mineshafts might be worth adding, if there's any way to do that (unlike the pre-built temples, villages and strongholds, there's no real center point to define a mineshaft, so it might not be as feasible.
    Posted in: Minecraft Tools
  • 0

    posted a message on Automated Crafting?
    Is there a mod out there that works with the current vanilla automation tools (hoppers and such)? I'm thinking something (expensive, probably, since it's just laziness) that lets you pipe stone (for instance) to a special crafting table that automatically converts it to stone brick. Might be useful for some of those megaprojects (if anyone else still does those in Survival) where you might need to convert your millions of cobblestones into a nicer looking block like stone bricks - you can automate the furnace, but you still need to convert the stone into stone bricks a mere 256 blocks at a time.

    I've seen something roughly like this in BuildCraft, but everything I've found on Buildcraft seems to suggest it died around the release of 1.4 or so. I've also seen crafting tables that let you set a specific recipe and have it pull the necessary items from your inventory rather than using the items on the crating grid. And I've seen the crafting dictionary that shows you the list of everything you can make with what's in your inventory. What I haven't seen is a crafting table that can take items from a hopper, use them to auto-craft something, and spit that something out into another hopper.

    If it doesn't exist, are there any modders out there who like this idea? (Obviously the crafting table would need a mini inventory, likely 9 stacks like a dropper or dispenser since there's 9 crafting field positions and thus the theoretical possibility of recipes requiring 9 different items. Probably needs a tenth slot for its output item, which the hopper below it pulls from. And it could be set up such that it only pulls items that are used for the recipe from the hopper above it (rather than getting clogged with, say, potatoes and carrots from a wheat/potato/carrot farm when it's designed to produce bread from the wheat), but I'd argue that's part of the fun of hopper system automation)
    Posted in: Requests / Ideas For Mods
  • To post a comment, please or register a new account.