jakj

No, that's a bug in the current version of my mod. I've already got it fixed and it will work in a server on the next update, which (hopefully) will be before the end of tonight.

I am using real ticks, though. I use a function called updateEntity that is called in the tile entity exactly once per physical game tick pass, and I increment a counter; On the server, when the counter reaches 20, it re-emits all the blocks it had absorbed, and on the client, it uses the counter to say "draw everything ticksExisted/20 blocks offset from their starting position". The rendering function is provided a "partial tick" argument, to make things smooth when the visual framerate is faster than the actual tickrate. I thought you were saying that the game could be designed to actually run at more or fewer than 20 ticks per second at full speed. If a server is supposed to run at 20 ticks per second but it can't keep up, then the process will take more than one real-world second. The issue comes at if the server is configured so that at full speed it's only doing, say, 10 ticks per real-world second, and could never get up to 20. In that case, at full speed, every single motion would take 2 seconds instead of 1. If that's the case, I'll have to add a configuration option to say "how many ticks per second is your server configured to run". And I will hate doing that, because I hate how shitty Minecraft is in a server environment, but I won't have a choice really.

That won't be a problem. Continuous mode is for normal redstone, meaning it keeps being activated by the same redstone signal instead of requiring pulses, so if you screw up, your creation will keep going off into the wild blue yonder until you either catch up to it and make a pillar in its way or it reaches the sky limit. For computercraft, it'll most likely be a simple "move in direction X by Y blocks and tell me when done". You can do that? Shit. Well, I guess I'll have to handle that eventually too. I can't give a rat's ass to actually play SMP, though, so you'll have to link me to some sort of documentation that tells me how the game can be configured to run at a different tickrate so I can start figuring out how it's handled.

That keeps coming up, and I think I'm going to have to address it at some point. I may have to actually add some form of Ugocraft functionality eventually. As it stands right now, though, it's true that you could put a drive in continuous mode and set the thing off on its way, but there's no way to control it after you do: You can't adjust it mid-transit because all the blocks are ghosts. If you're using ComputerCraft to control it (once CC is implemented, of course), then you're not going to be riding it for extended periods, because you can't interact with the computer while it's moving and the computer can't run while it's moving, so likely you wouldn't be riding it in the first place. Right now, continuous mode is designed for the smooth motion of the carriage over a predetermined distance, or setting up loops, or whatever. If you really want to use it as an airship/ufo/whatever, you're going to want to control it step-by-step. And in that case, I just don't think free motion while riding would be useful. If I ever were to include functionality like the old airships mod or ugocraft, then absolutely you would be able to move freely, but the amount of work that would take would be fucking insane. I could not even use placeholder blocks: It would have to be a free entity, and I would have to implement my own AABB collision detection transformed by the motion of the ship and apply it to present entities manually, and I would basically have to write an entire set of scripts for every single does-something-interesting mod block to reimplement its features during motion (because it would not exist in block+tileentity form during motion). (In short, there's a very good reason that Ugocraft supports only vanilla. ) For right now, I'm going to implement the motion as described, such that it locks you to the motion of the carriage but leaves you free to turn and act. I'll let you guys test that and see how it feels, and if you still think that is not acceptable, I'll listen to your feedback and go to plan B. I'm going to work on the next update a little bit tonight and more tomorrow; Hopefully it will be released before the end of tomorrow night if I don't have to stay late at work. I have another nice free weekend coming up, though, so it'll be a nice chunk of coding.

It's a little complicated for me to explain why the "pushes you out of blocks you're coincident with" effect wouldn't be sufficient in this case, so let me just put that idea out here. For the purpose of this, let there be two kinds of entities: Living and non-living. Non-living entiies are easy: Either they're stationary, like floating items dropped on the ground, or they can simply be frozen to the ground, like minecarts. These I can just hold where they are and apply a delta. Minecarts cannot be allowed to keep moving along tracks during motion because those tracks do not exist during motion. Living entities are players, monsters, animals, and such, that can move non-deterministically under their own power. For these, there exists a function already that effectively says "try to move by dX/dY/dZ but check for collision and other such stuff", which sounds like what we want, but then again, that function *also* takes into account things like the slowing effect of underwater. So if I use that function but the player activates the carriage while swimming, they are going to be moved too slowly and could end up embedded in a block opposite the direction of motion. If I simply increment the delta nd the player/animal/monster is moving in the same direction, they could get pushed too fast into a block. Now, what I could do is rip code out of both functions, the simple position-setter and the full movement-handler, and make a custom one that only does the collision checking. This is an option. But the thing I really want to ask is, would it even be necessary? That's even more processing occurring for motion that lasts for only one second, especially when you take into account the delay between client and server. Can you give me any exemplar scenarios of where being able to move around during one second of motion would be useful, keeping in mind that the only restriction being proposed is on the position, not the orientation or the action (so you can still turn around and do stuff, just not to the carriage because that's only a ghost)?

If I just apply a delta to current position per tick and a cow behind a fence decides to walk toward the fence in the direction of motion, it could put them in the fence and out the other side. The only alternative would be to use the builtin entity code for player or ai motion that checks for this stuff, which would add a lot of overhead with a lot of creatures present.

They can turn, use tools, attack, and do all the other normal things, but their position will be locked to the carriage for its one second of motion.

When the drive has determined the motion is valid and pulls the blocks out of the world, it will retrieve a list of all entities (players, mobs, floating items, carts...) in the cuboid region enclosing whatever shape the carriage happens to be (plus a small margin) and their current position. Each tick, it will manually reset the position of each entity 1/20 of a block in the motion direction, leaving its orientation untouched so it can still turn. At the end, the final tick will set all entities exactly one block from where they were.

That's about what I expected, and it will be in line with my method, except I'm just going to do a simple cuboid bounding box around the entire structure plus a margin instead of trying to figure out exactly what little bits should and should not be considered "on" the carriage. I don't really think that will be disruptive.

Between tonight and tomorrow I'm implementing entities like players being carried with the carriages. I have a method in mind already, but it would be helpful if you could describe redpower's glitches or flaws when it came to moving the player, so I can watch out for and test for that behavior.

Interesting. I was able to track down what caused that, but now I'm confused as to why it works with the integrated server: Looking at the code, it *should* fail there too, but doesn't. Anyway, it'll be fixed in the next release.

Ah, cool then. I did check my statistics with GoDaddy and it's starting to pull about 300 megs per day now. Part of that is the zip is one huge thing of everything, though, and if I put in nothing but the mod itself and kept the source download separate, it would be barely anything. I like having it atomic, though. If it gets to be a problem, we'll see; Right now, it gives me 300 gigs per month.

Wha? Did you link me somewhere?

You can make any array of them that you'd like to, as long as they're all full sets and powers of 2 (16x, 32x, 64x, etc.). I'll just put an option in the config file for the player to choose. Also, "2moz" made me die a little inside.

As long as you're willing to license them openly (WTFPL, GPL, CC, public domain, or something of the sort), then yes, I need them, because all I would do is scale down the existing textures in GIMP and they would look like absolute shit. I am not an artist by any means. (Just make sure they look fairly similar to the existing textures, so there's not a jarring "is this even the same mod" difference between them.) If you want to do that, then great. Go inside my texture directories (in the zipfile) and you'll find the original .xcf files with the separate layers that I use. I don't plan on adding any more textures any time soon, so if you do everything in there, it'll be a complete set for the forseeable future.

Version 0.0.2.0 now available. http://j-a-k-j.com/RedstoneInMotion_0.0.2.0.zip Known issues: Entities (like the player, minecarts, farm animals, et cetera) do not move with the carriage. Some modded blocks (like ComputerCraft computers) do not retain their state after motion. Forge information file (mcmod.info) not yet implemented. Some blocks in-transit are not yet rendered. Drives will not work on structure carriages when placed on an edge instead of a corner. Native-resolution texture option not yet implemented. ComputerCraft support not yet implemented. Omni-Wrench support not yet implemented. Recent changes (full list in "Changes.txt"): 0.0.1.1 -> 0.0.2.0 -- Blocks that have pending updates (such as buttons that were pressed) will now receive those updates after being moved. The blocks are in suspended animation during the motion, so the time remaining before the update will not decrease during transit (meaning that if it had 0.5 seconds before being updated before, once it finishes being moved, it will still have 0.5 seconds before being updated). Important note: If you get a crash that says "TickNextTick list out of synch", tell me, because that's probably my mod doing it. However, the code I wrote should (in theory) never generate the condition for that crash, so (hopefully) it will never happen to anyone. Also, don't stare too hard at the code. I did it in a very hackish way that I will later rewrite to be better, but for now it works fine, and since there are almost never a whole lot of pending block updates unless you just dumped down an entire ocean that's flowing down the side of a mountain, the inefficiency should be drowned out.

Remote control will be available with Computercraft integration. For adding to the mod directly I'll add to the "possibly later" list. Amusingly, that sort of thing is exactly the kind of trick my mod will have difficulty handling in other mods, any case of a block's xyz values being tracked outside of the tile entity.

No reason that AE won't work eventually. Tonight I will push out an update that fixes block updates missing their targets, so at that point go ahead and test AE and tell me if it breaks at all. I can understand the desire for pipes, wires, and tubes in carriage blocks for the sake of compactness, but honestly, it's not worth supporting when there are so many carriage types. Hell, if you're making something suspended in the air and are careful to never let it touch a wall, you can do the entire construct with just one single platform carriage block. Hello, buxville person. Your name is very familiar. Why would you not expect this of me? Our are you just saying "hey, small world"? Which is true.

Version 0.0.1.1 now available. http://j-a-k-j.com/RedstoneInMotion_0.0.1.1.zip Known issues: Blocks that schedule updates for themselves (like buttons) do not receive those updates after being moved. Some modded blocks (like ComputerCraft computers) do not retain their state after motion. Forge information file (mcmod.info) not yet implemented. Some blocks in-transit are not yet rendered. Drives will not work on structure carriages when placed on an edge instead of a corner. Native-resolution texture option not yet implemented. ComputerCraft support not yet implemented. Omni-Wrench support not yet implemented. Recent changes (full list in "Changes.txt"): 0.0.1.0 -> 0.0.1.1 -- changed recipes back to giving only 1 item each (an increase in wood required) -- changed carriages to prefer being broken with axe instead of pickaxe -- improved shading for in-transit rendering even more -- blocks now do not drop in creative mode

If you want to chat about this mod, do it here.

There's no reason I couldn't, but it seems a bit silly: There are practical limits to even player choice, especially since it's open-source and even somebody who knows exactly jack-shit about coding can simply change it theirself. You don't even have to configure stuff anymore: You download forge, run the "install" script, and it downloads both mcp and minecraft for you and does everything. EDIT: Here you go: http://www.minecraftforum.net/topic/1504359-152-theboos-mods-craftable-spawners-custom-recipes-and-magic-wands/ Supports mod blocks, so as long as the recipes don't need to generate NBT tags on the items, you're gold. That will work with the items in this mod perfectly, but a lot of the stuff in Essentia Vitae would come out broken if you tried that, or at the very least would default to level 1 cow.

No.

Funny as that might be, it's also just as bad as what Sengir did in terms of world damage. Now, if you made it visual-only by extending and replacing the vanilla still/flowing water blocks and overriding their getRenderType to your own that calls RenderBlocks.renderBlockFluid with an override texture, and you made sure to have a config option to disable this behaviour once it's no longer funny, then that would be great. I think CS had it closer to the truth, that he's not got a hardon for technic, but rather a hardon for ftb and he's using the bandwagon to support that. Then again, I have no knowledge other than reading that thread. Because the lasers are entities, yes. Right now, mine would move the torches but not the lasers, but when I add the code to move entities, it should handle both, and the only question would be if the landmarks when broken could still find them to clear them.

Seems you were right. http://forums.technicpack.net/threads/gregtech.35411/ I have to say, just wow at that, considering GregTech rips into the internals of all kinds of other mods to rebalance things and then has the audacity to block usage in a pack that didn't even include it in the first place? That actually exceeds Eloraam's hypocrisy, which I didn't think possible. Still doesn't quite piss me off as much as Sengir, though, because at least this was a deliberate and clear message rather than being sneaky and destroying players' worlds. Fuck him, then. I might still use GregTech for an ultra-hardcore mode eventually, but if I do, I'll be sure to include an obnoxious startup message (that can be disabled in the config, of course) tweaking in return. EDIT: I just read through the rest of that thread, and my reaction was (and I quote) "pfffffffhahaha". I'm not going to touch that sodding mess with a ten-foot pole, and now I'm glad I never even tried it. I'll stick to non-bullshit mods like TE and IC2. ----------- Once I get the entity-moving code in, its likely this mod will also be able to move activated BC landmarks and their lasers. I haven't looked at the code, though, so it might break down if there are any assumptions builtin about the location or if the X/Y/Z are cached anywhere instead of always pulled directly from the tile entity.

Wait wait, what? Anti-tekkit code? The only anti-DRM code I've done was v. Sengir's forestry. Are you thinking of that, or is this new? Rotations have been mentioned, but I'm iffy about it. The two main issues: 1) Collision detection: Making sure the carriage sweeping across an arc won't impact anything. Technically this is only visual, and can be ignored if visuals are not important. 2) Changing the facing of the blocks. This is a whole giant fucking ball of wax. Think about pistons, doublechests, every single machine in any mod (or even vanilla): I'd have to write code to rotate every one of them. Forge's new rotation code is barely supported by anything yet, and even in that case, it wouldn't handle the situation of something being flipped over vertically. So I'd say the chance of me doing rotation is farily low. I think Ugocraft does rotation for vanilla blocks, though. And I suppose I could add a -very- limited form of rotation using only the subset of blocks that don't have a facing, but I think all that would get me is a bunch of people yelling about how they want to rotate block X too.