Use two piston ...One that block the signal to the cable and the other let pass the signal to another bundle
I've thought about doing exactly that, actually. I don't like using pistons as circuitry components though, it irks me for some reason. If I ever have to build a larger version of what I was doing before though, I may have to reconsider as my solution does take quite a bit more space.
Shad20020, on 07 August 2011 - 06:40 AM, said:
Why would a bundle update status of stuff not connected to it ? Maybe stupid question .But it poped when i readed .
Just give me an example i will understand by myself ...no need of big explaination(i like the big explanation but if you don't feel for it) .i just can't figure for now
Eloraam:
You're kidding, right? Nice clean, shared code paths are a good thing. Sharing code between modules is why RedPower has so few bugs, relatively speaking. I had to add special-case handling for this specific case. If channel 0 (regular redstone power state) is included in an update, that update can effect things up to THREE blocks away under certain conditions.
Honestly I thought the hash table would take the pain out of that. I wasn't expecting Java's data structures being quite so slow. Sometimes, much to my annoyance, constant factors become large.
It's only the bundled cable that could receive any benefit at all from this, so that's what I did.
There's one more potential speedup I could add, but unlike this last one, it's a huge change, so don't hold your breath. It'll happen when it happens, and not before.
@007Blox - each cable segment is actually doing a pretty big amount of work when things change. The more you add, the slower things get. It's that simple. It's also extra bad if you change lots of signals at the same time. As fast as the solver is, you can still make it perform multiple sweeps over the cable network by changing multiple signals at a time. It may notice the change and roll it into the last sweep. Or it may not - and then it'll have to run another update on the whole network for each signal that changes.
That's what the test cases you both made do. You're changing lots of signals in a bundle in the same tick, but not at the same geographical location. Each one is triggering a sweep of the network. The network sweep code is pretty smart, it only visits each node a maximum of twice, and it never performs redundant block updates - even if 1.6.0 is performing potentially unnecessary updates. It never updates a block twice.
So the bigger you make the bundle network, and the more inputs you change in the same tick, the more power updates you're performing. bundle updates are already a little more intense than regular wire updates, because they have 16 channels to check.
Now, I could do one of a couple things to speed this up even further. I could scan the network and build a connected set graph, and stop actually propagating updates on the cable network entirely. I don't like this option for a lot of reasons, but there's a real show-stopper there: Minecraft doesn't give any meaningful indication of whether an update is due to a change in geometry or power state. That means that every power state update would require rebuilding the connected set graph, which is actually a bit more involved than the network sweep I'm already doing. That's bad.
The other thing I could try, which would help some with the multiple signal problem, is to switch to a deferred sweep. That also has a bunch of problems, the biggest of which is that it requires some pretty invasive hooks in the Minecraft base classes to make it happen.
Finally I can make bundle updates a little smarter about which channels they bother trying to update. While this may sound obvious, this is a very small constant factor improvement, which may be completely drowned out by the overhead involved in doing that. Also, last time I tried it, I ended up breaking the network invariant and causing cascading updates - which turns the whole network into an O(n²) problem. If you want to see lag, that would make you cry.
Yeah, doesn't change the fact that it could be useful to have bundled bundles.
1. I won't be rapid firing changes to it.
2. Even if it lags, if it still works, it still works.
3. If it does work, it can still be useful, lag or not.
People do things that lag Minecraft all the time, even fully knowing it will lag. People spend days prelaring things they know full well will lag Minecraft, suck as building entire towns out of TNT, then detonating it. You can repeat 'lag!' over and over as many times as you'd like, it doesn't change the fact that some people will actually have uses for some things. If Eloraam wants to say no, it's not going to happen, then I'll leave it be, but don't come and try to tell me that no it can't be done due to something people accept to begin with.
Yeah, doesn't change the fact that it could be useful to have bundled bundles.
1. I won't be rapid firing changes to it.
2. Even if it lags, if it still works, it still works.
3. If it does work, it can still be useful, lag or not.
People do things that lag Minecraft all the time, even fully knowing it will lag. People spend days prelaring things they know full well will lag Minecraft, suck as building entire towns out of TNT, then detonating it. You can repeat 'lag!' over and over as many times as you'd like, it doesn't change the fact that some people will actually have uses for some things. If Eloraam wants to say no, it's not going to happen, then I'll leave it be, but don't come and try to tell me that no it can't be done due to something people accept to begin with.
LOL yeah you want to play with lag ...People want to play with lag ...Yeah right ! you probably have reason ...If they can make it without or with lag they prefer with lag for sure ... Men think about what you're saying ... you know that it will lag but everybody want the game to be fluid ... you ask for more lag ...this is stupid . But hey the bundled bundle was asked like 2 month ago ..... where it is ? ...i'm asking ...So yeah kepp asking .
LOL yeah you want to play with lag ...People want to play with lag ...Yeah right ! you probably have reason ...If they can make it without or with lag they prefer with lag for sure ... Men think about what you're saying ... you know that it will lag but everybody want the game to be fluid ... you ask for more lag ...this is stupid . But hey the bundled bundle was asked like 2 month ago ..... where it is ? ...i'm asking ...So yeah kepp asking .
I'm not saying lag is a preference, but what I'm saying, if you can understand the concept, is that there are things that will be a lot easier to build with bundles of bundles. Perhaps even worth the extra lag it causes. Perhaps compromise is a foreign concept to you, and thus the idea is not one you would understand, but we can always hope.
LOL yeah you want to play with lag ...People want to play with lag ...Yeah right ! you probably have reason ...If they can make it without or with lag they prefer with lag for sure ... Men think about what you're saying ... you know that it will lag but everybody want the game to be fluid ... you ask for more lag ...this is stupid . But hey the bundled bundle was asked like 2 month ago ..... where it is ? ...i'm asking ...So yeah kepp asking .
well, if you don't want play with lags just don't use it. don't create tnt town, huge logic machines with tons of cables, etc. it's like to tell the modder do not create the mod, because you think it add something useless. (for example 100 enchanted armors, tools and ores)
I'm not saying lag is a preference, but what I'm saying, if you can understand the concept, is that there are things that will be a lot easier to build with bundles of bundles. Perhaps even worth the extra lag it causes. Perhaps compromise is a foreign concept to you, and thus the idea is not one you would understand, but we can always hope.
Posted 22 July 2011 - 08:57 PM
Jay, on 22 July 2011 - 08:51 PM, said:
So, insulated bundled wires? Nice. Not what I thought you meant earlier.
Bundled bundled cables? I think we might make Minecraft explode.
Eloraam reply :
Well, I actually eliminated the "non-insulated" bundle entirely. It just doesn't serve any purpose.
And yes, bundling bundled cables would require 256 channels. While that wouldn't *quite* make Minecraft explode, it would make for some pretty bad server lag, even assuming I used somewhat more advanced compression on the power packets. Although it does occur to me that I could probably cut out transmitting the actual power state of bundled cables anyway, since it doesn't actually change the rendering client-side. Still, just processing that many channels would tend towards the slow.
Bundling bundles isn't a good idea for many important performance reasons. I mean I could do it, but they would be rather intense on the system demands.
does server without bundled cables placed in the world lag as if there are a lot of it? i cant see where is the problem... or the users of this server cant follow simple rule ("no bundled bundled cables" for example)
Posted 22 July 2011 - 08:57 PM
Jay, on 22 July 2011 - 08:51 PM, said:
So, insulated bundled wires? Nice. Not what I thought you meant earlier.
Bundled bundled cables? I think we might make Minecraft explode.
Eloraam reply :
Well, I actually eliminated the "non-insulated" bundle entirely. It just doesn't serve any purpose.
And yes, bundling bundled cables would require 256 channels. While that wouldn't *quite* make Minecraft explode, it would make for some pretty bad server lag, even assuming I used somewhat more advanced compression on the power packets. Although it does occur to me that I could probably cut out transmitting the actual power state of bundled cables anyway, since it doesn't actually change the rendering client-side. Still, just processing that many channels would tend towards the slow.
Just keep asking ...maybe one day
...And? You know, with you repeatedly droning the same things over and over, I'm going to fall asleep. You made your point like five hours ago, and it was decided that I don't really care for one moment how badly it'd lag me, if I actually have use for them despite the lag. Add in the fact that 98% of the time, I play SSP, not SMP, thus the actual internet latency issues don't effect me.
...And? You know, with you repeatedly droning the same things over and over, I'm going to fall asleep. You made your point like five hours ago, and it was decided that I don't really care for one moment how badly it'd lag me, if I actually have use for them despite the lag. Add in the fact that 98% of the time, I play SSP, not SMP, thus the actual internet latency issues don't effect me.
yeah she should make it for u ....only ssp no smp and saying to everybody don't use it like this or this or this cause it will cause too much lag on your minecraft ...
Already run at 3 fps with bundle ...give me a bundle bundle so i can play at 0 fps .
If you need bundle of bundle your setup is already too big . and will lag at the end ...if you use the bundle bundle it will not lag it will freeze!
you have to understand that each wire trigger an update .
if the bundled bundle is 10 feet long it will trigger 256 check x 10 plus it will trigger an update of each thing 3 block away ...so if you have another bundle bundle near it it will trigger another 256 check ... So now imagine you made something that use only 32 wire and you plug it into a bundle bundle that is about 25 feet long ...how many update this will trigger in one sec ...Only for one wire on .
Hey Found a bug recently. either it's minecraft forge 1.0.6 or something else.
But Since updating my forge from 1.0.5 to 1.0.6 (used a fresh 1.7.3 jar) I lost the shadow guide for the coverplates as well as my infinite stock of items goes from 111 to 0 unless I go back into my inventory.
I can give you a list of the mods running if need be.
quick question / potential bug report. What is the intended behavior of repeaters? There are 8 states, 0-7. The original repeater has 4 states, 0-3. Each original repeater state n corresponds to n+1 ticks. For example, a repeater set to 2 would produce a signal that lasts for 3 ticks. Your repeaters behave similarly for 0 <= n <= 3, but then behave inconsistently thereafter. In particular, they go from linear to nonlinear. I could see justification for requiring this but am curious if it was indeed intentional. I very well could make a signal with delay d=5 or ticks t=5, but it would nonetheless be more convenient to do it with one block. A table is listed below. Thanks for your time and work!
yeah she should make it for u ....only ssp no smp and saying to everybody don't use it like this or this or this cause it will cause too much lag on your minecraft ...
Already run at 3 fps with bundle ...give me a bundle bundle so i can play at 0 fps .
If you need bundle of bundle your setup is already too big . and will lag at the end ...if you use the bundle bundle it will not lag it will freeze!
...You really don't have anything else to say, do you? You keep repeating the same thing over and over... Plus, I can see it, in some cases, being LESS lag, as some projected uses I have for it replace huge areas of bundles. We're talking 2,000 separate bundle cables, each doing all those updates. Now, I'd rather pack that data into one place, for LESS updates, thanks. Unless you have anything new to add, I think we're done here.
quick question / potential bug report. What is the intended behavior of repeaters? There are 8 states, 0-7. The original repeater has 4 states, 0-3. Each original repeater state n corresponds to n+1 ticks. For example, a repeater set to 2 would produce a signal that lasts for 3 ticks. Your repeaters behave similarly for 0 <= n <= 3, but then behave inconsistently thereafter. In particular, they go from linear to nonlinear. I could see justification for requiring this but am curious if it was indeed intentional. I very well could make a signal with delay d=5 or ticks t=5, but it would nonetheless be more convenient to do it with one block. A table is listed below. Thanks for your time and work!
We're talking 2,000 separate bundle cables, each doing all those updates. Now, I'd rather pack that data into one place, for LESS updates, thanks. Unless you have anything new to add, I think we're done here.
When they are separate they trigger less update .
1 wire on, in a bundle triger 16 check .
1 wire on, in a bundle, in a bundle bundle trigger 256 check . (per 1x1 flat bundled bundle) 10 feet bundled bundle = 10 x 256 check
So if you bundle your bundle even when you will turn on less wire, you will lag more
I'm just really getting into advanced redstone. I'm trying to get a simple bit of memory working. a simple 8 bit shift register or 8 bits of ram. I have played around with the multiplexer as I have seen a few posts here say they have been using them but I can't seem to get it to work. With 1 multiplexer I was able to get it to store 1 bit of data using the loop. However I am unable to figure out how to get it to store a second or more bits. I tried repeating this setup with two next to each other like Eloraam showed in one of the posts but it's not working. I can't seem to address them separately. Could someone post a .schmatic of some simple ram or shift register so I can pick it apart, or even just a overhead, close up screen shot? Thank you in advance.
I do infrequent changes of state, but for this project, I do them 64 simultaneously. Your point is again moot. Do you need further explanation?
:smile.gif: you don't understand ...but it's ok .
To other who understand ...
Try to avoid long bundle to reduce the check number .
Don't put them next to each other cause it trigger the update of the other cable ...so one wire on can easily trigger thousand and thousand of check in a millisecond.
you can make big setup that don't lag if you understand how to reduce the lag . Playing with f3 on, is a good check ...You can combine wireless redstone with redpower ...With both you can do a lot of stuff ...Like a wireless screen ...no need of bundle .
I've thought about doing exactly that, actually. I don't like using pistons as circuitry components though, it irks me for some reason. If I ever have to build a larger version of what I was doing before though, I may have to reconsider as my solution does take quite a bit more space.
Yeah, doesn't change the fact that it could be useful to have bundled bundles.
1. I won't be rapid firing changes to it.
2. Even if it lags, if it still works, it still works.
3. If it does work, it can still be useful, lag or not.
People do things that lag Minecraft all the time, even fully knowing it will lag. People spend days prelaring things they know full well will lag Minecraft, suck as building entire towns out of TNT, then detonating it. You can repeat 'lag!' over and over as many times as you'd like, it doesn't change the fact that some people will actually have uses for some things. If Eloraam wants to say no, it's not going to happen, then I'll leave it be, but don't come and try to tell me that no it can't be done due to something people accept to begin with.
well try to read it or pass . :smile.gif:
LOL yeah you want to play with lag ...People want to play with lag ...Yeah right ! you probably have reason ...If they can make it without or with lag they prefer with lag for sure ... Men think about what you're saying ... you know that it will lag but everybody want the game to be fluid ... you ask for more lag ...this is stupid . But hey the bundled bundle was asked like 2 month ago ..... where it is ? ...i'm asking ...So yeah kepp asking .
I'm not saying lag is a preference, but what I'm saying, if you can understand the concept, is that there are things that will be a lot easier to build with bundles of bundles. Perhaps even worth the extra lag it causes. Perhaps compromise is a foreign concept to you, and thus the idea is not one you would understand, but we can always hope.
well, if you don't want play with lags just don't use it. don't create tnt town, huge logic machines with tons of cables, etc. it's like to tell the modder do not create the mod, because you think it add something useless. (for example 100 enchanted armors, tools and ores)
Posted 22 July 2011 - 08:57 PM
Jay, on 22 July 2011 - 08:51 PM, said:
So, insulated bundled wires? Nice. Not what I thought you meant earlier.
Bundled bundled cables? I think we might make Minecraft explode.
Eloraam reply :
Well, I actually eliminated the "non-insulated" bundle entirely. It just doesn't serve any purpose.
And yes, bundling bundled cables would require 256 channels. While that wouldn't *quite* make Minecraft explode, it would make for some pretty bad server lag, even assuming I used somewhat more advanced compression on the power packets. Although it does occur to me that I could probably cut out transmitting the actual power state of bundled cables anyway, since it doesn't actually change the rendering client-side. Still, just processing that many channels would tend towards the slow.
Just keep asking ...maybe one day
...And? You know, with you repeatedly droning the same things over and over, I'm going to fall asleep. You made your point like five hours ago, and it was decided that I don't really care for one moment how badly it'd lag me, if I actually have use for them despite the lag. Add in the fact that 98% of the time, I play SSP, not SMP, thus the actual internet latency issues don't effect me.
yeah she should make it for u ....only ssp no smp and saying to everybody don't use it like this or this or this cause it will cause too much lag on your minecraft ...
Already run at 3 fps with bundle ...give me a bundle bundle so i can play at 0 fps .
If you need bundle of bundle your setup is already too big . and will lag at the end ...if you use the bundle bundle it will not lag it will freeze!
you have to understand that each wire trigger an update .
if the bundled bundle is 10 feet long it will trigger 256 check x 10 plus it will trigger an update of each thing 3 block away ...so if you have another bundle bundle near it it will trigger another 256 check ... So now imagine you made something that use only 32 wire and you plug it into a bundle bundle that is about 25 feet long ...how many update this will trigger in one sec ...Only for one wire on .
But Since updating my forge from 1.0.5 to 1.0.6 (used a fresh 1.7.3 jar) I lost the shadow guide for the coverplates as well as my infinite stock of items goes from 111 to 0 unless I go back into my inventory.
I can give you a list of the mods running if need be.
Visit MadPC on madpc.forumotion.com
quick question / potential bug report. What is the intended behavior of repeaters? There are 8 states, 0-7. The original repeater has 4 states, 0-3. Each original repeater state n corresponds to n+1 ticks. For example, a repeater set to 2 would produce a signal that lasts for 3 ticks. Your repeaters behave similarly for 0 <= n <= 3, but then behave inconsistently thereafter. In particular, they go from linear to nonlinear. I could see justification for requiring this but am curious if it was indeed intentional. I very well could make a signal with delay d=5 or ticks t=5, but it would nonetheless be more convenient to do it with one block. A table is listed below. Thanks for your time and work!
n=0 d=01 t=01
n=1 d=02 t=02
n=2 d=03 t=03
n=3 d=04 t=04
n=4 d=08 t=08
n=5 d=16 t=16
n=6 d=32 t=32
n=7 d=64 t=64
...You really don't have anything else to say, do you? You keep repeating the same thing over and over... Plus, I can see it, in some cases, being LESS lag, as some projected uses I have for it replace huge areas of bundles. We're talking 2,000 separate bundle cables, each doing all those updates. Now, I'd rather pack that data into one place, for LESS updates, thanks. Unless you have anything new to add, I think we're done here.
Well, I see an inconsistency, though I don't believe it's the one you see.
"n=2 d=03 t=03"
The rest of the pattern if that was removed would make perfect sense. Double each increment.
When they are separate they trigger less update .
1 wire on, in a bundle triger 16 check .
1 wire on, in a bundle, in a bundle bundle trigger 256 check . (per 1x1 flat bundled bundle) 10 feet bundled bundle = 10 x 256 check
So if you bundle your bundle even when you will turn on less wire, you will lag more
Do you need more explaination ...
I do infrequent changes of state, but for this project, I do them 64 simultaneously. Your point is again moot. Do you need further explanation?
:smile.gif: you don't understand ...but it's ok .
To other who understand ...
Try to avoid long bundle to reduce the check number .
Don't put them next to each other cause it trigger the update of the other cable ...so one wire on can easily trigger thousand and thousand of check in a millisecond.
you can make big setup that don't lag if you understand how to reduce the lag . Playing with f3 on, is a good check ...You can combine wireless redstone with redpower ...With both you can do a lot of stuff ...Like a wireless screen ...no need of bundle .