jakj

The error message already includes the coordinates of an obstructing block. But you haven't answered my question: What type(s) of value(s) do you want it to return in what circumstances? For reference: callMethod java.lang.Object[] callMethod(IComputerAccess computer, int method, java.lang.Object[] arguments) throws java.lang.Exception This is called when a lua program on an attached computer calls peripheral.call() with one of the methods exposed by getMethodNames(). Be aware that this will be called from the ComputerCraft Lua thread, and must be thread-safe when interacting with minecraft objects. Parameters: computer - The interface to the computer that is making the call. Remember that multiple computers can be attached to a peripheral at once. method - An integer identifying which of the methods from getMethodNames() the computer wishes to call. The integer indicates the index into the getMethodNames() table that corresponds to the string passed into peripheral.call() arguments - An array of objects, representing the arguments passed into peripheral.call(). Lua values of type "string" will be represented by Object type String. Lua values of type "number" will be represented by Object type Double. Lua values of type "boolean" will be represented by Object type Boolean. Lua values of any other type will be represented by a null object. This array will be empty if no arguments are passed. Returns: An array of objects, representing values you wish to return to the lua program. Integers, Doubles, Floats, Strings, Booleans and null be converted to their corresponding lua type. All other types will be converted to nil. You may return null to indicate no values should be returned. Throws: java.lang.Exception - If you throw any exception from this function, a lua error will be raised with the same message as your exception. Use this to throw appropriate errors if the wrong arguments are supplied to your method.

Which was a MISTAKE. Ever heard of those? Human beings fuck up. Maybe it didn't occur to him; Maybe he thought nobody offhand would care. mDiyo is a good guy: When he changed his smeltery, and people said "hey, you know, that's great and all, but I don't like it", he added a config option. So if Greg or GregTech players had said "hey, you know, that's great and all, but I don't like it", he would have added a config option. Do you know what had happened? Complaint after complaint after complaint about how his mod and GregTech interacted. He got sick of it and made a change, and OH MY GOD HE FORGOT A CONFIG OPTION THAT HE COULD HAVE JUST BEEN REMINDED OF TO PUT IN AS A PATCH OH GODS THE WORLD IS FUCKING BURSTING INTO A CLOUD OF DUST get over it. mDiyo makes a simple tweak, and an attention whore throws a fit. The rest went as expected.

Greg has the right to alter vanilla recipes. mDiyo has the right to alter Greg recipes. Greg has the right to un-alter recipes mDiyo altered. All three of these should be configurable by the end-user/player. None of these should ever result in a deliberate crash. That is my unwavering position.

The thing is, I have absolutely no clue how ComputerCraft works. I know the basic rudiments, since it is simulating a CLI OS, but not how all the little bits interact. The way the API works, I am expected to return "an array of whatever". (That's literally how it's coded.) These items are then converted by ComputerCraft from Java to whatever the hell Lua does. Right now, on failure, I throw an exception (which ComputerCraft prints as a string), or I return an array of one boolean of value true. So you'll have to tell me what is actually useful for writing programs. Do I return a string error message on failure and nothing on success? Or empty string on success? Or return string if success and boolean if failure? Or should I always return a boolean and string at the same time, and the string is empty if the boolean is true for success? Or should I return just a boolean true on success but a boolean false on failure and a string with it? How do I determine whether or not an error is printed instead of returning a value? I have absolutely no way to detect the difference between "user typed command while looking at computer screen" and "user wrote a program that is being run and issued the command".

Bullshit. Not adding the config option in the first place was a simple mistake: mDiyo has clearly demonstrated willingness to let users configure his mod by adding config options for other things in the past, including his own balance changes (e.g., the increased smeltery requrement). It's rapidly becoming clear to me that open and cooperative modders are a precious resource to be treasured, as this recent "blowup" has revealed to me even more DRM than I thought existed, INCLUDING EVEN IN MOTHERFUCKING THAUMCRAFT. Stop trying to make villians: You have plenty to choose from. Start with Sengir, CovertJaguar, Azanor, and RichardG, and go from there.

It'll still give out an error message just the same. The only thing the simulate flag does is cause the carriage to not actually move.

No, because he did the right thing both times, and was even a bit more lenient than I would have been. Greg pulled a Sengir, and did it with even less class and panache than last time, more like throwing a turd in everyone's face instead of planting stinkbombs in corners and letting them go off so people had to find them. mDiyo does things unobtrusively, for a reason, and gives config options. Not only that, but mDiyo has no problem in general with people fucking with his mod: Qwertyguy (i think that's his name?) has made a mod that will deconstruct TC tools, and mDiyo has endorsed it, even though mDiyo has said he will never add such a feature to his own mod because he thinks it's unbalancing and he doesn't like it. mDiyo is awesome.

Aha, yes, that's actually a known bug in my code that will be fixed in a future release. I apologize in the mean time for the inconvenience. For now, breaking/replacing the controller is the best way to fix it. But if you break/replace the controller and it works with lua directly but not with your program, then it has to be an issue with your program. I did code for explicit strength and directionality, because otherwise there can be confusion from sloppy redstoning that would cause it to potentially activate from a direction the user doesn't expect; It's better this way, where any non-clean signal simply doesn't work, instead of working in an unexpected manner.

The carriage controller issues a plain-text error message if it fails to move something. Try issuing commands directly to the computer instead of using your program and see what happens.

That's Optifine being a piece of shit. Nothing I can do about it. If they turn off "connected textures" in their video options, the crash will stop.

Well, it's probably storing the absolute X/Y/Z coordinates, then. I'll put it on the list for whenever.

How do you establish the connection in the first place? If it's a command, just add the command to the startup program after the sleep.

1) Computers reboot when they are moved (or when the chunk or world is reloaded), so there's no way your go() function will ever complete beyond the first iteration. To implement a loop like this, you'd need to somehow store your 'i' variable persistently and read it back in after the move, and put your code in the "startup" program. 2) Remember that computers need a short warm-up period to start working after a move, so you'll need something like "os.sleep(0.1)" at the beginning of "startup" (and if 0.1 is not enough, raise it higher, possibly up to 0.25).

INFORMAL BUGFIX RELEASE 1.2.0.1 This is a release, but without the usual fanfare, since I'm doing stuff right now but wanted to get these bugfixes out. It (should) now be safe to use in play worlds and open servers with Buildcraft pipes and ComputerCraft, without issue. (There was a report of an issue with IC2, but only in a super-new development build, so I won't worry about that for the moment.) https://www.dropbox.com/s/mm9646mh2pv9qgf/RedstoneInMotion_1.2.0.1_mc1.5.zip 1.2.0.0 -> 1.2.0.1 -- removed some vestigal server->client data transmission -- fixed buildcraft pipes not accepting items immediately after transit -- fixed items in buildcraft pipes stuttering/slowing after transit -- fixed ComputerCraft synchronization with Minecraft thread of execution to clear a bunch of crashes -- continuous-mode cooldown can now be changed back to 0, though the default for new configurations will still be 5 ** note that with no cooldown, after the first step of transit, many tile entities will no longer render correctly until transit stops ## this is cosmetic only, and does not occur if there is a cooldown of at least a couple of ticks unless server->client transmission is super-slow

That sounds a lot more like something that would belong in MFFS, creating a shell of air around yourself. If I were you, I'd post a suggestion to Calclavia to make a kind of force field that handles regeneration of water as you pass.

This is super-neat.

Oh thank goodness. I guess it is only the active object that gets synchronized, then. Good to know.

Since normally the blocks are unbreakable, I assume you're in creative mode. Don't destroy shit in-motion while in creative mode.

Second attempt at experimental ComputerCraft crashing fix with AE. (I remembered the source this time.) I have synchronized everything so that all accesses to Minecraft information is executed in the updateEntity call (meaning the actual Minecraft server thread) instead of the callMethod call (meaning the ComputerCraft offload thread). In theory, this should do nothing, because Java is -supposed- to propagate heap page alterations at synchronization points, but in case I have misunderstood and that happens to only objects proximal to the synchronization object, this change makes it so heap propagation isn't even necessary. I'm crossing my fingers, because this is the absolute last idea I have before I go "I have no fucking clue what is happening or how to fix it". As usual, this is super-alpha and not for public consumption unless that public knows what backups are. https://www.dropbox.com/s/w5j1nlvawg2vrc7/RIM_CC_FIX_TEST_2.zip

This AE thing is tough. The only thing left I can think of is that somehow the memory between the threads is going stale, but the synchronization is supposed to propagate that. I'm going to try shifting all processing to the other thread during sync to see if that helps. At least the buildcraft fix worked.

The current "easy" mode will always be the default option, even when I (eventually) add a "hard" mode. Setting the ID to 0 would probably just crash the game, right now. I'll put that on the to-do list.

Yeah, people have been complaining that my mod is overpowered, but my answer is "use frame carriages, then".

A thing of beauty.

Dammit, that error again. I swear, it is a ghost that is having a merry time watching me chase after it.

Okay, here's a new question regarding AE crashes: It looks like every time a crash happens, the controller and computer were being moved by the carriage. Has anyone gotten it to crash 1) with the controller moving but not the computer, 2) the computer moving but not the controller, or 3) neither the computer nor controller moving? I'm starting to think that some of this may be due to the objects being moved and doing the moving at the same time, and I'm needing to figure out if it's one or both.