jakj

HOW TO BUILD A TUNNEL BORE WITH TEMPLATE CARRIAGES http://imgur.com/a/ygZH1 There, now you can stop asking me. (Funnily enough, doing this made me discover a rendering bug. Oh well.)

My carriages carry tesseracts without issue. The problem is he's using frame carriages, and he's got that wire going through them, which means there's no frame carriage touching the block breaker connected to the wire so it won't be picked up. What he should be doing is using a template carriage to make a bore with a roof, or he could also use any of the other types with more difficulty and a stutter-step pattern. The easy way, though, is just make a 5x5x5 of template carriages, use the screwdriver, attach an engine, put up your machines and block breakers, put a roof on it to keep out the gravel/sand/liquids, and away you go. In fact, the way he's doing it in that picture is the only way to *not* do it.

Not only has it been mentioned, I've already explained in detail multiple different ways to do it. I implemented FOUR entirely new carriage types in addition to the old RP frames, specifically to make shit like this easier/possible. This specific example was even what reminded me I need to put in the template carriages.

Known issue: It will be fixed in a future release.

Carpet? Minecraft has carpets now?

I wasn't aware the grabbing height was too high. I'll test. I'm including options to configure what is grabbed when in a future release, but like the rest, will be server-side. No component of this mod except rendering is client-side. Sticky blocks are a neat idea and would solve the problem neatly, letting the server turn grabbing off but letting players still have it if they want. I'll add it to the list.

I can try rendering normally when there's no tile entity, but some stuff might break visually, like if it uses the old modloader methods, or if they're placeholder blocks actually rendered by a nearby tile entity. Your comment about flying is so vague and non-specific that it's useless to me.

Post or send me some screenshots or video and tell me what versions of what mods you're using, and I'll try to reproduce it for debugging. Do they reconnect with a delay or do they never reconnect?

Nevermind, I found my derp. Will be fixed in the next release.

Yep, that's the Bukkit crash that happened before that I can't do anything about. Although, if there's any way you could send me your deobfuscation/reobfuscation log, I could try adding a few fallback values to the reflection. I wanted to avoid having this be a coremod, but maybe that would work better......we'll see. But if I can figure out how Bukkit is changing the obfuscation, maybe I could adjust for it. (Or maybe bukkit could fix itself to stop fucking with the obfuscation. ) Asking permission before adding to a mod list!? Damn...Either you are polite well past the point of absurdity, or the Minecraft modding community is so toxic that they have bruised your psyche like a solid-black banana. What in the fuck? Minecraft called my block with the tile entity of another mod? Is it possible the tile entities got switched somehow? Hmm, I'm going to have to look into that one.

Well, there's no way within the current paradigm to avoid block-by-block motion, and it re-searches for entities each time it begins to move one block, so it would grab new entities without too much delay, but remember that the placeholder blocks are not a 100% representation of where the carriage was or will be: The placeholder blocks exist to prevent things like sand, gravel, and liquids from falling through the top of the carriage during transit when the carriage actually has a solid roof. Trying to jump onto a flying carpet that's going on its merry way could result in things like being suspended in mid-air during motion if it grabs you at just the wrong time, or jumping through what looks like a solid spot which really has no placeholder blocks. That's really one of the biggest downsides to not being locked in place on all three axes: You're quite likely to fall right through what otherwise looks like whole blocks.

My mod has been confirmed incompatible with Bukkit, and I have no idea what MCPC is, but planetguy seems to imply it uses bukkit, so that's why he said that. This crash was different, though, and I can fix it. We're just saying that if you have bukkit, you'll still crash eventually.

This is 100% true, but funnily enough, this is actually a different issue. Technically, it's not a bug in my code, but it's something I'm going to have to adjust for that Forge does that it shouldn't. Once it's fixed, you can try the code again, but I make no guarantees or promises of proper function except on vanilla servers running Forge. You want to use my mod to make a Mario game? Um. To do what you want in the way you want it, I would have to search for entities in the bounding box of every single carriage every single tick, so that once they're in the area of effect, they can start simulating a solid surface for the player to "jump" on, and even that would work only for horizontally-moving platforms: You can forget about it on vertical platforms, because of the way the placeholder blocks work and having to lock the player's vertical position during motion, it just flat-out won't work, no way, no how. Not that I'm trying to crush your dreams: I'm just saying "don't hold your breath". A flying carpet, now, that would be doable: You could use a continuous-mode engine, and you could configure a half-second delay or so between motions so the player has a chance to manipulate levers to stop the machine if desired. No way to get it to work without that delay unless you want it to be a permanent carpet ride out to block 300,000. *sigh* I'm really going to have to make this mod into Ugocraft some day, because even though this mod can do things Redpower never even tried, it 100% is not designed for half the things people are trying to make it do. I'm pleased by how creative people are being, though.

I never expected so many people to be put off by the textures. (That's how you can tell I'm a self-centered hermit.) I'm glad so many people are coming up with alternatives.

That's actually a really good point. Some people might feel it confining, whereas I feel it reassuring, and that is a dichotomy in its purest form. I really have no choice but a config option, then, to suit the personality of the player. Also, you haven't even said word one about my soul shards mod and its heads, and you seemed so eager for them. :P

Pff, it never got out of obscurity, because I refuse to bend over and host it on MCF instead of here, but I see what you're saying. Maybe if I can get free movement working on continuous carriages in a non-shitty way, it'll reduce the demand for ugocraftalikeness. I'll give it a shot, anyway, and if nothing else, I can say "hey, turn it on or don't, but don't whine if it doesn't work, because at least I tried".

Well, I just put in a way to get out of that, namely that the mod no longer stores the captured entities' IDs to disk, so if the world or chunk are reloaded, no entities will be captured, and on a server, every time you login you'll have a different entity ID, so that already let you escape. The other way of doing it from the way I'm doing it now is to simply translate the player's current position each tick without changing anything else. You might think that would work, but there are several complications, most notably placeholder blocks and vertical motion. First, placeholder blocks. If the player is going to have free motion, there have to be placeholder blocks, or else it would just drop you through the carriage. So then you say "so lock the Y coordinate but leave the X and Z coordinates alone and just increment them". This could be an option. Second, vertical motion. There wouldn't be any choice here: The Y coordinate would have to be locked and maintained. At the end of the day, I could do some testing, make some tweaks, and say "if you enable this, you get what you get". I'm all for player choice, so it's to be considered. But there's one thing I still don't understand: Why? Other than being able to escape a runaway carriage (which we already established as possible), what is the true difficulty involved in a one-second absolute translational immobility? During motion, you cannot interact with the carriage, so it's not like you could use your time flipping levers or opening chests. Being immoble doesn't restrict you from using items, opening your inventory, or eating food. If I keep getting messaged about this, then obviously there's enough demand for the feature that it should be included. I just don't understand why people want it.

Without screenshots to be able to tell anything you're doing at all, the only thing I can say is to remind you that frame carriages, like RP carriages, move only the block touching them directly, and anything beyond that will be an obstruction. The other carriages have different properties. If you provide pictures or video so I can see your setup and what you're trying to do, I can tell you why it is or isn't working.

No spoiler tags, no. It's theone and only thing I desperately wish it had.

I would have to adjust the placeholder blocks each step, for one thing. Also recheck for obstruction each step. And since I would no longer be forming the carriage atomically, the world could change mid-motion. In other words, I'd still be doing everything block by block. The only difference is the animation, really. Don't forget that the Redstone signal can change at any step too. I could maybe do some special checks for cc-controlled stuff to make it a bit smoother, but for regular engines and motors, there just aren't any short cuts to take.

The issue is how I do all my calculations: I could program it to accept a command to move N blocks, but it would still do it one block at a time. That crash mentions Dimensional Doors, not me.

If wireless Redstone never updates, I will add it, but I really don't want to. Seems like the chances of it updating are decent, though. Both source and flowing liquid blocks will always flow when moved by a carriage, even if they did not before, since I issue neighbor update calls to every block. I don't see a reason to limit the carriage to only source blocks. Under the current design, carriages will always move one block at a time. Try continuous carriages with safety stoppers for things like folding bay doors and elevators. In the future, I might adapt the code to make a mobile entity like ugocraft in addition to what it does now, in effect, a freeform airship controllable by player or computer. No promises.

Oh, good point. But still, there are some good reasons to carry liquids.

The first reason to move liquid blocks is for decoration: You can have a floating platform that's like some sort of courtyard with water fountains, and disguise the carriages as glass so you can see through the bottom of it. Or you could decide you have a really nice-looking lake and you want to move it somewhere else without having to dig it out and refill it. For digging, since I haven't programmed flammability into the carriages, in theory they should just be able to ignore lava and not even worry about it, so there wouldn't be any point to using water in that situation. But what if you want your tunnel bore to be manned, and pretend you're some sort of deep-earth explorer? You could have a pool of water near the floor of the bore, and set up some sort of hatch that will open and let the water flow down, then close again, if you decide to fly over lava and want to harden it. Or if you want to make a bridge across a lava ocean in the nether, you could do it the easy way of just laying down blocks, or you could do it the cool way, and have a contraption which flies immediately above the lava and opens/closes a hatch with water above, and since it's right above the lava, the flowing water will be contained to the width of the hatch. Boom! Obsidian walkway. Or yes, griefing, so a server would probably blacklist lava from being carried in the first place unless it's just a server of friends. This can get tricky. I might just have to put in some additional logic and flags instead of using the blacklist.

That...would be difficult to setup. I could make it so that, if a liquid container were in a blacklist chest, that liquid would be treated as an obstruction instead of moved through, but that would also blacklist that liquid from being carried in that carriage as cargo (in block form, I mean; liquid containers inside chests on the carriage would be unaffected). Are there any situations where you would want to carry liquid X in block form on a carriage while also preventing that carriage from moving through liquid X in block form in the world?