jakj

Redstone In Motion 1.0.1.0 is now released. http://j-a-k-j.com/RedstoneInMotion_1.0.1.0_mc1.5.zip https://www.dropbox.com/s/f16y982rexfxapa/RedstoneInMotion_1.0.1.0_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 1.0.0.0 -> 1.0.1.0 -- fixed a crash when re-loading a world that was saved with a carriage in-transit that had entities moving with it ** when re-loading such a world, the entities will no longer be locked to the carriage for that particular motion ** this also means you can escape a continuous-mode carriage simply by logging out and in again -- the invisible placeholder blocks are no longer connected to a creative tab -- the invisible placeholder blocks will now (eventually) delete themselves if they are stranded in the world by a crash -- added a config option to set the number of ticks (default 0) a continuous-mode drive will wait between motions KNOWN ISSUES Carriages treat liquids as solid blocks and refuse to move through them. Fire does not render correctly. Some blocks in-transit are not yet rendered. Drives will not work on structure carriages when placed on an edge instead of a corner. Recipes do not use the Forge material dictionary. PLANNED FEATURES 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. Config options to control which entities are and are not picked up by carriages. Native-resolution (i.e., 16x) texture pack. Omni-Wrench support. Altering carriage textures to be compatible with colourblindness. Making the carriage controller able to move itself like an engine, instead of only being able to stay in place like a motor. (POSSIBLY, NO GUARANTEE) Finding a way to make ComputerCraft computers and turtles not reboot after motion. A visual indication of which blocks will be moved by a patterened template carriage. An optional "hardcore" mode, for people who want this mod to be expensive to use.

No, blacklisting bedrock is just a vanilla game feature for me. You cannot remove bedrock from the blacklist, but you can (once I put that feature in) make it simply ignore bedrock and just refuse to move through it. I will not allow bedrock to be moved by my mod by any means: That is a block always intended to be used in creative mode and in no other way. Other than that, it's users' discretion. It's just a shame that Greg behaves like such an asshole: If not for that, I think I'd like him.

If you want to have a nested carriage where the inner carriage is a template that moves blocks suspended in midair, you will need to use either a structure carriage or another template carriage as your outer carriage (which are the two types of carriages that can move blocks that are not in some way directly or indirectly connected to it), or you will need to use a secondary engine in a caterpillar setup, that moves the inner template carriage before the outer carriage moves to catch up to it.

Template carriages always use coordinates relative to themselves, so no matter where in the world they are or have been, they always move any block (no matter what that block is) in the same layout with which they were formed. The template carriage will not be triggered by the engine: It will just be moved. But a support carriage moves anything above it that is in some way directly or indirectly touching it, so the blocks will move too. If they are suspended in midair, they will not be moved by the support carriage even if they would be moved by the template carriage.

You cannot move multiple types of carriages at the same time, but different ones will be treated by the active one as just more blocks to move. For example, if you have a support carriage which is your mobile platform of stuff, and a template carriage on top of that which alters the configuration of machines, when you move the platform of stuff, the template carriage will just come with it as more cargo. Some types of carriage can be put next to each other without problem, as long as you remember to close their sides so they don't try to connect: Frame and platform carriages should work in this way. Structure carriages never connect to anything but themselves, so they can move alongside each other without issue, but you have to configure them while they're apart and then move them together because otherwise the screwdriver will try to make them all one construct. There is no way to make multiple side-by-side support carriages: If support carriages facing different ways are in the same layer, the motion just fails; However, you can have multiple layers of them (like a smaller support carriage on top of a bigger support carriage) and that should work just fine. Template carriages work with their templates, and never care at all what they're moving. If I can figure out how to do it without everything bugging the fuck out , I will allow Carriage Controllers to move themselves as well. I'd just add another flag to the 'move' call to say whether or not it should.

Carriage Controllers (the carriage drives that can be controlled by ComputerCraft) act as motors, not engines, so they do not move when you give them commands.

The End has nothing but end stone and endermen, as far as I know. That said, with the new configuration option I'm adding, someone could just change the blacklist behaviour to ignore instead of abort, and it will let them start pulling up cores as soon as they get some iron and redstone. The player must be able to choose the game experience they want, and if they cannot resist changing it and instead want me to lock out features for everyone just because they have no willpower, then my recommendation will be to visit a local psychiatrist.

I'll make them not reboot on movement if I can, but remember they reboot anyway if the game is reloaded or the chunk is reloaded, and nobody but dan200 can do anything about that. Assume I will not be able to get them to not reboot, and make a startup program that works intelligently. The only thing the computer on the carriage needs to do is relay commands, anyway: There's no reason it needs to have any logic of any kind. Have your logic running in your base or nearby control center or whatever, and calculate the direction to move. Then all your computer on the carriage does is conenct to rednet, connect to the drive, and listen for "move" commands and return the result. I don't know how much code that would be, but I can't imagine it would even be a screenful. In pseudocode: startup() -- connect to drive on left side -- connect to rednet channel "ufo" -- infiniteloop -- { -- -- read int from channel "ufo" -- -- boolean result = drive.move(int,false) -- -- send result to channel "ufo" -- }

Until you tell me what you want my mod to do regarding CC, I can't tell you whether or not I'll make it do it. You will be able to use a screwdriver on a patterned template carriage to cause it to render blocks in the positions it can move them. It will not actually place any ghost blocks in the world, but it will appear to have done so. My mod and the Truss mod are roughly equivalent, except his looks prettier and mine has more features. It also has the benefit of not being tainted by being hosted by Technic, and has a thread on MCF. So I expect his to get 50x the traffic (at least) that mine ever will. Doesn't much matter, though.

My best guess is that Redpower transfers the tile entity directly instead of making it write itself out to NBT and read itself back in. At some point, I'm going to try to implement that to see if I can get it to work too, but there's no guarantee. If you mean so you can see which blocks are in the template after it's been formed, yes, that will come in a future update.

Vanilla code for nether portals re-calculates portal position every time you travel, and simply re-uses an existing destination portal if it finds one acceptably close, so yes, as you travel further, it will keep generating new portals. On the other hand, Mystcraft portals will always teleport you to the same destination no matter how far you move the source portal, but moving the source portal will not change the point at which its book is linked, so when you travel back, you'll end up where the carriage was, not where it is. It would pull cores up of that just fine. It's absurd to try to balance your mod against any other mod, unless your mod actually requires that mod to be installed and won't run otherwise. My mod is balanced against vanilla since it requires no other mod. I think making tunnel bores is easy enough already. Vanilla has no "block breaker", which means anyone making a tunnel bore is using other mods, which means they probably have a quick way to get lots of wood. The #1 best way to make a tunnel bore is going to be with template carriages, deciding how big you want it to be and filling the space with the template carriages so you can build a nice roof. Another option would be to use the upcoming whitelist feature to say "only the blocks already on my tunnel bore should get moved by it", and also the upcoming config option that says "just ignore blacklisted blocks instead of aborting the motion if they're found". That way, as long as you don't use smoothstone, sand, gravel, lava, water, obsidian, cobblestone, or ores (i.e., anything you can find underground as blocks) to construct your bore, it will just slide along the ceiling as you dig and let it all pass by. I could, but the slowest part of the entire process is changing blocks in the world, so adding any block alterations that aren't strictly necessary will really hurt for giant carriages, slow computers, or busy servers. I don't think the extra overhead is worth it for correcting what indeed is only a cosmetic issue.

Sure, I'll add some config options for what it should and shouldn't grab.

Aye, the Forge log is always the go-to log.

Heh, that was quick. The bug turned out to be in the code that runs when it reads the tile entity back from disk after having saved it, which caused Forge to say "your tile entity is bugged, we're going to delete it so your entire world doesn't crash", and THEN everything broke down because the tile entity was uninitialized when it tried to run. This is exactly why I tell people, don't truncate the logs! You were deleting the actual error and just giving me what looked like the error but turned out to be just another symptom of the real problem. Truncating logs is bad! Anyway, it will be fixed in the next release.

AHA!@% Finally, I am able to reproduce that exact behaviour. Thank you for the testing: I will now get to debugging it. Knowing that it matters whether or not you are on the carriage at the time should help me track down this bug.

The problem is, I cannot reproduce things going poof. If the world saves cleanly, then in-transit blocks save cleanly, and if it crashes, itshould roll back to the last save, which should be either before or after the blocks changed. Until someone can help me understand the exact circumstances behind the failures such that I can diagnose and treat them, I can't do a thing. As for everything else suggested in the last few posts, those are good ideas and I've added them to my list.

At least give me one screenshot of what you're doing to make it fail. Trying to go by verbal descriptions is excruciating.

Well, something's going wrong somewhere, because when I do it on mine, it saves and restores fine. Lag has absolutely nothing to do with it: If you do a clean save-and-quit, it's no longer processing, so there's nothing *to* lag. It iterates through all the stuff, writes it to disk, and closes. I'm going to add an extra call to mark the chunk as dirty, but I'm completely confident it's redundant, since the chunk is already marked dirty from placing the block in the first place. But once you have eliminiated the probable, whatever remains--however improbable--must be the truth.

Regarding Waila: Yes, when you have waila installed and you say the problem occurs when you walk near a block, that makes sense, because waila shows tile entity info so it's probably triggering from client to server to get that info. The redundancy check I'll put in will fix that: If the tile entity on the server has invalid data (due to a crash) it will just immediately delete itself, and the other blocks will eventually decay. Regarding saving in an indeterminate state: It can't happen with my mod. Physically impossible. From the moment I begin processing a signal on a drive to the moment everything is set in motion, it's all atomic, as in, my code never even releases itself for Minecraft to tick. A crash with my mod is all-or-nothing: Either you lose your entire construct, or you lose nothing, unless it's actually my code that crashes-mid process. I may have to at some point, but for right now, it's much easier to do it this way. I can split the download if I start to get complaints from people who don't want to download that much when all they want is the mod and not source.

I do so much double-posting in my own thread. Hurgh. But anyway... I just tested, and I even had multiple continuous carriages going in infinite loops all at the same time, repeatedly saving/quitting/reopening rapidly and at random times with all of them in mid-transit, and everything saved fine, everything restored fine, no crashes at all. You're going to have to give me more detail--screenshots, or even better, video--for me to figure out what's going on. I see your log says integrated server, so I know you're in singleplayer (assuming you haven't opened to LAN), so it's not a lag issue. Also, try it without Waila installed. I'm thinking that mod may be triggering my tile entity to write to nbt before it has loaded completely...how, I don't know, but it may be. Actual crashing, though, I can see where that would cause trouble. I can put in some additional redundancy to make sure that ghost blocks don't cause crashes, and I can put in for them to randomly decay (like leaves). You -really- do not want me to have them continually loop to check themselves for validity, though...that's a lot o' fuckin' tickin'. Decaying like leaves is the best I can do.

If you really were saving/quitting without a crash, the blocks-in-transit would not disappear: They write to disk just like anything else. Note that clicking the "X" button is not saving and quitting: Only hitting ESC to pause (in singleplayer) and pressing the save/quit button will do that. If you *are* doing that, well...hmm. That crash is caused by an uninitialized entity trying to write out a record of itself. One thing I want to know is, what is sending a custom packet to the server that is passing through Waila and causing it to write to nbt? I'm going to do some more testing. I don't see how it's possible, but I'm going to try and figure out if somehow sometimes my entity is not getting saved even through a clean shutdown.

Hmm. Do you think I should make it push through only liquids, or any block that is "replaceable" (as in, you can just put another block in place of without breaking it first), or even any block that is "fragile" (as in, if you were to pour water on it, it would pop off). So basically, should the carriage overwrite just flowing liquids? Flowing liquids and their source blocks? What about snow blocks, torches, crops, and the like? My first inclination is to limit the overwriting to only replaceable stuff like liquids, both flowing and still.

I suppose there's two ways to do it, each with ups and downs: If I make my own chests, it makes it clear from a distance what's going on, and it also makes it clear that every item in the chest is applying to the blacklist or whitelist. It's also very easy to make sure you don't screw up and put more than one chest next to the engine. On the other hand, if I use marker items instead, then I could connect to any inventory of any kind that Forge supports (so pretty much everything except vanilla ender chests) and the player could use whatever they want instead of a chest. But it also makes it more error-prone, as it's easy to not realize you might have multiple markers in nearby chests. I think the make-my-own-chests route is going to be a lot easier and clearer to manage, if not anywhere near as flexible. While I have you here, as a colourblind person, do you feel the carriage types need to be distinguished in the world in some way? In the inventory they have tooltips, but in the world it's just the colour.

Why markers when the chest itself could just have a different texture to indicate what it is? I can easily put a pattern on it to make it compatible with colourblindness.

Well, it would let you place the chest anywhere against the engine you wanted to. I would just a check for it into the loop that already checks for redstone signal and carriage presence. As for moving it with the engine, you'd just be responsible for making sure that whatever frame structure you use will account for it.