jakj

Buildcraft is going through massive drama and flux, Industrialcraft is being built in obscurity, Universal Electricity I haven't even touched yet, and Minecraft is about to go to 1.6, so there's really no way to make a thing like that "high priority" at this time.

There are already mods that let you remove recipes and mods that let you define custom recipes. None of the items currently in this mod use special NBT data for anything in terms of crafting, so there would be no odd cases to handle.

I'm likely to eventually put in a kind of "hardcore" mode, where you have to work to use the mod, but it's a low priority.

When I put it in, you'll use the screwdriver on the template carriage and it'll render placeholders. I mean if the controller moves and the computer doesn't, the computer can't access the controller because it's not there. You'll need to have the computer moved by the carriage too, and program your "startup" to reconnect to the controller.

This release contains BREAKING CHANGES that could send you into a crash-loop. READ THE CHANGELOG FIRST and take appropriate steps. http://j-a-k-j.com/RedstoneInMotion_1.1.0.0_mc1.5.zip https://www.dropbox.com/s/cxx215lp3l3ciq2/RedstoneInMotion_1.1.0.0_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 1.0.1.1 -> 1.1.0.0 -- includes MAJOR BREAKING CHANGES so read carefully to see if any apply to you -- also, since major portions of the code have changed, the potential for new and undiscovered bugs is high, so BACKUP YOUR WORLDS -- ************* -- BREAK ALL CARRIAGE CONTROLLERS BEFORE YOU UPDATE OR YOU WILL CRASH -- (having them in your inventory as items is fine) -- ************* -- make sure you do not have any carriages in-transit when opening the world for the first time with the updated mod -- ************* -- configuration file has changed -- before running the updated mod, you should delete all lines from your config file except the block and item IDs -- ************* -- completely refactored the code dealing with the formation of carriages -- railcraft hidden/tracking blocks should now be handled, so in theory you don't need to disable that block anymore (testing needed) -- structure carriages now accept drives on any edge or corner instead of just on the corner -- generalized in-transit renderer so all blocks from all mods without tile entities should render without needing to be explicitly handled -- improved capturing of entities at the start of carriage motion ** should now almost never grab an entity unless it actually is "on" the carriage in some way -- carriage controller now acts as both motor and engine, meaning it can either stay put or move with the carriage ** new command is "move <direction> <simulation-flag> <anchoring-flag>" ** anchoring-flag: true = stay put, false = move with carriage ** if the controller moves, computercraft will still act as if it is there, so it won't be able to move it again ## you would need another computer at the new position in that case ** controller now includes error messages at each step of the process ## "false" is no longer a possible return code: either an error will be printed or "true" will be returned -- added configuration option to control whether carriage can move through liquids or is blocked by them -- added configuration option to control whether carriage can move through fragile blocks (like tall grass, wheat, and snowcover) or is blocked by them KNOWN ISSUES Fire does not render correctly in-transit. Some vanilla blocks in-transit are not yet rendered. 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. (Possibly) OpenPeripherals support. 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. Native-resolution (i.e., 16x) texture pack. Omni-Wrench support. Altering carriage textures to be compatible with colourblindness. (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.

This thing? http://www.openperipheral.info/ Looks interesting. I'll check into it later.

Oh yes, I am working on implementing an engine for computer craft to go with the motor.

Yeah, it's a disturbing trend, but people seem to want it, so I'm all for player choice. Unfortunately, these modders aren't, so they cater to only one slice of their demographic at a time. An example of the right way to do it: mDiyo changed his mod so you have to use his multiblock structure to do pretty much anything, and then he added a config option to change it back to the old way. Or when BC nerfed their crafting table into obsolescence, the Logistic Pipe people just said 'mmkay' and added their own. These other modders are just going to have to get over the fact that, over time, the rest of us will just mod their mod.

If it gets too expensive, it'll be trivial to write a mod to adjust it if people want one. I myself got sick of all these mods requiring nether stars for every fucking thing and wrote a crafting recipe for them.

Other than screwdrivers and the look, very little had anything to do with redpower. I think he's working on it in conjunction with the upcoming forge multi part block API.

Thank you for testing. I just wish there were a simple way to make it compatible. Perhaps in the future.

Blech. Oh well, it was worth a shot, but clearly MCPC/Bukkit/whatever is still fucking with the field names. I just looked at the github for MCPC and found this: private LongObjectHashMap<Set<NextTickListEntry>> tickEntriesByChunk; // Spigot - switch to something better for chunk-wise access That's the field they've altered: Instead of having tick entries for the entire world in a single set like vanilla does, they have it split by chunk, presumably to improve performance. There's no way to resolve this reasonably: I would have to write a separate class with special code to handle the MCPC version (as well as not only sift through all of MCPC's code to make sure I can alter that field without destroying something else on the server, but maintain that code as MCPC changes in the future), and determine at runtime which class to load by reflection. Sorry folks: MCPC-incompatibility is official now. I'll update the front post.

A continuous-mode drive of any kind, when it finishes its motion, schedules an update after 1 tick the same as it does if there's a neighbour-block change, to give signals time to propagate at its new location. It writes to the world only at the start of motion and at the end of motion. The way I would make an elevator using only vanilla and this mod is with pistons. Have a continuous-mode engine ready to go connected to the elevator. Have blocks at each floor to stop the carriage. When the button is pressed, push a redstone block into place and let it be carried away. Once the carriage stops, let the presence of that redstone block trigger more pistons that remove the redstone block.

You should elaborate on those reasons, because I can't think of any. Continuous-mode carriage engines are tailor-made for things like elevators, and other mods do have deployers and block breakers.

Why would you need multiple computers? And CC-controlled drives don't even respond to redstone at all. A CC-controlled carriage needs one drive and one computer. Well, if you're not sure if it's a disguise block, it's super-quick to test it with a screwdriver for most carriage types. And for the rest, yeah, just remember, or get the Waila mod for stats on mouseover.

1.0.1.1 has now been released. Due to a change I made, this mod may be (but is not guaranteed to be) Bukkit-compatible (which is not to say Bukkit-ported). Anyone who crashed before should try again, and if you get a new error, tell me. http://j-a-k-j.com/RedstoneInMotion_1.0.1.1_mc1.5.zip https://www.dropbox.com/s/rnds6lop86xci6z/RedstoneInMotion_1.0.1.1_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 1.0.1.0 -> 1.0.1.1 -- fixed a crash where I forgot to clear obsolescent tile entities when clearing blocks prior to motion -- fixed a crash related to Silk Touch because Forge does something stupid -- removed all reflection against vanilla classes, which may or may not provide Bukkit compatibility -- added configuration options to control which types of entities are grabbed during motion ** note that, like everything else in the mod, these are server-side, so in singleplayer they work normally, but in multiplayer they apply to all players at once 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. A form of "sticky carpeting" to allow finer control over where on a carriage entities are grabbed. 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.

Hardcore mode will come, and will integrate with mods like Thermal Expansion in interesting ways, but take note that it is not high on my priority list, so don't expect it super-soon. Again, if you want more CC integration, you're going to have to tell me what you actually want that can't be better-handled by simply having a computer next to it that just listens to rednet and relays anything that starts with 'move'. That would not only require me to implement a custom renderer instead of just changing the icons being used, it would also defeat the purpose of disguising the carriage block in the first place.

It doesn't matter how many try to move it on the same tick, because Minecraft is not re-entrant: The first one that happens to get to it will absorb it in one atomic process, and when it releases the thread to the next block, everything's already in placeholder form and thus blacklisted. The way the system works right now is, every time a change occurs to a block neighbouring a carriage drive, the drive schedules itself to be woken up in one tick. (This allows redstone signals to fully propagate before trying to process them. A better way to do it would be to say "wake me up when all cascading calls to neighbour blocks have been resolved" but Minecraft does not have that facility.) At some point, I will try to remove that one-tick delay for continuous-mode engines just coming off of a motion, since in that case it is the source of the update calls and knows when the last one has completed, but there is no possible way of which I know to remove the call in the case of initial signalling without causing it to activate in a lot of situations it shouldn't from the user's point of view.

The placeholder block is blacklisted, so if another frame tries to move an in-transit carriage, it simply won't.

You are using frame carriages to mount your block breakers. You have a cable running through the back of the frame carriages, therefore leaving one block breaker not being picked up by any frame carriage. You are using what I assume to be a forward-facing support carriage to attemtp to compensate for this lack of connection, which will fail because the support carriage will attempt to connect to anything touching the block breaker. I can see what you intended to do: Keep breaking blocks until the carriage could move forward (to account for falling sand'gravel). This would not account for falling liquids, though with the changes I'm implementing in a future release, you could configure it to ignore and pass through liquids. I'll admit: At first I had no idea why you even had the support carriage there, because the back of my brain already knew they didn't connect like that. So now I see you did actually have a good idea, and weren't just being oblivious. I just have too much logic wrapped up in each type of carriage block, too many semantics and pieces of context dependant on the carriage as a whole that can't be realized on a block-by-block basis that would allow different frame types to interact.

It was a temporary ban (now lifted), and it wasn't a crash bug: It was that he'd screwed up (or failed to update) his reflection, and one feature wasn't working. Because he was catching the exception, it didn't crash, so people didn't think to check the logs, and since he'd been so silent and not bothering to update his mod (such that people in his own thread were talking amongst theirselves like he didn't exist), they thought he had actually removed the feature deliberately and were lamenting that fact. So I fixed it. And the very day the author of the mod bothered to check his own thread, boom, I get reported and temp-banned.

Because MCF is run tighter than the asshole of a politician, and I've already got 2/10 infraction points on there just for trying to help other mods who hadn't bothered to update. I'm making no money off this mod, so I see no reason to bother with that pile, even if it would increase my exposure by several orders of magnitude.

When I get back to this mod after working more with RIM (since everyone's hot-to-trot over RIM and barely said a word about this, I've had to put my efforts into the popular one), I'll put up some useful pictures. And yeah, I decided to go with cool-sounding (to me) names over usability, because really, there're barely any items in the mod. You learn half a dozen of them, and you're golden. The primary reason for the existence of this mod is to just give people an alternative to ShadowDragon's "new style" for his soul shards.

Those are just dispensers for illustration purposes.

Why, hello there.