Considering that minecraft seems to be adding devices that change how they work depending on signal strength i would suggest adding/changing 3 functions in redstone Api
redstone.getInput
To return second variable coding signal strength
redstone.getInput("back") --> "true" , 5
redstone.setOutput
To accept optional thrid variable coding signal strength
redstone.setOutput("back",true,5)
redstone.getOutput
To return secondvariable coding signal strength like getInput
redstone.getOutput("back") --> "true" , 5
Hopefully you see what i mean to convey in this post
Also i believe this change would have low or no impact on existing programs. Could be wrong thought.
Thoughts?
This is something I'll consider when 1.5 is out - until then there's not much point adding it - and it is indeed not simple to get the signal strength.
Won't you be able to tell differences in redstone power by propagation distance? So you just make a multi-path wire from a variable redstone source, and the stronger the signal, the further extensions of the path it will reach and activate. Admittedly, that will take a bit of space, so I guess you can use a line of comparators to digitize it (that's what their for, right?).
I don't see the need for computers to be able to tell redstone signal strength apart, except to save people the effort/expense of making their own signal strength digitizers.
WWWWOoooooowww. I suggested something like this in. . . April. Got ignored. Wonderful to hear it's being considered, even if it isn't my thread. With the Redstone update, I guess it'll be more important.
Yes...well, since they are also providing the means to effectively digitize those different strengths, I'm still not sure I see the need. Particularly if it is not simple to implement.
You do not see? Imagine you want to know how many people look in that chest. How would you setup comparators? How many? And for turtles large external is rarely an option.
Mojang is designing the system to not need computers at all. They aren't adding a set of integrated features that will only be remotely useful if someone has CC installed.
So no, I see this as about as useful a suggestion as having a special mode for interacting with witches. Which might be a fun extra to add, but I'm not voting in favor of it at the expense of PDA development time.
I just like things the way they are. A lot. So I'm not in favor of messing with things just for the sake of messing with them.
But I also feel like most new features need to be challenged to clearly show some definite improvement, a reason that they would be worth implementing. That way there is a clear goal in mind, which is important.
And I honestly would rather have as much development time going into PDA/notebooks as possible, I'm quite fond of that idea.
... So I sat down and just thought about what ChunLing said, for about ten minutes. I'm gonna put it in spoiler tags, because, while it pertains to the topic at hand, it is a rant, and I'd rather not dirty up this page with the like, but I feel it need be said, so pass it on by if you just want to hear my thoughts on the suggestion, and/or my response to Cloudy.
Spoiler
And so I came to this conclusion: Changing something for the sake of change is a better reason than change because it needs it. Needing a feature and then planning around it generally means you are one step behind all the time. This is why a good few mods have a suggestion forum, and why there was a suggestion section on minecraftforum, and eventually mojang.com. If you make a feature that looks useless at first, someone is going to find something to do with it that is awesome for the simple fact that no one thought that feature could be used in that way. Which is why there are a crap-ton of piston door and elevator tutorials, but not a lot of "monorail" tutorials. There are a couple out there, but nowhere near the others, simply because it took one person to do something no one else thought to do.
Now, we have an idea that, months ago, I could only come up with one passable idea for redstone power levels, because at the time, there was no other reason to do so. No, we are about to have a small slew of new blocks and features in Minecraft itself that will need to be interfaced with. Making a register? Weighted pressure pads for you, sir. Lacking a less-lag stock system with turtles? Then get yourself some trapped chests and some buttons! Got something more interesting in mind? Code that s**t and make a youtube video so everyone can see. But what if Mojang had never included pistons? Where would we be? Digging that crap out with our costly picks and putting back. Or the rather ugly doors Minecraft has by default.
Heck, I can think of a few as I type. How about a single-rs line rail station? Noteblocks?
And, what about the awesome coders here on the forum? My amateurish ideas are like hobble-horses next to the Mona Lisas of Nitrogen Fingers, Cruor, MysticT and the like.
Basically what I'm saying here, is just because it does not YET have a good use does not mean it will never have one. And really, I just listed off enough ideas that the relatively small amount of coding that should be required for this (I'm honestly not sure, but I'd think it would be something like a linked list in usage) is more than worth it. And we still do not know the full extent of the Redstone Update yet, so they might make something that would make using ComputerCraft that much more awesome, if only it had this.
So, while I anxiously await PDAs as much as anyone else (I even write personal-use code to interact with a variety of different cases that might arise from such a thing, hopefully one of them will stick when it comes out), I find getting other features in more satisfying. It's the Christmas Present dilema. Do you want one big gift, and then you're stuck until your birthday (at best), or a whole year? Or would you be happier with a bunch of smaller gifts that took up more of your time, or gave more happiness from the sheer fact that they are more numerous, and therefore give more opportunity for discovery and wonder? From a person who has explored both ideas in many forms, I prefer the latter, excepting only a serious lack. I do not consider PDAs a serious lack.
Whew. Okay, so rant over. In response to Cloudy's quote of me, I realize that was the case. I was merely remarking on the. . . imbalance. I was trying to be impassive, but in text voice is hard to do.
So, basically: I like this suggestion. Have since I tried in April. Love that it is getting attention somewhere. Can't wait to see it, and I desperately hope that Eloraam, Dan and Cloudy come up with something awesome for Redstone wires. Probably gonna be on Eloraam's side, but seriously, having a RS Wire always output 256 or something would make my life tons easier, when I figure something out to do with it. Hmm. That seems a lot lighter after writing a four-paragraph essay.
Problem with OP's suggestion would be breaking every current program that uses redstone. Combining idea from april, this would be ideal:
rs.getAnalogInput() would return number, old one with true/false would still work.
rs.serOutput() could have true/false OR number. So I could do rs.setOutput("back", 10) or rs.setOutput("back", true), which would translate to 16. Is that even possible with lua?
In vanilla there is currently no way to output a specific redstone signal strength. It can be read in a roundabout way (reading the metadata of the block next to the computer if that block is a redstone wire) but that will not work with, say, red alloy wires.
matejdro, on 07 January 2013 - 01:14 AM, said:
Problem with OP's suggestion would be breaking every current program that uses redstone. Combining idea from april, this would be ideal:
rs.getAnalogInput() would return number, old one with true/false would still work.
rs.serOutput() could have true/false OR number. So I could do rs.setOutput("back", 10) or rs.setOutput("back", true), which would translate to 16. Is that even possible with lua?
I'm not seeing how it would break any existing programs, as long as the suggested rs.setOutput() accepted nil as max (like a lot of other number argument functions do).
With regards to the idea that random novelty is inherently preferable to features that most everyone is really interested in using...I suppose that's a matter of taste? I'm not sure I would characterize this as a random novelty either. It just makes something easier that you can accomplish by using the other blocks Mojang is providing for that purpose.
And yes, as I've pointed out, you can have a portable rednet terminal by carrying a named turtle around, placing and breaking it as you like. But I've tried this...and it ended up making 1.4^ less fun for me than 1.2.5 with a PDA (a peripheral that I doubt really caught on much because it demanded you write all your own input/output for it). I'm seriously playing mostly in 1.2.5 because of that.
I may well decide, after playing with variable redstone devices for a bit, that the comparitor+distance drop just isn't adequate, and having these functions revised is essential.
Yes, PDA is preferred. Just not old PDA peripheral connected to comp.
And if RP2 Red Alloy Wires remains "digital" it would be quite easy to "digitize" RS signal with proper setup:
Yes, PDA is preferred. Just not old PDA peripheral connected to comp.
And if RP2 Red Alloy Wires remains "digital" it would be quite easy to "digitize" RS signal with proper setup:
But I hope it would be quite easy to implement this suggestion.
Sebra, on 07 January 2013 - 11:19 PM, said:
Yes, PDA is preferred. Just not old PDA peripheral connected to comp.
And if RP2 Red Alloy Wires remains "digital" it would be quite easy to "digitize" RS signal with proper setup:
1
OmegaVest, on 05 January 2013 - 11:09 AM, said:
