jakj

Read Searge's tweets for the past few weeks.

No, Forge is switching to the Gradle build system and working on dumping MCP because Searge will no longer be developing MCP after the current version because he's working for Mojang and they're (slowly) working on the official API (for whatever that will be worth) which will change the way deobfuscation does at all. Searge has refused to discuss it publicly, working directly with Forge instead. It's good in a way, because only an idiot could expect Searge to still be allowed to develop what is in effect a hacking tool for the software made by the company of his own employ, so we were going to lose MCP anyway unless somebody forked it, but the Gradle transitiion and AbrarSyed's stuff *should* make that not necessary. It's kind of...absorbing MCP, almost like the converse of Borg assimilation.

I'll get it going at some point: I'm just being lazy right now. Mostly waiting on the first prereleases of MCP/Forge/Gradle/Whateverthefuck for 1.7 to come out, most likely within a week, to see what we're up against. With Lex/CPW being on a "this is the right way to do things, deal with it" kick and Searge becoming a Mojang employee, 1.6 was the last "modding as we know it".

So have multiple templates that overlap so you can have as many anchors as you need. Each anchor can include the other anchors to move them. You can assemble them all with a slight separation so you can establish the full patterns, then use a single-block secondary carriage to push them into place so they move without being triggered or losing their pattern. I think they are plenty powerful enough to justify a little extra effort for such a limited application.

Possible, but a massive amount of work, not proportional to the amount of benefit gained by the effort. Explain.

That's the Buildcraft reflection code erroring out. It's harmless: It just means Buildcraft pipes behave strangely and don't re-initialize immediately (takes a quarter of a second) after motion, which is a problem only if you're trying to shove things into them immediately after motion. Go in your config on the server: "Dirty Hacks" { B:"Attempt to hyper-reinitialize Buildcraft pipes after motion"=true } Change that to "false".

Old versions of WR-CBE work with it, but not new ones. (Basically, versions from about the same time as when I first added multipart support.) New versions do more-complicated things with block updates that I don't support yet. SlimeVoid's might or might not work; I have no idea. You are correct about moving computers being unnecessary with a working WR mod.

Looks like the first glimpses of 1.7 are on the horizon, and the new build system is coming out with a full head of steam. I'm starting to take a look at it this weekend, to see how much of a change this will mean in my build scripts. And in case anyone is wondering, yes, 1.5 will still be supported until people stop playing it: My mod really isn't that complex, and with my new build scripts, it's trivial to support all three at the same time.

I never had updates working: They were just never an issue before. I don't know exactly which version of his changed the way his blocks worked, but he internalized the updates which meant they weren't passing through vanilla anymore. When I (and CB) were implementing support for multipart originally, it worked without issue. CB's already helped me enough, and I doubt he'd want to be bothered yet again. It would be awfully nice if he would implement a function that would spit out the updates for me in a nice list, but he's likely got other things to worry about right now. I'll keep messing with it here and there.

Not particularly soon, no: His code is not at all straightforward and it's going to take quite a lot of work to wade through it, hampered by the fact that I'm having to learn Scala on the fly as well as reflect into it from Java. Unfortunately, the amount of work required to get multipart updates working is an order of magnitude greater than that of vanilla updates (which is as simple as looking through a list, pulling out the bits I need and storing them, and then putting them back into the list later). It's kind of annoying he made it reliant on multipart anyway: It could absolutely have been done without it, with more work on rendering and collision detection and such. Oh well.

Oho, that's interesting: I didn't think of them doing that. Apparently, ComputerCraft is calling the "what does this block drop when broken" function *before* actually breaking the block, storing that value, and *then* breaking the block. At least, looking at enderio's code, that's the only possibility I can see. Enderio's capacitor block does an instanceof check (which is also a builtin null check), so if the TE exists, it uses it, and if it doesn't, it continues on. Okay, I can work with that. I'll make a note to copy enderio's style the next time I do a release. I'm glad you pointed this out to me.

That's a flaw in other mods. My mod requires access to the tile entity to determine what to drop when a block is broken, and the standard methods Minecraft uses for that, have already destroyed the tile entity before they're called, so I have to use a method that works only when an actual player breaks the block. It is actually possible for mods to create fake players and have "them" break the block, and that would result in the drops appearing properly, and then the other mod could scoop them up as nearby entities. But that's more work, so modders usually don't do it. It's physically impossible for me to do it any other way: Doing it the normal way would make carriages lose their decorations, translocators lose their labels, templates not spit out their contained blocks, and so forth. (It would actually be possible for Forge to make a small change in the code to pass the tile entity to the function that causes the drops to be generated, so I could make it work, but there's not a snowball's chance in hell that I could actually get any changes into the Forge codebase. They're way too busy doing their own thing and don't give two shits about Joe Random Coder's pull requests, and would probably just say "not needed; figure it out yourself". So meh.)

Or, with less absurd and unnecessary verbosity: S:Blacklist=25285:0,2415:0,2416,2417:2

You may just be doing it wrong. Post the line in your config file here so I can check the syntax, and also make sure you're using the correct block IDs and not missing any.

Okay, let's settle this: 1) Wireless Redstone having issues on carriages - This is a RIM bug, in that I haven't completed the final details of Forge Multipart integration yet, namely the propagation of scheduled subpart ticks. This means multipart stuff moves fine but doesn't always update. Older (by several months) versions of WR didn't have this issue, if you feel like downgrading that far. 2) ComputerCraft stuff rebooting on carriages - This is NOT a RIM bug, nor is it a CC bug: It is a CC limitation, in that CC computers reboot when the world is closed and opened. If CC ever reworks itself to save and restore computer state properly, this will stop happening. My answer to wireless redstone not working: "Have patience: I'll fix it eventually." My answer to computers rebooting: "Deal with it."

No idea about "Null Receiver": My mod doesn't print that.

Buildcraft works with the hack off, but is glitchy visually and takes a few ticks after motion for the pipes to start up again. If you're getting console errors, the hack is nonfunctional anyway, so you might as well save yourself the spam.

It is an assumption based on experience with "the community", yes. I have had no interaction with that particular developer. I may try some time.

At this point, the only place that anyone listens to anything I say is on this website, so that's not too terribly likely.

That's a good thought. On the surface, having something fail only on certain edges indicates a one-off error in the code (like when Notch screwed up some of the collision detection and you'd take damage being pressed by water into the corner of blocks with lava diagonally from you, but only on certain vectors, or how he had redstone signalling going so it had different timing in different directions), but I haven't been able to find any such one-off errors in my code. Something caching x/y/z positions but failing to remove from the cache on invalidate() could easily be the cause. It's stupid and lazy, because chunks load/unload all the time, so they should be handling invalidate() anyway (because accessing an unloaded chunk forces it to load which can cause performance degredation if the user didn't need that chunk loaded). Lazy lazy.

Two things: 1) The spammy NPE that are not actually crashing you (just being logged) is the Buildcraft workaround code. Buildcraft has since updated, making that code not work anymore, so it just basically fails and gets ignored. There's a config option to turn it off so it doesn't spam your log. 2) Minecraft's ass-backward crash reporting pisses me off, especially right now, because it's actually crashing INSIDE the special "crash report" function in the TileEntity class, which is causing the actual crash that started the problem to be obliterated and not even printed out. So I actually have not the slightest fucking clue what's going on, I'm sorry to have to say. I'll do my best to figure it out anyway, but my best may be or may be not good enough.

My animosity (or lack thereof) towards anyone has no effect on my code: I simply code, and if I feel the desire/need to work around someone else's silliness, I will. I'd never even heard of the "ender io" mod, which means right now I really don't care. Portal Gun is really the only "doesn't work" that I still actually give a flip about working on, and there's only one useful block in that mod that doesn't work already. Multipart works, though with some limitations, so it's "good enough for now". The rest of the picayune mods out there, eh.

"using cached locations to help with lag" Yeah, and when your block receives invalidate(), you remove it from the cache, and it gets added back to the cache on validate(). Gee, that was hard. "it is hard to develop around even on a good day" So, that's why 95% of all mods work out-of-the-box with it with no issues at all, eh? *sigh*

They're probably caching x/y/z values, then. Lazy, lazy programming. Understandable, but still lazy.

Another class-cast exception? Hurgh. Never did figure out why that happens. Does the crash happen when you initiate the motion, or when it finishes? Is anything left of the carriage when you reload the world? Does it happen the same way no matter which direction the carriage is moving?