Mod Feedback [By Request] RotaryCraft Suggestions

[rouge_bare]

There is math behind that Mongrel. The formulas needed are generally listed in the Rotarycraft Handbook. I beleive (been a while) minimum operation time is 0.05secs. Plug that in with the minimum torque requirement, and solve the equation.

EDIT: I should point out, some machines work slightly differently, for instance the Friction heater works best with an even amount of speed and torque.

 

[keybounce]

Maximum output? I thought the point of RoC was that you could put a whole nuke plant into any machine and not worry about a maximum output.

(Well, ok, that plus bedrock tools

 

[Pyure]

@Reika I have a question about turbines. I feel like a bit of an opportunity was missed for you to have HP turbines produce (in addition to power) LP steam for smaller turbines. Have you given any consideration for implementing that?

From a coding perspective I don't see any problems, although from a presentational standpoint I have no idea how you'd present steam output in lieu of (or addition to) water droplet output.

 

[Reika]

There is math behind that Mongrel. The formulas needed are generally listed in the Rotarycraft Handbook. Plug that in with the minimum torque requirement, and solve the equation.

You will need an understanding of logarithms.

I beleive (been a while) minimum operation time is 0.05secs.

Maximum output? I thought the point of RoC was that you could put a whole nuke plant into any machine and not worry about a maximum output.

That is because things cannot go faster than a tick, and my machines are not coded to do multiple operations per tick with even higher input values.

....Should I add that?

@Reika I have a question about turbines. I feel like a bit of an opportunity was missed for you to have HP turbines produce (in addition to power) LP steam for smaller turbines. Have you given any consideration for implementing that?

From a coding perspective I don't see any problems, although from a presentational standpoint I have no idea how you'd present steam output in lieu of (or addition to) water droplet output.

It would have to spawn the blocks, which is possible, but then you lose one of the main advantages of the HP turbines - no block updates or associated lag.

Also, from an engineering standpoint, the exhaust of a HP turbine is not LP steam, it is a saturated liquid/vapor mixture with little to no latent energy.

 

[Pyure]

It would have to spawn the blocks, which is possible, but then you lose one of the main advantages of the HP turbines - no block updates or associated lag.

Also, from an engineering standpoint, the exhaust of a HP turbine is not LP steam, it is a saturated liquid/vapor mixture with little to no latent energy.

I need (for the sake of my curiosity) more info.

There's a million of these images, but here's a good local Canadian one. The picture really does imply that the low pressure turbine receives steam from the high pressure variant. This would make no sense if the exhaust possessed insignificant potential energy.

On the other hand if the image is just misleading, then, I get it.

 

[zemerick]

I need (for the sake of my curiosity) more info.

There's a million of these images, but here's a good local Canadian one. The picture really does imply that the low pressure turbine receives steam from the high pressure variant. This would make no sense if the exhaust possessed insignificant potential energy.

On the other hand if the image is just misleading, then, I get it.


View attachment 19525

That's an abstract drawing. The turbine would be 1 single complete unit. Much like the HPTs are built of 7 stages consisting one single complete unit. They're a simpler design than what you see in the drawing, but close enough for MC. Either design would also likely draw enough power out of the steam for it to be of no use. The one in the drawing is just a bit more efficient.

Check out AgentJayZs videos on youtube:
https://www.youtube.com/channel/UCh57rwk3ySElDpzgCDLh9KA

He mostly deals with various jet turbines instead of steam, but you get the idea. Lots of good information in there, and you'll quickly see him mentioning 1 portion as the HP Turbine, and another part as the LP turbine in a single engine.

 

[MongrelVigor]

Maximum output? I thought the point of RoC was that you could put a whole nuke plant into any machine and not worry about a maximum output.

Regretably there are limitations, in fact it seems that I can't force the liquid distillery to make lubricant any faster under any circumstances. Unless I've missed something.

You will need an understanding of logarithms.



That is because things cannot go faster than a tick, and my machines are not coded to do multiple operations per tick with even higher input values.

....Should I add that?

Adding that would be excellent. There's a lot to like about rotarycraft, but the ability to scale up without spamming repeat machines is very high on the list, and makes power acquisition all the more enjoyable.

Please don't leave me in the dark to fidget with every machine until I get a vague idea of it's maximum and how many repeats of it I need , speaking of which, from my experiments it appears it is NOT possible to extend to multiple segments of the HP turbine at maximum diameter, though I think I did that with a normal turbine once, though I never tried to run steam through it.

 

[Reika]

I need (for the sake of my curiosity) more info.

There's a million of these images, but here's a good local Canadian one. The picture really does imply that the low pressure turbine receives steam from the high pressure variant. This would make no sense if the exhaust possessed insignificant potential energy.

On the other hand if the image is just misleading, then, I get it.


View attachment 19525

The HP/LP turbines in ReC are somewhat different, though based on that. The ReC HP turbine is effectively a joint real-world HP/LP turbine combo.

Please don't leave me in the dark to fidget with every machine until I get a vague idea of it's maximum and how many repeats of it I need

No, you do the math.

Possibly useful:

 

[MongrelVigor]

Calling all math genius/ code monkies to make a rotarycraft calculator java app

 

[Pyure]

Calling all math genius/ code monkies to make a rotarycraft calculator java app

The only time...ever...I use logarithms is to provide soft-controlled barriers in gaming designs. (for instance, if you want an RPG character to have theoretically infinite levels but those levels become progressively harder to get)

And every time I do it I have to re-read my highschool textbooks to figure out how to do what I want to do.

I'm....pretty terrible at what I do sometimes.

edit: Oh, and I don't do Java. So I'm not applying for position of calculatory/codemonkey/thing today.

 

[trajing]

That is because things cannot go faster than a tick, and my machines are not coded to do multiple operations per tick with even higher input values.

....Should I add that?

That would be ridiculously fast. Go for it.

 

[zemerick]

Calling all math genius/ code monkies to make a rotarycraft calculator java app

The problem with that is that each machine is different. So, they'd each have to be programmed in, then updated with every change.

However, WAILA will give you the processing time. You can pretty easily create a creative world and just use a creative coil to find the perfect numbers.

Remember though that some things require a balanced load ( such as the friction heater ), and others have variable output for torque. ( Such as the DPA, which requires a certain amount of torque to max the water produced per operation, plus a certain amount of r/s to reach 1 operation per tick. ) So, speed isn't always the only thing that matters.

 

[EyeDeck]

So I saw XCompWiz's LookingGlass announcement from a few days ago.

Perhaps this could be used, at least after it's polished up and made more feature-complete, to fix up RoC's CCTV cameras that haven't worked for ages.

It's being released under the GNU Lesser GPL v3, which would mean you could include it in DragonAPI without licensing issues.

 

[TomeWyrm]

No, the water/ammonia that went into the start of the PROCESS. You're re-collecting it at the end, obviously. But you already have blocks that interface with the end of turbines to prevent lag generated by block updates from the steam, just make one (or a multiblock) that fully collects the ammonia at the end of the turbine, once it's done all the work... heck, just route it into a special pipe that you have to surround with water or LN2 (wait, that would solidify the ammonia, wouldn't it?) or something, and after X many blocks it should all be condensed back into liquid.

Basically my suggestion is to give us a way to recollect our ammonia without having to deal with loose steam blocks or catching drips in reservoirs. I assume that the use of ammonia was not accidental, if we have real-world turbines that run off of ammonia steam, how do THEY recover the ammonia? Water steam nobody probably cares overly about, seeing as how we don't use the water that's actually touched the fuel... unless I totally can't remember how nuclear plants are constructed/run in ELI5 (Explain Like I'm Five) terms.


Re: logarithms and math.

Cheat and use Google/Wolfram Alpha (I can't do logs on paper, and my calculators all suck. Google works great as a calculator!)

I too royally suck at logarithms. I mean I understand what they do on a graph... but I never took the time/effort to learn them properly, and wouldn't have maintained the knowledge anyway. No use for them in my everyday life :-(

 

[keybounce]

That is because things cannot go faster than a tick, and my machines are not coded to do multiple operations per tick with even higher input values.

....Should I add that?

Please. I thought that, for example, the item pumps would pump more than one stack per tick, that the extractor could process more than one item in each stage, that the sprinklers had no upper limit on watering distance, that the wood cutter could cut large sections of jungle down very very rapidly, etc.

Multiple items per tick once you get sufficient power, yes. Or, more likely, some ticks you do one item, some ticks you do two. And as more and more power goes in, more and more of the ticks do two. Until it does three per. Then 4 per. Etc.

 

[Pyure]

Or, more likely, some ticks you do one item, some ticks you do two. And as more and more power goes in, more and more of the ticks do two. Until it does three per. Then 4 per. Etc.

This is actually good design principal. I had a roundup() function in C once that was for precisely this purpose.

If a character had 1.4 attacks per round, he always did 1 attack, with a 40% chance of doing a second attack.

Best if you can pull it off without floating point calculations in a case like this though, seriously :\

 

[TomeWyrm]

Warframe does something very similar. Almost every percentage stat can go past 100% and does something when it gets there. For instance multishot. At 100% it doubles (I think) the number of projectiles fired... on the weapons that use projectiles... You know it's really complicated with lots of exceptions, let's just use a "normal" gun as the example. 100% multishot means 2 bullets. 50% multishot means always 1 bullet and 50% of the time you get 2. 200% multishot means 3 bullets. 150% multishot means always 2 bullets and a 50% chance for one more. 100% crit means every attack will deal double damage, 150% crit means you'll crit all the time, and 50% of those will deal... Triple? It's been a while since I looked at the damage math.

But that kind of scaling makes a lot of sense, so as long as it doesn't kill my game because performance issues? I'm all for it! Letting all the currently scaleable processes keep on scaling would be amazing. I'd love to pump a Tokamak into an extractor and have it process a stack of iron in one tick (assuming it auto-output the products. In reality it would be closer to 1 stack per 5 ticks)

 

[Reika]

Please. I thought that, for example, the item pumps would pump more than one stack per tick, that the extractor could process more than one item in each stage, that the sprinklers had no upper limit on watering distance, that the wood cutter could cut large sections of jungle down very very rapidly, etc.

Done.

It continues the logarithmic trend; for whatever speed sets the per-tick operational time to zero, doubling the speed adds one operation per tick. So, for example, 8 operations per tick needs 2^8=256x the speed of the "threshold". That adds up very quickly.

Supported machines:

• Grinder
• Extractor
• Crystallizer
• Centrifuge
• Refrigerator
• Compactor
• Fermenter
• Obsidian Factory
• Grindstone
• Fractionator

The borer is not supported because of the worldgen lag it would cause (and can easily be stacked in parallel), and the bedrock breaker because as it is 1 operation a tick requires 17GW of power.

 

[TomeWyrm]

Reika, you are awesome.

 

[Someone Else 37]

Done.

It continues the logarithmic trend; for whatever speed sets the per-tick operational time to zero, doubling the speed adds one operation per tick. So, for example, 8 operations per tick needs 2^8=256x the speed of the "threshold". That adds up very quickly.

Supported machines:

• Grinder
• Extractor
• Crystallizer
• Centrifuge
• Refrigerator
• Compactor
• Fermenter
• Obsidian Factory
• Grindstone
• Fractionator

The borer is not supported because of the worldgen lag it would cause (and can easily be stacked in parallel), and the bedrock breaker because as it is 1 operation a tick requires 17GW of power.

Reika, you managed to make the engineer in me really excited to build even faster and more powerful setups, yet simultaneously annoyed because he doesn't know where to stop.

I don't think that's a bad thing.