Jump to content

jakj

Members
  • Content Count

    3240
  • Joined

  • Last visited

Everything posted by jakj

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. 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.)
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. You're missing two things: 1) Your textures, and 2) How to file a bug report so I can do dick-all about it.
  14. 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.
  15. "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 causin
  16. 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
  17. "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
  18. 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.
  19. 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 a
  20. Is this an occasional thing or a frequent thing? Definitely started happening only when you upgraded TE and not at all before?
  21. No, it's not the Rei stuff: That's just Rei's lazy programming, polling blocks that don't exist. Hmm.
  22. 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
  23. 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.
  24. 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 includ
×
×
  • Create New...