I've released 3.0_pr3 and updated the link on the previous page. The notes have likewise been updated.
Aside from the major issues noted, this build is working very well, and should be safe to use with IC2 1.106 or 1.107. I've got a couple more GUI upgrades planned, along with the infrastructure to support them, and then the release, so if you spot any issues not listed above, please report them!
Version numbers, please. Forge especially; my guess is that you're on a non-recommended build (like the IC2 1.107 beta requires).
I've updated the pre-release download link. It seems to be running properly on true servers now, and I fixed a display failure caused by being in negative coordinates. (I hate java's broken % operator.)
Well, I'm utterly unsurprised that it took a few more days, but I've got a 3.0 pre-release ready.
Important notes:
Did you read the notes? I'm not kidding when I say that they're important! Yes, I know it's buggy.No, I just want the new version.
For the curious, you can watch my project on github. master is the main part (pretty much done), and mcp_interface has the user-level stuff (plus an entire MCP install, for proper diffing).
I've effectively finished everything pre-forge (the mod decompile was so trivial I haven't written it down yet; literally just unzip -> fernflower), so I prodded cpw a little. From what he said, I gather that his project is essentially orthogonal to mine. Same basic goal, different approach, and since he's deprecating his project that I would have been building off of... there's not really anything for me to do on that front. 
I'm really close to building a new version of SeedManager. It'll be a test case for handling Forge, which is next up. So a new version as soon as tomorrow is possible.
Quote from mcmishhey , is there a version of this compatible with tekkit server 3? I've got the clients running, but the server just gives a lot of severe code when i tried the bukkit ported version on page 2 of this thread. Amazing mod though
I don't support Tekkit. Unlike some, I don't mind Technic, but I've no desire to support a random conglomeration of three bazillion mods.
Quote from NLZCould you get anything out of cpw?
That comes soon. I've got a combination of mcp_decompile and mcp_rebuild that seems to be working properly. It successfully processed SmoothWater from source to working Minecraft, but everything else I have requires Forge, and most of it needs IC2, too. So non-trivial testing needs more groundwork.
My next projectlet is a script for deobfuscating and decompiling mods. I only really need the first half, but Searge says the decompiling would be very well received (and I think he's right), so I might as well tackle that, too. After that, there will be a little wrinkle with allowing mods to build against deobfuscated mods, and then I'm on to Forge and integration tests, which is about when I'll hop into the Forge IRC room.
Quote from "Hewlitt"I'd love to use this in my modpack, do I have your permission?
If you're making a modpack for 1.2.5, go right ahead. You're welcome to *try* on 1.3.2, too, but you may find it ever-so-slightly difficult.
Good to know. I'll be sure to stop by the forge IRC and prod cpw about it when I get to that point.
The good news as far as SeedManager 3.0 is concerned is that I've acquired some personal matters (read: job hunt) that I need to attend to weekly, and working on this is my major justifiable procrastination. 
Basically, what I'm working on is making MCP stop being stupid. Any time you want to compile a mod with MCP, you have to recompile *all* of your mods, plus Minecraft itself. And then reobfuscate all of the above. Meaning that it takes around a minute each time you want to see your change in action. This makes debugging... painful.
One day of coding already gave me a working replacement for RetroGuard (the obfuscation/deobfuscation program that MCP uses), albeit with one annoying limitation: It doesn't understand inheritance. Another couple hours got me the framework for learning the inheritance, so my next project is linking them together and making it smart enough to track inheritance for classes that aren't in the current batch, probably meaning some sort of persistent storage.
Once that's done, the biggest obstacle to optimizing MCP is gone, because I'll be able to reobfuscate a mod by itself, without processing all of Minecraft. From there, I'll be integrating mcp_rebuild and improving it to do single-mod compilation. Run a single-mod compile, package up a zip file, reobfuscate it, and presto!, you've accomplished in a couple seconds (or less) what took a full minute before.
Better yet, I'll be able to run mods through a "deobfuscation" to the MCPC Bukkit naming, which will make it possible to build a Bukkit version at the same time. It's not magic, though; I'll still need to make a couple adjustments and maybe even a small code fork to account for the Bukkit idiosyncrasies. But the distinction won't be any worse than the previous client/server split.
So, yeah, rebuilding MCP from scratch, sort of. 
But it's not that bad. The hardest part (for me, at least) is figuring out how to tie stuff together in a way that makes sense to the user, and even that's not too hard. The really tricky part of MCP is building the renaming tables, and that I can just use as-is.
All-in-all, I'm guessing something like 5-7 days of work. Could be less, but I'm too familiar with Murphy to expect that. As long as I can stay focused (fingers crossed!), I'll have something polished up by the start of November. (Again, could be faster, but Murphy's a dick.)
And rewrite this mod from scratch
Nonsense, I'm not rewriting my mod from scratch. I'm just rewriting MCP from scratch.
(And I'm only half kidding about that.)
Oh, hey, the new IC2 is out. Must be time to update my dev environment.
when i add this mod i get an id conflict with 29870 (seedbag) i guess this isn't intentional, right?
On the contrary, that is in fact expected behaviour, and is responsible for filling in the final line of the tooltip (the one Alblaka left out when he stole-with-permission my tooltip system). No action required, just let it stand.
If it is using the check than it isn't pulling it from the texture pack folder, I'll try updating the image in the zip. [...] Replacing the gui with mine that is in the mod's zip it uses the check, and my arrows (the import/export ones)
Aha, I think I figured it out. The leading slash on most texture file names is missing from the calls that initialize that stuff. I'll compile up a test build and send it your way via PM shortly. (Edit: Sent!)
QuoteAlso the inventory slots aren't being used for whatever reason
The inventory slots should just be drawn on the background image. The code doesn't care about their appearance at all.
QuoteThe black mark is actually just the gui background stretched into the bars (I'm using a outdated version in my /texturepack folder).
Ah. Nothing to worry about on my end, then?
QuoteAll I know about texturefx is that as long as you are using forge's methods, it should work. When sengir migrated forestry/buildcraft to forge's texture api he could finally fix the hd compass in forestry, but he couldn't get it working until then (and he tried a lot of things).
Okay, looks like FML added support for it. AFAICT, I should be able to just scale my array size to fit the input data. I'll try that for the build I send you; let me know if it works.
ZexMaxwell001: Looks like it's gotten stuck in a loop when you tried to move items around. Best guess is that it's related to the phantom inventory slot used for setting the seed type. I'll keep an eye out for that when I do the official bukkit port.
pcmaster160: It does use the check mark, actually, but in a fairly weird way. It's the button's image, but the image that's displayed isn't normally changeable, so I have to do it by hacking the Y coordinate like this:
try {
int type_y = 54 + 1;
if (filter.allow_unknown_type) {
type_y = 72 + 1;
}
textureY.set(unk_type_button, type_y);
int ggr_y = 54 + 1;
if (filter.allow_unknown_ggr) {
ggr_y = 72 + 1;
}
textureY.set(unk_ggr_button, ggr_y);
} catch (IllegalAccessException e) {
} catch (IllegalArgumentException e) {
}Ugly, but it works.
I'll fix the background for the library GUI. I generated it in code, but there's no reason not to export that back to the image so it can be changed.
I'm not sure what's up with the black mark above the GGRT bars in your image. Any idea what might be causing it?
The next version will have support for front, side/back, top, and bottom textures (in that order), as well as on/off states for both and an animation for the front of an active seed analyzer. My current dev template is attached. Note that the seed analyzer displays the seed on top if one's present, turns the display on if it has power, and animates if both happen.
Also, do you happen to know how TextureFX works with HD packs? I'd like to support customizing the animation for them, but right now, I'd be working blind.
Update: I've got the animation working!
Hey, folks, sorry for the absence. Going in reverse order...
lucasdidur: What? The best interpretation I've got right now is that your crop blocks are being reset from having a plant to not having one. In which case you're looking at the wrong mod: SeedManager does absolutely nothing to crop blocks.
Kane Hart: I'll see what I can do about it. Assuming I stay active (which I wholeheartedly hope for), a proper Bukkit version is one of my high priorities.
I don't now: I love you. All of it looks very pretty. I think it could use a little enhancement, however. The displays really seem to be begging for a hint of animation, and the Seed Library needs an "out of power" version. I think I can probably manage both of those with my meager editing skills, but I'll let you know if they're not looking good enough. Are you happy with the MIT license (similar to CC-BY) I'll be putting on the next release, or would you prefer a separate one for your art?
Kane Hart (again): The preferred setup for automated processing is a library+analyzer pair. Apply redstone current to the analyzer and it will happily process all seeds from the library to their fullest. If you want to pipe them further once fully-analyzed, extract from the library with Unknown GGR unchecked. You can also use a lone analyzer with redstone current to auto-process a single seed at a time, but that's not really suitable for anything beyond manual seed IDing.
smbarbour: Thanks. I see your PM, too. I'll take a look and see if I can figure out what busted.
----------
Update: After further consideration, I don't think the seed library needs animation. I did give it an "out of power" variant, and I've attached a draft of new texture file and an animated gif of the seed analyzer. Seems like it came out pretty well. There are actually four animation tracks, only one of which is in the gif. All four tracks will be mixed and matched at random to produce a non-repetitive "sequenced genome" in-game. If you've got multiple analyzers sitting around, it will use the same animation for all of them, but I'm not especially fussed about that. (It's also a fundamental limitation of the implementation I think I'll need to use.)
I don't now: I've also included the GIMP project I was working with. Please feel free to use it for tweaking the result if you're not happy with my version.
As promised, an update today. Haven't had a chance to get back and make upgrades, including official Bukkit support, just yet, but I'll try to get to that soon.
Could I get the region file for the chunk it's in? I'd like to examine it and see how much energy it thinks it has stored.
Also, as long as I'm in the thread, a quick update for others: I haven't made any real progress on this for a week or two, beyond replying to various people. Had a pet die of old age, and I've just not quite managed to pull myself back together yet. I'll definitely put something out tomorrow or Tuesday, but I don't know if I'll have the official Bukkit conversion ready by then.
Sorry, I obviously failed to update the post carefully enough when I uploaded v4.0. DebugCrop is now ridiculously easy to obtain: plant cobblestone in a crop block.
Vanilla trampling uses a completely different hook, BlockFarmland.onFallenUpon, which is not affected by this issue. Indeed, the other solution (as I mentioned last time) is to just remove that check entirely and let the underlying farmland handle trampling due to falling/jumping. If the vanilla trampling code trips, the farmland will become dirt and break the crop block. Sprinting would still need to be handled by CropCard.
Observed behaviour: While connected to a server, contacting crops while on the ground randomly causes them to break.
Expected behaviour: As in simgleplayer, crops should only break in multiplayer if the player falls or sprints on them.
Underlying cause: This one's my fault, actually. I told Alblaka that EntityLiving.motionY was 0 for a player on the ground, and it is... in singleplayer. On a server, it rapidly switches between 0 and a small negative value (-0.0784000015258789, at least for my server). So half the time, the server thinks you're falling, and triggers the crop trampling chance.
Fix: Change "((EntityLiving)entity).motionY < 0" to "((EntityLiving)entity).motionY < -0.1". I recommend testing on another server as well, to see if my observed value for motionY matches. (I suspect it's one tick of the gravity constant, and will be identical on every server.)
Mea culpa.
Background: TileEntityCrop's reset method removes the plant in the block, preparing it for planting another crop or being overgrown by weeds. This is triggered by any of several events: Picking (left-click), trampling, and being replaced by another crop (including weed growth).
Observed behaviour: New crops and weeds will sometimes grow to stage 2 much faster than anticipated when they appear in a crop block that used to contain another plant, sometimes appearing to have skipped stage 1 entirely.
Expected behaviour: New crops and weeds should take (approximately) the same amount of time whether the crop block is old or new, provided it has the same growth characteristics (fertilizer, etc.).
Underlying cause: TileEntityCrop.reset() does not alter growthPoints, so pre-stage growth is carried over from one crop to the next. If you switch from a slow-growth crop to a fast-growth one, this can cause growthPoints to be high enough that the crop immediately grows to stage 2.
Fix: Set growthPoints to 0 in TileEntityCrop.reset().