A question and a suggestion:Do you update to snapshots?Also, can you have a mode in Schematica where equivalent blocks are ignored for purposes of "wrong block"? I.e. all non-glowing solid blocks, all stairs with proper orientation, etc.
Ahh, I catch your drift now. Sorry for my earlier misunderstanding.[snip]
...Sort of?
It actually raises more questions than it answers, though:
How does increment work? Does it simply ignore the second argument?
If there's 8 GPRs and 8 "special" registers, how does that fit in the 3-bit argument? Or are they the start of the general RAM?
What are the condition codes for jump?
Why are you discarding most of the instruction set space by discarding 6 bits with most operations? Or are you?
For the load/store operations, how do you specify the RAM location? ARG1 is only 3 bits, and I doubt that you have 8 bytes of RAM total. Do you access the RAM location specified by the contents of the register? If so, how do you overcome the "chicken-and-egg" problem of "you cannot load the value from memory until you have the memory address loaded from memory"?
It's right there in the initial post under "Instruction Set".
Correction:
How many bits long are the instructions? How many registers? What ALU ops are exposed? What are the arguments to the draw* commands? How much memory is addressable?
8-bit answers some of these, but not all. (Especially as many 8-bit instruction sets have an instruction length of >8 bits)
There are a few instant inverters in the UCRC and on the wiki. Is this better than them somehow?
The instant repeater you mentioned can run on no faster than a 3-clock, but the instant inverters on the wiki can run on 2-clocks, just like yours (and 1-clocks will break the wiki's and yours).
...Not really. About the only thing is that it doesn't use redstone blocks or repeaters. Pure piston logic.
I'm sure you've all seen this design of dual-edge instant repeater:
It's a good design, but suffers from two flaws. First, it's an instant repeater, which means that it cannot be used for general logic. Second, it has a 4-tick minimum delay between power turning off and on again.
With that in mind, I sat down and designed an instant dual-edge inverter, focusing on speed. And I got it. The following is an instant dual-edge inverter with a 2-tick recovery time on both edges. Also, it's chain-able - I've got a run of ~30 of these in a row that's in a repeater loop and it's still holding signal, and I've also got an XOR gate that's working well. If it suffers from hash timing, it hasn't appeared thus far.
It's currently kind of large, and I would appreciate it if someone could compact it while keeping the recovery time, but it works, which is the important thing to me.
Red wool has redstone wire, blue is either moved by a piston or has a redstone torch on it, green is not part of the gate itself. If you want schematics or a download, feel free to as, but I think these screenshots should be enough.
There are many reasons I moved the crafting of the machines into the worktable [snip]
For the record, I just read through the thread (all 71 pages of it), and when I saw that recipes had been moved into the worktable I was rather disappointed.
To the end user, what it ends up doing is adding tedium, and that's all. Yes, there are good reasons for it (well, some of them. Some of the mentioned reasons can be dealt with in other ways, but I'll get into that later.), but none of that is visible to the end user. It's the same reason why (many) people stopped using Railcraft when the rolling machine was introduced, and GT when plates/hammers/etc. were added.
Current disadvantages to the end user of having the worktable be the only way to craft RC stuff:
NEI/TMI/Craftguide doesn't work
Autocrafting systems don't work
It takes longer to craft items, as you have to bounce around between the vanilla crafting bench and the worktable
It requires your crafting area to have yet another block
Current advantages to the end user of having the worktable be the only way to craft RC stuff:
1. The worktable stores its inventory, so that you can leave and come back to it. I do this rather frequently, forgetting gear units, mixing up base panels with ingots, and so on. With a vanilla table, you would have all the items spill on the floor (especially if your inventory is full while crafting).
3. RotaryCraft is and always was designed to be fully functional even without other mods. Thus, I want recipe automatability even without AppEng/BC. This means a devoted machine.
Great! However, neither of these addresses the point of removing the recipes from the vanilla system. There is nothing about these points that requires the recipes to be only in the worktable.
2. The recipes registered to the main crafting system are publicly accessible and therefore modifiable. I do not want my recipes being edited, and moving them to an internal system adds a lot of security against that.
If you're really concerned about that, add a check a couple of game ticks in that scans through your recipes seeing if any have been modified.
Easy enough to have an utility class function that adds recipes to a private internal set as well as to the vanilla recipe set, and then scan through and check if the recipes have been changed.
For that matter, it's a forge mod, on Java without a security manager. Nothing is secure, period. Both Forge and Java provide methods of changing private variables.
4. The worktable would be nearly useless with just tool charging as its function; I am very careful to not add machines with one small function like that, as it is wasteful and lends to a mod becoming a "bloat mod".
Point 3 mentions that it is part of an integrated autocrafting system. That doesn't sound like "one small function" to me.
5. Moving the machines to the worktable actually improves the gameplay in two ways. One, it pushes RC a little further into the techtree - now requiring clay and an extra redstone. Two, it makes the machine fabrication feel more involved, something I like.
My only real response to that is that it seems like RC machines are resource hogs to begin with. By the time one has the resources to do anything with RC you're going to have clay and redstone. I see your intended point, but all it seems to do is add tedium.
That being said, it seems like a great mod. Just... please rethink this. As it is, RC isn't something I'm going to do much with anytime soon.
Except.. the encoding would be added _before_ the already existing compression, not after. But granted, that is still, in many cases somewhat inefficient addition. However...
The data already being compressed is done (afaik) by a method designed for one-dimensional data (i.e. a sequence), not for 2D let alone 3D (minecraft world data). The amount of work done to the compression method shows in that even so, the compression is doing quite a good job.
But when a compression is designed for the specific purpose (e.g. minecraft's blocks organized in chunks of 16x16x16 blocks + some extras like entities), it can beat those de facto compressor quite easily. I could go on with this thing quite a lot deeper, but its actually not on this topic.. compression is a separate thing from cubic chunks. Perhaps start another topic for it, if desired (it is worthy of one).
Please do, I for one would be interested in talking more on the subject. Deflate / zlib works reasonably well with periodic data, which is what most of the current chunk data is.
Also, I wonder if it would be better to have the network compression and the chunk compression on-disk use the same algorithm, or a different one.
Reducing the amount of data that needs to be sent is not the same as compressing the data that needs to be sent.
Wrong, at least in this case. If this was a talk about not sending a heightmap over the network and regenerating it client-side, for example, you would be correct. However, in this case, methods of doing, eg, RLE encoding are methods of compression.
You do bring up a good point. Though there are a lot of Air-Only chunks over the nether sea, where the lag is worst. Perhaps another way you could do it would be a layer-by-layer compression in each chunk. Where the same layers are saved smaller.
You do know that Minecraft already does this specifically for air-only 16x16x16 "chunks", right? So no, it wouldn't even help there.
Layer-by-layer compression might help, but again adds data in the worst case, enough that I question as to if it would actually be useful. Not to mention that the data is already compressed.
You are assuming nobody would be playing anything else but the standard world types. Superflats can already benefit from the idea a lot. But once people get to make new generators for the increased height, there might be much more whole chunks of the same blocks.
I had even thought about making a generator mod more than year ago, and that was aimed at the current world height, and its basic idea was to concentrate ores into bigger but rarer blobs, and some adjustments to surface features... and suddenly, the most common 16x16x16 chunks would be all stone or all air, a bit of all water and all dirt.
(And as someone mentioned (I think), the idea is oooold. It is also one of those simple, obvious ones that every coder should give the obligatory thought for when handling large data amounts.)
Except that the data is already compressed. This is just another layer, and one that doesn't add significant compression in the best case due to it being already compressed.
Don't reinvent the wheel, guys. The data is already being run through a compressor, and one that has had a lot more man-hours put into tweaking and improving it than any scheme anyone here can put into it, including me.
Here is another idea for making sending chunks faster:
Sorry for raining on your parade, but that won't really help, and here's why:
Other than all-air chunks, there aren't really any chunks that are entirely one block. In the overworld, the only ones that would be affected would be large chunks of stone, but there are ores enough to generally cause it to fail. In the nether, since there are random lava blocks, again, it generally fails. The lava ocean generally doesn't have complete 16-deep 16-aligned chunks. About the only place that would affect would be the end, and most of the end is air chunks anyways, which are already covered by the existing algorithm.
Also, it would come at a price, by definition, as does any compression algorithm. The act of requiring a flag for "this chunk is entirely a single block type" means that chunk network data would be larger for non-uniform chunks.
A better method would be to gzip / some other compression algorithm the chunk data before sending it over the network, if it isn't done already. They tend to be faster / have better compression ratios than home-brewed compression algorithms.
To me, it adds annoyance late-game and adds early-game difficulty. This is precisely opposite of how things should scale - things should start as annoyances and progress into real threats. As it is, it puts people off of the game, new and established. New because they are being swarmed by zombies and die constantly, established because it means that they need to stop every 5 seconds and kill a zombie because it distracts them.
0
It's not showing mobs as being able to spawn on upside-down half slabs. Unless I'm missing something, hostile mobs can spawn on them.
This is a 1.7.2 client. (Note that the block at the far left is a double stone brick half slab. The light level on the block I am standing on is 3.)
0
0
Is there any version of this that doesn't use Forge?
0
...Sort of?
It actually raises more questions than it answers, though:
0
Correction:
How many bits long are the instructions? How many registers? What ALU ops are exposed? What are the arguments to the draw* commands? How much memory is addressable?
8-bit answers some of these, but not all. (Especially as many 8-bit instruction sets have an instruction length of >8 bits)
0
0
...Not really. About the only thing is that it doesn't use redstone blocks or repeaters. Pure piston logic.
0
It's a good design, but suffers from two flaws. First, it's an instant repeater, which means that it cannot be used for general logic. Second, it has a 4-tick minimum delay between power turning off and on again.
With that in mind, I sat down and designed an instant dual-edge inverter, focusing on speed. And I got it. The following is an instant dual-edge inverter with a 2-tick recovery time on both edges. Also, it's chain-able - I've got a run of ~30 of these in a row that's in a repeater loop and it's still holding signal, and I've also got an XOR gate that's working well. If it suffers from hash timing, it hasn't appeared thus far.
It's currently kind of large, and I would appreciate it if someone could compact it while keeping the recovery time, but it works, which is the important thing to me.
Red wool has redstone wire, blue is either moved by a piston or has a redstone torch on it, green is not part of the gate itself. If you want schematics or a download, feel free to as, but I think these screenshots should be enough.
1
For the record, I just read through the thread (all 71 pages of it), and when I saw that recipes had been moved into the worktable I was rather disappointed.
To the end user, what it ends up doing is adding tedium, and that's all. Yes, there are good reasons for it (well, some of them. Some of the mentioned reasons can be dealt with in other ways, but I'll get into that later.), but none of that is visible to the end user. It's the same reason why (many) people stopped using Railcraft when the rolling machine was introduced, and GT when plates/hammers/etc. were added.
Current disadvantages to the end user of having the worktable be the only way to craft RC stuff:
- NEI/TMI/Craftguide doesn't work
- Autocrafting systems don't work
- It takes longer to craft items, as you have to bounce around between the vanilla crafting bench and the worktable
- It requires your crafting area to have yet another block
Current advantages to the end user of having the worktable be the only way to craft RC stuff:- [This space intentionally left blank]
As for the specific points:Great! However, neither of these addresses the point of removing the recipes from the vanilla system. There is nothing about these points that requires the recipes to be only in the worktable.
If you're really concerned about that, add a check a couple of game ticks in that scans through your recipes seeing if any have been modified.
Easy enough to have an utility class function that adds recipes to a private internal set as well as to the vanilla recipe set, and then scan through and check if the recipes have been changed.
For that matter, it's a forge mod, on Java without a security manager. Nothing is secure, period. Both Forge and Java provide methods of changing private variables.
Point 3 mentions that it is part of an integrated autocrafting system. That doesn't sound like "one small function" to me.
My only real response to that is that it seems like RC machines are resource hogs to begin with. By the time one has the resources to do anything with RC you're going to have clay and redstone. I see your intended point, but all it seems to do is add tedium.
That being said, it seems like a great mod. Just... please rethink this. As it is, RC isn't something I'm going to do much with anytime soon.
0
Please do, I for one would be interested in talking more on the subject. Deflate / zlib works reasonably well with periodic data, which is what most of the current chunk data is.
Also, I wonder if it would be better to have the network compression and the chunk compression on-disk use the same algorithm, or a different one.
0
0
Wrong, at least in this case. If this was a talk about not sending a heightmap over the network and regenerating it client-side, for example, you would be correct. However, in this case, methods of doing, eg, RLE encoding are methods of compression.
You do know that Minecraft already does this specifically for air-only 16x16x16 "chunks", right? So no, it wouldn't even help there.
Layer-by-layer compression might help, but again adds data in the worst case, enough that I question as to if it would actually be useful. Not to mention that the data is already compressed.
Just use a proper compression algorithm already!
Is it? In that case it already compresses a chunk of the same ID to... 26? bytes - and that's with checksum and header.
As such, this adds data in the general case while not really providing much compression even in the optimal case.
We should be concerned more about worst case than about best case.
Except that the data is already compressed. This is just another layer, and one that doesn't add significant compression in the best case due to it being already compressed.
Don't reinvent the wheel, guys. The data is already being run through a compressor, and one that has had a lot more man-hours put into tweaking and improving it than any scheme anyone here can put into it, including me.
2
Sorry for raining on your parade, but that won't really help, and here's why:
Other than all-air chunks, there aren't really any chunks that are entirely one block. In the overworld, the only ones that would be affected would be large chunks of stone, but there are ores enough to generally cause it to fail. In the nether, since there are random lava blocks, again, it generally fails. The lava ocean generally doesn't have complete 16-deep 16-aligned chunks. About the only place that would affect would be the end, and most of the end is air chunks anyways, which are already covered by the existing algorithm.
Also, it would come at a price, by definition, as does any compression algorithm. The act of requiring a flag for "this chunk is entirely a single block type" means that chunk network data would be larger for non-uniform chunks.
A better method would be to gzip / some other compression algorithm the chunk data before sending it over the network, if it isn't done already. They tend to be faster / have better compression ratios than home-brewed compression algorithms.
Or alternatively, use a true RLE algorithm.
2
To me, it adds annoyance late-game and adds early-game difficulty. This is precisely opposite of how things should scale - things should start as annoyances and progress into real threats. As it is, it puts people off of the game, new and established. New because they are being swarmed by zombies and die constantly, established because it means that they need to stop every 5 seconds and kill a zombie because it distracts them.
0
Honestly, I don't expect it to be changed back, but one can always hope.
A suggestion: link to the bug tracker. Perhaps something there would get more attention.