Posts by narc
-
-
Wow, so Forestry is considered 'cheating' now?
Anything is "cheating" to someone. Minecraft is exceptionally open to being played in many different ways; the only strangeness I tend to notice is when someone thinks their way is the only way and goodness-forbid one should ever think of doing it any other way. Usually, I laugh a lot when someone suggests that.
-
That doesnt happen in IC2. There is no researching or leveling up needed, only resources
That also doesn't happen in vanilla Minecraft. This has always been one of the things I *LIKE* about Minecraft. I'm also on the same page as LostCoder regarding Thaumcraft research -- the cheat sheet version of the Thaumonomicon exists for me to use.
Other than that, enjoy your game your way; if you like having to "research" something before being able to use it, more power to you -- unless you intend to change my game, which I don't think you want to.
-
Quote
No mod directory found, creating one: C:\Users\Alastor\AppData\Roaming\.minecraft\mods
Might be the wrong FML log? This one says you have no mods installed at all.
Edit: Oh, and I just remembered: use a pastebin for long text people only need to look at once or twice.
-
It has a hamster running on a wheel inside, whether you electrocute it or smash it, it still runs in fear. XD Which is of course connected to a dynamo so you still get the same speed whether you use MJ or EU.
I can live with that.
[...]I think it's doable, but you'll need thaumcraft-like determination of UU cost, which would really be too much.[...]
Nah, it's fine, we only care about chasing things up the IC2 machine processing trees anyway (well, that and vanilla crafting/smelting). My only (minor) concern is for items whose cost can be only partially determined for whatever reason, but we can just fall back to an expensive default, like I said earlier.
-
^ Well, I just tried it. I'm glad they don't just teleport cleanly, but the duplication is kind of irritating. Guess I need to check if the setBlockAndMetadataWithNotify actually worked, which is irritating because I'm clearing the source blocks *after* I create the destination blocks. I think. I actually don't remember, it's been a while.
The fact that the source blocks turn into unbreakable ones is even more irritating (and strange). I guess the moral of the story is: don't do it, unless you have a way to destroy unbreakable blocks (like going into Creative).
-
Oh? I didn't really check, darn.
-
The crafting system, basically, takes a textual representation of your recipe (for instance, a 3x2 recipe could be 'aab', 'cdd') and an explanation of what each character in the recipe is (for instance {'a', Item.apple, 'b', Item.redstoneTorch, etc}). This is what Greg was trying to explain earlier with the examples, and you'll note his examples follow the rule.
The boolean that shows up in the middle (in our examples, it's always false) allows you to specify a shapeless recipe.
-
For an attempt at trolling, the most you seem to have managed to do is make a few of us laugh. 'Sall good.
-
In my current world I have a chainsaw named "Butcher". I also had the good fortune to find a couple of Fortune I enchanted books, so I have an enchanted diamond drill which I rather uncreatively named "Lucky".
I'm similarly uncreative about naming my RP2 canvas bags -- I've had, in succession, "The Black Bag", "The White Bag", and currently "The Blue Bag".
-
Well i think combustion engines need a bit of love, even with the buffed fuel/oil values they basically suck for energy production (Use a boiler). A thought came to me and im not sure if it would be possible, but IF you use electrolyzed water as a combustion engines coolant you get a better cooling process but also an accelerated higher output.
That really would be interesting, but unfortunately there's no support for it -- nobody ever thought the coolant might affect fuel efficiency in an iron engine.
Forestry already provides a good conversion method (Lossy but configurable) as well as a Fuel>EU generator
Im hoping you choose a way that feels a bit unique to the other conversion mods.Forestry makes excellent progress towards merging the two power systems, but once you've generated MJs, even if you have Thermal Expansion to store them, you can't get them out as EUs again; likewise, I agree that simple conversion has been done several times over, with varying success, and I want to find a method that feels at least different.
I don't actually care that much about generating MJs myself -- as you said, the Forestry electric engine is just fine for that -- but using them to produce EUs would make me quite happy: since I've started using Thermal Expansion heavily, I often find myself having a pneumatic energy system long before I have an electric one, and I'd like to be able to convert my excess MJs into something useful without consuming anything other than the MJs themselves. Efficiency may be exceptionally low (5 MJ for 2 EU sounds fine -- the coal-based equivalence is inverse: 2 MJ for 5 EU), and the transformation chain itself may be complex, but if it can ultimately be a closed system, that's about ideal for me.
For this reason I'm leaning towards making the liquid electrolyzer accept MJs as an alternative energy source, without being able to supply MJ out; if powered this way, the LE would be forced into its input-only state (i.e. only electrolyze, never the reverse; no getting EUs out of the same block that accepts MJs), which should work nicely when paired with a liquid transport system and another electrolyzer set to the opposite state (only de-lectrolyze). The only real problem I have with this is how to explain it logically from an in-game perspective: why does the electrolyzer work on MJs? Does it have its own internal generator that can be powered directly by a pneumatic engine, or something? Is this its normal modus operandi, and when powered by EUs it's actually shortcutting part of its internal mechanisms?
-
I think BC Energy is kinetic/pneumatic[...]
Yes, so I mentioned. Opinion otherwise noted and will be considered.
Suggestion:
Advanced acclerating Liquid UU-Matter Assembly Thingy-A highly advanced combination of Crafting Table, capable of using the inbuilt acclerator and the inbuild crafting table to assemble UuM at millitary precission.[...]That's on my todo list only as far as making measured amounts of things that can already be made directly out of UU -- chasing things down the crafting tree is a good refinement and really would make it stand out, so I very much like the idea. The problem I have with it is selecting what gets made... which just struck me as being solvable by the "item duplicator" idea that's also on my todo list. To summarize: when determining costs, if it's possible to track down UU costs of components through the crafting trees, do so and make the cost the sum total of all the raw materials and other operations. Otherwise, just pick "really expensive" as a default and allow overrides.
Any thoughts on the EU/MJ thing mentioned above?
-
^ Nah, they're just being polite.
-
Hmm. I note an odd possible bug: if injectEnergy is called with an amount < 4 while you have less than 10,000 EU stored, you return a negative number. I have no idea what the EnergyNet does when you do that, but it might be what's causing your issue here. Here, check my mental steps for injectEnergy(Direction.YN, 3):
Code
Display Moreif (directionFrom.equals(Direction.YN)) { // true if (Energy >= 10000) { // false this.Energy = 10000; return amount; } else { // we take this path: int left = amount - 4; // left = 3 - 4 = -1 Energy += (amount > 4) ? 4 : amount; // Energy += 3 if (Energy > 10000) { // false left += Energy - 10000; Energy = 10000; } return left; // return -1 } } return amount;Again, I'm not sure if this is the problem, but otherwise it seems to do what you seem to want it to (which is to accept only 4 EU at a time, no matter how much was actually sent to you, until you have a buffer of 10,000 EU exactly).
Swapping the return for
Codereturn ((left < 0) ? 0 : left)should do the job.
-
[...]But the post is very weird!
1. just very cold. --- OK so far
2. too hot to touch. --- You just said it's cold!
3. but as lava goes. --- WTOMG?!?!
4. Ice cool. --- EVERYONE KNOW ICE IS COOL!!!No, that's an accepted English idiom: Minecraft lava is cold compared to real-life lava. "Ice-cold" is a common descriptive expression, I'm not sure what you're confused by.
But, to sort of return to the topic at hand, Vilim here had an exceptionally interesting idea: using electrolyzed water as an intermediary for MJ<->EU conversions. If you think that sounds at all interesting, I urge you to give the Github issue (linked earlier) a read, but to save time I'll copy/paste part of my thoughts on the matter (the part I'm currently leaning towards):
QuoteI'm slightly wary of the internal logic of Buildcraft power -- it's supposed to be pneumatic/kinetic rather than electric; this is why it's generated by engines and not generators. The electrolyzer, on the other hand, is by definition electric.
On the other hand, I could certainly see an engine run off electrolyzed water[...]. Railcraft steam engines and boilers, [for instance,] should find it easier to break down the charged water, leading to an increase in the steam output when boiling it.
Of course, consuming electrolyzed water in an engine does nothing for the reverse transition (MJ to EU), and I'm not sure what logical machine would convert water into charged water using kinetic energy. [But if we] rename the LE to "Agitator" and just let it accept both MJ and EU, [we can] pair this with burning electrolyzed water in an engine and you can have two-way conversion in any direction, as long as you're willing to make [electrolyzed water] as an intermediate step: use MJs to power an agitator and transfer the electric water to another agitator that outputs EU; or use EUs to power an agitator and burn the electric water in an engine to make MJs.
I'd very much appreciate as many views on the subject as possible -- this could be very interesting and fun to play with, and the more possibilities you can show me, the bigger my pool of choices for the eventual implementation (whenever that comes around).
-
I think you mis-linked there. I'll take a look at it if you fix the link, though.
-
One cubic meter. That's the size of most things in Minecraft. And steve can carry stacks of 64 of these things. If steve wasn't superman, how would he carry 64 cubic meters of iron like it's nothing, while also being able to hold 35 more stacks of 64 cubic meters of iron. And a cubic meter of iron weighs 7,874 kg.
Or, there is one very different explanation on why Steve is so strong. He is actually from the Monster Hunter series World, and is thus exactly as strong as he needs to be.
Yeah, Steve is really superman! He can carry around 44 500 tons of gold in his backpack and belt(hotbar)! Actually... STEVE=Super Trans-Evolved Versatile Explorer(of Minecraftia)! It makes sense!
Both of these make sense, and are hilarious to boot!
So, there you have it: 1 mB = 1L (more or less). Also, buckets are enormous. -
The Buildcraft repository has moved to BuildCraft/BuildCraft. I haven't had any issues with github myself, but I only check when I'm actively using it. Which I have, the last couple of days, but not today. Still, seems fine currently.
-
Why are you stuffing a mods folder mod into the jar? Why? This is just wrong. Mods folder mods in mods, coremods in coremods, only jar mods in the jar.
To amplify this, the only jar mods you're likely to be using are Forge and Optifine (and they go in the jar in that order). Everything else should be left to the Forge Mod Loader to load out of coremods and mods.
-
No, you need the entire old world copied over to the new one. IC2_map.cfg does nothing, by itself -- it's just a marker for IC2 to look at and say "so, when this world was created, this is what the values for my block and item IDs were". FML has its own implementation of basically the same thing (it came later, if you're wondering why there are two implementations of the same thing), except FML also checks when you connect to a server -- so if block IDs don't match between client and server, it'll know not to let you on, to prevent crashes and exploding rubber trees*.
What you need to do is have the old config/IC2.cfg on both your server and client(s) and also re-copy your old server world to the new one (as previously mentioned, the new one was rewritten to delete all IC2 blocks when you first successfully loaded up the world on the server). Doing it this way will keep the exact same block and item IDs that were on the server before, both in the config and in the world itself. IC2 hasn't actually changed its default block ID allocation at all -- but its default block IDs are under 256, and Forge is currently unwilling to allow that as a default; it will only allow it if the config file says so.
If, for some reason, you want to update the world, there is a script called mIDas, which can load up the world and change the old block IDs to the new ones, as long as you can tell it what to change to what. To my thinking, and for my own personal needs, that's an unreasonable amount of work for something that can be as easily settled by just reusing the old configs. On the other hand, if you're trying to gain compatibility with a fresh install (one that will not have had the old config installed), this is an option.
* -- I had this happen to me back before Better Than Wolves broke compatibility with Forge (possibly even before Forge existed): my client had BTW flour mills on the block ID that the server had rubber tree leaves. The flour mill block had a default behaviour of emitting random explosion sounds once in a while. Therefore... exploding rubber trees.
