As posted in the OP:
Notice: this mod is officially retired! Explanations have been made in the official README, as well as on the project page on my website. If someone else wishes to take over, they should start a new thread (and maybe link this one, for historical reference).
Thanks for playing along, folks, LiquidUU has been good fun and I may see you again in some other mod.
I hope you understand mcp_deobfuscate isn't being updated and basically whet you're doing thorughout the mod by importing stuff from IC itself and not just the API is cheating. You should find a way to do all of it with just the API!
Right. It's ignorant bullshit like that that makes my first reaction to your statements to ignore them. FYI, mcp_deobfuscate's developer is a personal friend of mine and I'm fully aware that he's been working on that as much as I've been working on LiquidUU -- which is to say, not at all. Telling me this is just going to push my buttons to get me mad, and honestly I have better things to do with my time than get mad at some bozo on the Internet.
As for using stuff out of non-API IC2 bits, that's only a problem when IC2 breaks the bits I'm using, which isn't all that much:
[narc@hermes ~/src/LiquidUU/src/common/ro/narc/liquiduu]% git grep "import ic2.core"
CommonProxy.java:import ic2.core.Ic2Items;
SlotUUM.java:import ic2.core.Ic2Items;
TileEntityAccelerator.java:import ic2.core.Ic2Items;
TileEntityAccelerator.java:import ic2.core.block.machine.tileentity.TileEntityMachine;
TileEntityAccelerator.java:import ic2.core.block.machine.tileentity.TileEntityElectricMachine;
TileEntityAccelerator.java:import ic2.core.block.machine.tileentity.TileEntityRecycler;
integration/Forestry.java:import ic2.core.Ic2Items;
integration/ThermalExpansion.java:import ic2.core.Ic2Items;Ic2Items is replaceable by search-and-replace with some api function, but I never felt bored enough to do so. Meanwhile, the tile entity imports are actually quite necessary. Therefore, and with all due respect, sir: shut it.
Now, speaking of the fact that I've not been working on LiquidUU -- let me just quote myself from a few months back:
You should only really worry if you don't see me logged into the forum here for days on end
It turns out it's been something like a couple of months since I logged into the forum here, and that's a definite hint to me that I've left things up in the air for too long (I'm sure you'll all agree).
So here's the state of the mod: I haven't even started Minecraft since something like mid-March, and I have no current plans to get back to it -- it will be a while until I return to it. Consequently, my mods (LiquidUU and BeamMeUp) are going to be similarly languishing.
However: the projects are both open-source, as is mcp_deobfuscate, which they both depend on for compiling. Likewise, my Jenkins is going to stay up indefinitely, and automatically builds anything that's pushed to the github (and I promise to try to update its compiling environment if there is a need in future). Therefore, if other people want to take the current code and update it, I am more than willing to give you full collaborator rights to the github project.
I recognize that some folks have been using LiquidUU, and while I have no desire to leave you all in the dark, I simply don't have the resources (mostly the time) to maintain it myself. Luckily, there hasn't been much need for maintenance lately (we're still on 1.4.7? really?), but if there had been, I'm not sure I would've noticed in useful time. So it's up to people who are still playing and are willing to take over: if you're interested, go ahead and PM me or post in this thread. I'll need to know your GitHub account name, and you'll probably need to know how to use git, but otherwise it should be quite simple and straightforward.
Just wondering, when you port to 1.5.1, could you add placeable Liquid UU? That would be awesome.
I'll certainly look into it, but I'm afraid I have no idea when that'll be; I haven't really had time or interest to dedicate to Minecraft in general, or LiquidUU in particular, in more than a month. If anyone else wants a crack at it, well, that's why it's open source. 
You know, just yesterday I was updating stuff in my instance and wondering if there was a new OreDupeFix -- and now here it is!
Thanks kindly for your effort, it's really made my Minecraft so much better.
No, no cables. Did you not read what I wrote above?
i was thinking about the thermal expansion mod, it adds many new alloys(invar ingot, shiny ingot, electrum ingot...), but they are very simple to make... and maybe railcraft(rollingmachine recipes, steel...)
All right, but as I said earlier -- if we make a dependency on other mods, we need to provide either alternative recipes or just skip the ones we can't fulfill.
Now, to the recipes: this is the first and last time I will do this for you, but I've uploaded them all to imgur as an album. I'll critique them in detail when I have time, but I'll note that you haven't actually given me any alternatives for when Thermal Expansion and/or Railcraft aren't available. I'm also not particularly fond of the "superconductor" idea (don't we already have at least two other addons that provide one?). I'd rather have some, you know, actual components, like the third-tier circuit.
Either way, thanks for your time. If you have any further thoughts, feel free to share.
[...]and whats a heisenberg compensator made off?
Heh. Nobody knows -- it's a purely fictional device that somehow compensates for the Heisenberg uncertainty principle. Just think high-tech and intricate (and if it requires a special machine that we could give some other recipes to, that'll work just as well).
*EDIT Could i use items from other mods for the recipes?
Yes, but cautiously -- ideally, the minimum required for BMU should be just IC2 itself, so if we use other mods' items we need to either have alternate recipes for when they're not present, or just disable the recipes altogether. With that said, I'm not completely against implementing alternate versions of basic items, especially if they're registered in the Forge ore dictionary. To illustrate what I mean by "basic": I wouldn't duplicate the PortalGun miniature black hole (it's an expensive item), but I would make my own implementation of ender pearl dust and use that to make something (quantum circuit?).
I *think* you need to have Forge, not just FML, installed in the server. The class it's complaining about is present and accounted for in my server running Forge build 518 (which, yes, is pretty old), and I can confirm the forge zip includes a copy of it.
Incidentally, it's not necessary to install Forge into the minecraft_server.jar anymore (hasn't been for quite a few Minecraft versions) -- just run java -jar minecraftforge-universal-[blah].zip and it will work as long as it can find the jar in the same directory. Much faster than messing around with the .jar internals.
what about inverting the thing of pads, making a module needed to use the PADS, not the padless transporting?
I... what? Um, could you rephrase that, please, I have no idea what you just said.
As to the recipes: these are a good start, but they're a bit too simple for my taste (and why one per post?), aside from the beacon recipe (which is a fairly simple device).
Consider this: transporters are high-tech devices, therefore crafting them should be a fairly long process, and use several intermediary components (look at the Gravisuit recipes, for instance). I also mentioned (at some point in the past) one of the components for a transporter absolutely needs to be the Heisenberg compensator. I can also think of a transporter buffer component (or two), an advanced machine block and/or an MFSU (did you check the power capacity on the transporter? It should be a full MFSU's worth). At least one HV cable comes automatically with the MFSU in the recipe, and there can be up to four other components I haven't thought of.
The pads can be simpler (they're useless without a transporter nearby) and perhaps use a beacon in the recipe -- part of their job is to act as one. Reinforced metal, like you have, is also a good idea, and perhaps a FreqTrans and an advanced circuit. In fact, that's a pretty good recipe already -- six reinforced metal (the left and right columns) with a beacon in the center, a freq trans over the beacon and an advanced circuit under it.
The interdictor recipe you have is mostly okay -- I'd just replace the middle column with... something? Machine block in the center, I think, and then two other components at the top and bottom. Probably some kind of jammer component (which needs a better name) and a circuit. We do want interdictors to be easier to make than transporters are, it's a balancing factor for the early game.
With all that said, I really appreciate the starting point you just gave me. I'll be poking more at the recipes myself (and I appreciate input from anyone else interested), but this gives me something to build on. Thanks!
Okay, I have some feedback: dafuq? I'd like to give you the benefit of the doubt, but I have a hard time believing you never noticed this forum is for a Minecraft mod; in fact, I'm wondering if you're not actually a spambot in disguise -- except you're not advertising anything and you have good spelling and grammar.
Please, look around -- while it's possible there are a few engineers around who might be able to help you out, does this really seem like the right place to ask?
[...]i strongly advice to check something easy to for begining, like buildcraft (it open source)
IronChests is also an excellent choice for a fairly small mod that does things right.
[...]if you want machines that does stuff instantly, place 16/13/10 overclockers on them (macerator-extractor-compressor/electric furnace/recycler) and pay about 5x more EU per operation.
Or use the accelerator from LiquidUU and pay in UU-matter. It's not like you have any other use for the stuff.
Thank you, and my apologies for the late reply (it slipped my mind, honest).
BMU is currently a lovely toy to have, but I'm not sure it's an all that useful one to have in a regular game session -- I've used it in my serious world a little bit, for moving extra-dimensional barrels and chests around, and for that it's great, but it's really cheaty in that it uses no power for its teleports.
Whenever I end up bouncing back to working on it, the teleport costs will definitely be the next thing to make it in. Transporter pads (as per the mechanics thread) will likely be the next thing after that, especially if I can get some alternate textures for the transporter main block -- the ones it has now fit the pads better. If The_Paragon is still watching, I'd love to have him do that, but he's indicated coming down with a serious case of the real life -- which is okay, because so have I, after all -- however, I will happily accept other people's submissions as long as they're willing to have their work be licensed under CC-BY.
As far as timing, though, no promises. I've only been working on LiquidUU's Liquid Electrolyzer for what, four months now?
I understood fully, and your feedback is appreciated. I have to think, though, that you're talking about making an entirely different mod -- the mechanics for BeamMeUp have been settled to my satisfaction so far, and they are (as intended) reminiscent of Star Trek. Making the pads work as I outlined in my previous post is something that can be done without changing the (already partially implemented) mechanics terribly much. Making them as you would like would require a complete redesign and rebalancing of the mechanics already decided on, as well as make them behave unlike the prototype.
As for the textures, I'm extremely happy with the ones I have right now, thank you very much. This mod integrates with IC2's energy system, it is not intended to be a part of IC2 -- therefore, it should not look as if it were.
I am thinking the recipes could use some of the BC chips (For both machines) in my mind they seem to really fit into the IC2/BC crossoverishness of the two.
That's not a bad idea, and a fair point -- the accelerator, at least, can definitely be explained as "the machine that turns a macerator into an autocrafting table".
[There] should be transport pads, that will be [just a] machine with a [simple] gui [where] you could set a transporter frequency and a pad id. [If] one or more pads with right frequenc are within certain range from an transporter, there could be a command to lock onto them [using their pad id]. [That would] automatically adn no fail get lock on whathever is over it, consuming a bit of extra energy(from the pad). if the pad has no energy or if its out of transporter's range, lock is inpossible in it. what you think?
Purely personally, and don't take this the wrong way, but the lack of capitalization really threw me off yesterday when I was tired. Don't worry too much about it, though -- I (think I) understood what you were saying when I re-read this just now (though please tell me if I misunderstood).
So, these transporter pads are a fairly interesting idea -- they read to me like a combo of linked transporters and beacons. The problem is, I've already designed for and written a bunch of code for linked transporters and beacons, and the pads aren't adding anything (or are they? Let me know if I missed something).
With that said, I do see a different potential idea here: separating the transporter machine (the one that takes commands from a controlling computer, or eventually from the transporter console) and the transporter pad (the block that things have to stand on to be teleported). In brief, I could see using a transporter command block that connects to ComputerCraft, which further connects to transporter pads nearby (~7-block cube) on the same frequency and uses them as the source/destination for the requested transmission/retrieval.
This slightly complicates the simple case of single-pad transporters (target lock coordinates would be relative to the command block, but transport coordinates would be relative to the pad), but allows the fairly Star Trekkish activity of transporting a six-member "away team" at the same time, as long as each one stands on a different transporter pad. Also make for some neat transporter rooms. It would even make the transporter officially a multiblock structure, and we all know how everyone loves those!
and i'm thinking about some crafting recipes too.
Sounds good, I could really use some thoughts on that, particularly intermediary crafting components.
Thank you for the idea, and the interest, and if you have any other thoughts on the matter, please don't hesitate to share them!
For the LE crafting recipe: be sure to throw in gears, cables and electrolyzed water cells.
I'm currently thinking the recipe should include a regular electrolyzer, maybe a circuit or advanced circuit, possibly a waterproof pipe or something of the sort.
Of course! With time, we have nothing to report or conversate about, so you should keep us informed about everything, so we know you're still active and to maybe even help you a bit with the newest things.
That sounds good to me -- I'll go ahead and report progress as it happens. Possibly there won't be a lot of it all that often, but it should at least be interesting to follow along with.
[IC2 1.111] is for 1.4.5, you cant install it on 1.4.7
Indeed. While occasionally there are Minecraft versions that are compatible with each other (e.g. 1.4.6 and 1.4.7), for the most part mods built for a given version of Minecraft will only work with that one. This should be one of the first things on your "that mod isn't working" checklist.
I see you bumped the github version to 0.8. Why didn't you write anything here?
Because it's not ready for release. I just took the time to make the electrolyzer actually read adjacent tanks, but it's still got plenty of needed work (GUI tabs, assignable machine faces, EU in/out, crafting recipe (actually, I think I have a decent idea for that last one), and probably more I can't remember right now).
It's progress, but it's not a release yet, and I'd feel weird having a long line of posts all authored by me, just reporting minor changes along the way to a new release. Edit: Although, if you think I should (maybe to keep up interest?), I wouldn't mind doing so.
needs EU power to keep the food from spoiling.
I thought we already had inventories that kept food from spoiling: all of them.
What I mean is, your request isn't "add something that prevents food from spoiling", but "make it possible for all food to become spoiled over time, and also add something that prevents (or delays) the spoiling". That's ...not cool, bro.
