If you could add support for smelting recipes I would really love this mod. It would be super helpful for all of the technical mod packs like feed the beast and such, so that you could ensure that you always get the same types of ingots.
Edit: I guess I should have scanned the topic before I made that post, because I see it's already in your plans. Well, let me say that I fully support it.
You may also be misunderstanding what I mean by smooth movement. I only show the coordinates as an integer. The smooth movement refers to the map image itself, not the numbers it displays
No, I understood what you mean, but upon further testing, the issue only occurs on the full screen map. Movement on the minimap in the corner is smooth like you said it should be.
So, I downloaded the modloader version of Zan's Minimap the other day, but it doesn't appear to be up-to-date with your changelog. Are you only maintaining the jar version, or is it just an outdated link on your planetminecraft page for it?
Specifically, I noticed that the map was updating by 1 coordinate at a time, no matter how zoomed in I got, even though the changelog shows "smooth movement: the map no longer moves one coordinate at a time even when each coordinate is represented by 8 pixels. When zoomed in, you can see your position within a block" from a month ago
Minor bug to report. In single player, if you aren't looking at a rift/dimensional door when you walk through, it won't activate. Then you can close the door on the other side. Haven't tested in multiplayer.
That's the obvious solution, but I plan to have my input chest be an ender chest, and they can store far less items than diamond chests, which I use for storage.
But yeah, I'll figure out a system to make that work.
Which is why I said you have one golem move everything from your input chest into your misc junk chest, and attach the rest to your misc junk chest. For speed, make your diamond misc-junk chest immediately next to your input ender chest, and use a strength core on that first golem.
if I dump a lot of stuff into a chest that a bunch of advanced stone golems are set to process, there's often a lot of stuff left that doesn't really belong in any category (especially in FTB) and it would be great to have a way to move items to my "Chest-of-random-trash-I-might-need-at-some-point" without needing a hundred golems for it.
Have one golem move everything to your random crap chest. Have the other golems move stuff from the random crap chest to the sorting chests.
I figured this one out. The default config was missing a leaf block metadata for the canopy trees, but when you break a log close enough to the top it would trigger a change in metadata for some leaves, so then the tree would be detected. I also found/fixed an issue with how non-default configs were being handled. I'll get a 1.4.5 update out before I start on 1.4.6 stuff.
Excellent, thank you for your tireless work in maintaining this mod. I apologize if I came off as confrontational before, I was suffering from a pretty bad bladder infection, so I was impatient and snappish.
It looks like I probably messed up the default config metadata maybe. If you figure out what's wrong with it, feel free to enlighten us. Or just turn useStrictBlockPairing to false for now.
Disabling strict pairing does not change the behavior...
Neither does removing the metadata definitions from leaves and logs.
List of trees that don't work:
certain twilight_oak trees
most twilight_canopy trees
ebxl giant oak
ebxl giant redwood
ebxl giant fir
some mystcraft huge trees (which use vanilla oak logs and leaves)
vanilla giant jungle trees
No vertical limit... it just finds the top log block in the current block column and counts the leaf blocks in the 3x3 box around it. if it finds 2 or more leaf blocks, it's a tree. I even configured for the rotated logs' metadata with the default mod block IDs.
Right, I know that's how it's supposed to work, but right now, it doesn't go all the way to the top of the column if the tree is too tall. My first instinct was that it's falsely thinking the column is over if the metadata has changed, but I'm sure there are other possible explanations that would also cause the behavior I'm seeing.
But whatever the reason, there's definitely a bug here. Please look into it.
Specifically:
certain trees that were recognized by the prior version (with correct config) are not recognized by the current version (with correct config).
The thing all these trees have in common is that they are very tall.
If you keep moving up the trunk and chopping higher blocks, the trees will eventually be recognized and fully tree-capitated, but often you have to get to a log that is directly adjacent to leaves before this happens. To clarify: the log that eventually causes the tree to be tree-capitated is in the same column as the logs that wouldn't, but higher up.
Most of these trees have an uninterrupted column of logs all the way up to their leaf line. All of these trees were recognized by the r03.
Just to be sure nobody misinterprets this, I really do appreciate all the new features. I'm just trying to make a thorough bug report here.
TY for the update I truly love the use of the Treecapitator mod but for some reason when I go to chop down a Redwood ID#1315 I'm getting nothing but one block at a time... Before the update I had gone through and added all the tree log ID#'s and leaf ID#'s from all the various mods I use within the Magic World FTB mod pack, to the config file and no matter the tree I was able to knock it down using any ax from diamond and above w/ no issues... Now, I tried w/ out any changes to the config file first to see if any tree could actually be dropped and it worked fine on vanilla trees but when I tried the redwood, silverwood, & greatwood (just to name a few) nothing... I then went into the config file and tried various different changes and several different locations due to the lack of several ID's located within the config file, but still no luck... Any help w/ this matter would be greatly appreciated, TY...
It looks like the intelligent tree detection in the new version of treecapitator is giving up a little too soon.
Testing with twilight oak and canopy trees in twilight forest shows that if I break a log block immediately below the leaf line, it works, but if I break a log all the way at the ground, I only get the one log. I suspect this is related to the new block metadata support -- if it encounters a log with different metadata (e.g., a rotated log) before it reaches leaves, it gives up, but if it finds leaves first, it will correctly break all logs configured in the tree type.
Either that, or bspkrs added a vertical test travel limit for no apparent reason...
I've taken the liberty of creating a config to make the new treecapitator work with the default block and itemids in the Feed The Beast magic world pack.
I'm having an issue where this mod doesn't seem to be reading its config files on load -- the position and advanced options are all reset to default every time I launch minecraft again, and the config files are rewritten to match.
There is not currently way to specify multiple leaf block types for the same log block in the treecapitator config. Treecapitator will only read the first leaf config for a given block type.
This is the issue you're running into. I don't have the default twilight forest IDs memorized, but my guess is that with that config you can treecapitate canopy trees, but not darkwood trees.
0
Edit: I guess I should have scanned the topic before I made that post, because I see it's already in your plans. Well, let me say that I fully support it.
0
No, I understood what you mean, but upon further testing, the issue only occurs on the full screen map. Movement on the minimap in the corner is smooth like you said it should be.
0
Specifically, I noticed that the map was updating by 1 coordinate at a time, no matter how zoomed in I got, even though the changelog shows "smooth movement: the map no longer moves one coordinate at a time even when each coordinate is represented by 8 pixels. When zoomed in, you can see your position within a block" from a month ago
0
0
Which is why I said you have one golem move everything from your input chest into your misc junk chest, and attach the rest to your misc junk chest. For speed, make your diamond misc-junk chest immediately next to your input ender chest, and use a strength core on that first golem.
0
Might you consider increasing this cap to 1635xp, which brings you precisely from 0 to the anvil's level cap?
Have one golem move everything to your random crap chest. Have the other golems move stuff from the random crap chest to the sorting chests.
0
0
Excellent, thank you for your tireless work in maintaining this mod. I apologize if I came off as confrontational before, I was suffering from a pretty bad bladder infection, so I was impatient and snappish.
0
Disabling strict pairing does not change the behavior...
Neither does removing the metadata definitions from leaves and logs.
0
ForgeModLoader-client-0.log: http://pastebin.com/zGhf7nBA
Relevant mod configurations: http://pastebin.com/H44Qm4PX
List of trees that don't work:
certain twilight_oak trees
most twilight_canopy trees
ebxl giant oak
ebxl giant redwood
ebxl giant fir
some mystcraft huge trees (which use vanilla oak logs and leaves)
vanilla giant jungle trees
Is this enough for you to work with?
0
Right, I know that's how it's supposed to work, but right now, it doesn't go all the way to the top of the column if the tree is too tall. My first instinct was that it's falsely thinking the column is over if the metadata has changed, but I'm sure there are other possible explanations that would also cause the behavior I'm seeing.
But whatever the reason, there's definitely a bug here. Please look into it.
Specifically:
Just to be sure nobody misinterprets this, I really do appreciate all the new features. I'm just trying to make a thorough bug report here.
0
It looks like the intelligent tree detection in the new version of treecapitator is giving up a little too soon.
Testing with twilight oak and canopy trees in twilight forest shows that if I break a log block immediately below the leaf line, it works, but if I break a log all the way at the ground, I only get the one log. I suspect this is related to the new block metadata support -- if it encounters a log with different metadata (e.g., a rotated log) before it reaches leaves, it gives up, but if it finds leaves first, it will correctly break all logs configured in the tree type.
Either that, or bspkrs added a vertical test travel limit for no apparent reason...
1
You can grab it at https://dl.dropbox.com/u/75343/treecapitator/TreeCapitator.cfg
0
0
This is the issue you're running into. I don't have the default twilight forest IDs memorized, but my guess is that with that config you can treecapitate canopy trees, but not darkwood trees.