jakj

I'm going to have to look at all these errors later at home instead of on this tiny-ass phone screen. Overall, both of you describing lost state is caused by tile entities disappearing, thus being recreated as if the block was freshly placed but without any of the proper on-placement logic running.

That error indicates that somehow the blocks between my mod and that mod are getting Frankenstein'd together somehow. I saw people reporting that error earlier in the mod's history but not recently until now. I notice an indication of excessive server load before that exception. Does this happen regularly or only under heavy load? Can you get it to happen 100% reproducibly with a particular arrangement of blocks, or is it intermittent? When precisely does it happen: Before, during, or after a motion? What (if anything) is left behind: Is the carriage mostly intact, is it completely gone, or are the invisible placeholder blocks left? Can you reopen the world without crashing? If yes, do you notice any specific block missing?

All I do is occasionally google "Redstone in motion" and that came up. I just kind of feel a bit resentful when casual searches of my mod by the public result in people saying my mod is unstable and shouldn't be used, but those people don't even bother to take the time to tell me so I can either fix it or show them what they're screwing up. It's hard enough to get my mod in use by the public when I'm associated with Technic, don't use MCF, and am viewed as a minor rogue element and overall a nasty person by a lot of the "bigs" of modding.

Minecraft 1.6.3 has been announced. In theory, the mod should run in it with no changes, but be sure to backup your stuff before updating and report any issues if there turn out to be any.

It's trying to render the translocator before the server has reinitialized it from its motion, and I (stupidly) forgot to check for that. Will be fixed in the next release.

To make a translocator's label private, craft it with a redstone comparator. "private to self" means it's using your private channel, and "private to other" means it's using the private channel of someone else. "public" means it's not using a private channel at all.

Here's another one: http://aiminecraft.com/home/m/12489167/article/1732335 I'm rapidly coming to the conclusion that the entire Internet is laden with stupidity.

I'll have to check the vanilla classes to see how it uses the flag, because it won't be useful if it ends up giving lots of false positives. Then again, I could skip the check for anything in the net.minecraft namespace...

*sigh* 1) Use code tags so I can actually freaking read it. 2) Post the full forge log ("ForgeModLoader-client-0.log"). The FULL log, not just what looks like an error. If you have played since the crash, the log will no longer contain the error, so you'll need to make it crash again. 3) Post a screenshot of the crashing carriage before you move it so I can see what blocks are where.

I've never even heard of that function/flag, which means I didn't account for it in my code. In the Minecraft world (and, to a lesser degree, in the Java world), all prohibitory actions must be opt-in, meaning that (for the most part) you have to deliberately check for restrictions in order to be restricted by them. If you were to give me a list of all "if X is Y then it's meant to be immovable just like bedrock" functions/flags/properties/whatevers and how to use them, I could easily iterate through the entire set of 4096 blocks and add them all to the blacklist. (The user would still be able to turn off this blacklisting in the config, of course, but obviously this would be fine for servers since the blacklist (and almost every other setting) is server-side.)

Why did you think I was gone? Because I said fuck off to MCF?

So, random googling of myself found this in an IRC log: [07:47:27] <Kodos> Apparently there's a bug with RiM, in that you need to break and replace the transmitting translocator each time you want to move something Has anyone here experienced anything like this, or is this guy just doing it wrong? Since I don't have a bug report to go on because hey, he hasn't bothered to submit one. (Sidenote: It's kind of annoying to google my mod and see people elsewhere describing it as "wip", "buggy", "too new", "flakey", and "crashy", when according to you all it works great and the few crash bugs I've fixed without too much delay. I'm trying to decide if you're trying to keep me buttered up, or if the rest of the Internet is just people who don't know how the fuck to use their computers.)

It would be simpler to use the regular screwdriver, and I could just hook it into sneak-activate and leave the nonsneak-activate as it is (which displays the ghost blocks). However, I must consider the fact that every other current use of the screwdriver is a toggle of some sort, that can be undone by simply doing it again, but this would introduce a use of it that creates and deletes things, especially since a player might well be sneaking while messing around with the carriage. Which is more beneficial (and more common)? Not having to use a different tool to adapt a pattern, or not accidentally screwing a pattern if the player happens to be sneaking and happens to be using additional template-carriage blocks for some other purpose nearby?

You're using a newer version of ComputerCraft, and there was an API change that mine hasn't been built against. I haven't yet decided the best way to support both versions at once, but in the mean time, the only way to get it working is to downgrade ComputerCraft.

By the way, to whomever has been keeping the "Not Enough Mods" bot list up-to-date with my releases: Thanks; By the time I remember that thing exists and go check, it's always already done.

Another bugfix patch! Stupid mistake #2. Shall we go for 3? (This, folks, is why you remember to give new releases a little time before you push them out to public servers and packs.) 2.1.0.2 - MC 1.6.x http://j-a-k-j.com/RedstoneInMotion_2.1.0.2_mc1.6.zip https://www.dropbox.com/s/3m37xzpinkps1iy/RedstoneInMotion_2.1.0.2_mc1.6.zip 2.1.0.2 - MC 1.5.x http://j-a-k-j.com/RedstoneInMotion_2.1.0.2_mc1.5.zip https://www.dropbox.com/s/tgezpzwo6naojw7/RedstoneInMotion_2.1.0.2_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 2.1.0.1 -> 2.1.0.2 -- fixed a bug preventing the mod from being loaded on dedicated servers

Okay, nevermind all that: I thought of a way to do it. *) Craft a regular screwdriver with a bucket of water and a ball of clay: Becomes a constructive screwdriver. Place down a new template-carriage block where you want to add something to the existing pattern, and use the constructive screwdriver on the patterned template-carriage block to re-absorb the pattern. If the new block would have been added to the pattern in the first place had it been present, the pattern will now contain it. *) Craft a constructive screwdriver with a bucket of lava: Becomes a destructive screwdriver. Place down a new template-carriage block where you want to remove something from the existing pattern, and use the destructive screwdriver on the patterned template-carriage block to remove that block from the pattern (or blocks, if multiple were placed down). This will allow someone to create a template with holes in it. I'll put it in a future release, but not any time soon. Maybe for 1.7 unless 1.7 takes a long time to get here, in which case it'll come before. (Yes, everything will still be backported.) I really hope this doesn't make everyone use nothing but template carriages for everything everywhere from that point on, because that would kind of piss me off. It's their right to choose how they want to use the mod, of course, but that doesn't mean I have to be happy about it.

Can't click on the ghost blocks as they don't exist. Would have to use a special kind of template for that too.

If someone can come up with a process that makes sense and is simple for the player to add a position to an existing template as well as to remove a position from an existing template, I'll consider it. No GUIs.

Possibly, but it would require rewriting several algorithms or implementing a new item. Also, it would just lead to even more complaints if I didn't then also implement removing one. I guess I can put it on the "maybe if I ever feel like it" list, but the things are ridiculously powerful already. I'd also not like to remove nearly every reason to not use any carriage type except them.

The amount of effort it would require to implement such a thing is not worth the small reduction in inconvenience it would generate.

You have to break it and lay it down again. Yay, my second stupid mistake by forgetting to remove one keyword. I'll fix it tonight.

BUGFIX PATCH RELEASE - 2.1.0.1 2.1.0.1 - MC 1.6.x http://j-a-k-j.com/RedstoneInMotion_2.1.0.1_mc1.6.zip https://www.dropbox.com/s/3wj0wz8zwv9rq62/RedstoneInMotion_2.1.0.1_mc1.6.zip 2.1.0.1 - MC 1.5.x http://j-a-k-j.com/RedstoneInMotion_2.1.0.1_mc1.5.zip https://www.dropbox.com/s/seci4wqb3od7l9m/RedstoneInMotion_2.1.0.1_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 2.1.0.0 -> 2.1.0.1 -- fixed crash bug when entities were on carriages being translocated

I guess 2.0.0.0 because it's been out longer, but nobody's complaining about 2.1.0.0 yet other than the one bug I'm fixing tonight. My mod rips into Minecraft's internals pretty deeply, so "stable" will always be salted for it. If it helps any, I personally would have no hesitation to use my mod in a play world, but I would always test a combination of mod blocks first just to be sure.

Crap. I must have somehow left in the code that grabs entities in the translocator. I'll fix it tonight.