ZenithSelenium (of sammich mod fame) and I spent the whole weekend getting BTM to run sufficiently on Bukkit that we could push our SMP server over to 1.4. Terrain generation was solid, and we weren't getting any crashes, so we were pleased.
There was, however, some very odd spawning behavior that resulted from this. Specifically, after updating the BiomeBase to conform to the new List<BiomeMeta> in the CraftBukkit APIs (the r,s, and t arrays are now ArrayLists), we couldn't get anything except Monsters to spawn. Saturday was more or less consumed with trying to pinpoint which part of the BiomeBukkit sources were leading to this behavior. I think it has something to do with the custom chunk loading code, some method was probably renamed from a() to b(), and it still compiles but doesn't work right now. Still running a diff against the working CraftBukkit source files to try to find the origin of the bug.
I know it's not helpful for me to bring this up without having code to show you, R-T-B. I'm just hoping to warn you about a Bukkit-specific challenge you might encounter after you get the source to build and deploy. I'm not sure where the mismatch is--the ChunkLoader or WorldChunkManager are both potential candidates that I'm digging through now. The JD-GUI decompilation of World.java was so badly broken that I couldn't put it back together enough to override a method and set up traces to try to pin down the spawn code. I'm going to compare the MCP version of World.java with the JD-GUI version to see if I can suss out where the tangle is, and hope to work more with the Bukkit folks on this as well.
Also, with regards to Bukkit (I have zero interest in SSP, my only concern is using this for my SMP server), I have some ideas about how we might smooth out the integration with the underlying craftbukkit, usince BCEL or AspectJ method interceptors. It might allow you to override only the methods that you need to override, pushing the occurrence of obfuscation-related bugs or method mismatches back up into CraftBukkit. No use overriding the entire class when you might just need to add one method, right?
Anyway, don't work too hard. Burnout is bad for everyone.
1. This mod does not work with 1.4.
2. It will be at least a week before it does. If you're using 1.4 right now, you will need to wait.
3. When you do finally install it, set the sea level to 120 and log in. If you're at the top of the map, the installation was successful.
4. If your installation was unsuccessful, re-read the instructions and try again.
Even so, "held hostage" was a very poor choice of words on my part. Didn't mean to come across in such an inflammatory way there.
I think the point they were trying to make is that if we, as users, want a faster turnaround time on this (awesome, game changing) project, then we probably ought to get involved and help the devs. Open Source relies on an active user community willing to give back to the project and the community at large.
The Nether is a huge resource and labor saver as well. Instead of digging a 1600 meter tunnel between two bases and burning through 600 iron ingots to make rail, as well as dozens of boosters along the tracks, I can now build rail lines in the Nether with 75 iron ingots to cover the same distance. Mining the nethercobble is much faster than mining cobblestone, so it's easier to dig through, as well. So, after a fashion, the Nether just saved me the equivalent of at least 525 iron.
1. @OP: Boosters still work in the Halloween update.
2. In one of my stations, a cart waits for me near the exit. When I want to leave, I climb in, triggering a stone pressure plate. This fires a booster down the second track, which accelerates me out of the station. Now, both the cart and rider are off of the stone plate and the wooden plate. The lack of a cart on the wooden plate directs a second booster to draw a cart out of a cart storage hangar and place it near the exit, so that the next time I get to that location, there is another cart waiting for me.
This functionality could *not* be replicated by a booster block. Why? The booster block is stationary, whereas the booster cart is dynamic. It can be directed to move along a track to a location, so that sometimes it's performing boosting at a location, and sometimes it is not.
Right now I can do three separate tasks uniquely at a minecart location. Detect the presence or absence of a cart, detect the presence or absence of a rider, and boost a cart. These are three separate tasks. With careful wiring, I can also place buttons or levers nearby and get a fourth variable if I need it, but these require me to be there and explicitly interact with them. A "booster" block as described above would only be able to perform one task. Further, because it would perform the role of an actuator, it would displace the stone and wood pressure plates that I currently use as sensors, so I would lose my ability to sense and monitor the state of my minecart system. Right now I have two different sensors and a separate actuator that is not stuck in one place. I'd hate to give up the power of using all three in concert.
The booster carts may be an unintended side effect, an example of emergent features, something unplanned for. But that something is beautiful and elegant. There's no reason that this side effect cannot be preserved.
Happens to me as well. Constantly. Very frustrating--I have to stand just so to prevent it from happening. It's not a click speed issue--I've varied click speeds. Even messed around with the "double click speed" settings for my mouse. So far, no change.
Well, I've done some experimentation based on the original CleanRoom experiment. I fired up MCEdit, and built a new 256 x 256 CleanRoom, 32 stone blocks above the adminium layer. On this I built 2 meter high walls that divide the plane into 16 x 16 individual rooms. Gave myself some tree trunks and coal in the center chunk so that I could build, moved my spawn point there, and fired it up.
Step one was to build a rudimentary shelter, then a large 2x2 staircase going upward so that I could observe the plane around me. Darkness fell, and the mobs began to spawn. Quite quickly, in fact.
The first thing I noticed was that they were spawning in the chunks directly adjacent to my own--my stairwell was 16 blocks high, and there were no torches in my chunk, so the minimum 30-block range, I believe, is a thing of the past. Second, the mobs were not in any way clustered into a big concentrated area--no "zero chunk" or randomly more important chunk seems to exist. It's all pretty much a normal distribution centered on the player's location. Monsters spawned in groups of 1-5 or so, of identical types. I did not observe anything spawning more than 4 chunks away in any direction, so with my chunk in the middle, this appears to preserve the old 9x9 spawning zone hypothesis that predated the focus on chunk 0,0.
Once the sun came up, I ventured out to inspect the various chunk-cages. I found most of the arrows and feathers in a 4 chunk radius from the center chunk (where my stairwell is). There are *very rare* cases where I have found feathers as many as six chunks away, but next to never.
My conclusion is this: Yes, you can still build machines for farming mobs. But now, they must take on an epic scale in order to deliver at an epic rate.
I can confirm that the chunk 0,0 bug appears to have been fixed. The endless river of mobs was sure fun while it lasted. I was working on an arena where mobs would pour out of a hole in the ceiling and you could battle them endlessly.
I actually created / registered an account on the forums *just* so that I could thank Dusty for the hard work. I just discovered this pack, and I'm a true believer. It's got serious legs, and I'm switching over to it right now.
Thanks, seriously. It's hard to do pixel art, especially when you're not limited in your color pallet. There's constant temptation to reach for photorealism, but that destroys the synesthetic audiovisual language of the game. Dusty, your work here carefully treads that line, and borders on "pure rock".
As an aside, BoingBoing ran a FANTASTIC article this spring on the synesthetic language of video games, and it's totally worth reading, especially if you're interested in pixel art. http://boingboing.net/features/morerock.html
0
There was, however, some very odd spawning behavior that resulted from this. Specifically, after updating the BiomeBase to conform to the new List<BiomeMeta> in the CraftBukkit APIs (the r,s, and t arrays are now ArrayLists), we couldn't get anything except Monsters to spawn. Saturday was more or less consumed with trying to pinpoint which part of the BiomeBukkit sources were leading to this behavior. I think it has something to do with the custom chunk loading code, some method was probably renamed from a() to b(), and it still compiles but doesn't work right now. Still running a diff against the working CraftBukkit source files to try to find the origin of the bug.
I know it's not helpful for me to bring this up without having code to show you, R-T-B. I'm just hoping to warn you about a Bukkit-specific challenge you might encounter after you get the source to build and deploy. I'm not sure where the mismatch is--the ChunkLoader or WorldChunkManager are both potential candidates that I'm digging through now. The JD-GUI decompilation of World.java was so badly broken that I couldn't put it back together enough to override a method and set up traces to try to pin down the spawn code. I'm going to compare the MCP version of World.java with the JD-GUI version to see if I can suss out where the tangle is, and hope to work more with the Bukkit folks on this as well.
Also, with regards to Bukkit (I have zero interest in SSP, my only concern is using this for my SMP server), I have some ideas about how we might smooth out the integration with the underlying craftbukkit, usince BCEL or AspectJ method interceptors. It might allow you to override only the methods that you need to override, pushing the occurrence of obfuscation-related bugs or method mismatches back up into CraftBukkit. No use overriding the entire class when you might just need to add one method, right?
Anyway, don't work too hard. Burnout is bad for everyone.
o7
--
saintx
0
2. It will be at least a week before it does. If you're using 1.4 right now, you will need to wait.
3. When you do finally install it, set the sea level to 120 and log in. If you're at the top of the map, the installation was successful.
4. If your installation was unsuccessful, re-read the instructions and try again.
Hope this helps.
0
I think the point they were trying to make is that if we, as users, want a faster turnaround time on this (awesome, game changing) project, then we probably ought to get involved and help the devs. Open Source relies on an active user community willing to give back to the project and the community at large.
0
0
0
0
2. In one of my stations, a cart waits for me near the exit. When I want to leave, I climb in, triggering a stone pressure plate. This fires a booster down the second track, which accelerates me out of the station. Now, both the cart and rider are off of the stone plate and the wooden plate. The lack of a cart on the wooden plate directs a second booster to draw a cart out of a cart storage hangar and place it near the exit, so that the next time I get to that location, there is another cart waiting for me.
This functionality could *not* be replicated by a booster block. Why? The booster block is stationary, whereas the booster cart is dynamic. It can be directed to move along a track to a location, so that sometimes it's performing boosting at a location, and sometimes it is not.
Right now I can do three separate tasks uniquely at a minecart location. Detect the presence or absence of a cart, detect the presence or absence of a rider, and boost a cart. These are three separate tasks. With careful wiring, I can also place buttons or levers nearby and get a fourth variable if I need it, but these require me to be there and explicitly interact with them. A "booster" block as described above would only be able to perform one task. Further, because it would perform the role of an actuator, it would displace the stone and wood pressure plates that I currently use as sensors, so I would lose my ability to sense and monitor the state of my minecart system. Right now I have two different sensors and a separate actuator that is not stuck in one place. I'd hate to give up the power of using all three in concert.
The booster carts may be an unintended side effect, an example of emergent features, something unplanned for. But that something is beautiful and elegant. There's no reason that this side effect cannot be preserved.
0
0
Step one was to build a rudimentary shelter, then a large 2x2 staircase going upward so that I could observe the plane around me. Darkness fell, and the mobs began to spawn. Quite quickly, in fact.
The first thing I noticed was that they were spawning in the chunks directly adjacent to my own--my stairwell was 16 blocks high, and there were no torches in my chunk, so the minimum 30-block range, I believe, is a thing of the past. Second, the mobs were not in any way clustered into a big concentrated area--no "zero chunk" or randomly more important chunk seems to exist. It's all pretty much a normal distribution centered on the player's location. Monsters spawned in groups of 1-5 or so, of identical types. I did not observe anything spawning more than 4 chunks away in any direction, so with my chunk in the middle, this appears to preserve the old 9x9 spawning zone hypothesis that predated the focus on chunk 0,0.
Once the sun came up, I ventured out to inspect the various chunk-cages. I found most of the arrows and feathers in a 4 chunk radius from the center chunk (where my stairwell is). There are *very rare* cases where I have found feathers as many as six chunks away, but next to never.
My conclusion is this: Yes, you can still build machines for farming mobs. But now, they must take on an epic scale in order to deliver at an epic rate.
[EDIT]
0
Ah, well.
0
Thanks, seriously. It's hard to do pixel art, especially when you're not limited in your color pallet. There's constant temptation to reach for photorealism, but that destroys the synesthetic audiovisual language of the game. Dusty, your work here carefully treads that line, and borders on "pure rock".
As an aside, BoingBoing ran a FANTASTIC article this spring on the synesthetic language of video games, and it's totally worth reading, especially if you're interested in pixel art. http://boingboing.net/features/morerock.html