jakj

They added some sort of block registry to forge for 1.6 that mimics the one for 1.7 and they're using that to establish a mapping. I'm sure somebody will also make a world-converter tool that lets you specify block id/meta -> new mapping, once 1.7's forge actually exists.

A secret, for now. But it's not related to Minecraft, so you're not missing anything. (It may eventually be useful for Minecraft, though...possibly. We'll see.) It's a personal project that I'll open-source release when it's working.

Minecraft stuff's been pretty "back burner"ed while I'm working on this other project, but I'll get back to it eventually. Going to have to overhaul the whole frickin' thing anyway for 1.7 which hasn't even settled into a workable state yet, so probably at that point I'll just do a refactor and then backport to 1.5/1.6 once I see how I can abstract things to not be difficult to maintain with this Gradle foolishness.

At this time, the only real way to find out you're being moved is to pull the call chain out of your stack trace and look for a method invocation from my mod's namespace. You can do that in validate/invalidate, and in writeToNBT/readFromNBT, or even the constructor.

Waila needs to use try/catch blocks.

No eta. The best solution in the mean time seems to be to use a turtle instead of wireless redstone, where the turtle moves itself instead of being moved by the carriage. I'm sure somebody here can help you out with getting that to work, but basically it's "send wireless command to turtle ; turtle signals controller; controller moves carriage; turtle moves itself to follow". Make sure the turtle is positioned so that it's not trying to move onto where the carriage already was (so if your carriage is moving north, put it on the west/east/top/bottom) or else put in a looping check for "is there a block in front of me" before moving.

It'll be on github eventually, just not right now. For the moment, the source being in the .zip file is good enough, as is people posting in this thread.

That's why it's an average: Some can, some can't. I'm glad you can. I don't actually have an active GitHub right now, though: I've gotten so sidetracked with my Java preprocessor that I haven't done much on this project recently. (Java is amazing. I used to be a C devotee, and I still like it a lot, but Java is so fun: It's like living in a candyland paradise where unicorns prance around and little winged ones and zeros fill the sky.)

The average Minecraft user, even if you restrict that set to only the ones capable of installing a mod for themselves, is not sophisticated enough (or driven enough) to actually use a proper issue-tracker.

That crash doesn't even mention my code, and I'm really not feeling eager to decompile other mods every time something weird breaks. Until further notice, unless it's actually my code crashing, or it's obvious in some way that my code has caused some sort of corruption, I'm just going to assume the other mod is doing unclean caching or making too many assumptions and not worry about it. That doesn't mean it's necessarily a bug in the other code either: It just means they're doing too much wild stuff that makes it hard to handle.

Computers resetting on motion is not a bug. When ComputerCraft is altered so that computers retain their state when the world is closed/reopened, they will no longer reset on motion.

Even if the forge rotation were to become standard, and even if every mod everywhere simultaneously decided to support it, that would still leave multi blocks like tanks and pistons. Also, the first two points are incredibly unlikely anyway. If you want limited support for rotation, go bitch at the ugocraft people.

You go ahead and try to code rotation, buddy. You'll give up the moment you try to rotate anything like an IC machine or an extended piston.

You're missing two things: 1) Your textures, and 2) How to file a bug report so I can do dick-all about it.

That is definitely a lack of a null check in TE code. The question to be determined is whether that null check missing is a flaw in TE, or if a flaw in my code is causing expected state to be invalid that otherwise could never be invalid.

"unjustifiable" only when you don't consider the generality involved: My method works by default with the majority of blocks because it uses in-game mechanisms and duplicates Minecraft's code as much as possible. It's not "better" than Redpower's method: It's different, and lets me not have to write special code for the majority of mods, especially ones that implement deliberate counter-measures against their blocks being moved. (That said, the way I propagate lighting updates is dreadful and may account for the majority of time spent moving blocks.) I don't claim to have no bug causing this issue: I simply claim that, at this moment, I think I have none such, with regard to the actual blocks being moved. I'm absolutely open to finding out I'm wrong, though, if you do determine your code handles the cleanup properly.

Well, I have no idea about the particular complexity of your multiblock structure, but plenty of them move around just fine (even CJ's, and he hates them being moved especially). You have to support some way of clearing out the cache when a block is broken, though. Can you not take the code that runs when a block is broken and run it also when invalidation happens? There wouldn't be any risk of staleness, because when it's put back down, the full "I just got loaded from disk" routine runs on the blocks, and they are all in place (even with their tile entities) before any of your code gets a chance to run. All of the notifyBlockChange and what-not happens after everything is in its new position.

"Whose fault is this?"/"At whom should I yell?" is a complex question in this case. First, I haven't actually decompiled TE to check it out, so I'm operating simply on logic and precedence based on behaviour and experience. That said, here are the actual possibilities: 1) An undiscovered bug in my code that is fucking things up. 2) An issue with caching in the other mod. 3) An unexpected low-level interaction with vanilla. 1) is my fault, 2) is his fault, and 3) is both of our faults (since modding is unofficial and unsupported). In the case of 1), yell at me. In the case of 3), yell at me first. In the case of 2).....you can't yell at anyone. The reason for this is that mods (should be) based on vanilla. As in, your mod should be balanced against vanilla and coded against vanilla, unless it's some sort of expansion mod for another mod which obviously would require that mod (like extra bees would require forestry). As much as *technically* it is the fault of the other modder for doing lazy cache manipulation...that cache manipulation is valid in vanilla. Analogy time: Every morning, Susan puts her husband's watch on the bathroom sink so he remembers to wear it. Every morning, Joseph completely forgets about his watch until he sees it on the bathroom sink, and then puts it on. One morning, their son Peter decides (for whatever reason) to grab the watch from the bathroom sink and put it on the nightstand instead. Joseph never sees the watch, so he never remembers the watch, so he gets to work, and then goes "wait, what the fuck time is it" and is annoyed for the day. Who should Joseph's boss yell at for his lack of productivity due to distraction? Susan (vanilla) correctly did what she always does. Joseph (TE) carried on with the expectation that Susan (vanilla) would do what she always does, because he had no reason to suspect otherwise. Peter (RIM) was just trying to be helpful. Obviously, Peter's the one who moved the watch...but Joseph is the one that just assumed subconsciously that it would be provided to him instead of going "hey wait, where's my watch". And Susan had nothing to do with the whole thing: It's between Joseph and Peter. Since I feel that 2) is likely what's going on, there are only two possibilities: 1) Convince (gently) the other modder to do better caching. 2) Wait for me to (eventually, presumably before we all die of old age) write specific code to post-manipulate the other mod's cache myself so it stays valid (or, at least, not invalid).

Fucking class cast exception again. Augh! That error is my blood nemesis, I swear, and harder to grab than a greased eel in the Mediterranean.

Well, according to where in the code that happened, all of the stuff in the world already got put back in its spots, so you (should) have lost no data. Which also makes the crash silly, because as I say, everything already got put back in the world. That word "cache" in the TE code, though: What an awful word when it comes to this mod. On its own, not so bad: *IF* the other programmer has done his job and properly manages the cache on validate()/invalidate(). Quite a few times, though, that doesn't happen: Blocks aren't *supposed* to move around, after all, and modding is a giant hackjob anyway, so a good few modders make assumptions that are fine for vanilla code but not after I finish screwing around with their stuff. At a wild guess, it's making assumptions about how the cache is structured, and it crashes or doesn't based on what just so happened to be in what spots before and after, and also in which direction it moved, meaning that sometimes, after motion, accidentally its cache is still semi-valid (or at least, has the right slots open even if the slots contain old stuff). Smells like a situation where the cache is updated on block break instead of on invalidate. A pity. This is going to have to go on my list of "will fix if can, but don't hold your breath" because it's really the paradox of "he did it wrong because he doesn't properly clean up" and "he didn't do it wrong because vanilla doesn't cause him to have to properly clean up".

Is this an occasional thing or a frequent thing? Definitely started happening only when you upgraded TE and not at all before?

No, it's not the Rei stuff: That's just Rei's lazy programming, polling blocks that don't exist. Hmm.

Interesting. According to that error, the mod is crashing because it is retrieving a tile entity that does not exist and trying to act on it. However, the line of code immediately preceeding that crashing line is the line that creates the tile entity that is being retrieved. And it can't be crashing on any other part of that line, because if it were, the crash would have instead happened on an earlier line in that function. Somehow, the creation of the tile entity is failing. Without seeing your actual Forge log, I can't tell if it's printing out any other sort of error that might tell me why.

Sweet Mary and Joseph, that is the gnarliest crash log I have in my life ever seen. I can tell you right this moment that I will never be able to figure out *that* one. Multithreaded synchronization, socket manipulation, and Lua closures, all in the same crash, without even giving me a single line of my own code as a reference, or even as a starting point? Nope. First time anyone's mentioned Mystcraft crashes, too. Nope, nope, nope, no idea.

It's possible I've misunderstood, but I doubt it. The basic gist of it is, AbrarSyed has taken MCP and absorbed it into his Gradle project, and the "just MCP" method of modding is nearing its death, as MCP is just hanging on long enough for the Forge/Gradle system to become stable and replace it. And Forge is taking great pains to drive everyone away from doing anything anywhere at any time *except* with Forge, including base-class editing (even if Forge-compatible), so if you ever again want to work outside of Forge's limitations, you're going to have to learn a whole bunch of bullshit including Gradle internals and Scala, as well as set up the full development environments, to be able to recompile Forge piecemeal. Either that, or hope the Forge gods smile upon your tiny efforts and accept your pull request. Overall, except for fringe cases, it's fine. The big mods will keep working because Forge accepts their pull requests like a fat man accepts chocolate cheesecake, and the majority of the rest of modders already don't need anything that Forge doesn't provide. And mods like mine, where I just copy and paste vanilla code into my mod and rewrite it instead of editing base classes, will also be fine.