jakj

Remember to back things up and test them first. I never play on servers so SMP is the weakest part of the mod (though in theory it shouldn't be since singleplayer is basically local SMP).

Multipart works fine now (other than the already-known issue with scheduled ticks for subparts) and some crashes gone. 2.3.0.0 - MC 1.6.x https://www.dropbox.com/s/iriq2spgf4vblo8/RedstoneInMotion_2.3.0.0_mc1.6.zip http://j-a-k-j.com/RedstoneInMotion/RedstoneInMotion_2.3.0.0_mc1.6.zip 2.3.0.0 - MC 1.5.x https://www.dropbox.com/s/0tgr1vl7rsnwzxo/RedstoneInMotion_2.3.0.0_mc1.5.zip http://j-a-k-j.com/RedstoneInMotion/RedstoneInMotion_2.3.0.0_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 2.2.0.0 -> 2.3.0.0 -- fixed typo in config file ("BlockIds" -> "Block IDs") ** YOU NEED TO CHANGE THIS MANUALLY BEFORE RUNNING THIS UPDATE ## if you do not, the block IDs will reset to the default ones ## in your config file, look for the line that says this --> BlockIds { ## change it to this --> "Block IDs" { ** (sorry for the inconvenience, but I am way too anal-retentive to leave that wrong now that I noticed it) -- fixed bug with multipart blocks disappearing due to a change in Forge ** all version combinations of multipart/forge should work now ## subpart tick scheduling still isn't handled correctly though -- fixed bug with rendering template ghosts that span more than one chunk -- eliminated the caching of world objects for loaded translocators -- improved in-transit rendering of translucent things like liquids -- removed legacy conversion of item forms of decorated carriage blocks and labelled translocators -- redid the packet code to use tag compounds -- added slightly more redundancy to rendering code 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. *-*-* 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. When translocated, some entities (especially chest-carts) behave strangely, but nothing major (so far). *-*-* 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. Anything else that caches 'x/y/z' values for any reason (possibly some chunkloaders, likely anything that does teleportation) has a strong chance of misbehaving. These should be reported to me as bugs. *-*-* 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 *-*-* THINGS HIGH ON THE PRIORITY LIST *-*-* Redoing translocator labels and other things to use a GUI instead of trying to draw on the block. An optional "hardcore" mode involving tiered crafting and power consumption, for people who want this mod to be expensive to use. *_*_* THINGS TO BE WORKED ON LATER *-*-* The ability to prevent individual blocks/items from being registered. 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.

UPDATE ON MULTIPART SUPPORT So, it turns out, it wasn't actually the change in Multipart at all. It was a change in Forge. So to get it working, you need to downgrade Forge, not Multipart. Derp. That was an hour-long debug session! Anyway, I'll fix it. Bugfix patch will be out today, maybe with some small new features sprinkled in if I get time. EDIT: Yeah, fixed it in 40 fucking seconds. Ugh, ChickenBones is right: I need to start using a proper debugger. One hour of debugging, one minute to fix bug...heh.

Only if your block IDs are different than the defaults. It's just a 30-second change of a text file, anyway. I think people will live.

Heads up on a small upcoming breaking change: I have a typo in my code, where I say "BlockIds" instead of "Block IDs" in the config file. I'm going to fix this for the NEXT release (so don't do anything yet). What this means is that you should go into your config file (after installing the next release when it comes out, but before actually running it), and where you see this: BlockIds Change it to this: "Block IDs" I'll admit I'm doing this just because I'm too anal-retentive to let the typo slide now that I've seen it. I'm pulling the "I'm not getting paid for this so nyah" card on this one. :P

According to the Github log for multipart, any version from Sept 17 or older should work.

Yes, it's on my priority list, and I'm working on it over the next few days.

Okay, so, I've recently come to grips with three facts of life: 1) The way I'm doing labels for translocators right now is extremely shitty. 2) The ways I've tried to do texturing for the different tiers of everything have been six orders of magnitude shittier. 3) GUIs in modern Forge are actually really easy. So, I'm taking back my previous "no GUI" rule, and I'm going to switch from trying to texture these things to just displaying it in a gui. I really don't think it's that much of a hardship on people to just right-click on something to see its current status. Being able to see everything on the side of the block at a glance is nice, of course, but it's just turning into such a complete pain in the ass, especially with multiple texture sets to support (all of which I like and won't get rid of), that it's just not worth it. I can't just say "activate the block with anything except a screwdriver" without forcing you to sneak any time you want to put anything anywhere on a carriage, so I'm going to require the activation to be done with an empty hand to bring up the status display. I can also create a second tool for the purpose, if people want. The benefit of this is that empty hotbar slots tend to get filled up if you're breaking/moving things a lot, so it's hard to keep an empty spot, so it's handy to have "something" you can place there that will keep that slot devoted to a particular purpose. It would be optional to make this tool, unlike the screwdriver. Thoughts?

Maybe some day. If I ever do anything like that, I'd probably just make the placeholder blocks load themselves.

Even if the modder was smart and coded well their chunk loader so it handles well being moved, the structure could indeed be unloaded during transit if the loader is being moved and you're unlucky. At the least, you will need one loader to keep the core loaded while it moves. I have not tested chunk loaders with my mod, and it's also possible that, if they are coded in a lazy way, they could either continue to forever load chunks as if they were in their original position, or else continually try to load chunks redundantly along their path.

The "hard mode" will include tiers of each item, requiring more materials for higher tiers, and the recipes there are now will be the base recipes for the lowest tier. There will also be energy requirements (at least Buildcraft, and possibly IC/UE support also). Also, some of the recipes will be alterable with my "Craftin' Cheap" mod that's currently WIP. It is not possible for you to craft the Carriage Controller without ComputerCraft installed. You probably have it installed on your client, and if you try to craft it, it should just produce blankness as the server has no matching recipe to your client one.

Oh, that would work, if it's namespaces by mod id.

If anybody got a spam DM on twitter from my account, just delete and ignore it (and let me know if you get another one). Apparently some fuck got my password, and I changed it now, but Twitter's security is sketchy and it may allow cached logins to continue even after a password change.

No idea, since I haven't looked at the code yet. Presumably the same way it does now, by saying "Hey moron, you're trying to register something that's already registered". For the most part, there will be no issues, because for the most part, mod authors have enough of a clue to at least put the name of their mod in their internal handles. If somebody registered it as "tile.copper", then they really are too dumb to be modding in the first place.

For one thing, blocks will now be registered by name instead of by ID, which I anticipate might have a significant performance hit because, instead of simply referencing by array index, now it will at the least be querying a map by string hash. Do I think "significant performance hit" means "performance hit anyone will notice"? Eeeeeh...I'm kind of leaning toward not, simply because Minecraft is so efficient in so many other ways, that small additional inefficiencies are completely drowned in the process. This is obviously affecting worldgen to a significant degree, too, and if you noticed the whole 1.6.3/4 thing, that was a "transitional" patch to alter some data structures in storage for the 1.7 transition, because otherwise worlds would be un-upgradeable, and that transitional patch already broke some mods (pretty much anything that did custom worldgen structures), and 1.7 isn't even here yet. Let me try and put it in perspective this way: As one major developer has already said, "Even the dirt-to-diamonds mods will have to be rewritten.". Do I think this is a catastrophe? No, I think we'll be fine. From what I've seen and heard, the transition to integrated servers was much more difficult, and this really isn't looking like a difficult upgrade process. What it looks like is really fucking annoying beyond anything that's ever come before, and it's going to be unimagineably tedious for the huge block-altering mods like Buildcraft, Ars Magica, and...well, 95% of all mods, quite honestly. Is it a good change? If they don't fuck it up, yes: Getting rid of block IDs would be awesome. But when 1.7 hits, expect the whining and moaning to begin (from myself included), expect the majority of modders to be in "oh hell no" mode for at least the first week or two, and expect a few mods to announce that they're skipping 1.7 entirely. But once the dust settles, and people realize (if nothing more changes between now and then) that it's not really difficult but just super-annoying, I think the majority will sit down and push out a 1.7 version before too terribly long.

The Minecraft code base is undergoing a refactoring even bigger than the transition to the elimination of true single player, even to the point that cpw is concerned that many modders, even big ones, will be so daunted by the sudden major changes that they might even stop modding altogether. Cpw does overreact, but there's an element of truth to it in this case.

Fortunately, because my mod is so small, the difference between the 1.5.x and 1.6.x branches is only about ten lines of code. When 1.7.x hits...then will come the pain.

There are plenty of ways to auto-build carriages. Hell, you can auto-build them with nothing but a turtle, and if it's something as simple as a structure carriage, you can write that program while asleep. The only issue with breaking it back down is the method I have to use to generate drops requires access to the tile entity, and the normal Minecraft method of breaking blocks has destroyed the tile entity by the time it gets there. It works fine for normal play, but other-mod automation can't handle it, so instead the drops are just gone.

4 is in effect a faster version of a continuous-mode drive, yes, except it does not ever occupy the intervening space.

Multiple ways to do it: 1) Translocate. If anything's there, tough titties, it's gone now, Star Trek episode where you phased through the floor. Easy to code; Quick to execute. 2) Try to translocate: Fail if you can't. Easy to code; Quick to execute. 3) Try to translocate: If you can't, pull back one block's distance and try again, repeating until you get back to the starting position, failing if you reach the starting position. Moderate to code; moderate to execute. 4) Try to translocate: Start checking spot-by-spot in the direction of travel (to a maximum of your "jump distance"), and translocate at that distance or just short of the first discovered obstruction. Moderate to code; Super fucking slow to execute.

That's an interesting idea: Unidirectional translocation. I'll give it some thought.

Doing that would require making the carriage into an entity, and at that point I might as well make a whole airship mod out of it. I'd have to rewrite somewhere around 20-30% of my entire mod. Placeholder blocks are solid. Where are you seeing them be not? Are you sure you're not just somehow getting stuck in one and having the game push you back out?

I told you I'm not compatible with the latest multipart version. Use an older one.

Ah, that explains it: Betrothed and promised are closely related in meaning. I added your video to the front post of this thread.

Ah, yes, Google Translate, how you never cease to amuse me. Your aperture-pyramid is pretty wicked, and the beacon at the top is a nice touch. When it lit up, it looked quite cool.