Minecraft Forums

Quote from AbsentFuture»

Dragnoz' video doesn't work in 1.9?/1.10+ due to the fact that they change the datatype of 'Health'. It now requires a float value instead of an integer value meaning that you need to be extremely precise. Which means a huge amount of commandd blocks.

Makes me think of Zelda. It would be a really nice addition to combat.

You could almost build that out of command blocks. It would probably be pretty rickity, though.

This sounds right up my alley. I'd like to ask what sort of functions you're looking to fill. Are we talking about basic animations/adding character to the server, or game modes and whole new game mechanics?

Name: Patrick
Age: 28
Skill with Command Blocks: 6.5/10 (there are people WAY better than me, but I'm getting there!)
Free Time: Average 2-3 hours / day, with a few days a week off, though I can't promise all of this time.
Do you have Skype?: Yup
Social media websites?: None at the moment.

A few of the things I've built with command blocks:

- An Armor Stand selection tool for mapmaking.

- Dodge / sprint-up mechanics.

- Player state detection for combo moves.

- Prototyped custom move sets for enemy mobs.

I'm based out of Vancouver, Canada. I live by myself, bartend for a day (night?) job. My biggest hobby at the moment is Minecraft command blocking, and I'm trying to use it to get geared up for software development school starting January. I'm also working my way through Dark Souls, and I tend to enjoy metroidvanias, driving games, roguelikes. Any more questions, shoot me a message!

Hey, man, just so you know, you're asking for an absolute TON of extra features to be added in there. It's probably 10-15 hours of work for someone skilled to make this. Asking nicely and being patient and willing to do your own research will definitely guarantee you a better response.

For making custom mobs, I would recommend going on youtube and looking up "Custom Mobs in Minecraft." The videos by Jragon14 are quite good, and fairly simple to understand.

There are a bunch of methods for making mobs spawn naturally, but probably the easiest is to have another mob turn into your custom mob. My personal approach would be to make a random number generator and assign a random number to each new Zombie (or whatever) that spawns, then turn a certain set of those into your new mob, which can be done mostly through the /entitydata command (though you can't turn a Zombie into Pig or whatever - they have to stay the same time). Another way to do it is to /execute a /summon at your tagged mobs to bring your custom bad guys in, then /kill the tagged mobs, or /tp them into void to avoid loot drops.

Stalking and killing the player is a tough one. I feel like you'd get better results by faking it than by having them actually hunt the player down. You could drop a trail of markers behind the player and have your monster follow that trail. Mr. Garetto had a 1-command creation for making any one mob follow any other one mob. If you have your custom mob follow an invisible pig or something, you can check for when he's close enough to the pig and then teleport the pig to the next oldest marker and delete the previous one.

As for the block breaking, man, I'm not too sure how you'd do it. Mobs don't break blocks the way players do - you can do it with a /fill or /setblock air command, but that instantly removes or destroys it. There's no digging time involved. If you wanted to simulate that, you'd... probably have to check for every type of block in the game to determine what it's digging difficulty was going to be, and then set a timer on the monster based on the block type.

A lot of that's just guesswork, though.

Incidentally, I do like the stalking/hunting-you-down mechanic. It would make survival games waaaay more tense.

Good luck, man!

Edit: I realized after I posted that it's really not what you were looking for. I thought about it, and put together a solution for you. It's not going to help with horses that have already been ridden in your world, but if you install it, you'll have it working from this point on.

The stat.horseOneCm stat is for players riding horses - specifically, it counts 1 point for every 1 centimeter moved in in the game. Now, that's for players, but, you can transfer that to a dummy objective that's set up just for the horses.

// Initialization
/scoreboard objectives add riderDistance stat.horseOneCm
/scoreboard objectives add horseDistance dummy

// Running on repeat:
/execute @a[score_riderDistance_min=1] ~ ~ ~ scoreboard players operation @e[type=EntityHorse,c=1] horseDistance += @p[] riderDistance
/scoreboard players set @a riderDistance 0

I tested this, and it works just fine.

The first command executes from any players who have a riderDistance score higher than 0. At each of those players, it adds that value onto the horseDistance stat for the nearest horse. The next command then sets the riderDistance score back to 0 for all players (which will, incidentally, initialize the system for all newcomer players).

Hope this helps!

Np! I find it helps to share this stuff. It gets it cemented into my brain, and makes me try things that I wouldn't otherwise. Have fun with the modded playthrough!

One thing I just discovered: even though the negative levitation effect makes entities fall slowly, they still take just as much damage as if they'd been falling full-speed. To combat that, you're going to want to apply a high jump boost or resistance effect to them while they're traveling downwards, as well.

Hey! No worries.

Quote from LuciusKane»

I'm aware there's a "range" command, and I was originally going to try and find out how to use that. I was thinking if I specify an x,y,z coord, set the range to 1 to make it a 3x3x3 area, then anything entering that area would have the effect applied to them automatically right? Am I misunderstanding that?

There's no range command, but you've got the right idea. It's done using target selectors. The part that reads @a[dx=3,dy=15,dz=3]... that's the target selector, and the stuff inside the square brackets are the arguments. The @a means "all players," and the stuff inside the square brackets [] filters it down so that it's only players inside that volume of space, originating from where the command is executed. The "execute" commands determine where that point is (more in that in a minute). The dx=,dy=,dz= determine the size of the field. dy is the height, so change that value if you want it to be different!

The other way to do it is using the range target selector. That would look something like this... @a[r=1]. The trouble with range is that it works like a sphere, instead of a cylinder, so you'd need to apply the effect multiple times, all the way up the shaft. That's actually not a bad way to do it, though. It would make it really easy to customize the height of the shaft on a per-shaft basis (again, more on that in a minute).

Whichever method you want, you need to execute the command from a specific point in space. That's where the range and volume bits are measured from. That's what the /execute command does. /execute @e[type=ArmorStand,name=elevatorUP] executes at all the armorstands named "elevatorUP," and the ~-1 ~ ~-1 causes it set the origin point of that execution to -1 x, -1 z. It's just because of the way the volume target selector arguments work.

As far as this effecting everything that goes into the field, it's actually only targeting players right now. If you want to affect mobs, too, change the @a[dx=3,dy=15,dz=3] to @a[type=!ArmorStand,dx=3,dy=15,dz=3]. the type=!ArmorStand is so that the elevator its self doesn't get lifted upwards.

Quote from LuciusKane»

I used Armor Stands because they're easy to move around, and it makes the process way more dynamic. Otherwise, you'll have to do a separate set of command blocks for every elevator in your map. You can make armor stands invisible and un-clickable by players with a couple of tags, applied with the entitydata command.

/entitydata @e[type=ArmorStand,c=1] {Invisible:1,Marker:1,Invulnerable:1,NoGravity:1,CustomName:elevatorUP}

This command will give those properties to the closest armor stand to you. They're all pretty self-explanatory, except for "Marker." Marker means that players in your world won't be able to click or right-click the armor-stand, meaning they won't accidentally give it their items or destroy it. If you want to remove those armor stands later, you need to set the Marker tag back to 0.

Quote from LuciusKane»

Also, as for moving downward, would it be possible to instead base this off of if the player is looking up or down?

Yeah, that would totally work. Ahh... My head's a bit fuzzy right now, and I've got a project I'm working on, so I don't think I'm going to fully get into explaining it. However I'll give you some links and the code and you can do your own research if you want the details for yourself.

/effect @a minecraft:levitation 0 0 true
execute @e[type=ArmorStand,name=elevatorUP] ~-1 ~2 ~-1 /effect @e[type=!ArmorStand,dx=3,dy=15,dz=3,rxm=-90,rx=-30] minecraft:levitation 1 3 true
execute @e[type=ArmorStand,name=elevatorUP] ~-1 ~2 ~-1 /execute @e[type=!ArmorStand,dx=3,dy=15,dz=3,rxm=-30,rx=30] ~ ~ ~ /summon AreaEffectCloud ~ ~ ~ {Age:4,Duration:6,ReapplicationDelay:0,WaitTime:0,Radius:0.5,RadiusOnUse:-0.5,RadiusPerTick:0,Particle:depthsuspend,Effects:[{Id:25,ShowParticles:0b,Duration:1200,Amplifier:-1}]}
execute @e[type=ArmorStand,name=elevatorUP] ~-1 ~2 ~-1 /execute @e[type=!ArmorStand,dx=3,dy=15,dz=3,rxm=30,rx=90] ~ ~ ~ /summon AreaEffectCloud ~ ~ ~ {Age:4,Duration:6,ReapplicationDelay:0,WaitTime:0,Radius:0.5,RadiusOnUse:-0.5,RadiusPerTick:0,Particle:depthsuspend,Effects:[{Id:25,ShowParticles:0b,Duration:1200,Amplifier:-6}]}
execute @e[type=ArmorStand,name=elevatorUP] ~ ~7.5 ~ /particle spell ~ ~1 ~ 1 7.5 1 0 100

Phew... that looks WAY worse typed in, but it works like a charm. If the player looks straight ahead, the float stable. If they look up or down, they move in those directions. Try copy + pasting that into a text editor and turning word wrap off to see the commands in a bit more of a readable fashion.

The reason for the /summon AreaEffectCloud instead of the /effect command is that you can't apply negative effects directly to players, so instead you have to do this clunky workaround. Here's a reddit thread with the details of how it all works.

Anyway, if you want to change it so it works in a sphere around the armor stands, it shouldn't be a problem either.

Quote from LuciusKane»

Finally, is there a way I can set a maximum height for the elevator?

execute @e[type=ArmorStand,name=elevatorUP] ~ <strong>~7.5</strong> ~ /particle spell ~ ~1 ~ 1 <strong>7.5</strong> 1 0 100

So, this is a bit confusing, but particles basically only originate from the center of their execution, so if you execute this from the same location as your levitate command, you'll have particles extending through the floor. To change that, you need to execute it from half way up the shaft, and also make its height by half the shaft. So, the bold bits there in the code snippit above? Those need to = half your shaft height.

Right, that's my explaining done for the day. Hope that helps!

For the levitating, it's the /effect command. For the particles, it's the /particle. For detecting where the player is, there are a bunch of ways to do that, but I think you're looking for the "select targets by volume" under target selector arguments.

The following command will do the levitation part of what you're looking for. I set it up so that it will be active above any armor stands named "elevatorUP." (this makes it easy to have several of them, or to move individual ones around later, if needed).

execute @e[type=ArmorStand,name=elevatorUP] ~-1 ~ ~-1 /effect @a[dx=3,dy=15,dz=3] minecraft:levitation 1 1 true

By its self, it'll be a little bit awkward, as the effect lasts for a second, even after stepping out of the portal area. My usual fix for this is to run something like this first.

effect @a minecraft:levitation 0 0 true

This removes the levitation effect from all players. Just keep in mind that if you use the levitation effect for anything else, the two are likely to butt heads and possibly cause your contraptions to break or behave strangely.

For the particles, you want the /particle command. I'm not sure what the bedrock effect you speak of is. I just used the spell particle. You can find a link to all the different particle types under the particle command.

execute @e[type=ArmorStand,name=elevatorUP] ~ ~7.5 ~ /particle spell ~ ~1 ~ 1 7.5 1 0 100

Soooo.... altogether, we have this. Run the first one in a repeating command block, and the rest in chain command blocks set to always active.

effect @a minecraft:levitation 0 0 true
execute @e[type=ArmorStand,name=elevatorUP] ~-1 ~ ~-1 /effect @a[dx=3,dy=15,dz=3] minecraft:levitation 1 1 true
execute @e[type=ArmorStand,name=elevatorUP] ~ ~7.5 ~ /particle spell ~ ~1 ~ 1 7.5 1 0 100

For the downward elevation, it's a lot trickier, as (to the best of my knowledge) you can't detect when someone is crouching unless they're moving along the ground (i.e., sneaking). I'd say your easiest option is just to make a down elevator shaft.

I saw that one, too. It looked really nice, and I'm proooobably going to poach it sooner or later as well!

effect @a[] 2 0 0 true
execute @a[] ~ ~ ~ detect ~ ~ ~ double_plant -1 /effect @a[] 2 1 <strong>3</strong> true

You want to run this in a chain of commands (so the first one is a repeating command block that is either powered or set to always active, and the rest are chain command blocks set to always active). The first command removes the effect, so that you're not left slowed after you step out of the bushes. The second command checks to see if there's tallgrass on the block the player is standing on. You can change the emboldened number on the second line to affect how slow the player goes.

Keep in mind, if you've got other command block creations that use the slowness potion effect to do things, this might not work, and there may be weird interactions between them.

Have fun!

Also, if you want it to affect mobs as well, there are a bunch of ways to do that, but the easiest is probably just to duplicate both commands, and change anywhere it says @a into @e.

Well, I don't really use comparators for timer systems (I don't trust their update rate, though that might be totally ungrounded), but here's some code that should work just fine.

// Initialization commands...
scoreboard objectives add Ticks dummy
scoreboard objectives add Seconds dummy
scoreboard objectives add Minutes dummy

scoreboard players set TimerSystem Ticks 0
scoreboard players set TimerSystem Seconds 0
scoreboard players set TimerSystem Minutes 0

// Run-time commands...
scoreboard players add TimerSystem Ticks 1		// Run this one in a repeating command block. The rest go in chain command blocks.
scoreboard players test TimerSystem Ticks 20		// Checks to see if the Ticks score >= 20
scoreboard players add TimerSystem Seconds 1		// CONDITIONAL CHAIN COMMAND BLOCK
scoreboard players set TimerSystem Ticks 0		// Also conditional chain command block
scoreboard players test TimerSystem Seconds 60		// Checks to see if Seconds score >= 60
scoreboard players add TimerSystem Minutes 1		// CONDITIONAL CHAIN COMMAND BLOCK
scoreboard players set TimerSystem Seconds 0		// Also conditional chain command block

It's a pretty simple pattern. Use the scoreboard TEST function to see if you're in the range you're looking for, and then execute two conditional command blocks afterward if it's successful.

This particular method only works if you've got one global clock (or rather, you need to duplicate it for each global clock you're running).

If you're doing it on a player-by-player basis, you can actually do it in fewer commands, but it means you can't use fake players (like I'm doing with the fake player named "TimerSystem" up above).

On a player-by-player basis, I'd use these runtime commands, instead.

// Run-time commands... Run the first one as a repeating block, the rest as regular chain blocks.
scoreboard players add @a[score_Ticks=20] Ticks 1
scoreboard players add @a[score_Ticks_min=20] Seconds 1
scoreboard players set @a[score_Ticks_min=20] Ticks 0
scoreboard players add @a[score_Seconds_min=60] Minutes 1
scoreboard players set @a[score_Seconds_min=60] Seconds 0

Hope that helps!

Hey, everyone,

I'm a little stumped on a project, so I thought I'd throw it out there and see if anyone has any ideas.

TLDR: Looking for visual indicators that I can apply to a player's HUD (or something equivalent).

I'm building a custom combat system with command blocks. The last main cornerstone I'm working on is power-up attacks (hold down right click, release when charged to fire attack). However, I'm a bit stumped on creating an indicator as to when the attack is charged.

Anyone have any thoughts on this?

I was messing with applying blindness or night vision really briefly to make the screen flash, but I've found both kind of give me nausia (something I've never experienced playing games before). It's not terrible if I immediately remove it, but it's still a bit jarring.

The XP bar crossed my mind, but its resolution is super low unless the player's at high levels, and I'd frankly rather not write off the built-in XP system for this.

Particles are mostly pretty slow and kind of unwieldy. I don't mind making custom sounds and putting them in a resource pack, but I'm worried they'll wind up being a tad annoying if they get played repeatedly, and they're not likely to be accurate enough if I just use the in-game sounds. My guess is that I can't really add/take away the enchantment glow of the weapon without using the replace command...

Any feedback / ideas are appreciated. Thanks!

Hey, OP, may I offer an alternative solution?

Rather than having the command tellraw stuff into your chat, why don't you just use JSON Creator for Minecraft to create a book that displays whatever your currency scoreboard objective is to @p (which will always be the player reading the book)?

I think that you'd be better off using the scoreboard to tag players who are ready to shoot a fireball, rather than the testfor. It would also make more sense to use chain command blocks, rather than your standard impulse types.

scoreboard players tag @a[] add doShootFireball {Inventory:[{Slot:-106b,tag:{display:{Name:"Fire Ball"}}}]}

This makes it multiplayer compatible, too. You can then change the target selectors in the blocks that summon the fireball to look for the doShootFireball tag, like so:

/execute @p[rym=135,ry=180,<strong>tag=doShootFireball</strong>] ~ ~ ~ /summon Fireball ~ ~ ~-1 {ExplosionPower:0,direction:[0.0,0.0,0.0]}

Hi, everyone!

Thanks for taking your time on my post. The title is pretty self-explanatory - I'm wondering if this is possible.

I figured out a way to detect which direction the player is moving (surround the player with a circle of armour stands and check which one he/she is closest to. Combine with scoreboard objectives for walkOneCm / sprintOneCm / crouchOneCm / etc. to verify motion). If I can get something like this to work in multiplayer, I figure I can combine it with detecting the direction he/she is facing to determine key press and build some pretty dynamic combat enhancements (dodge moves, various charged-up weapon or spell abilities, etc.).

The trouble is, I don't think this would work in multiplayer due to getting tangled up in other peoples' armour stands. I was looking at Crushed Pixel's idea for assigning unique ID's via scoreboard, but I don't think it gets me any closer to tying a bunch of entities to another single entity without having a totally separate set of command blocks for each player (or without having a ton of latency due to iterating).



If anyone has any ideas, I'd be stoked to hear them!