To play the line "oh but it's not realistic to the real world" is a bit naive
I don't know where you saw that, but the IC2 team's motivation for removing CASUC was: "it's far too powerful, nobody was using non-CASUC anymore".
Posts by narc
-
-
Factorization wrath-lamps?
Are fighting uphill, like I said. If memory serves, they make fake light blocks to add more lighting around them. I also seem to recall some bugs tend to result, e.g. the lights not actually disappearing when the wrath lamp is broken.
And I'm not sure about this, but what about using sunlight instead of block light?
Sunlight and block light have the same limits: light level 15. Sunlight is special because it automatically travels down to the floor, dropping light-15 behind it. It's also special because it gets visually reduced to light level 4 at night.
There are ways to fake lighting altogether, including its effect on mob spawning -- FunnyMan3595's Wustendorf does this to entire hunks (not chunks!) of the world at a time, cuboidal regions reaching from the top to the bottom of the world in the affected areas. Makes for an interesting transition, going from light level 15 to 0 in the span of one block. The unfortunate side-effect of that is it completely disables normal lighting in the affected region. So if you set a light level of, say, 0, your torches will not make any light at all inside the box (I don't recall what happens to sunlight, but I think it's unaffected). You can see how this would just not work as a general-purpose solution.
-
I did enjoy the read, thank you, and I imagine one or two of the aspects of things you've mentioned might get stuck in my head and come back around and whack me as "inspiration" later.
If there's one thing I would think most important to bring to your attention, it's the lighting parts -- the way light works in Minecraft, it's literally impossible to have colored lighting or light levels greater than 15, which is the light level inside a glowstone block. Anyone trying to implement anything above that is going to have to fight uphill -- and I won't say they're not going to be able to do it, but it'll certainly be less robust to begin with. That's the one thing I'd consider most important to keep in mind.
-
Aye, sorry, I got a little too roundabout in saying that -- should've just said "That list where?" and left it at that. I'll go have a look and work out some feedback.
Edit: Right, I wish I hadn't promised any feedback. There are a few interesting ideas, as well as several that are just completely impossible. Overall, I'm not sure that any of these things are particularly needed or interesting to play with. This is just my opinion, of course.
-
I thought it was a shotgun with phosphorus shells.
-
"That list", huh? I might've looked at it, but all I have to go on is this "Nate" screen name, and the keywords "mod idea", of which there are thousands. You're not standing out from the crowd any. Hell, you're not even on my radar.
-
There is exactly one thing to fix with the current default mcp_deobfuscate, and that is that it assumes Forge makes a mcp/src/common, which isn't true anymore. I personally get around this by symlinking src/common to src/minecraft, but renaming would also work, since you really only need to compile MCP+Forge once.
The other part of the process that you're missing is setting up the MCPDeobfuscate jar and its dependencies, which live in the master branch of the mcp_deobfuscate repository. Instructions for compiling MCPDeobfuscate are in the README.txt in master. Instructions for hooking it up to the mcp_interface python scripts are in the README.txt in mcp_interface.
This is the second time today I catch you saying "I have no idea what I'm doing and I refuse to even try to figure it out myself", which is kind of sad for an aspiring programmer. Did you get your independence removed, or have you not grown it yet?
Edit: There we go, the README now includes a "Compiling" section.
-
MCP with mcp_deobfuscate interfaced in. I'm doing magic, really.
-
The idea with the battery hulls isn't bad. But filling them with Fuel? Then they wouldn't be batterys but fuel cells. Maybe filling hulls with a hyd. Coal Dust/Redstone Combination.
Or just coal dust. And give RE-batteries the same recipe, except using redstone. Imagine having to make a canning machine to make a generator. It would give you a reason to always have one. Of course, it does beg the question of how to power the canning machine to make a battery to make a generator... good old redstone-as-an-energy-source to the rescue. So you'd have to use two redstone to make a battery to make a generator: one to fill the battery hull, one to power the canning machine for that one operation.
-
Did you try to teleport a block into another block? That's not permitted, as an anti-griefing measure. In future, I'll make the transporter actually drop the block if that happens -- as if broken by hand. Try a retrieve if you're not sure about your target coordinates, it's easier to check that the transporter platform is clear.
-
Indeed, the published mod pack policy makes no claims about the addons -- you'll have to negotiate separately, where needed.
-
The ITankContainer makes it possible to have diffrent Tanks for diffrent Sides of a Block.
And ITankContainer is not the same as ISidedInventory. Thanks, Greg.
-
1) Rename it "Water Electrolizer". It makes more sense.
No, it doesn't. It electrolyzes liquids, therefore liquid electrolyzer.
2) make the front side input EU, back size ouput EU, left side as water input/output, right side as electrolized water input/output, and make it convert water to elctrolized water on redstone off, and the opposite on redstone off. When you get that working, make it switch between redstone control and a GUI button for controlling it's actions.
Or I can do exactly what I already said I'd do and have it use adjacent tanks for water and electric water storage, and have the faces settable using the same method Thermal Expansion uses. Which is what I'm already planning on.
I will try to make some code for you as soon as I see if ISidedInventory works for liquids.
It doesn't, liquids are not an inventory item. On the bright side, I already know what needs doing and how to get there.
BTW, how do you even compile it? It doesn't work for me! Start using the IC2 api, not the source itself!
I just put IC2 in lib-obf/ and ran runtime/deobfuscate_libs.py. It got automatically added to my classpath. mcp_deobfuscate is nice that way.
-
Successfully reproduced! It's NetherOres. As soon as I add it, I get that exact crash. Nothing to do with PetroGen, although for some reason when it's not present, the crash doesn't happen. I'll build myself a custom EE3 and see exactly what's happening there.
Edit: I guessed right: input is somehow null when going into RecipeHelper.addSmeltingRecipe. I really want to know why it takes the presence of both NetherOres and PetroGen to cause it, but the solution is fairly simple and I can make it a pull request. I'll dig a bit further before I do, though.
Edit[2]: Uh, okay, correction: input is fine, input.getItem() is null. I can tell you that it's *trying* to be the NetherOres block ID, but why it would get nulled when PetroGen is present is beyond me. PetroGen doesn't even do anything with smelting, does it?
Edit[3]: That pull request I was talking about earlier.
-
^ What, the big sticky thread in the (locked) Bugs section of the forum not big enough? Here: http://bt.industrial-craft.net/.
I'd've linked the thread, but I have that forum turned off.
Edit: Oh, hey, look what I found stickied in this forum.
-
It's... probably possible, though I'm not sure about components taking up multiple slots -- that sounds like it might get clunky and hit a whole bunch of corner cases in a hurry. Other than that, it would definitely work, but I'm not sure that I see it adding anything to the experience in exchange for losing compatibility with the vanilla crafting mechanic.
To put it another way: what's awesome about it?
-
^ You seem to be deliberately misunderstanding. Here's a ForgeModLoader-server-0.log where EE3 pre1e and PetroGen 1.1 start perfectly together. Sorry about the TreeCapitator spam, it doesn't seem to want to listen to its own config.
Mods list:
If you want any help in figuring out what you're doing wrong, post your own FML server or client log. Cutting it down to just an exception and stack trace does not say enough (except for: EE3 did something stupid).
-
It's not compatible with EE3.
It works well with only this mod and it also works well with only EE3.Cannot reproduce. Works just fine for me using PetroGen 1.1, EE3 pre1e, IC2 1.112, Forge 472, and tons of other mods. Tested both client- and server-side. You've got something else going wrong, man.
-
Word of warning: a bunch of folks around here get crazy when they see "Quantum Suit" and "change" in the same post, particularly when "change" tends to mean "nerf". Don't take too much offense at what they may say.
For myself, I like the idea, as I've liked a couple of similar ideas that have been posted in the past. I have my doubts that it'll be implemented quite this way, though this post from past-Alblaka would suggest he's at least thinking about it.
-
...Okay, yes, it's true the saplings really don't matter -- they function as a sort of clock tick, so that for each 0.8 buckets of source liquid consumed (!!!), you consume a sapling, but they don't affect the amount of output at all. The fermenter also doesn't matter, for the same reason: its function is to modify the amount of source liquid consumed in one step of operation, and how many steps can be done with a single fermenter (fertilizer lasts for 200 cycles, at 56 units of source liquid consumed per cycle = 11,200 millibuckets, like the wiki says).
Which ultimately means the *only* table we care about is the output modifier table: water will turn into biomass at a 1:1 conversion -- for every 1 biomass produced, 1 water will be consumed. Apple juice and liquid honey are consumed at a 2:3 ratio -- for every 2 apple juice consumed, the output will be 3 biomass. Which means you miscounted somewhere, because 14 apple juice makes 21 biomass. It will always make 21 biomass, no matter what organic input or fermenter is used. You will use fewer saplings than any other organic input, and you will produce output faster if you use fertilizer than if you use manure or mulch (14 versus 12 buckets in 250 ticks), but you will use more fertilizer to do so.
Given this information, it's clear that 1 UU should be equal to 8 apple juice, if we want to match 1 UU to 12 biomass, so I've updated the conversion and rationale.
That wiki seriously needs to explain better how all the numbers apply.
