The framing system is excellent — the ability to apply arbitrary textures to furniture is a killer feature. But why limit it to framed blocks only? Why not let the player resurface, say, an ordinary wood table? It seems odd to limit the awesome new features to a special new type of block.
I am running a server on my home computer. After it's started up, it hovers below 50% CPU utilization even with six or seven players online. However, after a few hours, the CPU usage increases to 103–105%, whereupon it starts dropping ticks (the dreaded "[WARNING] Can't keep up!").
I am running vanilla 1.7.2 with no plugins on Mac OS 10.9. I am currently running off my hard drive, but running it in a RAM disk did not alleviate the issue. I have an i5 3570K @ 3.4 GHz and 8 GiB of DDR3 @ 1600 MHz.
I did not see this issue on the last server, running up to 1.6 on the same machine with Mac OS 10.8.
If it were me, I'd use a stack machine. I built my best-in-class certical bidirectional shift register for just such a project. Having a stack machine means that you don't need to waste instruction bits on addressing registers -- you could, in theory, have 256 different one-byte instructions. It's also reasonably new territory for redstone computers.
While length and width are interchangeable as stated, the y should be in a constant place.
Why, exactly? It's not like people remember the conventions by "the vertical component is the second one, right?" People remember the whole convention as a sequence: (x, y, z); (length, width, height). Yes, it's true that one of the components of the coordinates triple does sort of correspond to one of the components of the dimensions triple, but the least confusing thing to do is to maintain the current convention, not change the convention to preserve the correspondence of the vertical components.
How in the world is anyone supposed to understand anything if the coordinates are messed up?
It seems that everyone does understand it, yourself included.
There needs to be a proper standard, otherwise it'd be like everyone speaking a different language.
But there can't be a single standard, because you're talking about specifying two distinct types of quantity: coordinates and dimensions. For each quantity, there is a single standard: (x, y, z) for coordinates and (length, width, height) for dimensions. As you yourself admit, the latter convention is nigh-universally used and understood.
Has it been a problem in the first place?
No.
Easy solution: Instead of saying your circuit is 2x9x7, say your circuit is 2 wide, 9 high, 7 long
I usually specify my dimensions as 1 x 2 x 3H. As long as the height dimension is specified, the order doesn't really matter.
As long as the ordering of dimensions is essentially arbitrary, and as long as "They always list the height as the last axis", then what in the world is the problem? People generally list dimensions here as (length, width, height). You should be thankful that we're adhering to some convention rather than irritated that it's not the convention you prefer.
If your planning on programming anything, your going to have to use the proper way. or x,y,z to properly list coordinates.
Wrong, because Minecraft indexes blocks internally by (y, z, x) for performance reasons. It used to be (x, z, y), and to my knowledge it has never been (x, y, z). The real lesson is that you should pick the convention that best serves your needs.
Also, keep in mind that (length, width) is not the same as (x, z) or (z, x). Unlike x and z, length and width are interchangeable. It's the y dimension that's the odd one out, and there is no real reason to prefer (length, y, width) over (length, width, y).
So, you need a circuit with three outputs A, B, C, and one input X, such that a rising edge on X causes either A or C to be activated for some finite time period, alternating each time the circuit is triggered, and once that period has expired, B shall be activated instead?
In principle, that's X hooked up to a TFF, hooked up to the select input of a 2-way demultiplexer, where X is also hooked up to a pulse generator, where that pulse generator is hooked up to the data input of the demultiplexer, and the inverse of the pulse generator is hooked up to B. In practice, there's surely a way to make this compact.
Someone just told me that a multi-input XOR gate was a not-equal gate, and cited this guide. I looked at the XOR gate description, and it doesn't quite say that this is true for more than two inputs, but since this has been a common point of confusion on this forum, it might help to put a note in the XOR gate description mentioning that, with more than two inputs, it is equivalent to the PARITY gate.
Without counting what? Without counting the periods of the constituent clocks? Can't be done, even approximately. Without computing the LCM? Use a pairwise coprime set of periods for the constituent clocks. Without figuring out if that set is pairwise coprime? Use all prime numbers for the periods, or powers of distinct primes.
0
The framing system is excellent — the ability to apply arbitrary textures to furniture is a killer feature. But why limit it to framed blocks only? Why not let the player resurface, say, an ordinary wood table? It seems odd to limit the awesome new features to a special new type of block.
0
- What sort of server software you would like plugins for.
- What sort of plugins you would like.
- How much money you intend to pay.
0
I am running vanilla 1.7.2 with no plugins on Mac OS 10.9. I am currently running off my hard drive, but running it in a RAM disk did not alleviate the issue. I have an i5 3570K @ 3.4 GHz and 8 GiB of DDR3 @ 1600 MHz.
I did not see this issue on the last server, running up to 1.6 on the same machine with Mac OS 10.8.
0
0
0
0
0
0
Why, exactly? It's not like people remember the conventions by "the vertical component is the second one, right?" People remember the whole convention as a sequence: (x, y, z); (length, width, height). Yes, it's true that one of the components of the coordinates triple does sort of correspond to one of the components of the dimensions triple, but the least confusing thing to do is to maintain the current convention, not change the convention to preserve the correspondence of the vertical components.
It seems that everyone does understand it, yourself included.
But there can't be a single standard, because you're talking about specifying two distinct types of quantity: coordinates and dimensions. For each quantity, there is a single standard: (x, y, z) for coordinates and (length, width, height) for dimensions. As you yourself admit, the latter convention is nigh-universally used and understood.
No.
I usually specify my dimensions as 1 x 2 x 3H. As long as the height dimension is specified, the order doesn't really matter.
0
Wrong, because Minecraft indexes blocks internally by (y, z, x) for performance reasons. It used to be (x, z, y), and to my knowledge it has never been (x, y, z). The real lesson is that you should pick the convention that best serves your needs.
Also, keep in mind that (length, width) is not the same as (x, z) or (z, x). Unlike x and z, length and width are interchangeable. It's the y dimension that's the odd one out, and there is no real reason to prefer (length, y, width) over (length, width, y).
1
In principle, that's X hooked up to a TFF, hooked up to the select input of a 2-way demultiplexer, where X is also hooked up to a pulse generator, where that pulse generator is hooked up to the data input of the demultiplexer, and the inverse of the pulse generator is hooked up to B. In practice, there's surely a way to make this compact.
0
0
0
0