jakj

Stop truncating your error logs: You've left out shit I need to know, like which version of my mod you're using.

If you want to download an old version, either search back through the thread for the post where I announced it, or use the j-a-k-j.com link and change the number in the URL. As for block-ID clashes...uh...that's what a config file is for, dude. There is no international minecraft-mod block-ID registry.

Here's the 1.6 test version with source if anyone wants to mess with it. THIS IS NOT A BETA RELEASE. If you're not a modder, don't bother unless you're just really bored today. https://www.dropbox.com/s/gj6r7r088g1d7p9/MPDEV_RedstoneInMotion_2.0.0.0_mc1.6.zip Expected behaviour: Blocks using multipart (non-Immibis microblocks, CB WRE) should be moved by carriages fine, but they will appear invisible and won't do anything. Once you completely close and open the world, they should pop back up intact, be rendered, and start working again.

Progress on multipart support: I have now (in 1.6 so far, to be ported to 1.5 when it works in 1.6) gotten it to correctly move blocks from ChickenBones Wireless Redstone. However, the world has to be completely closed and reopened after a carriage move for it to work. If I just move the carriage and do nothing else, the block is there, intact, but completely unresponsive. If I close and reopen the world, it pops back up, frequency intact, and receives signals. So that's progress, at least. If anybody with modding knowledge has any clues to help me going forward, I'd appreciate them; Otherwise, time for breakfast and I'll come back to this later.

It's the next big thing on my to-do priority list, now that the teleporters are in. Have patience, m'lad.

First post now updated with fixed 1.5.x version. If anyone has any further issue with it loading but not doing anything, let me know. 1.5.x (fixed and reuploaded) http://j-a-k-j.com/RedstoneInMotion_2.0.0.0_mc1.5.zip https://www.dropbox.com/s/rblvjpx53tqmj2b/RedstoneInMotion_2.0.0.0_mc1.5.zip

Craft with dyes to add label, or just leave at the default label. Craft with comparator to prevent others adding to your channel and hijacking it. Place against carriage just like any other drive. Make sure chunks are loaded. Apply Redstone signal to teleport.

Are these rendering glitches all the time or just when the carriage is in transit? Screenshots would be good, too. Is it affecting blocks of many mods, or just other mods but not mine?

Oh good. I guess it was just a corrupt dev environment somehow, then. I'll update the post tonight if nobody still has issues.

Okay, I looked through what you put up, and you didn't change anything, as far as I can tell. All you did was tweak things so they worked in your particular IDE, but not a single line of code (that I can see) is actually different. I downloaded a 100% fresh Forge and redid *everything*, squeaky out of the box. https://www.dropbox.com/s/3euu7ymlib9v28q/TEST_RedstoneInMotion_2.0.0.0_mc1.5.zip Anyone who is having trouble getting the 1.5.x version to work, try that one instead and see if it does. Because if it doesn't...I don't fucking know. It works for me, none of you posting error logs actually have any errors and they all show my mod loading fine without issue, and clearly all past 1.5.x versions have been working up until now. Somehow a corrupted dev environment is the only way I can explain it working with a recompile, so now I used a new dev environment. Here's hoping...

What the crap is going on? How can the mod successfully load with not one single exception thrown, and yet simply do nothing at all? I can't even begin to imagine how to diagnose such a thing. Has anyone besides me managed to get the 1.5.x version running? Are you experiencing a similar issue with the 1.6.x version? We have to figure out some sort of commonality as a starting point to figuring this out.

2013-08-30 19:29:51 [iNFO] [JAKJ_RedstoneInMotion] Activating mod JAKJ_RedstoneInMotion Perhaps you have some sort of odd conflict?

What? No existing items should have been affected. All I did was change the recipes to not let you craft new ones that would do it. I need more detail on what you're seeing.

That's a good thought. My original (and the most obvious) idea would be to just draw the label somehow on the side of the block, which works great for some of the texture sets but for others is actually impossible. I'll give it more thought as time goes on; In the mean time, though, it's really not too much of a hardship to just remember.

I like to avoid GUIs whenever possible. I'll probably add a craftable label at some point, though, that lets you apply a new pattern inline.

Release 2.0.0.0 is finally out, several whole days after I said it would be. Guess I learned why Blizzard avoids giving hard ETAs! Welcome to being able to send anything anywhere at any time. (Also, more than likely, welcome to fifty bugs or glitches I didn't discover in my own testing. Yay!) 1.5.x http://j-a-k-j.com/RedstoneInMotion_2.0.0.0_mc1.5.zip https://www.dropbox.com/s/rblvjpx53tqmj2b/RedstoneInMotion_2.0.0.0_mc1.5.zip 1.6.x http://j-a-k-j.com/RedstoneInMotion_2.0.0.0_mc1.6.zip https://www.dropbox.com/s/oe5w82ycyd6z6e9/RedstoneInMotion_2.0.0.0_mc1.6.zip RECENT CHANGES (full list in "Changes.txt"): 1.2.1.0 -> 2.0.0.0 -- EXPECT UNDISCOVERED BUGS BY THE PLENTY -- BACKUP YOUR WORLDS -- DO NOT USE ON STABLE PUBLIC SERVERS UNTIL 2.0 LINE HAS BEEN OUT AND BUG-FREE FOR A WHILE UNLESS YOU LIVE ON THE EDGE -- DO NOT HAVE CARRIAGES IN-MOTION WHEN UPDATING -- support for Minecraft 1.6.x added ** support for Minecraft 1.5.x will be removed when support for Minecraft 1.7.x/2.0.x/whatever added -- fixed typo: should be "Carriage Motor", not "Carriage Drive" -- cleaned up a bunch of messy/crappy code -- added a good bit more robustness against garbage input and other-mod shenanigans -- removed legacy conversion of old decorated carriage blocks stored as items -- removed legacy conversion of old decorated carriage blocks in the world -- moved some things around to reduce redundancy and increase performance slightly -- added Carriage Translocator ** teleports carriage between locations and dimensions ## does not yet teleport entities (like players) with the blocks ** can be labelled (like channels) ## default label is blank (effectively "channel 0" ) ## craft translocator with dyes to add to label %% each dye can be added once %% 16 possible dyes effectively acts as a 16-bit number, making 65,536 possible channels ## channels can be made private to the player who placed down the translocator %% craft redstone comparator with translocator to make private %% will be locked to player name who places the translocator in the world == anyone can activate translocator if they can apply a redstone signal to it, but it will teleport only to translocators of the owning player ## craft translocator by itself to remove label and privacy flag ** requires empty air on the destination side ## will not teleport even into grasses or liquids ** chunk containing destination translocator must be loaded or Bad Things will probably happen ## specifically, it is possible for a carriage to teleport into nothingness and be permanently gone on rare occasions if the destination is not loaded %% I cannot yet prevent this ** if more than 2 translocators of the same label and privacy status are in the world, no guarantee is made as to which destination is chosen -- added ability to deactivate sides of drives (except Carriage Controller) ** sneak-activate with screwdriver to activate/deactivate side ** a closed side will still accept a redstone signal but will ignore any carriage block touching it ** enables the creation of segmented crane arms and other things ** carriage drive will still refuse to operate if more than one -active- side is being touched by a carriage block -- added temporary check to decorated-carriage and labelled-translocator recipes to dodge new Minecraft flaw (read Known Issues) KNOWN ISSUES *-*-* THINGS THAT ARE BUGS THAT WILL EVENTUALLY BE FIXED *-*-* I have discovered a (stupid) limitation in Minecraft, that 4-byte damage values on item stacks are truncated to 2 bytes when being stored to disk. This means that certain dyes will not work for labelling translocators, and blocks with very high block IDs will not work for decorating carriage blocks. Until this can be resolved by fixing Minecraft (somehow), the recipes simply prevent you from crafting items that can't be stored properly to disk. I will add a configuration option that lets you override this check if you wish to make use of the full range of blocks for decorations or dyes for labels, but you use the option, you will have to be careful to always place your blocks down on the ground immediately after crafting them (because they are safe in block form but not in item form). 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. *-*-* THINGS THAT ARE NOT BUGS BUT HOPEFULLY WILL EVENTUALLY BE FIXED *-*-* 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. *-*-* THINGS THAT ARE NOT BUGS THAT PROBABLY WILL NEVER BE FIXED *-*-* If you are using Optifine and get an error 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 Some way for a translocator in the world to display its label. The translocation of entities (e.g., players) along with blocks. Redoing and simplifying the 'move' command to make it more intuitive and easy to use. 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. 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 add additional continuous-mode cooldown to individual drives. An optional "hardcore" mode, for people who want this mod to be expensive to use.

Yay, I just discovered a new shitty problem with Minecraft! When storing an ItemStack to disk, it truncates the int to a short (making it 16 bits intead of 32). Fuuuuuuuuck Notch's lack of foresight, really. So yay. This is actually an undiscovered issue with this mod, in that if you were to decorate a carriage block with a block type that has a very high ID (anything above 255), it will work fine when placed on the ground, but if you save and load with it in item form in your inventory, it will actually fuck up completely and give you a different item back. Isn't that great. This problem is also limiting how many dyes can be used to label translocators. I am temporarily putting checks into the recipes to prevent you from making item stacks that won't save to disk. I'll put in a config option later that says "I understand the risk and I will be sure to always put things down on the ground immediately after crafting them or else not complain when I lose it" to somewhat work around it. (In case you're wondering why I don't just use NBT to store the value, I can, and I used to, but it made nothing stack properly because Minecraft has a shitty implementation of checking for NBT-tag equality, so I stopped.) In better news, the update is almost done, and I'm just putting the finishing touches on it now. The last really annoying bug I was trying to work through was the one I just described. Stay tuned!

True, but I still have to check for clearance for the blocks themselves. It would be a rum thing to just overwrite bits of the world.

Oh, I'm sure that as soon as I think it's fully functional and release it, I'll immediately get six crash reports within an hour. You can come back to when it's stable.

Not as of now, but I'm working on it. I don't see any reason why it wouldn't eventually do it. I guess I'd have the entities teleport at the end of the animation.

It requires open air (won't teleport into anything, not even grass/liquids; will probably let it later on like the regular drives do). It searches through all active translocators of the matching label (and player name, if private), and takes the first one it sees in its internal list. There is no way to predetermine which one it will go to if there are more than two of any particular label/player, so it's recommended to not do that. There will be 65,536 possible labels per player, and another 65,536 for the open channel, so any particular singleplayer game will have 131,072 possible channels. Currently doesn't render the label on the block itself, so you have to break it and look at the tooltip to see what it is.

Lest any of you think I'm full of shit, here's a thing. Update is coming Soon. I had to give Minecraft a hot-oil massage and I'm still trying to clean off the table, so there's a little more to do, but the main part is it doesn't crash now and does its thing! (In before "lol op".)

Premature optimization is really fun, though. One nice thing about doing programming as a hobby instead of a job is we can take diversions like that as we desire, just for the hell of it. And another nice thing is being able to do the opposite, being inefficient because it's more fun that way. And besides, all of my inefficiencies put together are still nothing compared to the shit that is the Minecraft codebase. And I'm not even a university graduate! But I saw one of the Minecraft devs tweet that they refactored the code and made several hundred changes, so while I cringe at the work that will be involved in tracking down and understanding those changes from a modding standpoint, I also cheer that Minecraft is finally well on its way to becoming a well-written piece of software. The day where I compare my code to Minecraft's and actually feel embarassed instead of smug, will be a very good day indeed.

Do what with the who now? Even if possible/feasible, the speedup would be almost unnoticeable. My code can reach the default 5000-block limit and fail out an improperly-placed platform carriage in less than a tenth of a second on my computer, but (also on my computer) the same code lags for almost ten seconds when moving an entire mountain peak that is not even close to 5000 blocks in volume. As wasteful as some of my code is, even a shitty computer isn't going to have even the slightest problem with it. To increase performance of my code, the one thing I can really do is delve deeper into Minecraft's internals to better understand the lighting functions and rewrite that part to be more efficient. (Right now it's super redundant and wasteful.) The worst part of all of it, though, is changing all those blocks around, and unless you rewrite Minecraft itself, that's always going to be slow. If I had a gun to my head, I'd say I might be able to cut somewhere between 10%-40% of the current time off of gigantic motions by improving the lighting code, but I'm fairly certain almost nothing can be done to improve the rest of it in Minecraft's current state.

Because the planes don't exist while in transit. If you want blocks to do things along the way, you'll have to introduce some sort of delay, like with a redstone timer.