jakj

By the way, Lethosos, I just now got around to looking at those textures you made. (Yes, just now, I'm *that* lazy. ;-)) And they are really good. For some reason, they make me think of delicious jelly-filled pastries with sprinkled sugar......or maybe I'm just really hungry right now. Anyway, I'm working on a small update to be put out in the next few days (yay one-month no-update anniversary!) and have added your textures.

Unfortunately, all this tells me is that somehow one of my tile entities got Frankenstein'd with one of TE's blocks, and not when or how. The best I could suggest is try to reproduce it with as few mods as possible, and see if you can figure out whether some other mod is interfering, or if you could use that to tell me more about what's going on. To get your world back, delete the block at (194,96,-8215) with a world editor. This is a useless report. Go find a clue, then come back.

The error message is the error. It tells you what's wrong. It's plain English.

Alright, let me try very small words. The Carriage Controller is designed to move a carriage. If you tell it to move a carriage, either it will be able to move it or it won't be able to move it, so it will either move it or tell you why it can't. If you simulate, it is the same thing. You tell it to move a carriage, either it will be able to move it or it won't be able to move it, so WITHOUT ACTUALLY MOVING IT it will either tell you it can move it or tell you why it can't. Trust me: You are overthinking this by a fucking mile.

The same information returned by trying to move it. The functions are identical except simulate means don't actually carry out the motion. Stop trying to overthink it.

It simulates the motion: It does everything as it would if you were trying to move the carriage, except it doesn't actually move it. It tells you what will happen if you do actually try to move it.

The behaviour of a carriage based on which sides of it are closed depends on the order in which the carriage blocks are processed, which (very roughly) is in a radiating-outward-from-the-original-carriage-block pattern. When you have something as simple as a crane arm, you can 100% guarantee the order of traversal of the blocks along the arm. So, if the algorithm begins with a carriage block with an open side touching a carriage block with a closed side, it will pick it up without issue, but if it begins with a carriage block with a closed side touching a carriage block with an open side, it will not pick it up. That's why the first arm would carry the second arm but the second arm would not carry the first. This will be implemented.

Because it isn't intuitive. Putting such a functionality in would immediately generate the desire for three different behaviours: 1) Extra drives act as whatever carriage blocks they happen to be connected to; 2) Extra drives act as specific types of carriage blocks configurable by the user; 3) Extra drives act as they do now. People would also want a way to configure that on a per-drive basis, increasing complexity significantly. Also, the default would have to be for the current behaviour, because as I say it's not intuitive, and there is *no* visual or logical indication of any kind by default that this could possibly be the case. That rectractable arm can easily be implemented by adding a couple frames to connect the second arm to the first, and all that has to be done is to close some of the sides of the second arm so that the second arm can move freely, but the first arm moving will also move the second arm. There's no reason to open a giant can of worms to solve a few simple engineering problems.

I'll make it so you can control which side(s) of an engine/motor are able to move carriages, allowing you to attach multiple frames to one and have it still work, but I won't be implementing where you can have multiple carriages trigger each other in sequence or all at once. (Basically, though, what you posted in your video will be possible at some point.)

Not a bug in my mod: Whatever you are using to break the block is not calling the "removeBlockByPlayer" function, which is what I use to generate the drops. My mod uses far too much information for the 16 values of metadata to suffice, so I have to generate drops based on data in the tile entity, and by the time the normal base Minecraft "generate drops for the block that just got destroyed" function is called, the tile entity has already been removed and I cannot access it. You should file a report with the other mod saying they need to better simulate the process of a player breaking the block. That's on the to-do list for the future.

Oh, I see. Yeah, that's not going to work with the way I do things internally, but since I have many more types of frames available, creative engineering can counteract that limitation. Nested carriages can be implemented to a limited extent by staggered activation.

We just came up with a solution for the first thing you said, but what does it mean to transfer the movement force? Are you talking about nested carriages again?

So.........basically, being able to deactivate the sides of motors/engines just like you can deactivate the sides of the carriage blocks? Intriguing.

You could either use a mod that has a block that lets you break and place other blocks on the fly, or you could use multiple motors (possibly with computer control) to push them into some sort of storage channel in a wall or the ground.

I forget what it was called,, but someone found a block that can cause item activation like old redpower deployers so you can remotely trigger a portal gun to fire.

I get the feeling that it's been bothering quite a few people, but only two so far in the entire history of the mod have bothered to mention it. I've found some random message boards too, where people complain about bugs and how they don't want to use the mod until X and Y are resolved, and yet they haven't even said anything. Seems that only a tiny percentage of the users of a mod ever post about it. I suppose that shouldn't actually surprise me, though. Good idea.

Folks, now seeking feedback for changing a couple names to reduce confusion, since I've had a few messages about it and I happen to agree. The platform carriage (the blue one that pulls everything anywhere in the world that is touching it all in one lump) and the support carriage (the green one where the carriages' open sides have to all be facing the same direction and it moves anything in that direction and no other) seem to be confusing people, because "platform" sounds like what the support carriage does, i.e., a platform is a flat thing that holds stuff, and "support" sounds like what the platform carriage does, i.e., supports an object like pillars support a building. I want to swap these names, so platform carriage becomes support carriage and support carriage becomes platform carriage. Pro: More intuitive. Con: Confusing to people who are used to the names now. Options: 1) Don't change it, because it hurts more than it helps. 2) Change it, but only for the eventual 1.6 release. 3) Change it the next time I do an update for the 1.5 release. Thoughts?

Awesome to see spotlights being put out. I'm watching it now.

What I meant is that (for example) you will never be able to do things to in-transit carriages like flip levers, press buttons, open chests, add/destroy blocks, process redstone signals, or anything else similar. What some people want is carriages as fully-controllable airships, which is a completely different paradigm, requiring everything to be an actual moving entity (like a cow or an item frame is an entity) versus a tile entity (like a chest or a furnace is a tile entity).

There's no way to interact with a moving carriage and there never will be. If you absolutely need to stop one mid-transit, you'll have to give it a delay. To make an elevator with no delay and multiple floors, you need to create a system (probably using pistons as stops) to cause it to wait on each floor for you to say "go up again". If you are jumping, you may be jumping above the "area of influence" (think of it kind of like magnetism) of the carriage, which means your position is no longer locked to it when it moves. At which point, you suddenly discover that the carriage does not actually exist while it is in transit, and though it does place down some invisible placeholder blocks, it doesn't place them *everywhere*: Only where necessary. Improved motion while on a moving carriage is on my "to do" list, but it's very tricky and I'm not 100% focused on it, because quite honestly, the carriage system (and the original frame system, for that matter) is just not designed to make airships. (That's what Ugocraft is for.) I'm glad that you *can* make airships with it, but them not behaving completely airshiip-like really is just a limitation, not a flaw. Carriages are best used in situations where only one space is moved at a time (meaning it's only one second, which is a super-short time), or where there is no need to move or interact during motion (such as in a closed elevator). You are never going to be able to make some sort of carriage airplane unless you use a delay and let it be super-jerky.

That might be the case in less than one out of every five thousand error reports, and meanwhile, it fucks with the experience of legitimate users and fucks with modders who try to use unsigned jars because there's no point to signing the jar of a Minecraft mod besides DRM. People don't even use hashes to check downloads, nor would they even understand how.

Controllers do not have a continuous mode.

The version number prints out in the log and always has.

Well, that's certainly pleasant to hear. :-)

I know your first language isn't English, but you're going to have to try a bit harder than that.