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.