jakj

If you get the same crash or a different one, post the forge log instead of the Minecraft crash log.

Yay releases! Rendering sucks less now. LOTS of new features, so read the changelog! Remember to not have carriages in-motion when updating, and backup your shit. 2.1.0.0 - MC 1.6.x http://j-a-k-j.com/RedstoneInMotion_2.1.0.0_mc1.6.zip https://www.dropbox.com/s/fauf1wxou6ztz7o/RedstoneInMotion_2.1.0.0_mc1.6.zip 2.1.0.0 - MC 1.5.x http://j-a-k-j.com/RedstoneInMotion_2.1.0.0_mc1.5.zip https://www.dropbox.com/s/m3jw6s48kr5kjtr/RedstoneInMotion_2.1.0.0_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 2.0.0.0 -> 2.1.0.0 -- translocators now render their labels on their sides ** label foreground is 16 icons for 16 dyes ** label background indicates "public" , "private to self" , and "private to other" ** labels by default should support colourblindness by position and shape of dye icons and pattern of background ** THE BACKGROUNDS I MADE REALLY SUCK HOLY CRAP DO THEY EVER SUCK ## please, somebody make something that doesn't suck for the three background images ** each texture pack could have its own icons/backgrounds, but right now they're just copied/pasted between ## if you have a texture pack in the mod (or want to), feel free to make your own if you want -- support for ChickenBones / Forge Multipart blocks (non-Immibis microblocks, ChickenBones wireless redstone, etc.) added ** credit goes to ChickenBones who actually wrote the code for me ** WORKS ON 1.5 AND 1.6 REGARDLESS OF FORGE MULTIPART VERSION ## KNOWN ISSUE - block ticks for parts of a multipart tile (such as buttons that have been pressed) are not yet correctly transferred %% having parts with scheduled ticks might result in strange behaviour but most of the time will cause no real issues %% until this is fixed, don't do things like press buttons encapsulated within multipart tiles or you'll have to break it to reset it -- changed/improved internal storage format of decorated carriage blocks and translocators when stored as items in an inventory ** eliminates the issue of not being able to use high-index decorations or dyes: now all 4096 blocks and 16 dyes are valid ** old-format items must be converted to new-format items ## (only when in item form; blocks placed in the world have not been changed) ## craft old-format item with screwdriver (screwdriver is not destroyed) to convert item to new format ## tooltip on item indicates if it needs conversion ## old-format items will be supported for several versions to give people time to convert without stress -- added configuration option to allow carriages to move bedrock -- added new ComputerCraft commands ** intended to increase your code's readability ** anchored_move ( 3 ) == move ( 3 , false , true ) ** check_anchored_move ( 3 ) == move ( 3 , true , true ) ** unanchored_move ( 3 ) == move ( 3 , false , false ) ** check_unanchored_move ( 3 ) == move ( 3 , true , false ) -- strings in addition to indices now accepted for direction in ComputerCraft control ** case does not matter: "negy" , "NEGY" , "NegY" , "negY" , etc. are all equivalent ** 0 == "down" == "negy" ** 1 == "up" == "posy" ** 2 == "north" == "negz" ** 3 == "south" == "posz" ** 4 == "west" == "negx" ** 5 == "east" == "posx" ** EXAMPLE: peripheral . call ( "left" , "move" , "north" , false , true ) ** EXAMPLE: peripheral . call ( "left" , "anchored_move" , "posY" ) -- added config option to control whether animation continues during severe lag that delays the replacement of blocks ** if set to false, motion will continue past final position and teleportation will continue to flicker until blocks are actually replaced ## looks weird but is a clear indication that things aren't yet done ## this is the current behaviour ** if set to true, motion will stop at final position and teleportation will stop flickering even if blocks are not yet replaced ## doesn't look weird but is more confusing if someone thinks the blocks are there and tries to interact with them but can't -- replaced my crappy translocator textures in the Lethosos set by ones actually made by Lethosos -- fixed a potential crash in CarriageRenderCache -- x/y/z positions of tile-entity records are now updated before creating the tile entities -- added more robustness to icon-retrieval functions for when minimap mods do stupid things -- overhauled rendering of carriages and carriage drives to improve performance ** carriages in-motion still have the issue with rendering transparency which will be fixed soon -- prevented carriage blocks from wasting CPU time by receiving unnecessary updateEntity calls KNOWN ISSUES *-*-* THINGS THAT ARE BUGS THAT WILL DEFINITELY BE FIXED *-*-* Multipart blocks that need scheduled world ticks (such as buttons that need a tick to pop back out) aren't receiving their ticks properly. Transparent blocks (like water) render in a bit of a wonky fashion in-transit. *-*-* THINGS THAT ARE FLAWS THAT WILL HOPEFULLY BE FIXED AT SOME POINT *-*-* Anything that already uses a display list to render will not properly render 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. "Billund" blocks have been reported to be wonky when moved by 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 The translocation of entities (e.g., players) along with blocks. The ability to prevent individual blocks/items from being registered. Swapping the names of platform and support carriages to reduce confusion in the future. 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. An optional "hardcore" mode, for people who want this mod to be expensive to use.

1) Take screenshots with F2, because with the pause-menu buttons in the way, I can barely see what the fuck you're doing. 2) Does this happen every single time without failure (repeatable), or is it only sometimes? 3) I'm drastically changing how rendering works (for the better) in the next release which will come out either this morning or tonight, so hopefully it won't happen again anyway.

Looks like something's wrong with my Buildcraft hack. If I were you, I'd avoid having any items travelling through pipes until I figure out what's wrong. (If the pipes are empty, everything should be alright.)

Did you have Buildcraft pipes on the carriage?

I have made some changes to the rendering code here and there, so hopefully they went away because I fixed something. :P

Oh, Dan made that mod? Not surprised it's having issues, then: Dan codes in hardmode and cranks out some complex things that are difficult to match by weaklings like me.

Do they move fine but just not render, or do they get deleted?

New test versions / release candidates: (now 2.1.0.0 instead of 2.0.1.0 because I added a bunch more stuff, so there won't actually be a 2.0.1.0 release) https://www.dropbox.com/s/m3jw6s48kr5kjtr/RedstoneInMotion_2.1.0.0_mc1.5.zip https://www.dropbox.com/s/fauf1wxou6ztz7o/RedstoneInMotion_2.1.0.0_mc1.6.zip I'll let this go a day or so, to see if anybody gets any immediate issues, and then release if not. For now, treat it as beta. Changes: 2.0.0.0 -> 2.1.0.0 -- support for ChickenBones / Forge Multipart blocks (non-Immibis microblocks, ChickenBones wireless redstone, etc.) added ** credit goes to ChickenBones who actually wrote the code for me ** WORKS ON 1.5 AND 1.6 REGARDLESS OF FORGE MULTIPART VERSION ## KNOWN ISSUE - block ticks for parts of a multipart tile (such as buttons that have been pressed) are not yet correctly transferred %% having parts with scheduled ticks might result in strange behaviour but most of the time will cause no real issues %% until this is fixed, don't do things like press buttons encapsulated within multipart tiles or you'll have to break it to reset it -- changed/improved internal storage format of decorated carriage blocks and translocators when stored as items in an inventory ** eliminates the issue of not being able to use high-index decorations or dyes: now all 4096 blocks and 16 dyes are valid ** old-format items must be converted to new-format items ## (only when in item form; blocks placed in the world have not been changed) ## craft old-format item with screwdriver (screwdriver is not destroyed) to convert item to new format ## tooltip on item indicates if it needs conversion ## old-format items will be supported for several versions to give people time to convert without stress -- added configuration option to allow carriages to move bedrock -- added new ComputerCraft commands ** intended to increase your code's readability ** anchored_move ( 3 ) == move ( 3 , false , true ) ** check_anchored_move ( 3 ) == move ( 3 , true , true ) ** unanchored_move ( 3 ) == move ( 3 , false , false ) ** check_unanchored_move ( 3 ) == move ( 3 , true , false ) -- strings in addition to indices now accepted for direction in ComputerCraft control ** case does not matter: "negy" , "NEGY" , "NegY" , "negY" , etc. are all equivalent ** 0 == "down" == "negy" ** 1 == "up" == "posy" ** 2 == "north" == "negz" ** 3 == "south" == "posz" ** 4 == "west" == "negx" ** 5 == "east" == "posx" ** EXAMPLE: peripheral . call ( "left" , "move" , "north" , false , true ) ** EXAMPLE: peripheral . call ( "left" , "anchored_move" , "posY" ) -- added config option to control whether animation continues during severe lag that delays the replacement of blocks ** if set to false, motion will continue past final position and teleportation will continue to flicker until blocks are actually replaced ## looks weird but is a clear indication that things aren't yet done ## this is the current behaviour ** if set to true, motion will stop at final position and teleportation will stop flickering even if blocks are not yet replaced ## doesn't look weird but is more confusing if someone thinks the blocks are there and tries to interact with them but can't -- replaced my crappy translocator textures in the Lethosos set by ones actually made by Lethosos -- fixed a potential crash in CarriageRenderCache -- x/y/z positions of tile-entity records are now updated before creating the tile entities -- added more robustness to icon-retrieval functions for when minimap mods do stupid things

Heads up on another change in the next release: ChickenBones also helped me understand how to do NBT on ItemStacks so they'll properly combine in the inventory, and as a result, the problem with high-index decorations and labels will be gone (i.e., you'll be able to use all 4096 blocks as decorations and all 16 dyes on the label). This will require converting your items (again, yes, I'm sorry, but I'm progressively learning and hey, at least you're not paying money for this ), which is as simple as crafting them with a screwdriver. (The screwdriver is not destroyed.) Blocks on the ground need no changes, a tooltip on the items will tell you if the item needs to be converted, and the old format will still be supported for several versions so that you don't need to feel stressed about losing your stuff.

Well, there's already liquid ender in TE which is really cool. If you were to drink it...wow, I almost want to see someone come up with a concept animation of that. Except I don't think I'd have the balls to watch it. Also, thank goodness for you giving a spot for a label. Yours were honestly the only textures I couldn't figure out how the fuck to fit something on. :P

Ah, so much better than my hackjob. I'll put it in for the next release.

No more bug reports yet? Or is everybody away at PAX or actually having a life for labor day? I'll let the test builds sit a bit more before actually formally releasing, just in case, but you can certainly play with them now if you want to.

I always appreciate bug reports. :-) You are my QA team!

Okay yeah, he has a whole implementation for block ticks inside multipart containers separate from the normal world ticks, because normal Minecraft ticks can't be targetted to a specific part. I'll add special code to handle this later; For right now, I'll just add it to known issues, as it's not serious enough of a bug to hold up the release.

Interesting. I'll dig into CB's code and see how he handles block ticks.

It's a song, doofus. http://www.youtube.com/watch?v=h-LbvFckptY

Holy shitballs, Batman: He just turned it up to 11! new test builds for multipart support - WORKS ON BOTH 1.5 AND 1.6 AND DOESN'T REQUIRE UPDATE TO MULTIPART MOD So yeah, forget everything I said before. Now it works everywhere. Because ChickenBones inspired me to modding greatness...so at least I managed to reach mediocrity! :-) https://www.dropbox.com/s/8gfunmhm8q5yizb/RedstoneInMotion_2.0.1.0_mc1.5.zip https://www.dropbox.com/s/8bt86thqzni9gn7/RedstoneInMotion_2.0.1.0_mc1.6.zip FILES ARE NEW REDOWNLOAD BY ALL THAT IS HOLY DELETE THE OLD ONE AND REDOWNLOAD I'M SO EXCITED I JUST CAN'T HIDE IT

It looks like you're running out of memory. Too many mods maybe? I'm really not sure that this actually has anything to do with my mod. Those error printouts are showing that Rei's Minimap is trying to get the icons of blocks that don't exist, but it's getting valid values back, and it's not actually crashing on that.

2.0.1.0 test versions including multipart-block support (1.6.x. only), some bugfixes, and some tweaks. https://www.dropbox.com/s/8gfunmhm8q5yizb/RedstoneInMotion_2.0.1.0_mc1.5.zip https://www.dropbox.com/s/8bt86thqzni9gn7/RedstoneInMotion_2.0.1.0_mc1.6.zip THESE ARE NOT RELEASES YET but they will be if nobody starts crashing. Back up your worlds, and try them out. Should also make Rei's Minimap not grind to a halt when it does stupid things.

Yes, 1.5.x and 1.6.x. 1.5.x just won't be able to move multipart blocks unless CB backports his change.

I'll throw it in with my multipart-support test release later today. If the change I made doesn't fix it, you can let me know then.

That's incredibly strange. And this is a singleplayer world? In any case, I added a few extra unnecessary checks to my code that'll get thrown into the next release to account for other mods doing stupid things like tring to get icons for blocks that don't exist. That should take care of the issue.

Are you sure that's actually a crash? As in, Minecraft is closing on its own without you closing it? Because it looks to me like it's just printing the errors to the log and continuing on. According to that log, your client closes 1 minute 17 seconds after those errors happen.

IMPORTANT NEWS REGARDING FORGE MULTIPART SUPPORT I contacted ChickenBones, and he altered his and my code to add support for Multipart blocks (non-Immibis microblocks, ChickenBones wireless redstone, etc.), and a test version will be out later today. It requires a new version of Forge Multipart and will not work with any previous. Requires version 1.0.0.154: http://files.minecraftforge.net/ForgeMultipart/ At this time, that version is available for only Minecraft 1.6, not 1.5. Hopefully a 1.5 revision will come out too, but I can't control that and I don't know if he can/will do one. So for now, multipart support will be in only version 1.6 of the mod.