jakj

Forge is the one that added this "JAR signature check" bullshit in the first place, under the delusion that people are shipping around viruses embedded in .jar mods, as if somebody who knows how to modify a mod to include a virus can't figure out how to resign the fucking jar. Forge is part of the problem, though it only provides some of the tools of drama, and not any of the actual drama itself.

Not any time soon, though eventually I will. I've gotten almost no interest in this mod overall, whereas I've gotten a ton of interest in Redstone In Motion, so my development energy's been spent primarly on that. Right at the moment I've been taking a mild break from modding to relax and play games, since I pretty much modded nonstop for an entire month before and after the initial release of that mod. Just working on getting my groove back.

Hidden DRM. And this topic is dead and buried: The community has proven that it is unable to get these modders to improve thier attitudes, or otherwise thinks those attitudes are fine, so there's no fucking point even talking about it anymore.

Sweet! That's amazing. Immibis is a god of code to get such a thing to work.

Immibis covers worked with my mod? They moved? I can't imagine how, but that's awesome.

I haven't tried it, but I have to assume they would either disappear, or just be left behind. They're not stored as part of the block's information.

Ha, no, her mod is a hundred times as big and important as mine. She has enough on her hands already.

I'll be honest: I'm not looking forward to it, because it means I'll have to learn Scala and get its tools added to MCP. All credit to MachineMuse, I tried to be enthusiastic about it, but after a little time spent messing about, I've come to the conclusion that I'm just not man enough to handle Scala. Oh well.

That's been reported here, too. Everything using the multiblock system is going to break, because my code completely bypasses all Minecraft functions and does everything itself, and my code was written before the multiblock system existed. I'll have to add explicit support for multiblocks in the future, and in the mean time, all multiblocks should simply disappear when moved.

To replicate Redpower behaviour, combine Carriage Motor with Frame Carriage. Closing the sides of the carriage with the screwdriver or omniwrench is equivalent to placing covers.

No no, that's just us discussing how to do it in the next update. You want code using the "pcall" function of Lua.

Until the next update that improves how the function is called, you can use the "pcall" to wrap it and check for errors. Look back over the past few pages for sample code.

The Applied Energistics ones use unified item-transport and power cables. Eloraam probably transferred the tile entities directly instead of indirectly recreating them like I do it. Doing it her way 1) would not save past a crash/reload, so I'd have to have my method in there anyway as a backup, and 2) is not general, requiring all kinds of manual special handling for bullshit like CJ's code that works against blocks being moved, or Buildcraft item pipes that cache coordinates, or what-have-you. Essentially, more trouble than it's worth, since "write a better startup program" works too.

Okay, combining the "increased delay reduces the problem" with "changing how the mod is located/structured on disk reduces the problem", I'll give you an explanation I currently feel about 85% confident in: It's the multithreading again, and not actually a bug in my mod, nor is it actually a bug in ComputerCraft. ComputerCraft is running all of the computers' setup/startup code plus your own startup program in its own thread, and this can be slowed by the disk (because disk is much slower than memory) and IS NOT SYNCHRONIZED WITH MINECRAFT. That's the key here: Normally, if Minecraft is doing something disk-intensive, shit just slows down: You get intense lag (like generating new chunks with lots of mods) or similar behaviour. That works fine for Minecraft, because even though it's being slowed down, all the rest of Minecraft has to wait until the slow part is done, so nothing gets out-of-step. ComputerCraft does most things in its own thread, specifically to prevent Minecraft from being slowed down. That's why a more computers causes this to happen more, and more delay causes this to happen less: You're giving everything time to finish. Why does it not happen when Minecraft is actually loading the world versus moving the carriage? Because Minecraft is slow as fuck, especially when loading world from disk, and by the time the world has loaded enough for you to even see it, ComputerCraft has had plenty of time to finish initializing everything as it's being loaded. My mod lags Minecraft very little for a small carriage, so it doesn't have time to finish in that case. This is the same reason I had to get people to add an os.sleep() to the start of their programs if those programs need to move carriages multiple times in a row: It takes a bit for the computer to actually start running again, and sometimes ComputerCraft tries to do things too early and sometimes too late. Why is this not a bug in my mod? Because it's the way ComputerCraft is designed. Why is this not a bug in ComputerCraft? Because ComputerCraft is designed for vanilla, where the only two times a computer loads are 1) from disk, either opening the world or loading a chunk, in which case Minecraft is plenty slow for it to work, and 2) when putting down a computer from your hand, in which case the computer doesn't even turn on right away, so it's done initializing by the time you click on it again. So, basically, the only solution is to add more delay as you add more computers. Trying to use computers as block breakers in this case really just isn't going to work unless you want a super-freaking-slow tunnel bore. I recommend switching over to something like MFR for your block-breaking needs.

Are you saying it's proportionate to the carriage size, to the computer count on the carriage, or both together? Because those aren't the same thing. So does it happen if you have a lot of computers carried by only a few carriage blocks, or does it happen if you have just a couple computers but it's a huge carriage construction, or what? Also possibly relevant: Does the behaviour change based on whether or not the computers are directly adjacent to each other or separated by some airspace? Does the behaviour change based on whether the computers are labelled? Are the computers being moved in continuous mode or is there always at least some sort of delay between operations? Does the number of failed-to-turn-back-on computers change based on how long the delay is? Are the computers connected to anything (like a peripheral), or do they connect to anything before/after motion? Another interesting test: Set everything up like you're going to move it, but instead of moving it, close and open the world a bunch of times quickly, as many times as you would have moved the carriage to get it to fail. Does it fail then too? This could be yet another complication caused by ComputerCraft trying to do things in a multithreaded way.

I'm pleased that more people are creating intricate and novel contraptions with the carriages, rather than just complaining about how it doesn't use enough nether stars. The overall-higher maturity on this site is keeping me sane and balanced.

Since you have five types of carriages to choose from, I advise you become more creative.

The remote orderer item thingy must be storing absolute X/Y/Z coordinates of the pipe, which obviously won't be correct once the pipe is at different X/Y/Z coordinates. It's possible for me to adjust internal variables of blocks that are being moved to handle some things, but there's absolutely no way for me to try to iterate through every player's inventory searching for remote orderers in order to adjust them. Sorry to say it, but this is going to have to be marked "can't fix". The only way for it to be "fixed" would be for the Logistic Pipe developers to use a frequency system instead, like the TE tesseracts do, so that when the pipe finishes being moved and its validate() is called, it reconnects to the appropriate frequency. You can suggest that to the LP team, if you want, but they already have a very long to-do list. Anything with multiparts (including his new wireless stuff) is going to be broken by my code. I'll handle it eventually, but as of now I haven't even looked at the new multipart code in forge.

That looks delightfully StarTrekky.

I'm glad the hotfix worked for you. The bug you just demonstrated will be fixed in the next release, whenever that happens to be.

https://www.dropbox.com/s/mm9646mh2pv9qgf/RedstoneInMotion_1.2.0.1_mc1.5.zip

Post the full Forge error logs on pastebin. Stop just extracting one exception trying to help, because that exception doesn't even mention my code. And post pictures, because I can't tell what the fuck you're trying to do just from a vague textual description. Turn off Connected Textures in Optifine.

Good to hear.

It's taken five weeks for anyone to even mention this, so I'm not worried about fewer bug reports. A config option will do nicely.

A config option would work, yes. I'll have it default to the current behaviour of continuing motion, so people won't be confused who think a config is a type of fruit salad.