jakj

I doubt that's the case, because what my mod does (currently) is make a display list (the OpenGL equivalent of a photograph) on the client side before any blocks have been moved. If GregTech is using display lists individually for his blocks, that could explain the GregTech blocks not rendering, because his internal display lists would not copy over once the blocks disappear. (Same problem happens with template carriages: The grey "ghost" blocks use a display list, so if you have them turned on and move them with another carriage, they won't render until it stops.) But that wouldn't explain non-GregTech blocks not rendering.

Alright then, in that case I won't worry about it. If you can get the issue to pop up at any time without GregTech installed, I'll take another look at it.

Can you do screenshots or a video? On mine it does render.

ALPHA TEST for RIM update to 1.6 If all goes well, this will break nothing. If not all goes well, this will break your shit. You know what to do. This is an alpha test, not a release candidate: That means bugs are guaranteed. It is 99.9999% identical to 1.2.1.0 (the current release) for 1.5, so you are looking for things that are fine in 1.5 but broken in 1.6. Feel free to copy your config file from 1.5 to 1.6 to make things easier to test, if you want. (Credit to Lordmau5 for doing the work and sending it to me, which I mostly just copied and pasted.) https://www.dropbox.com/s/izr8wtffs8rd9nm/ALPHATEST_RedstoneInMotion_2.0.0.0_mc1.6.zip

Computercraft is multi threaded and does not explicitly sync with Minecraft. It takes time for things to settle after a move. The smoothest possible motion comes from a motor or engine in continuous mode with cooldown in the config set to 0, because everything happens in a nice orderly lockstep. Computercraft has to have a too-large delay embedded because it lacks that lockstep and you cannot programmatically be sure when the world is settled. I won't say it's a flaw in Computercraft, but I will say its multi threaded nature is a giant pain in the ass most of the time, and while I understand why he choose to do it this way, he needs to have allowed it to operate within the main thread instead as an option.

Me, in the FTB IRC? I might as well just throw rolls of toilet paper at passing police cars: It would cause far less drama. It'll be fine. I just need to sit down at some point and start grepping and grokking.

Right, I'll just pick up my red phone with a direct line to Chicken Bones HQ and...oh, wait: He'll not just stop and walk some random asshole through his code. Turn off player grabbing in your config, then.

I will, but I doubt it will be easy, so no predictions.

Due to the contribution by Lordmau5, updating to 1.6 will begin on Sunday and should be released on Monday. 1.5 and 1.6 branches will be maintained simultaneously with no feature differences between them.

That's a flaw in ComputerCraft, not a bug in my mod: I have to use removeBlockByPlayer to generate drops, because I need access to the tile entity to do so, whereas the normal block-drop functions of Minecraft are called after the tile entity has already been destroyed. ComputerCraft does not properly simulate the use of this function when its turtles break a block.

I will when I get home and settled in this evening.

I just hadn't bothered even learning 1.6 yet, to be honest. If you got it working that easily, I can just look at what you did and do the same. And have you even looked at my license? How can you possibly think you don't have permission to post it? My license is so permissive, someone could rip off my entire code base byte for byte, give it a new name, and release it as if they wrote the damn thing theirself.

I wasn't talking about that. I was talking about my comment that I was going to split the anchored and non-anchored into separate blocks, and then decided I won't. My edit wasn't clear. Okay well, you guys try to think up something more intuitive, then. I'd rather not do something like move_anchored and move_unanchored but I guess I can. Or I can just leave the boolean parameter in there, but I think splitting the functions would make code much more readable.

What? First change, you will be able to use the strings "up","down","east","west","north","south" and the strings "posy","negy","posx","negx","posz","negz" in addition to the current digits of 0,1,2,3,4,5 for specifying direction. Second, simplifying the commands: move(0,false,false) becomes drive(0) move(0,false,true) becomes move(0) move(0,true,false) becomes drive_check(0) move(0,true,true) becomes move_check(0) So basically, "drive" is non-anchored mode like engine, and "move" is anchored mode like motor. So the terms are intuitive, think of a car: If you drive the car, you're in the car and you go with it, whereas if you just move a car (like with a crane or tow truck), you don't go with the car.

Disregard the controller change: I thought of a better way to do it.

For the texture issue, there's really no reason it should be doing that, but since it is, I have a workaround I can try. For the subreddit, I have no interest in administrating such a thing, but if someone else makes one, I can give it a shot I guess.

Don't ever let the minority prevent you from benefitting the majority. Small and closed minds have no place in proper society.

Carriages are not designed to handle being altered in the midst of an operation, especially not if you're messing around with them in creative mode.

It will be configured by clicking on the block with an item, and its current value will be displayed on the side of the block.

To celebrate the one-month anniversary of no updates, have an update! (The changelog includes the 1.2.0.0->1.2.0.1 update as well as the current 1.2.0.1->1.2.1.0, because I was super-lazy and never officially released 1.2.0.1.) http://j-a-k-j.com/RedstoneInMotion_1.2.1.0_mc1.5.zip https://www.dropbox.com/s/siozd2pws3b1kk6/RedstoneInMotion_1.2.1.0_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 1.2.0.1 -> 1.2.1.0 -- added 16x Dynasty-based texture set by Lethosos -- added notes to tooltips that 'platform' and 'support' carriages will be swapping names in the future -- fixed bug that the pattern-holding block of a template carriage can overwrite other blocks in the world -- template carriages will now drop their pattern carriage blocks when the core template block is broken -- fixed bug that caused controllers to not recognize existing carriages when the world or chunk is loaded -- return codes overhauled for Carriage Controller ** (this needs testing because I don't know ComputerCraft or Lua) ** if motion is successful, returns "true" and nothing else (1 value) ** if motion is not successful because of obstruction, returns "false", then a plain-English error message, then the X/Y/Z coordinates of the obstruction (5 values) ** if motion is not successful because of something other than obstruction, returns "false", then a plain-English error message (2 values) ** the only time it will now throw an error and abort the running program is for a syntax error; a valid command that simply can't be carried out will no longer abort the running program 1.2.0.0 -> 1.2.0.1 -- removed some vestigal server->client data transmission -- fixed buildcraft pipes not accepting items immediately after transit -- fixed items in buildcraft pipes stuttering/slowing after transit -- fixed ComputerCraft synchronization with Minecraft thread of execution to clear a bunch of crashes -- continuous-mode cooldown can now be changed back to 0, though the default for new configurations will still be 5 ** note that with no cooldown, after the first step of transit, many tile entities will no longer render correctly until transit stops ## this is cosmetic only, and does not occur if there is a cooldown of at least a couple of ticks unless server->client transmission is super-slow KNOWN ISSUES Anything that already uses a display list to render (like the ghost blocks of a patterned template carriage) will not properly render in-transit. Transparent blocks (like water) render in a bit of a wonky fashion in-transit. ---------- Portal spawners from iChun's "Portal Gun" mod do not yet work on carriages. Try finding some way (possibly using additional mods) to activate a portal gun directly instead. Anything using Forge's "multipart" API (such as the newest ChickenBones wireless redstone) do not yet work on carriages. ---------- If you are using Optifine and get a crash with the word "ConnectedTextures" in it, either disable connected textures in Optifine or disable/remove Optifine. ComputerCraft programs that are carried by carriages and interact with the carriage's drive, need to have a delay added to their "startup" program to give time for things to settle before trying to interact again. Try "os.sleep(0.1)", and increase that number if it still doesn't work. (The more overloaded your machine or Minecraft is at the time, or the more computers or turtles you have on the same carriage, the higher this number will need to be. Making the number higher than it needs to be is fine: Too much won't hurt, but too little will.) Computers on carriages that are running at the time of motion will reboot after motion, and run their 'startup' program. (Computers that are off at the time of motion will remain off.) If a carriage is moving continuously, and the continuous-mode delay is set to 0, tile entities (like chests) will not render properly after the first motion until the carriage stops. This is purely cosmetic, and does no harm. To prevent this, make sure the continuous-mode delay is greater than zero. (The more Minecraft, your system, or the server is overloaded, or the longer delay there is between you and the server, the higher this number will need to be.) PLANNED FEATURES A mechanism for teleporting carriages between dimensions. Redoing and simplifying the 'move' command to make it more intuitive and easy to use. The ability to deactivate specific sides of engines and motors to allow for staged carriage structures with multiple carriage blocks in contact with drives. A config option to specify whether in-transit rendering of a carriage continues or pauses when there is severe lag. The ability to set block or item IDs to 0 to prevent their being registered. Improving the behaviour of placeholder blocks. Swapping the names of platform and support carriages to reduce confusion in the future. The ability to remove bedrock from the blacklist if desired. A config option to let a carriage treat blacklisted blocks as simple obstructions instead of completely aborting the motion. The ability to selectively whitelist/blacklist blocks in-game for each drive, in addition to the overall config-file blacklist. These blocks will always be treated as simple obstructions instead of completely aborting the motion, regardless of the setting in the config file. A form of "sticky carpeting" to allow finer control over where on a carriage entities are grabbed. Different styles of controlling player position during carriage movement, to try to allow more freedom. The ability to set continuous-mode cooldown per drive instead of only system-wide. An optional "hardcore" mode, for people who want this mod to be expensive to use.

That's why it's called a bugfix patch: I fixed bugs. :P

1) You are using version 1.2.0.0. Try version 1.2.0.1 and see if that helps. 2) The error log is called "ForgeModLoader-client-0.log", right after a crash. If you have since opened the game without crashing it again, you'll need to get it to crash for that file to be the proper error log. 3) Since I've never used the mod you're using, I have no idea what it does, and what effects it has. Can it somehow counterfeit a block, so my mod thinks a block is a carriage block but when it tries to actually treat it as one it fails? I don't even know what you're trying to do.

Yeah, that's not good enough, as it turns out. According to the error that you posted, somehow you are triggering a carriage to move, but at the time the carriage starts to move, the first carriage block (attached to the engine or motor) is not actually a carriage block, but is instead some block from that other mod. Almost like a last-second prestidigital swap. This, of course, makes no sense, so without further information (a full log, screenshots), I can't help you.

I told you to post the log, not just clip out the error. But there's some useful information in there, so I'll see what I can do with it. I'll post again if I track down the issue.

Yes, post the full forge error log to pastebin or send it to me in a private message.