Well, good to know that work hasn't killed you Ken.
I suggest a whip. Not for the mod, for Muse to 'motivate' people who post without reading the new rule.
Actually, a whip sounds like a good idea for a separate mod, or a cattle prod if people want an electrical version.
Don't worry about it. It was an honest mistake.
I do wonder though how Calclavia will handle old MFFS installs... I know Monazit Ore will be replaced by Fortronite in in new worlds and possibly newly generated chunks in worlds migrating to Cal's MFFS. More than likely Cal will reduce the amount of FE/Fortron Energy that Forcicum will produce in the Extractor...
For me, one of the more exciting changes is the ability to store the Fortron as a liquid. Railcraft powered mass storage HERE I COME!
Gregorious, the NPC Villager.
Wears labcoat with big G on it.
Sells Circuits, machine blocks and Automation machines, with super expensive Emerald prices.
Costs multiple stacks of emeralds! Or heck, stacks of emerald blocks!
I'm another one that dislike solars, due its easy place and afk.
Also you can solve generator flickering on/off using redstone gates and such...
I used to be a Solar Placer, I've slowly been weening myself off of them through use of GregTech thanks to that nuts solar recipe (thanks Greg). The only reason I still use Compact Solars and Adv. Solars is in conjunction with Geothermal Generators to act as back-up power for my more intensive operations. I now use Reactors (IC2 Fission & GT's Fusion when I can afford the ignition costs) as my main power source once I can afford them.
Although, now I go back on myself with this, once I can afford it, I usually carry around 1 or 2 HV Solars of Ult. Hybrid Panels to give myself a jumpstart in a new area if I have to move base for whatever reason, then they go back to back-up power sources.
Just to get this straight, ODF basically "forces" mods that implement ingots and dusts that have entries in the ore dict to swap to the 'whitelisted' ingots when certain recipes and/or machines are used (fe. RP's copper nuggets result in IC2 copper ingots if IC2 copper ingots are the 'whitelisted' ingots). Right?
I suppose conflicting mod detection and disabling could be added, but I'd prefer to only add if its really necessary.. I agree, most people will probably not install both mods. If they somehow accidentally install both and get confused with the results, well, that's a corner case probably not worth coding for . Although you actually can use ODF with GT (not to say its a good idea, but maybe there are some cases where it would be useful), I'm testing with it now – to avoid overwrites, the configs can be tweaked appropriately; its really up to the user.
In the case of GT and ODF conflicting when it comes to differing unification targets, wouldn't it be possible that in that corner case, the two mods can communicate and synchronize their unification targets?
And considering the problem I read above about the problem with the RP Alloy Furnace, I know it would be buggy as all hell, but couldn't you override the offending AF recipes? I do realize that it would be considered stepping on Elo's toes, it's either that or talk to someone who is in direct contact with her and they forward the request to her.
This may be a known issue, however, I would like to attempt to report it here anyway.
When MFFS is initialized on my Direwolf20 Pack (FTB) Server, which has been upgraded with the latest forge (188.8.131.524) and XyCraft (0.10.18), but other than that has been untouched.
There is a FileNotFoundException thrown, I believe this is due to either the file being moved, or the wrong address trying to be accessed by the InputStream. The file not being found is the Remote Version Info file.
The Stack Trace:Code
2013-03-11 08:42:58 [SEVERE] [ForgeModLoader] [Modual ForceField System] cannot read remote Version file! java.io.FileNotFoundException: https://raw.github.com/Thunderdark/ModularForceFieldSystem/master/src/minecraft/versioninfo at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source) at java.net.URL.openStream(Unknown Source) at chb.mods.mffs.common.Versioninfo.newestversion(Versioninfo.java:61) at chb.mods.mffs.common.ModularForceFieldSystem.preInit(ModularForceFieldSystem.java:251) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:487) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69) at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45) at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317) at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300) at com.google.common.eventbus.EventBus.post(EventBus.java:268) at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:153) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69) at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45) at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317) at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300) at com.google.common.eventbus.EventBus.post(EventBus.java:268) at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:86) at cpw.mods.fml.common.Loader.loadMods(Loader.java:505) at cpw.mods.fml.server.FMLServerHandler.beginServerLoading(FMLServerHandler.java:86) at cpw.mods.fml.common.FMLCommonHandler.onServerStart(FMLCommonHandler.java:351) at ho.c(DedicatedServer.java:64) at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:458) at fy.run(SourceFile:849)
This shouldn't be a serious error, but I wanted you to be aware of it.
Smart man, you figured out what the error meant instead of whining. Let me explain: MFFS links to Thunderdark's GitHub repo to look up version numbers to find out if there's an update available. Unfortunately, Thunderdark has retired from modding and has, presumably, closed down the MFFS repo leading to the error. For future reference, MFFS is now being developed by Calclavia of the Universal Electricity API, who assures everyone that they will strive to keep IC2 compatibility for use of IC2 EU in the MFFS machines. Link to the page is as follows: http://www.universalelectricity.com/?m=mffs
According to the page, Calclavia is bringing some substantial changes to MFFS when MC 1.5 drops. Most notably is that Forcicum will be deprecated and replaced with Fortron.
or try to assign Buildcraft something else then 4094 and 4095.
Unfortunately that is just as likely to fix Hutchinman's problem as it is to possibly make it worse. But then again, sometimes you have to take the risk.
Question to the OP: What Buildcraft blocks do you have assigned to 4094 & 4095? What you could try is using the tool mIDas (here: http://www.minecraftforum.net/topic/252880-) to change the ID of the offending blocks to free IDs and then go into the buildcraft config and change those entries to whatever you set them to via mIDas.
I know what it is, I've used it before. But I usually avoid IDEs altogether, and Java doesn't really allow for that (if its possible, I can't find out how, because every single google result is on how to do X with an IDE).
There are some devs that go what I call "hardcore" and use a text editor like Notepad++ that has syntax highlighting, Unfortunately, from what I've seen, the 'middle ground' concept doesn't really apply here.
Eclipse is just a powerful Java IDE that a lot of modders tend to use for said power. You can take a look at the Eclipse website to get a better idea.
Hmm. This might be possible to do as an addon afterall now that I look at the IC2 API. Somebody point me at the instructions for integrating APIs into a mod and we'll see if my noobish skills produce anything.
As far as I have seen, the API needs to be present in a folder in the src folder that was the target of MCP's decompilation so "/src/ic2/api" would be the path on a *nix system.
Basically the steps are:
1) Successfully decompile Minecraft via MCP
2) Download the Forge src zip, and follow the instructions that are in a txt file inside the zip
3) Once done, just drop the "ic2" folder into the "/src" folder
4) Fire up Eclipse or whatever IDE or text program you typically use
The Cover-Thing is something I have planned in a diffrent Way. Basically I will make my own Metal-Covers, which can be attached to my Machines to make them blend in nicer with Walls (and to block their Inventory/Tank Sides)
So, effectively a different, but liberally similar system to Thermal Expansion's configurable in/outputs?
Yeah, Immibis' microblocks been mentioned quite a lot of times. Additionally, the microblocks can autodetect blocks to saw.
APasz: Apparently you don't understand. Integrating another mod's feature is really simple nowadays if the mod has an API. All you need is to call the methods needed and include the API afterwards. The only trouble it can cause if the mod's API changes. But I doubt there are any non-prerelease mods out there who have extremely volatile APIs.
I haven't been keeping up with this thread, just figured I would chime in and try to help.
Speaking of APIs, I was digging through the Applied Energistics wiki a while back and found that AlgorithmX2 uses a Buildcraft API interface called "IFacadeTile" or something to that effect (can't find it anymore). If someone could convince the IC2 devs to use this, then there's one solution. If not, I'm sure an add-on dev could figure something out.
If you guys really want facades for cables and don't mind installing two additional mods, you can try Immibis' Microblocks mod: http://www.minecraftforum.net/topic/1001131-
Bear in mind that Immibis Core goes in the mods folder and Immibis Microblocks go in the COREMODS folder. It'll automatically detect IC2 and add support for it's cables. It works, believe me. If I had screenshots, I would post them here.
Oh, as a note, "immibis-microblocks.cfg" allows you to define what the mod supports (it'll automatically support IC2 cables, BC pipes, Thermal Expansion conduits and liquiducts (I believe), and all of Applied Energistics and the "immibis.cfg" allows you to define the microblocks block ID and the saw's item ID.
Hope I helped.
At current moment, I believe that rubber trees at generation time 'looks' at the list of biomes at chooses biomes to spawn in based on the biome name containing "swamp" or "jungle."
If anyone would like I can talk to Scott of EBXL to get confirmation.
Sweet. I'm currently thinking of toying with both BMU and Liquid UU and putting them into my Let's Play loadout. You've done some amazing work so far, keep it up.
Hey, Lost? When you say "any EnergyTile" for chunkloading purposes, would this mod be out-of-the-box compatible with the wires from GregTech, or would that have to be worked on?
For the uninstalling issue, I would recommend talking to Immibis on the Minecraft Forums and finding out how he made Dimensional Anchor blocks just vanish when DA is uninstalled.
I think Chickenbones might be able to help too, but the last version of ChickenChunks I used left a chunk hole where the loader was (AKA the entire 16x16x128 chunk was missing) when I removed ChickenChunks from my install. I have no idea if it's been fixed.