This means nothing to me. I don't know what your function represents. More importantly, I think we're discussing two different things.
Mod Feedback [By Request] RotaryCraft Suggestions
- Thread starter Reika
- Start date
Yeah, the ratio has been 520:1 for quite some time now, and nothing in the changelogs leads me to believe that Reika has seen fit to tinker with that since I was last able to play (8ish months ago).
As for the magnetostatics, iirc, the wiki may confirm your math at the top end where they suffer a 50% loss. The lower tier motors actually fair better in terms of conversion efficiency (if not power output), scaling from better to worse as you move up through the tiers.
Aside from the relative difficulty of most RF generators to supply the power needed to run the converters, the efficiency cost has always been a highly motivating reason for me personally not to use them. Reika's in intentions have been pretty clear in that regard for a long time. I wonder if part of that doesn't have somethig to do with magnetostatic's digital interface where people could set torque and speed (has that changed?) without having to think much about gearing?
That beig said, I understand why you would want to use them in the absence of ElC. But at the same time, I've never found power on demand to be much more than a redstone signal away anyway. You're losing (fuel) efficiency in the startup costs and winding down of higher tiered RotC engines or in RF >> shaft power conversion either way. As the former works out to be less, while also keeping my real estate footprint smaller, it was my preferred approach.
As for the magnetostatics, iirc, the wiki may confirm your math at the top end where they suffer a 50% loss. The lower tier motors actually fair better in terms of conversion efficiency (if not power output), scaling from better to worse as you move up through the tiers.
Aside from the relative difficulty of most RF generators to supply the power needed to run the converters, the efficiency cost has always been a highly motivating reason for me personally not to use them. Reika's in intentions have been pretty clear in that regard for a long time. I wonder if part of that doesn't have somethig to do with magnetostatic's digital interface where people could set torque and speed (has that changed?) without having to think much about gearing?
That beig said, I understand why you would want to use them in the absence of ElC. But at the same time, I've never found power on demand to be much more than a redstone signal away anyway. You're losing (fuel) efficiency in the startup costs and winding down of higher tiered RotC engines or in RF >> shaft power conversion either way. As the former works out to be less, while also keeping my real estate footprint smaller, it was my preferred approach.
The one valid utility I see for the magnetostatics is to enable RF as the form of power transport, as can be seen in most of my base tours. Once ReC reactors are used, the RC power model shifts from a dedicated-source-sink model (i.e. one engine cluster per machine cluster) to a central-source model (one generator for all machines). Even with ElC, and certainly without, the logistics of this supply are difficult, as shaft power's long-standing weakness is with long-range and freeform (i.e. bending around walls, corners, et cetera) transport. ElC helps but introduces new challenges in the form of resistors. RF, on the other hand - and for that matter, the other power systems - offer a simple solution to this. However, to prevent people from choosing magnetostatics preferentially, they have been made painfully inefficient - and expensive - for all other use cases.
The conversion rate is a flat ratio - indeed at 520W = 1RF/t - and the efficiency of a magnetostatic is a linear function of its tier.
The code appears to have a power curve (^1.4) as well, but it is currently unused.
Reika: Thanks.
I find ElC to be highly interesting. My major concern with it (other than its being unpopular on my server) isn't resistors. Its that I'm given to understand that a (activated) battery always outputs its maximum amount regardless of demand, and unconsumed power disappears into the aether.
Also: Resistors (ok fine) desperately, desperately needed some sort of coloring tool.
I wrote a premise a couple years ago that contradicted this fact, but i'm told I was flat-out wrong.
I find ElC to be highly interesting. My major concern with it (other than its being unpopular on my server) isn't resistors. Its that I'm given to understand that a (activated) battery always outputs its maximum amount regardless of demand, and unconsumed power disappears into the aether.
Also: Resistors (ok fine) desperately, desperately needed some sort of coloring tool.
I wrote a premise a couple years ago that contradicted this fact, but i'm told I was flat-out wrong.
My information may be out of date. But the last time I tinkered with resistors, you needed to carry cactus, lapis, etc for every bit of coloring you might do. It was pretty horrible.
I'd prefer to have some sort of tool that I could shift-right-click to cycle through all the colors, and right-click on the resistor band to set it to that color. I don't even mind if I have to "load" it with dyes first (255 per color or whatever), I just don't like carrying stacks of dyes around.
We've discussed this before. In 2014. The idea has already been rejected for reasons I don't recall.
I wasn't party to those conversations, but for the sake of argument, did anyone ever suggest a UI from which to choose color bands? I'm thinking something similar to the beveled gears colored in/output selector. I don't know how well Chromaticraft provides for colored dyes, but even with other mods like Botania, harvesting colors can be a real PITA. Botania does have methods of growing dye flowers but even so it still holds players hostage to RNG when looking for the color(s) they want. Vanilla flower farms vary in output by biome and I've been told in the past that my setup was laggy (lol).
That's an interesting idea, assuming it'd be feasible. Open a UI for it and place a dye inside to colour-code the resistor. You'd still have to figure out what the colours actually mean (PROTIP: they're found in real life), but for folks like me that have issues actually targeting the right bloody bands, it would save a lot of time and, barring ChromatiCraft, occasionally hard-to-find dyes, especially cocoa beans.
I hate to be a naysayer here, but I feel like a non-gui interface is explicitly what Reika wants here, and I think its a reasonable design choice. Its even consistent when considered with things like Ender Chests.
Minor aside: ChC's dye trees are fairly uncommon, but not super rare. They come in all sixteen colors, and will give you large amounts of their corresponding Vanilla dyes (and yes, lapis and bonemeal grow on trees in ChC). Also, there are the rainbow trees that are quite rare, but give all sixteen colors of dyes and chroma berries, as well as apples and some other stuff, in large amounts.
Getting lots of dyes is no problem with ChC installed, but using them for things like ElC resistors could certainly be annoying. I like Pyure's idea- something like AE2's painter that can be loaded up with dyes, which can then be cycled through with a right-click.
Reika if I remember correctly, we spent a rather large amount of time on teamspeak a few months ago resolving a bug with Magnetostatics and their power usage, which resulted in them receiving another nerf to their RF input requirements. It's even listed in your changelogs for V12. (RotaryCraft: Changed magnetostatic power curve to fix unintentionally high efficiency; RF costs are now almost 2x higher). I remember creating the excel spreadsheet and messing around with the formulae. I probably still have that file too xD
Edit: I do indeed still have the file.
Edit 2: The values from that file were added to the upgrades page in the RotaryCraft section, found here: http://ftb.gamepedia.com/Upgrades_(RotaryCraft)
Last edited:
Is there a way to make the blast furnace not consume the last stack of an item?
I have a system constantly producing iron, feeding it into the blast furnace, but it produces slower than it's used, so the 9 stacks turns to 8, then 7, etc, all the way down to a single stack, and the item conduits don't seem to want to make a new stack once it's used up. It'll keep that one stack stocked, but won't fill the other 8 now empty slots.
Sent from my SM-G930V using Tapatalk
I have a system constantly producing iron, feeding it into the blast furnace, but it produces slower than it's used, so the 9 stacks turns to 8, then 7, etc, all the way down to a single stack, and the item conduits don't seem to want to make a new stack once it's used up. It'll keep that one stack stocked, but won't fill the other 8 now empty slots.
Sent from my SM-G930V using Tapatalk
Celestialphoenix
Too Much Free Time
Crafting pattern might do it.
Otherwise you'll want to buffer your iron, and run the blast furnace intermittently- or bump up iron production
Otherwise you'll want to buffer your iron, and run the blast furnace intermittently- or bump up iron production
Uhm... not sure if this is the right place to ask, but seeing so many math-works thrown around, I hope it is ^^"
I'm wondering if there is a miscalculation in Rotarycraft concerning the "Engine Control Unit". The manual and every site I find say that 6.25% would make the fuel 4x more efficient.
I tested it with the gasoline-engine and put in 10 ethanol crystals which ended in 10 minutes normal time. With 6.25% it changed to 10 hours 40 minutes, so 640 minutes. Wouldn't that be a 64-times more efficient ratio?
I'm not so good with efficiency-maths so I wonder if I may understand it wrong. Would be nice to know for future plannings when it comes to using the unit.
I'm wondering if there is a miscalculation in Rotarycraft concerning the "Engine Control Unit". The manual and every site I find say that 6.25% would make the fuel 4x more efficient.
I tested it with the gasoline-engine and put in 10 ethanol crystals which ended in 10 minutes normal time. With 6.25% it changed to 10 hours 40 minutes, so 640 minutes. Wouldn't that be a 64-times more efficient ratio?
I'm not so good with efficiency-maths so I wonder if I may understand it wrong. Would be nice to know for future plannings when it comes to using the unit.
Celestialphoenix
Too Much Free Time
Ah thank you!
Totally forgot to calculate that into my thinking, only looked at the fuel-time. ^^"
With these lil mistakes I already see my first reactor blow up once I get to reactorcraft *chuckles*
[edit]
One more question, not sure if there is a bug, or my mind forgets the important thing again:
I'm trying to automate an extractor to shut down the engine when it has no more work to do. So added a comparator and it works fine, when the extractor has nothing to do, the comparator activates.
Now the problem is: even when I put in new items to process the redstone signal just not stops. So I'm wondering to what the extractor reacts to tell the comparator "Okay, I want to do something, turn of the signal"?
Last edited:
Thank you
Though one question to that: For this block update the extractor needs active power?
I tried the comparator-setup not connected to the engine control, so that the extractor kept being powered. Then it works totally fine. Nothing to do -> redstone signal on, put in an ore -> redstone signal stopped. When there is no power - cause the comparator shut it down - it seems to not work.
(sorry if this is a stupid question, but while I understand stuff like block-updates on the surface, the deeper technical details for these things are a book with seven seals for me)
I do not remember how it was implemented.Thank you
Though one question to that: For this block update the extractor needs active power?
I tried the comparator-setup not connected to the engine control, so that the extractor kept being powered. Then it works totally fine. Nothing to do -> redstone signal on, put in an ore -> redstone signal stopped. When there is no power - cause the comparator shut it down - it seems to not work.
(sorry if this is a stupid question, but while I understand stuff like block-updates on the surface, the deeper technical details for these things are a book with seven seals for me)
If you haven't worked out the problem yet, could you maybe provide us with a screenshot of your set up? I can see no reason why you'd need or want to detect any block updates for this or any other machine. I can only think of a handful of places where that's even useful, most of which involve making old school redstone circuits.Thank you
Though one question to that: For this block update the extractor needs active power?
I tried the comparator-setup not connected to the engine control, so that the extractor kept being powered. Then it works totally fine. Nothing to do -> redstone signal on, put in an ore -> redstone signal stopped. When there is no power - cause the comparator shut it down - it seems to not work.
(sorry if this is a stupid question, but while I understand stuff like block-updates on the surface, the deeper technical details for these things are a book with seven seals for me)
I have an idea about what might be going on here, though. On the surface of it, it sounds like you're trying to take the comparator's analogue redstone signal (RSS) output and plug it in directly to your engine control unit (ECU), which is effectively a binary (or digital, if you like) device, being a strictly on/off switch for our purposes here. Of course, this "works" logically, but it's obviously not giving you the results you're expecting. The problem being that the ECU doesn't care about the data being transmitted by the comparator. That is, the "has work" information that the comparator is taking as a reading from the extractor is lost at a logical on/off gate, the ECU.
Remember that the comparator attached to an inventory outputs a positive RSS strength (RSS = 1 ≤ X ≤ 15) when it detects that the inventory contains a given volume (RSS = X, where X is not equal to zero) and outputs no RSS when the inventory is empty. Thus, whether your comparator's output is 1 (the attached inventory almost empty) or 15 (full), they both represent a "true" or "on" state insofar as the ECU, which only accepts discrete binary signals, is concerned. Critically, the ECU turns itself off when it is provided with a positive RSS (of any strength, all effectively RSS "on" signals).
Thus, the simplest solution is to supply an inverted RSS (a simple NOT logic gate) to the ECU and your engines should run continuously while there are items in your extractor's inventory and shut down again when there aren't.
However, in my view at least, this is not very interesting. Yes, it gets the job done. But, remember that comparators output an RSS strength equal to the proportion of an inventory's current volume over its maximum capacity, measured in one fifteenths increments. If you can figure out a way to use that information such that it governs the up and down time of your engines when fixed quantities are reached rather than being merely on or off regardless of volume, larger or small, you can avoid problems where your engines start up and shut down over short intervals (eg: if the input chain in your supply of ore to a grinder or extractor is slower than their output, any case where one or the other is out of sync). To get you started, if you're interested, investigate Minefactory Reloaded's Programmable RedNet Controller block, paying particular attention to the SR-Latch circuit.
I would also caution you against taking your comparator readings off of the internal inventory of the extractor itself, which is comparatively small. Using a larger chest as an input buffer that feeds into the extractor will extend the time that your extractor "has work", ensuring that the duty cycle of your engines lasts longer, thus giving you better fuel economy (less time and energy spent getting the engines up to speed and losing it again when they are shutting down/stopping). More importantly, however, it will help avoid spilling items on the ground. Since it can take a few moments for some engines to wind down to a stop, they're still "doing work" up to a point, even as their RPMs slow, which if their output chests are full can make a (potentially laggy) mess if you're not careful, especially with machines tuned for 1-tick operating speeds. Personally, I use two chests, one to take readings from, the second to feed into the first and serve as an overflow buffer, just in case
Last edited: