...or you could've just copied IC2.cfg from the 1.3.2 install to the new one. Too late now -- when Minecraft loads a world with block IDs it doesn't know what to do with, it deletes them to prevent itself from crashing. The IC2_map is there for your protection against this exact circumstance.
[...]And you're telling me that long-range light is impossible? Luminators as of now are 100% USELESS. We need them to have more use. I SUPPORT THIS SUGGESTION.
I'm pretty sure nobody ever said long-range light was impossible, just that it would have to use magic tricks -- and I'm fairly certain your two examples use exactly those magic tricks that were brought up in the very first reply to this thread. As for your other point, I agree fully: luminators are currently useless, and we need them to be useful -- this suggestion is a good way to make them so.
I have to admit, that our mods are more in-dev compared to IC2. That is because we have only been around for 7 months while IC2 was around for 2 years I think.[...]
Here's a question: how coordinated is development in the UE mod-set? IC2 has (reasonable) consistency primarily because it was all designed centrally, whereas my impression of UE development is that most people just pick something they'd like to do and do it. There's nothing wrong with this approach, but it does mean it'll take some extra time for both devs and players to decide on what the best features are and how they should look.
The way all the UE mods use the same network is appealing too. If all the mods that use electricity (IC2, UE, RP, etc.) could use the same network, life would be easier for the user. But I know this probably will never happen, mostly due to pride of the mod authors.
Honestly, I'd say it's mostly because of inertia -- going back into something like Buildcraft and redesigning the energy system would take a fair amount of time and effort (look at Thermal Expansion's solution to the matter: implement their own energy conduits; I'm willing to bet that was not a rapid undertaking) and introduce a fair amount of new bugs that would need to be ironed out.
To be fair, Buildcraft may be a poor example, because the energy sent through BC power pipes is meant to be pneumatic energy rather than electric; I'm willing to accept that kinetically agitating redstone in a TE energy conductor or cell will charge it up with energy that can be released as from a flywheel, but not that watts and joules have any sense in there. Redpower would be a much better choice for the UE API, but I suspect Eloraam simply isn't interested: her energy network is something she likes tinkering with and I get the impression she's at least trained as an electrical engineer -- she's not likely to give up the joy of writing her own, and I honestly wouldn't want to ask her, either; I rather like what I've seen so far and wish to see it realized to its full potential.
UE is still young, and it's not being developed as one unique mod but as many interconnected ones. It's normal for quality to vary in these circumstances, but it'll improve, given enough time. The basic API is probably well-made, though I can't say anything for certain as I haven't looked at it myself.
As for "copying", that's a joke -- "inspired by" is the most you can say.
Guys, ease up -- I think he was aiming for the "Orbital Anarchy" thread and missed.
Actually, I'm not entirely clear what your measuring unit is -- Minecraft liquids are measured in millibuckets*, and I've defined one piece of UUM as one bucket's worth. 30 mB is exceptionally cheap (a macerator acceleration costs more than that), whereas 30 buckets is huge (tanks tend to store 16 buckets per block, for a sort of comparison).
Of course, we don't have to consume all 30 buckets at once... huh. I vaguely recall having a similar discussion at some point in the past, about a machine that would consume a liquid gradually and maintain progress even if the liquid supply was a bit slow. I think it was a kind of liquid UU carpenter, and probably around page... 5? of this thread. And you know, these two ideas do go together quite nicely.
* - a millibucket might theoretically be 1L if you follow this logic: 1 bucket takes or places 1 m3 of liquid, therefore 1 millibucket (literally, 1/1000th of a bucket) is 1 dm3, or 1 liter. The problem with this logic is 1 m3 of water kind of weighs a ton (literally, 1,000 kg), which really doesn't sound right at all.
So, duplication of any item using liquid UU? Yes, I very much approve of the idea! The previous suggestion along the same lines would have limited it to things that can be made normally with UUM (thus making it very easy to give them a reasonable cost), but we already have the solid UUM to do this with, and it didn't really have a hook -- I have it in my issue tracker as "needs refinement".
Now, duplicating literally anything seems to me even trickier to balance -- what should be the cost of duplicating Nether Stars, for instance (the highest-rarity thing I can think of)? Having to get two of them to begin with is an excellent start, and might be enough all by itself, but having a unique duplication cost seems to me like it'll be either greatly over-powered or severely under-powered.
There's a kind of middle road I can think of, which is to try to derive the cost of an item by what it's made of, if we can trace that as far back as things that are already made of UUM -- and this is probably the best method for determining costs -- but that's going to be a lot of work and is contingent on being able to follow things through non-vanilla crafting systems (e.g. assembly table, carpenter, magma crucible). That includes tracing liquids used in crafting, where appropriate. Sisyphean work, if you ask me.
The simplest thing I can think of, which is not ideal, but is at least interesting, would be to have a base duplication cost, and a way to override it for specific items (perhaps by passing a multiplier). I can then publish some API for the override (most likely a simple IMC event) and have anyone who wants poke at that. Theoretically, I can also make a configuration section or file where players could define an item and its price override, but that has its own set of problems, mostly of presentation.
You can't spawn it pre-charged because the stored energy is remembered in NBT, and /give doesn't know how to initialize the NBT tags. Spawn it as :27 and it should look as uncharged as it actually is.
Warning, there is an item loss bug in the current version of LiquidUU (and possibly in earlier ones, as well) -- it shows up if you use the hotbar keyboard shortcuts to try to feed the accelerator's UUM slot. The details of the bug are available on github.
For now, I strongly recommend that you do not touch the number keys while your mouse is pointing at the accelerator's UUM slot -- use Shift-click or pipes to put UUM into the accelerator or take stuff out of it instead.
^ I imagine one would use lossless mode and recharge the wrench after each operation. Also, I really like that acronym.
Should that be "Reactor active output [...]" for 20 seconds rather than 2 seconds in the OP?
Okay, that stack trace got me looking in exactly the right place: there's no Item.getCreativeTab() on the server... though there is a setCreativeTab. I... just don't even. Easily fixed, thankfully, now that I know what the problem is.
Go ahead and grab v0.7.12b from the OP or the download page -- my tests suggest it should work properly.
As for the Extra Bees thing, that's a purely custom error message -- I'd have to look at the mod's source to tell you what it was trying to do and not managing. It might be related, but only in as much as it might also be trying to do something client-side on the server-side (but considering what the error says it was trying to do, it seems unlikely).
Hm, okay, I wasn't sure, that's why I said "looks like". Maybe something else is misdownloaded or poorly installed? The error you're getting is Java complaining that one of the files it's trying to load up and use has been tampered with in some way -- might even be as simple as forgetting to delete META-INF from the minecraft.jar, to be honest -- I don't remember what error message you get when that happens.
Either way, there are several of us who have IC2 1.112 (both official beta and dev builds) running on Minecraft 1.4.7, so there's nothing broken there. Report back if you get it working, and good luck!
For now I'm dumping the extra empty cells down a void pipe, but yeah it does strike me as something that you'd want to clear up for obvious reasons.
Indeed! The TE API itself is a little sparse as far as removing or replacing recipes, but I've found a suitable workaround, thankfully.
Extra bees runs the latest API, IC2Crops doesnt use the API, no idea about thaumicbees
ThaumicBees doesn't have anything bad in it, either. I appreciate the assist, by the way, I really couldn't have tested them before today.
So, bad news: I couldn't reproduce the Forestry squeezer/bottler errors at all. Every time I loaded up Minecraft, it just worked -- no complaints. It's at least marginally possible that 0.7.12 will fix it, but if it keeps happening, Vandalite, I'd appreciate if you could turn on debug.override in LiquidUU.cfg and get me the stack trace that will be printed when the Forestry integration fails to load. Debug mode is a little chatty, so you might want to turn it off afterwards, but if you get me that stack trace I can maybe do better than guessing. Maybe.
I also have some bad news for anyone who plays on servers that include LiquidUU: v0.7.12 really won't work with v0.7.11. I made changes to how machine faces are drawn, and trying to make the two work together could lead to a crash (or at least some visual glitching) and I don't think you want that any more than I do.
On the bright side, the TE Liquid Transposer is actually working correctly again. As I said above, I found a reasonable workaround to keep things loading in mostly the same order, but still allow me to register the correct recipes before TE adds its automatic ones.
And if you'll allow me a kind of side-note, I want to explicitly mention that when I mention versions of Forge, IC2, etc., I'm only specifying what I built the package with (which is also usually what I tested with). I don't actually have the time to test older versions myself, which is why I don't specify minimum versions of anything from the mod itself, either -- it's entirely up to you guys to try it and let me know if a certain older version refuses to work. With that said, I can at least mention that I tried v0.7.12 with Minecraft 1.4.6 and Forge 489 with no crashes before the main menu. So please don't be scared if you see "Forge 499, IC2 1.112.192-lf" next to the download link when you're nowhere near those versions -- it might still work.
So, to finally come to a conclusion: v0.7.12 is out. It doesn't really like v0.7.11 and will refuse to work with it, but it does fix the Thermal Expansion bug and might even fix other bugs for all I know. Pick it up from the OP, as always, and thank you for playing with LiquidUU (and for the bug reports; bug reports are great)!
P.S.: Before I forget again, everyone give a big "thank you" to Zerrens for giving us some Liquid Electrolyzer front textures -- they fit the IC2 theme wonderfully and look quite excellent, in my opinion.
^ Looks like a bad download of one of the LWJGL jars, nothing to do with IC2 at all. Or even Forge.
I really rather like the idea of an access list. As a workaround if you really want something soon, I think the MFFS secure storage would do what you need when linked to a security station with the right people's ID cards in it (Industrial Miner also mentioned this earlier in the thread, but did not name the mod).
For storage expansion, it would be nice if an array of personal safes would act as one large one (perhaps the UI could let you page through them?).
Thank you kindly, I'll see if I can reproduce the issues and give you more information about them, but will still have a new version up regardless. If I don't manage to reproduce them myself, I'll need you to test it for me.
As a pure and utter guess from your list of mods, it's possible (if somewhat unlikely) that either ExtraBees, IC2Crops, or ThaumicBees are shipping with an outdated version of the Forestry API -- this could cause the issue you've been seeing with LiquidUU recipes not initializing correctly.
I'm also concerned about the Thermal Expansion integration -- LiquidUU is not complaining about loading its integration, yet it apparently didn't have the desired effect. I don't imagine TE is broken, so I must be doing something wrong.
Thanks again for the reports, I'll track down everything I can and let you know any facts I discover -- the above is pure speculation.
Don't mind RawCode, he has great difficulty being polite, as I'm sure you've noticed. I rather expect the creative/NEI depleted cells are meant to spawn that way to make it easier to test something, but I'm fairly certain if you give yourself a uranium ingot and eight cells and craft them together, you should get normal depleted cells. Give that a try, it may help.
(also please do note the OP of this thread specifies explicitly that bug reports for this build should go on the bug tracker)
Hmm... Vandalite, could I trouble you to pastebin your server log, at least the part where it lists all installed mods and versions? I'll want to try to reproduce your issue and it'll help to see them all listed in one place (I'm particularly interested in the Forge version, but you never know if someone else is being troublesome).
Using the latest LiquidUU (0.7.11b) with The currently available Forestry version (126.96.36.199) isn't working properly. LiquidUU is not properly registering the squeezer (and bottler) recipies. I found this in our server log:
2013-01-18 00:08:29 [INFO] [STDOUT] LiquidUU: Loading Forestry integration...
2013-01-18 00:08:29 [INFO] [STDOUT] LiquidUU: Did not load Forestry integration: java.lang.reflect.InvocationTargetException
Also, using the thermal expansion liquid transposer to convert UU to liquid form generates empty cells! This is probably not expected. I'm using Thermal Expansion 2.1.7
That indeed is not expected, it sounds like I need to update the APIs I'm linking against. Check back here later today or tomorrow for v0.7.12, and thank you for the report!
Hmm im not having the forestry issues, I dont use TE so cant comment on that.
Might just be that you're using a Forestry from before an API change -- I'm currently linking against 188.8.131.52, so I need to update anyway.