jakj

If you mean traveling through portals and teleporting the carriage, that would require me to turn the carriage into a mobile entity which would require almost a full rewrite of the mod. Being able to teleport carriages is an intriguing idea, though: I'll give that some thought. Supporting any mod's dimension is as easy as storing an integer.

Well, a lot of modders mod for themselves instead of for the community, which is silly, because if you're modding for yourself, save yourself the headache of support and don't publish it. People think they get both halves of the pie: The recognition of people saying you made a neat thing, and then the control of telling those people to fuck off if they think it could be improved. That's not how it works.

The only way to make it remotely feasible for me to code is to make the logic as simple as possible, such that multiple carriage types can't act independently but rather only add to the overall carriage. That has very limited use, though, because if all it does is add to the structure, most of the time the original frame structure could have just been expanded in the first place. The only situation I can think of where this would be even slightly useful is with support carriages, which right now can operate only in one direction at a time. If they could link together, you could have one part that faces up and one part that faces down. Even just that bit adds all kinds of complication to the logic, though, because support carriages are not as simple as just "go out in a straight line" and it becomes super-difficult to figure out the difference in that case between "aditional carriage to handle with logic" and "just another block to carry".

That's been a requested feature, but the potential logic involved is so complex, I'm not sure I really feel up to tackling it. What about the ordering? If you have a support carriage inside a template carriage inside a structure carriage, which activates first? Which last? What if the activation of one changes the structure of the other? Right now, there are 5 carriage types, which means 5 sets of logic to write, test, and maintain. If you add just a single level of nesting, that adds 25 possible combinations that might need special handling. Another level of nesting, and those 30 get 125 more. It's not good enough to just say "run the logic for each carriage type separately and just add the blocks together to form the final package" because even the tiniest difference in placement can lead to completely different results.

Well, you can use Frame Carriages and Carriage Motors to mimic the old RP2, and you can just pretend they need power if you want. Maybe try using an engine and making the most compact possible airship that can travel in all six directions.

No, I don't think it would be better, but I will make it an option in the config. Putting a block down next to the controller and removing it also works, so somehow it is not receiving its proper update upon load. Will be fixed for next release.

Sorry, folks: I just spent over two hours testing and pouring over the source code of both Buildcraft and Minefactory Reloaded, and I've had to give up. I almost made progress when I discovered that buildcraft stores the absolute X/Y/Z positions of the items in its pipes, and when I correct those positions, the items in the pipes do behave better upon cessation of motion, but a few items also end up getting kicked out of the pipes onto the ground, whereas if I leave the wrong numbers in there, Buildcraft goes through a "warm up" period where it recalculates everything and then nothing pops out. The Buildcraft code is a mess. I can see the glimmer of past elegance in the design, but that has long ago been covered up by the cruft and grime of iteration over time, and now it is just awful in places. I have done all sorts of debugging, tracing the exact code paths that each mod is taking, and all of my debugging output comes up as "yeah, everything is in the proper state, so it should work" and yet items still kick out. I am stopping just short of the point of losing my mind over this code. There's no help for it but to declare this as a known issue without a fix available, and just say "you need to let the pipes sit there for at least 0.1 sec, preferably 0.25 sec, before you try to put anything in them". If at any point in the future I figure out a way to fix this, I will. Good: I'll add it.

Power requirement is part of "hardcore mode", so yeah, it's down at the bottom. Honestly, right now the mod is balanced enough: If you feel platform carriages are too cheaty, just don't use them; If you're making decent-sized carriages with just vanilla, that's a lot of fucking wood; and other than some sort of tunnel bore (which is going to need a whole other mod anyway which probably has its own power requirement), the mod doesn't even do anything special like give you diamonds. It just moves things, which you could do yourself. The most you could say is "it's cheaper than silk touch", which is true, but it's a massive pain in the ass to do that if whatever it is needs to move a long distance. It's on the to-do list because people want it and people deserve to get what they want when it's reasonable, but as I say, it's low on the list, because people should be able to take control of their own play experience.

1) Open-source mod: Change it and recompile. 2) There already exist mods that remove recipes and mods that add new recipes, and both have already been linked in this thread in the past.

I am now working on an alpha-quality test for working around the buildcraft issue. Expect it in a few hours, unless I can't get it working. (It will be for testing only, not an official mod update.) Added. Fixed. If you want them added to the mod, you must release them under permissive terms (WTFPL, CC, GPL, public domain, or similar).

No, I'm 80% sure it's because of Buildcraft; I may have explained inadequately. Further examination has given me a promising idea that I will try out later today, so we can hope for the best. EDIT: Yeah, I just confirmed it by looking at Buildcraft source code: At the time MFR is trying to stick items into the pipe, the pipe has not yet fully initialized, meaning when MFR says "are you accepting items" Buildcraft says "I don't even know what I am yet" and MFR says "okay, I'll just leave these on the floor here". Workaround in the mean time: Use an obsidian pipe to pick up stray bits. I'll keep looking at the source code to see if I can safely manually initialize it without breaking Buildcraft to bloody bits in the process.

Yeah, you guys can play around with hardmode all you want, and if you come up with something people like, you can just run with it. Hardmode genuinely is on my to-do list, but it's so far down it's barely a footnote.

I'm glancing at the BC code, but it's going to take me a bit to unwind that whole mess and figure out why the delay is there in the first place, plus the fact that I actually want to do more than just develop this mod right now.

Well, the good news is I know what's doing it! The bad news is I can't do anything about it. This is the same issue with the item loss that I added the cooldown for, except in this case the cooldown doesn't help. Your block breakers are activating the moment they are being put down by the carriage, and immediately spewing into the pipe, which is still doing its internal cooldown so it doesn't handle things properly. You will notice that, once the thing has sat there for a second, if you put blocks down in front of your breakers, it then works fine. The only way to get this working properly with BC pipes is to figure out some way to introduce a delay between putting down the carriage and having the block breakers activate. (Of course, the best solution of all is to get Buildcraft to remove this delay. I haven't looked closely enough at the code to figure out if there is or isn't a good reason for it, but it's likely it can be fixed somehow.) Maybe try with a different transport system? Doesn't MFR have some sort of conveyor? There's no reason it has to be quite this compact, after all. Maybe try using AE block-breakers with their cabling; Since AE combines power and transport into the same cable, you can have a solid front-facing wall of breakers without needing to have your bore side-step before moving forward.

Well, since this is the first time anyone has given me anything at all to go on regarding the issue in all this time, I will now take a look. Well, that's surprising, but I'll always take good news.

Not perfectly stable, certainly not. It makes portal spawners from iChun's mod vomit all over themselves, for example. But "highly stable" I would say absolutely yes, unless I am informed otherwise.

Yeah, everything works 100% the way it did before: There's just an internal countdown between actions. In addition to making Buildcraft work and making things not glitch too much while rendering, it also lets people recover from a carriage they have foolishly launched into orbit. But yes, I'll add an option that will say "I know the risk: Disable carriage-drive cooldown entirely".

I figured it out: It's just happening too quickly. The world needs a tiny bit of time to settle, and ComputerCraft is trying to activate the controller before the controller is completely put back in place, which sends the computer into an error state, so it keeps failing. If you add an os.sleep command to your startup program before you actually try to connect to the peripheral, it should work. I'd say, start with os.sleep(0.1) and increase it if it still doesn't work. That was added in the current release to work around an issue with Buildcraft pipes and with rendering carriages going extremely quickly, and I forgot to put in an override option to let people do it after assuming the risk. I'll make a note to add that option into the next release. Right now, though, the continuous mode works exactly as it always did: It just pauses. You can still do exactly what you were doing, but it just won't be smooth.

Yes, I was able to reproduce the issue myself, such that I had to right-click on the computer to get it to activate, which immediately closed the gui window and started moving. I'll put it on the known-issues list and mess with it as I get time. If you discover any further details about this problem, let me know.

Yeah, that's not something I'm going to be able to fix right now, unless there's some token I can synchronize against. What's happening is my mod is forcing the tile entity to write itself out to a saveable record, just like what happens when the world is being saved. The problem is, this Tick Threading mod of yours probably makes the assumption that the function I'm calling will never be called except by Minecraft itself during the saving process. (This is actually the same thing as the Optifine crash above, where Optifine is assuming the rendering functions will be called only by Minecraft during the normal cycle.) And I expect the Waila mod would be incompatible with TT for the same reason. You can ask the TT guys if there's a way to synchronize tile-entity access so I can query tile entities at will; Without that, I don't see any way to make my mod compatible.

Reentrance? Fuck me. Well...I'll give it a shot, but no promises. My mod rips into the internals of Minecraft to do what it does, and it might be that the only way to get things to work in the presence of RIM is to synchronize the entire thread pool and lock it while I work. We'll see.

That program doesn't make sense to me. You're calling getInput on the back of the computer, which gets redstone signal, but then you're calling the controller peripheral also in the back? The controller doesn't output a redstone signal.

The 8 carriage you lose by doing that cost you some sticks and one piece of lapis lazuli. I think you'll live.

Yep, it's a long-standing bug in Optifine, because Optifine makes the assumption that the rendering functions will never be called except by Minecraft itself during the normal rendering cycle.

Any time Optifine crashes for me on connected textures, having connected textures off always fixes the crash.