jakj

Amusingly enough, I don't use an IDE: I'm bare metal. ;-) But thanks.

I appreciate your interest, but I'm not very good at cooperating. I'm very picky. I couldn't care less if people take code from my project, but I'm super anal about the code that goes into it.

The three aforementioned bugs should now have been mostly fixed. I have discovered several improvements I need to make to the code, to not only improve compatibility but also to improve safety, which I will begin to work on tomorrow. For now, though, this (in theory) will stop the majority of people crashing. http://j-a-k-j.com/RedstoneInMotion_1.1.1.1_mc1.5.zip https://www.dropbox.com/s/40gllacfv16mpp7/RedstoneInMotion_1.1.1.1_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 1.1.1.0 -> 1.1.1.1 -- fixed bug preventing crafting decorated carriages in SMP -- (hopefully) fixed bug sometimes causing TE redstone conduits to lose their connection state -- (hopefully) fixed bug causing stack overflows relating to packets when attempting to render red wire (and other things) -- ** these fixes should stop the majority of the crashing, but there are further fixes I've discovered and begun work on KNOWN ISSUES Recipes do not use the Forge material dictionary. Some mod blocks look really goofy when rendered in-transit. PLANNED FEATURES A config option to cause carriages to render all sides every time (making it easier to see which of the faces are closed), instead of only the ones facing the player (which matches vanilla behaviour). 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. 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.

I'm not surprised it vomits on multipart. I'll have to add support for that manually.

Patience, m'lad: The fix is coming. Funnily enough, the bug as it stands actually depends on the order that my mod puts the blocks back down, and in some configurations, it does actually keep its settings.

Here is my donation link. Which version of BC are you using? In one of the updates, they made it remove the pipe on invalidate() which should work with my frames. This, pretty much. As I say, it's not a bug with my frames and it's not a bug with BC: It's just the fact that the block is being made to do something it was never designed to do. I will add in special cases if they are easy and reliable, but in the mean time, do this.

Yeah, this mod is a bit of a mess, considering how much I've learned about modding just in the short time I've been working on RIM. I'm hoping to get back to this soon and give it a thorough makeover.

Yeah, that's from the same source as the red-wire stack overflow and will be fixed by the same change.

Okay, I now know how to fix all three bugs you folks have reported to me today, thanks to your diligence in reporting them well. I'm a bit tired tonight, so I'll work on the fixes tomorrow; Expect a bugfix patch no later than the end of tomorrow.

Ick. I'll make a note to diagnose that issue.

Yeah red wire stack overflow already being worked on. Also, thank you for the good error report about the recipe, and I think I know a fix for that now too. Will work on it when I get home tonight.

Yeah, not a chance in hell I can diagnose that. Start from vanilla+forge, and start adding mods until it happens, or otherwise try removing mods one by one until it doesn't happen.

I'll probably have to add a special case for the quarry that actually breaks and replaces it instead of just moving it. Not technically a bug with my mod but something that does need to work. It would, however, lose its internal buffer of energy every time that happens.

It's happening because I'm recreating fake/ghost versions of the in-transit blocks to let them render, telling them they exist but really they don't. In this case, one fake block is accessing another fake block which causes the first fake block to regenerate which causes it to access the other fake block again... What I'm going to try is generating all the fake blocks at once in a controlled pattern, so that when they're trying to render, they aren't regenerating.

Interesting: I hadn't considered anything looping like that. I will start working on a fix for that issue.

It actually works with MCPC? Thank the gods. That blood fellow helped me out with that.

(Updating to 1.6.x will begin as soon as the storm dies down and it's actually worth the attempt. Hint: Not yet.) EXPERIMENTAL AND UNTESTED support for MCPC+ has been added. No longer will you crash: If it fails, it will print errors to the log instead. How to test: Use a carriage engine on any type of carriage, and put a button on the carriage engine. Activate the button. When motion is done, the button should pop back out. If it does not, send me your log which will have exceptions printed out in it. THE WHOLE LOG not just part. There should be at least two exceptions. http://j-a-k-j.com/RedstoneInMotion_1.1.1.0_mc1.5.zip https://www.dropbox.com/s/5szev8eyd9r4s8h/RedstoneInMotion_1.1.1.0_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 1.1.0.0 -> 1.1.1.0 -- omni-wrench support implemented -- in-transit rendering now uses a display list for a massive performance boost with large carriages -- completely refactored the rendering of in-transit carriages ** every single block from vanilla and every single mod in existence will now render ** some are going to be a little imperfect, like enchantment tables will always render with thier books closed ** lighting is still a bit off, but is much better, and now actually uses ambient occlusion if enabled in the Minecraft config ** some mod items look really goofy ## buildcraft pipes have the correct shape but a missing texture ## thermal expansion conduits, cells, and tesseracts render their constituent fluids but not their actual shells ## (and plenty more oddities, I'm sure) ## never expect this to be perfect: I will continually work to make it better, but at some point, it's "good enough" since it's cosmetic ## any time you encounter rendering issues, look in your Forge client log file for exceptions; If you see any with "JAKJ" in them, report them to me -- fire now renders properly in-transit -- improved compatibility with the mod "Big Reactors" and possibly some others -- EXPERIMENTAL UNTESTED support for MCPC+ added ** crashing has been removed on error; instead, the error will be printed to the log file and the process will continue ** this prevents you from losing your entire carriage and having a server crash on motion ** if errors occur, things like buttons and pressure plates that are pressed at the time of motion will stay pressed forever; break and re-place ** check your log for errors and REPORT THEM to me -- invisible unbreakable placeholder blocks will no longer automatically decay very slowly over time ** instead, use a screwdriver on them to immediately remove them ** other than being a nuisance, they don't do any harm, so don't worry if you can't find them right away ** the only circumstance they can ever be left behind is if there is a crash while a carriage is in motion and the carriage did not save ## hopefully that won't ever happen! -- in-transit carriages will now render no matter which way the player is facing KNOWN ISSUES Recipes do not use the Forge material dictionary. Some mod blocks look really goofy when rendered in-transit. 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. 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.

I'm not particularly concerned if someone uses a carriage to break a multiblock and it doesn't work. The intent of the mod is to keep things intact.

No, because I'd have to leave them in the world and let them move independent of the carriage. For now, they just run "startup" like computers do. That's a good idea, though: I will decompile the turtles to see how they move themselves, to see if I can do similarly.

Minecraft really is a freakish thing. So, through some wild and arcane manipulations, I've managed to abstract the internals of Minecraft sufficiently that I can get everything all the way up to ambient occlusion working for an in-transit renderer. However...for some reason, each time the carriage moves, all water in the world stops rendering -except- any water on my carriage. O_O Yay for modding.

I would not at all have expected golems to retain their targets. I'm pleased that Azanor has programmed them defensibly to handle cases like this, rather than going the easy route.

So, I just did a little testing with Buildcraft pipes being moved, and I got no issues with disconnection and spew. So whoever reported that bug before but never gave more details, unless you do give more details, I'm going to assume it's not a bug anymore. At this time, other than graphical glitches (which don't matter), computercraft computers rebooting (which still allows them to function), and small delays (like in pipes with autarchic gates, where it takes them a couple seconds after motion to get back up to full speed), I am aware of zero instances of this mod not moving blocks properly. Whether that's actually true, or people just aren't reporting bugs, or even if very few people are actually using this mod, I don't know.

If you make a full set of 16x textures and release them under an open-community license (like CC, GPL, WTFPL, public domain, etc.), I'll put them in the mod as the official native set.

Added video demonstrations. Playlist: Frame Carriage Demonstration Platform Carriage Demonstration Structure Carriage Demonstration Support Carriage Demonstration Template Carriage Demonstration Demonstration of Engine, Motor, and Controller Demonstration of Some Neat Stuff

I've made a very big deal about listening to feedback and taking all suggestions to heart, so comments like that are to be expected, I suppose. I'm trying to be very visible and proactive to set an example of how modders *should* behave, instead of how quite a lot of them do behave.