jakj

Yeah, I'm not worried about internal changes: My mod is super-simple, and the most difficult part of it is actually just a copy/paste with some editing of a Minecraft function anyway. I just mean gameplay things. I guess it'll be fine, then. I'm back in that zone where I can't bear to download/install practically any big fun mod because I feel like it's smeared with all the diarrhea spewed out by its creator. It just sucks all the fun out of the game when that fun is put in place by someone who's known to be an asshole. Fortunately, I really don't even need to play the game to be able to mod it, and if I stick to just MCP/Forge, I don't feel that taint spreading over me like a fungus, so it stays fun and exciting. (Even if from your viewpoint I update infrequently, from my viewpoint I dick around with it a little bit pretty much every day and have a good time. And I haven't gotten to the point yet that people are yelling at me for being slow, so hey, guess I'm doing alright.)

Regarding 1.7, I would appreciate it if any of you (if you try 1.7 out at all, that is) to keep me apprised of any gameplay elements that might affect my mod or how people use it, since I don't actually play Minecraft right now. I'm not sure that there really will be anything that affects things, since the majority of the changes seem to be with either worldgen or backend/engine, but you never know. As to when the update will come, well...even CPW says a month before Forge is even stable, and CPW is the one who's mortally-offended that people even use old versions and wishes all of us modders would refuse to support old versions at all. So, the answer is "a long damn time". But if Lex finds his way into the Zone, it could come sooner.

Yeah, my code is not running at the time that crash happens.

Put it in the folder called "mods" in your Minecraft folder.

That crash is either in LWJGL or in your graphics-card driver. Make sure you are using the newest stable versions of both.

I need to do one of the following, whichever ends up being easier/better: *) On client-side, detect when the player connects to a remote server instead of running the integrated one, and send a packet when the connection has stabilized. *) On server-side (dedicated or LAN-shared integrated), detect when a player connects, and send a packet when the connection has stabilized. What are the different methods available for this? I want to do it without any sort of tick handler: I want to respond to actual game or Forge events.

No.

WR-CBE relies on Forge Multipart, and my support of Forge Multipart is incomplete: I do not yet correctly propagate scheduled ticks for the subparts. This means they move correctly, but they don't automatically update. If you're willing to downgrade, I'm fairly sure that old versions of wireless didn't rely on updates and thus do work. At least I don't remember having a problem when I was first testing my multipart support.

The import/export will come later in the mod's life, because that's going to be a more-complex UI element. I'm going to focus first on the UI I already have, which is adding/removing individual overrides while optionally browsing existing recipes.

Well, what I'd likely do is instead provide some sort of export/import option. On exporting, it would convert each block/item ID into a class name, and then on import it would search through registered blocks/items for something with the matching class name. Alternately, there's going to be little up and down arrows which will cycle through the existing recipes for a particular device, so if they want to change your recipe for Explosive Space Modulators to take six Illudium Q-36 instead of ten, they would click on the tab that says "MPS Crafting Doohickey-Whatsits", and then click on the arrows until they come to the ESM recipe, click on the Illudium, and then click the down arrow for Illudium 4 times, then hit "override", and it will add an override for that specific recipe. So, you can either provide alternate configs yourself (like for "difficulty levels"), or else they can just change things themselves without config files at all.

CB used some sort of auto-formatter in Eclipse that cleaned it up to the "normal" style. If it reeeeeally is a problem, I can write a few sed filters to adjust it, but since you're at least 86 times the programmer that I am, I think you can handle it. I'm going to put up my "internal build system" as well as the already-processed source files for each package, so you can choose whichever suits you best. (The "internal build system" uses a pseudo-preprocessor that lets me write code more easily. The already-processed source is the normal stuff that gets passed right into Java, so it's exactly what you'd expect to see.)

I can throw it on there to make it easier for you, sure. If you can handle my alien whitespacing style. I think I gave ChickenBones hives. Gimme a few days. Client/server sync eventually, but for starters it functions without it.

Eh, I have no regrets for my actions, so I have no regrets for the outcome. If people elswhere want to make up and spread nasty stories about me to sow distaste and disfavor, there's certainly nothing I can do about it. I miss some of the popularity I otherwise might have, but I like where I am now, so I suppose I have no cause to complain about a world that isn't perfect when that world is still quite good.

Oh, it doesn't happen enough to actually piss me off. (Mostly because I've alienated everyone on the planet except on this website, so I'm low-traffic. Meh.)

About what?

It's understandable: I'm picky myself whenever someone again suggests block rotation for my mod. I'm fine if they just don't want to do it; I just wanted to be sure it wasn't because they had something against me personally.

What, they don't want to, or they think I'm a stinky-butt too?

What a lazy way to do it instead of using proper moderation. Oh well.

That would certainly take care of the issue with computers rebooting after motion. If you do contact them and they do end up giving a shit about the idea, you can mention my willingness to (reasonably) alter my code to support the needs of whatever method they end up using.

Delays are always good: My mod breaks assumptions and rips into the laws of physics that Minecraft and its mods rely on. Carriages fuck with the game universe harder than a bored Q. Also, I've always said that chunk loaders are an unknown entity and are incredibly hard to use and test in this way. If this problem you describe can be reliably reproduced, the first thing you need to do is reproduce it, except also have stationary chunk loaders too to guarantee everything stays loaded, and see if it happens again. This will tell you if the moving chunk loaders are even working right.

Yes, the problem is all the special code for pretty much every block, especially the ones that span multiple like extended pistons. Physically turning the set of blocks' positions is actually not hard at all, but the result would be scrambled eggs instead of an omelette. Useless to try for anything more complex than a dirt-and-cobblestone hut.

Joint-axial translation is a possibility; The coding would be fairly trivial. As long as it never involves actually rotating the blocks (either individually or as a set), then it's 3rd-grade mathematics. Computercraft control will be available for these and for translocators eventually; Got to decide how, since my code right now works well but is pretty frickin' twisted so a refactor would be good. Really, I would have preferred to have computercraft baked into each block directly instead of as a separate block, but there are several complications with that. One option would have been to have two releases, one with CC and one without, but that would have been a massive pain in the ass, and I'm not even going to try. Another option would have been to have duplicate classes in the single mod that get selected between at runtime, but that's actually more annoying to code than separate releases, rather than less. The newest version of forge actually has a neat feature that can strip interfaces away at runtime that would do exactly what I want with no fuss, but that would mean dumping support for everything before 1.6.4 and pretty much every modpack on the planet, so...eh. It's unfortunately a limitation in the Java classloader that you can reflect fields and methods but not classes conditionally. I'm probably going to just redo the whole thing for 1.7 anyway, since it's only about a 3% chance I'll be able to maintain it alongside the 1.5/1.6 version. (That doesn't mean I dump 1.5/1.6 when 1.7 comes out: It just means 1.7 will not be functionally-identical to 1.5/1.6. Since at that point the new forge feature will be guaranteed, I'll probably dump the Controller entirely and bake everything into the blocks. We'll see. 1.7 is still weeks away at best, and probably more like a month, since Grum/Dinnerbone are still fucking with the code to such an extreme degree that they even have to delay snapshots. I think it'll be great when it gets here, but it'll be a transition for sure.)

I'm going to do it the simple way, where it is directed to teleport a particular distance along a particular axis, and it will check that exact spot as if there were a receiving translocator there. It won't "fudge it" to try and fit nearby, but it will teleport through walls. Since I've changed my no-GUI policy, it will be easy enough to simply set an upper limit for the distance (a flat maximum in the config file for normal mode, or dependent upon tier for hard mode) and allow precise specification of any number of blocks up to that limit.

Oh yeah, I forgot to add that to the planned features. Thanks for reminding me.

Try using today's update: I put in a fix for a change in Forge that was causing blocks to prematurely process after being put down but before being fully restored. It was causing Multipart blocks to disappear, so it could be the same problem.