Okay, well, I've succesfully made the XP bank. It was fairly easy, but I'm quite proud of it . Here are some pictures, explaining how it works:
Firstly, you want to start with the scoreboard commands. This is what we will store our levels with. Just for an example, I am only able to store and withdraw 5 levels at a time. You can configure this by adding extra deposit/withdraw buttons, and changing the amount of levels.
As you can see, it's very simple. The player can then use the [TAB] menu to see how much experience they have stored in their bank balance. The experience they have on them is shown above the equipment bar.
Only thing with this system is, everyone can see it. There is no way to show the scoreboard ONLY to one player.
As for the message you wanted, scoreboard values can't be shown in chat. I'm not sure how you would do this..
Well, I wasn't going to, as it's something I think I already know how to do anyway.
But since you sound hungry for something to try:
An "advanced" dialogue/quest system where entering an area will activate a set of long dialogue sequences (that will go through different command-blocks of chat-text, only once). But, when the player achieves something; the dialogue will switch to a different set of text, and entering the same area as before will give a new conversation...etc.
Edit: If you want to take it a step-further, try adding the ability for the dialogue to have temporary 'quests', that activate when the player finds something (so, activated when they enter a different area, but only speaks when they go back to the chat-area). When the chat+new quest objective for this temporary one is finished, it goes back to the normal, linear, quests+dialogue.
Not really that challenging, but I know some other peeps would like it, too. And, who knows, maybe you approach it in a much-more efficient way than the re-worked one I have in mind (I already had this before /scoreboard was added; it used lots of ring-counters). Anyway, the one I'm building is being built into the map; so, unfortunately, even if I did finish a really smart, really compact, version, I couldn't easily share here :C
I'll see what I can come up with. If I can't, we'll see what you've invented
Okay, well, I've succesfully made the XP bank. It was fairly easy, but I'm quite proud of it . Here are some pictures, explaining how it works:
<snip>
Thanks!
~Feare_104
Interesting.. I also been attempting a xp bank that does something similar - not as complicated with the TP-ing & display (just yet) but does something similar with a dummy scoreboard variable.. I would guess it may be quite easy to add an extra command block or so to post the messages etc
I cant take full credit for this though - as I found a Youtube video of something similar - just altered it to see if it'll work with command blocks...(If I can find the video I'll post the link)
I won't go into a series of screenshots as the layout is quite easy (I think) to understand
Firstly need to set up the 'variable' for the account
/scoreboard objective add xpbank dummy XP
Redstone layout [shown from side]
CB = Command Block
R1/R4 = repeaters set to either '1' or '4' ticks
COM = Comparitor
(Arrows shows the way they have to point)
Red lines on side/top of blocks are redstone dust
& I guess you can guess what are redstone torches
I can stack these side-by-side (with 1 block apart) & have each set up with '1','10','100' etc for each level you want to deposit/withdraw
To add (or deposit) into your savings account
Lower command block [CB] has
/scoreboard players add @p[r=2,lm=10] xpbank 10
IF you (player within 2 blocks) have at least 10 Levels (lm=10l) then ADD to 'xpbank' a value of 10
Upper Command block has
/xp -10L @p[r=4,lm=10L]
Take 10 Levels from your actual XP level
To remove (or withdraw) from your account
Lower Command Block
IF 'xpbank' has a value of at least 10 then Remove '10' from 'xpbank'
Upper Command Block
/xp 10L @p[r=4,lm=10l]
Add 10 levels to players XP level
NOTE: - I THINK you can remove the 'lm=10L' in the upper command block lines as the block will not work unless the lower block condition is true - I didn't realise this until after I tried this out
I would think you could add a command block above the upper one with a 'show display' or 'TP' command in it & it'll also work
e.g
if it was a tp command you would get tp'd once you've pressed the button
if it was a 'display' command you would get the display
I've not fully tested this in a multiplayer environment - unfortunately the server I go on (Where I have limited MOD access) doesn't have 'scoreboard' enabled for some reason (I've been told it's something to do with a plugin conflict or something like that) but I've tried it in a single player & it seems to work just fine
Interesting.. I also been attempting a xp bank that does something similar - not as complicated with the TP-ing & display (just yet) but does something similar with a dummy scoreboard variable.. I would guess it may be quite easy to add an extra command block or so to post the messages etc
I cant take full credit for this though - as I found a Youtube video of something similar - just altered it to see if it'll work with command blocks...(If I can find the video I'll post the link)
I won't go into a series of screenshots as the layout is quite easy (I think) to understand
<snip>
I've not fully tested this in a multiplayer environment - unfortunately the server I go on (Where I have limited MOD access) doesn't have 'scoreboard' enabled for some reason (I've been told it's something to do with a plugin conflict or something like that) but I've tried it in a single player & it seems to work just fine
Your idea is a lot more clear. Mine was a rough one, just started from scratch. I use /tp as it helps avoid bugging with comparators. I find a lot of the time that, when the player hits a button, the comparator activates, but doesn't switch off. I assume this only happens when using /testfor, though.
One thing about your design, though. You can see the command blocks. Here is what I suggest doing.
Leave the button wall where it is, but move the whole design to the left. Have the button power a repeater, and have a block infront of that repeater to do the inverter. You should understand what I mean.
EDIT: I tested your design, and as I said previously, the comparator didn't switch off. The player would have to leave the targeted radius, then re-enter the area to be able to deposit/withdraw again.
Your idea is a lot more clear. Mine was a rough one, just started from scratch. I use /tp as it helps avoid bugging with comparators. I find a lot of the time that, when the player hits a button, the comparator activates, but doesn't switch off. I assume this only happens when using /testfor, though.
One thing about your design, though. You can see the command blocks. Here is what I suggest doing.
Leave the button wall where it is, but move the whole design to the left. Have the button power a repeater, and have a block infront of that repeater to do the inverter. You should understand what I mean.
EDIT: I tested your design, and as I said previously, the comparator didn't switch off. The player would have to leave the targeted radius, then re-enter the area to be able to deposit/withdraw again.
~Feare_104
true the command block are at the front, but I guess it depends on how you build the bank around it..
In my case I was/am planning to build a 'counter' for them & have 'deposit' on one side of the bank & 'withdrawal' from the other side
As for the leaving area to reset the comapritor ...weird
- it worked for me in single player when I first built it but when I rebuilt it again in another single player world - it didn't check for level properly but it DID allow you to keep pressing the button & adding to xpbank without moving out of range...
I'm going to have to wait until I'm back in work to check the working version against the one I built at home - I might've done something wrong when I made the picture or something
Well, I wasn't going to, as it's something I think I already know how to do anyway.
But since you sound hungry for something to try:
An "advanced" dialogue/quest system where entering an area will activate a set of long dialogue sequences (that will go through different command-blocks of chat-text, only once). But, when the player achieves something; the dialogue will switch to a different set of text, and entering the same area as before will give a new conversation...etc.
Edit: If you want to take it a step-further, try adding the ability for the dialogue to have temporary 'quests', that activate when the player finds something (so, activated when they enter a different area, but only speaks when they go back to the chat-area). When the chat+new quest objective for this temporary one is finished, it goes back to the normal, linear, quests+dialogue.
Not really that challenging, but I know some other peeps would like it, too. And, who knows, maybe you approach it in a much-more efficient way than the re-worked one I have in mind (I already had this before /scoreboard was added; it used lots of ring-counters). Anyway, the one I'm building is being built into the map; so, unfortunately, even if I did finish a really smart, really compact, version, I couldn't easily share here :C
Okay, here's what I've done so far:
Upon entering an area, dialogue plays.
When re-entering that area, that dialogue changes.
The events linking of the dialogue change upon re-entering the area.
As for the temporary quests.. Can you evaluate? I'm thinking of how I would do it, and I have ideas, but none of them are solid. It's really frustrating me
true the command block are at the front, but I guess it depends on how you build the bank around it..
In my case I was/am planning to build a 'counter' for them & have 'deposit' on one side of the bank & 'withdrawal' from the other side
As for the leaving area to reset the comapritor ...weird
- it worked for me in single player when I first built it but when I rebuilt it again in another single player world - it didn't check for level properly but it DID allow you to keep pressing the button & adding to xpbank without moving out of range...
I'm going to have to wait until I'm back in work to check the working version against the one I built at home - I might've done something wrong when I made the picture or something
BTW - found the
I think the problem is when we do the radius targeting. In the video, he didn't use the radius, and used a dropper instead of a command block to give the item.
Because we do the targeting argument, the command block is always sending a signal through the comparator. So, instead of having only ONE input signal (which should be [score_NAME_min=#]), it's taking TWO ([score_NAME_min=# and [r=#]), meaning it cannot output them correctly.
I suppose the difficulty of making temporary-quests depends on how you've built your quests.
Mine's a rather flawed circuit in the sense that as the player progresses (unlocking the next dialogue-phase) so does the delay for the new set of dialogue to start; in other words, dialogue 1 (coloured as iron) has I think a 16-tick delay before it starts, and dialogue 2 (coloured as gold) has 2 ticks added to it; afaik, I have no way to change this. It's hardly a big problem, unless you're making LOTS of these; and there's probably an obvious fix I'm missing.
Anyway, as for temporary-quests, it seems like it should be easy for the way I've build this - a case of just creating a secondary (temporary) dummy scoreboard, and another line of dialogue :>
In theory, it should be really easy for me, but perhaps I've now doomed the whole thing xD
Anyway, just gotta xpand this out a bit, I hadn't given myself enough space *cuts 'n' pasted some things about*
Pics+explanation of my thing should be up soon; I'd like to see yours (mine's rather...big*)
*innuendo not intended
Mines massive, cause of all the repeaters and pistons.. It's really rather terrible, but it gets the job done, at least. I'm not using the dummy scoreboard for mine, but rather /testfor @a[r=#] ... It seems to work rather well.
not sure what you mean by that command; I'm still using a testfor command for the area the player steps in, the dummy scoreboarding is so my circuit knows when to switch more easily+wirelessly. The rest is really simple, but just involves some special designs I came up with (for the Ring Counters):
Hopper-clock cycling through all testfor commands used (one to check area, and any # for checking scoreboard amount)
Area for there to be a delay between each new line of dialogue (I've set it really short in the example, though; so it's easier to see what it is)
Mini's™ special Ring-Counters, designed several months ago by myself soon-after the locking repeater were released. It uses a pulse to cycle to the next output on the counter, and will cycle back to the start. AFAIK (not tested much) it's infinitely-stackable, and reasonably compact :>
It's not the most-compact of it's kind (I've seen a slightly shorter, but actually taller, hopper-based design by minecraftpg5; but it doesn't really give me what I need
RS-latches to lock the RCs after they reach the end (you may wonder why I don't just remove their recycle-feature, but that's because I was thinking of adding the ability for the player to press a button to hear dialogue again !)
testfor commands checking for increase in scoreboard score, that pushes a piston down to unlock the next RC in the sequence.
For Side-quests: A different scoreboard dummy counter is made; else, it should work in a similar way, and I think i have a good idea how to block any current normal-quests from continuing their dialogue temporarily (else, that wouldn't matter too much if the player may have stay there a bit long to hear the other quest)
Pics soon, hopefully.
I'm using redstone loops on command blocks like this: /testfor @a[r=4] . Off that I run a comparator into a T-Flip Flop, then a sticky piston to pull away the block. This stops the dialogue playing a second time. The T-Flip Flop sends a one-tick pulse to a piston which pushes a block which starts the next loop. Another piston pushes the block down so the signal is only one tick.
So, pretty much, the system goes /testfor, T-Flip Flop, dialogue, next loop.
I think I'd need to see your system to get what you mean...
And I still think mine's probably larger...
Also:
For this, all I'll be doing is subtracting a score-point from the main 'Quest' dummy, while adding one to the 'Side-Quest' dummy. Why take one from the main one? Well, because it already locks into place (only stating it again if the player presses a button), I could easily just have it count-back temporarily, and when the side-quest is done, it just adds it back.
I think this should work 100% fine; as, think about it, if they have a Quest dialogue they've not heard yet, and use this, it'll take it away from them for a moment, so when they enter they hear the Side-Quest dialogue, and it will give it them back.
If they've already listened to the latest dialogue from Quest, then they won't end up getting anything extra - it'll just take it away+give it back
I <3 my RC circuits
Well, seems better than what I've come up with I'll leave you to it. Post it here once you've finished!
Well, it's rather messy. It's still colour-coded+partially labelled, but still a really inefficient layout, so I might recreate one with a layout to make a bit more sense
xP
Very-nearly done btw; wbu?
Everythings everywhere, it's not colour-coded OR labelled... It's disgusting.
Darn, stumbled into a bit of a problem (nothing major, but it's annoying).
Because my clock's inverted when inactive (i.e. on when not running to the dialogues); it meant that when it added the Side-Quest dummy, and all the quest-dummy point-testfor CBs get a pulse from the update w/their value (gets decreased, remember?); it means that I had to switch it around. But this gives the problem of why I had it like that in the first place - delay.
Now, all repeaters attached to it can only be at a 1-or-2 tick delay, which means double-sized delays :S
Ah well, I co--
Wait.
I'm a god-damned idiot.
I'm already using Hopper-timers, I could just add more items in 'em to slow down the delay
*awesome revelations while typing*
some pics:
Key:
Red = RS-latch output (locks the dialogue so it can no longer continue); for timing purposes, this is attached to the second-last dialogue output (I am unsure if this will always be the case)
Iron/Gold/Diamond = The stages of dialogue, ordered first-to-last. Note that the first one is designed here to NOT require you completing any objectives beforehand.
Emerald = To show where the next Quest-step could go after Diamond
Wood:Oak/Pine/Birch/Jungle,Oak-Logs = Order of the command-blocks for the dialogue strings
Lapis-circle = (lower-left); simply where you stand for it to move to the current dialogue sequence
Green = Hopper-timer (the main+only clock used), and the player-position /testfor commandblock
Cyan = The 'Track' (as I like to call it); when the player is in position, the clock's output will run though this in order to cycle through the Ring-Counters used (like I said earlier, my ring-counters need and on/off toggle to advance)
Brick = The Side-Quest dialogue sequence; note the extra command blocks used to subtract +re-add one point from the main Quest (so the Side-Quest can always take priority)
Not Added (but easily done) = because of the way I've designed this, you could easily add some redstone branching off those RS-latches for a player to press a button to hear them again - I was thinking of having a button there to just repeat the last dialogue-sequence, though; or maybe just repeat all that haven't been completed (which can only be max. 2 at a time anyway).
Close-up of the RC circuits I use; this one is the Side-Quest one, but they're all identical. Note that they give outputs on two sides; this is extremely useful for making additional commmand-blocks at the other side in for either debugging, or as extra scoreboard-dummies for specific moments; or, like I used, an easier alternate-output that I used for the RS-latch output.
Figured I may as well clarify it before you ask; this here was just for me to add/remove/delete/see points for the dummy-scoreboards 'Quest' and 'SideQuest' (Side-Quest) - lapis=Quest; Quartz=Side-Quest.
This thing may seem reasonably advanced; honestly, though, I don't think any of it is at all. There's a lot of redstone there visually, but it's much simpler than my poor-descriptions make it seem. Just a scroll through command blocks for chat, then lock. All branching from one running testfor clock (that makes it messy as I hadn't pre-planned positioning xP)
I'll try to make a cleaner, more efficient (and perhaps extra-compact), version. As for now, though, this seems to work perfectly-well...
Not sure if I should make a tut. for the RCs I use, as I know there's more-compact designs out there (probably)
Anyway, glad I made that!
I've got so many uses for it; like I said, I wanted this as an improvement for a much less-laggy, more-efficient version. But this is better than I thought I'd turn-out with - the feature of Side-Quests is really great to have
Soooo Excited to be able to slap this all over my map! I've got several town-areas (one futuristic, one western, one fantasy, and one steampunkish-Victorian, so this thing was a must! *I be happy*
EDIT:
WHAT!?
NUUUUUUuuuuUUUuu! I wanted to see what you'd made!
~mini
Haha, wow! This is wayyy better than what I came up with. Would you be able to make a tutorial on how to build? Take a look at mine, and use the same layout - It'll make it easier.
Also, don't forget to add screenshots to the tutorial! Just PM me with the TUT when it's done
Oh geez; a tut for this will be very hard to do...mainly because of the compacted RCs I use (although they're the only ones to work in this design afaik).
Okay, like I said before, I'll make a cleaner-designed version, as this one looks a bit overwhelming, and is a little too inefficient...I'll [i]try[i] to make a tutorial for each individual section (i.e. the clock, the RCs, the latches; etc.) - but I'll probably also add a .schematic file for a version that explains itself, and a more-compact version if I have the time.
Will be back soon to post all this.
Also, I enjoyed building that; was thinking of having a 'Request Mini' thread for amateur redstone devices ('cause I'm no pro; but when I get an idea I can usually nail it)
I'm not much of a wiz either.. I don't really study latches and gates and all that stuff, but I usually come up with my own designs. They are usually very inefficient..
Firstly, you want to start with the scoreboard commands. This is what we will store our levels with. Just for an example, I am only able to store and withdraw 5 levels at a time. You can configure this by adding extra deposit/withdraw buttons, and changing the amount of levels.
Command: /scoreboard objectives add Money dummy Money
Next: /scoreboard objectives setdisplay list Money
Okay, let's dive into the command blocks!
We'll start with the "Deposit" section.
^^ This will make the player teleport to a pressure plate at the set coordinates to deposit ^^
^^ The layout I am using ^^
^^ This will remove 5 experience levels from the player when they deposit ^^
^^ This will convert the 5 experience levels into a dummy score, which can be found in the [TAB] menu ^^
^^ This will teleport the player back to the Bank lobby ^^
^^ This will inform the player that they have successfully deposited 5 experience levels ^^
^^ This will teleport the player to a pressure plate at the coordinates to withdraw ^^
^^ The layout I am using. It's pretty much the same as the "deposit" system ^^
^^ This will teleport the player back to the lobby at the Bank ^^
^^ This will remove 5 dummy score from the players scoreboard ^^
^^ This converts the 5 dummy score into 5 experience levels, which the player then recieves ^^
^^ This informs the player that they have successfully withdrawn 5 experience from their account ^^
------------------------------------------------------------------------------------------------------------
As you can see, it's very simple. The player can then use the [TAB] menu to see how much experience they have stored in their bank balance. The experience they have on them is shown above the equipment bar.
Only thing with this system is, everyone can see it. There is no way to show the scoreboard ONLY to one player.
As for the message you wanted, scoreboard values can't be shown in chat. I'm not sure how you would do this..
I'll update the Weather section now.
Thanks!
~Feare_104
I need ideas for devices to create! What do you guys want to see?
Feed me your ideas!
~Feare_104
I'll see what I can come up with. If I can't, we'll see what you've invented
Thanks
~Feare_104
I cant take full credit for this though - as I found a Youtube video of something similar - just altered it to see if it'll work with command blocks...(If I can find the video I'll post the link)
I won't go into a series of screenshots as the layout is quite easy (I think) to understand
Firstly need to set up the 'variable' for the account
Redstone layout [shown from side]
CB = Command Block
R1/R4 = repeaters set to either '1' or '4' ticks
COM = Comparitor
(Arrows shows the way they have to point)
Red lines on side/top of blocks are redstone dust
& I guess you can guess what are redstone torches
I can stack these side-by-side (with 1 block apart) & have each set up with '1','10','100' etc for each level you want to deposit/withdraw
To add (or deposit) into your savings account
Lower command block [CB] has
IF you (player within 2 blocks) have at least 10 Levels (lm=10l) then ADD to 'xpbank' a value of 10
Upper Command block has
Take 10 Levels from your actual XP level
To remove (or withdraw) from your account
Lower Command Block
IF 'xpbank' has a value of at least 10 then Remove '10' from 'xpbank'
Upper Command Block
Add 10 levels to players XP level
NOTE: - I THINK you can remove the 'lm=10L' in the upper command block lines as the block will not work unless the lower block condition is true - I didn't realise this until after I tried this out
I would think you could add a command block above the upper one with a 'show display' or 'TP' command in it & it'll also work
e.g
if it was a tp command you would get tp'd once you've pressed the button
if it was a 'display' command you would get the display
I've not fully tested this in a multiplayer environment - unfortunately the server I go on (Where I have limited MOD access) doesn't have 'scoreboard' enabled for some reason (I've been told it's something to do with a plugin conflict or something like that) but I've tried it in a single player & it seems to work just fine
Your idea is a lot more clear. Mine was a rough one, just started from scratch. I use /tp as it helps avoid bugging with comparators. I find a lot of the time that, when the player hits a button, the comparator activates, but doesn't switch off. I assume this only happens when using /testfor, though.
One thing about your design, though. You can see the command blocks. Here is what I suggest doing.
Leave the button wall where it is, but move the whole design to the left. Have the button power a repeater, and have a block infront of that repeater to do the inverter. You should understand what I mean.
EDIT: I tested your design, and as I said previously, the comparator didn't switch off. The player would have to leave the targeted radius, then re-enter the area to be able to deposit/withdraw again.
~Feare_104
So far, I have got down the following:
I'll countinue working!
~Feare_104
In my case I was/am planning to build a 'counter' for them & have 'deposit' on one side of the bank & 'withdrawal' from the other side
- it worked for me in single player when I first built it but when I rebuilt it again in another single player world - it didn't check for level properly but it DID allow you to keep pressing the button & adding to xpbank without moving out of range...
I'm going to have to wait until I'm back in work to check the working version against the one I built at home - I might've done something wrong when I made the picture or something
BTW - found the
Okay, here's what I've done so far:
I think the problem is when we do the radius targeting. In the video, he didn't use the radius, and used a dropper instead of a command block to give the item.
Because we do the targeting argument, the command block is always sending a signal through the comparator. So, instead of having only ONE input signal (which should be [score_NAME_min=#]), it's taking TWO ([score_NAME_min=# and [r=#]), meaning it cannot output them correctly.
Thanks
~Feare_104
Mines massive, cause of all the repeaters and pistons.. It's really rather terrible, but it gets the job done, at least. I'm not using the dummy scoreboard for mine, but rather /testfor @a[r=#] ... It seems to work rather well.
I'm using redstone loops on command blocks like this: /testfor @a[r=4] . Off that I run a comparator into a T-Flip Flop, then a sticky piston to pull away the block. This stops the dialogue playing a second time. The T-Flip Flop sends a one-tick pulse to a piston which pushes a block which starts the next loop. Another piston pushes the block down so the signal is only one tick.
So, pretty much, the system goes /testfor, T-Flip Flop, dialogue, next loop.
It's simple, but takes up a lot of space.
Well, seems better than what I've come up with I'll leave you to it. Post it here once you've finished!
~Feare_104
Everythings everywhere, it's not colour-coded OR labelled... It's disgusting.
I gave up on the design. It's up to you, now!
~Feare_104
Haha, wow! This is wayyy better than what I came up with. Would you be able to make a tutorial on how to build? Take a look at mine, and use the same layout - It'll make it easier.
Also, don't forget to add screenshots to the tutorial! Just PM me with the TUT when it's done
Thanks!
~Feare_104
In mean the one you made was AWESOME thx
Haha, no problem! Thanks for checking it out
I'm not much of a wiz either.. I don't really study latches and gates and all that stuff, but I usually come up with my own designs. They are usually very inefficient..
~Feare_104
Happy to help!
~Feare_104
Hehe, my pleasure!!!
~Feare_104