Posts by The Stick

    (Going on a resurrecting streak, apparently...)


    So, maybe a key and chest could have a separate variable, akin to the different groves on the key. If one key's value is the same as the chest's, it opens.


    In theory, then, if a keyring is made, then a key could be held in hand and right clicked on an invalid block (that is, not a chest) and the key would be destroyed, and the key's value would go on the keyring. Right clicking an invalid block with the keyring in hand spawns a key with the key value on it, removed from the keyring, produced in First-In-Last-Out order.


    So, the keyring could possibly pose as multiple keys, each with their own value.


    As it appears to me, this addition asks that the chest looks through the player's inventory (or at least hotbar) to see if there's a matching key for it's lock. Then, if a chest hits a keyring instead of a single key, the chest could look through each individual value in the keyring to find a pair.


    That said, with this, it might also be possible to create a key-duplicator machine. The lock would be made first, and it would be dropped in a key-duplicator with a blank key to generate the lock's key. Then the lock is deployed on a chest (using code similar to wrenches removing machines) and the lock is destroyed, putting the value on the chest.


    The key is duplicated as many times as it needs to, and is distributed.

    ...probably resurrecting something here... but.


    I would think of this less as some little add-on that gets placed on an MFE or wire, but more as an implant. Instead of having the transmitter sit on top of the MFE, it would probably make more sense to simply put the transmitter inside the MFE itself.


    In the code, using a transmitter on an MFE would consume the transmitter, and toggle a canTransmit boolean, which allows a FreqTrans (or specialized tool) to copy-paste frequencies onto the receiver, much like the teleporter pairing went. To handle the "multiple transmitters to one receiver" bit, there is two ways I can see it: copy one transmitter freqency and paste to the others, only finishing an operation once it's pasted on a receiver... or copying from the receiver and then continuing to paste it on each transmitter until it's copied from a different receiver. If we're to link up a set of multiple transmitters and receivers, then perhaps copy from one piece and paste on all the other pieces, not copying until the tool is cleared by trying to paste to an invalid piece twice.


    Adding the transmitter to a wire could toggle the same boolean, but it'd require also drawing the antennae...


    And those wire strippers could be used to remove the transmitter, too. If it's used on a canTransmit = true MFE, it spawns a transmitter and toggles canTransmit false. If used on a cable, it'd remove the transmitter before any of the protective shielding.

    I'll admit its grasping at straws, the logic being oil=dead dinosaurs, and dead dinosaurs have bones that could be used for bone meal fertilizer like skeletons. So oil=bone meal? I just read another post that was better for fertilizers, so I would put my support behind that one. Still plenty of uses for oil here.

    ...oil = bones... + time + pressure + heat. Organic matter like bones (and plants) only really became oil after a very long time with a whole lotta pressure, probably more pressure than a measly Compressor can pull off. We're talking centuries... nay, millenniums of being compressed with literally thousands of tons of pressure. I mean, seriously.

    ...primer?


    Eloraam's RedPower mod lets you put cables on walls and ceiling, which makes me wonder if that "place anywhere" code can't be re-purposed to put some kinda primer-object on everything, which can be subsequently painted.


    I mean, currently the Painter just colors an existing item. Would it be easy enough to add another "color" that instead places primer on stuff? Or is it going to have to be a separate item?

    If you had a generator to miner to conveyor to cart setup you could automate with a PLC. Generator powers the miner and conveyor, when an ore block is mined the conveyor activates to transfers it to the conveyor which transports it to the minecart. When the cart is full the power rail is activated sending the cart to wherever you're sending it to. Set up the machinery, program it, and walk away until you hit bedrock.


    Similar set up could be a geo-generator hooked to a miner and lava pool. PLC reads the state of an MFE/MFSU, when the storage unit is full it stops the miner from pumping lava. Use energy from the storage unit and drop to a programmed set point (say half capacity) and the PLC starts the miner up again until the MFE full.

    I find fault in your examples.


    First of all, how do you plan to figure out a Minecart's contents automatically? By dead reckoning, basically guessing when it is full?


    Or even, how do you plan to figure out when an MFE/MFSU is fully charged or even half charged? Neither give any signal output when it's at any level, full or otherwise.


    Even then, there's no real way to STOP a Miner until it's done... not to mention going from surface to bedrock with a Miner doesn't even fill a single line in a chest, rendering the first example pretty much unnecessary anyways.



    On a completely different note, this idea would be very great. It would definitely save on the space (and CPU) you'd otherwise need to create complex Redstone circuitry... however I feel this might be something more for RedPower, since it deals less with Industrial EU and more with Redstone. The actions you describe are the main function of Redstone - basic pulses of nothing more than a signal. EU is electrical power intended more for actually doing stuff, like grinding ore or smelting it down.

    This would actually end up with one more recipe than the current system. As it is, it's 1 recipe per plant > plant clump. With your system, it's 1 recipe per plant clump > plant chunk > plant clump. The only benefit of this system is you can stack it for later processing. But even with the buildcraft system, this leaves you with an extra autocrafter to worry about.


    What (I believe) RawCode is saying is that, to get the entire list of recipes for every possible permutation of plants -> plant clumps (which includes mixing) would require a large number of recipes. Specifically, there are cactus, seeds, reeds, and saplings (the recipe doesn't differentiate between any of the 3...) meaning 4 different materials. That said, you need 8 of a specific plant to make the clump. Hard-coding each of these means 4^8 or 65536 different recipes. Instead, having each one be crafted into this supposed plant "chunk" then into the plant clump means only 5 recipes - one each for the different plant and then the 5th for the actual clump.


    As for the concern for BuildCraft autocrafters, yes, it's another step in the refining process. However, I feel that adding the ability to mix-n-match plants for biofuel otherwise is better in the long run.

    I'm getting serious problems from the wiki. I can't access any of the pages because it says that the Wiki server can't understand my browser's requests.

    Quote

    Bad Request
    Your browser sent a request that this server could not understand.


    Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny13 with Suhosin-Patch Server at localhost Port 80

    Using Chrome v13.0.782.218 and Windows 7 SP1 Home Premium.


    Surely I'm not the ONLY one getting these problems. With this, I cannot access ANY Wiki pages - not the home page, not any individual item page, not even difference or talk pages.

    Have you tried windmills/solars separately?

    On my (much worse) laptop, single-core 1.7GHz, I was lagging out with only two windmills.



    I haven't had any issues with my Wind-tower dropping my FPS as of yet, and it's running approx 45 windmills atm.


    A quick question though, what's your render distance set to? I noted that you said you toggled the quality (assuming Fancy to Fast), but didn't see anything about your fog. Minecraft has issues with it's Far render distance on it's own (creating a recursive Memory loop that eventually crashes the game), and I'm betting IC's added CPU usage (and the like) isn't helping.


    Try setting your fog high (Normal or Below) and see if that helps.

    By "Maximum quality" I meant Fancy, Far, Smooth lighting, Camera bob, Advanced OpenGL, the works. By "minimum quality" I meant Fast, Tiny, Rough lighting, no camera bob, Basic OpenGL, etc.


    It probably wasn't a bright idea to be adding on extra stuff like more windmills or solar collectors after finding it was lagging out my laptop...


    I may or may not be having the same issue, loading up my old world makes my computer want to die. I was getting great fps, now 0. It isn't instant either. It is actually fastest during the initial loading stages, then it gets to something in the distance (likely my water towers or solar farm) and dies.

    Oh, speaking of which, both desktop and laptop are still play-ably fast when loading a world, but it slows to a crawl fairly quickly. And I've always been close to my stuff - it's among the first few chunks loaded.

    Have only tested in SSP v8.00 and v8.10.


    Using 4 Windmills and 5 Solar Collectors was enough to cripple the most powerful computer in my household - a quadcore 3GHz computer. The problem isn't with the memory, however.


    Before (MC 1.6.6, IC v7.20), this computer was running with around 250 fps with maximum quality, with 4 Windmills, 5 Solar Collectors, and 4 Watermills. Luckily, I was in the middle of moving stuff around when MC and IC updated, so all my stuff was in my inventory. I set up the 4 Windmills and a 5-Solar Flower, and, when the day came, the fps plummetted to 0. I switched to as little quality as I could, and I still got 0 fps. In fact, I would even bet, despite the fact that MC only shows integer fps, that it would have been .25 or .125 fps. It was really lagging.


    And this is while Memory was only around 11% of the default 1 GB.


    I didn't know whether to put this as a bug or in support, however, since I had no error log, it's going in Support.