Mod Feedback [By Request] RotaryCraft Suggestions

[Pyure]

??

Help me identify loopholes in this?

When water hits the hydro (written in pseudo-BASIC)
1) do we need to update?
2) if yes, "trace" back to this water's source block (otherwise goto 7)
3) calculate "force": check adjacent blocks for water source blocks
4) Replace the block with a Reika-block to prevent any infinite-source-creation or water-placement-automation
5) Apply force to hydro. It will determine how long this source "fuels" the hydro
6) set "do not update" flag on hydro
7) deplete some duration on the hydro
8) if duration = zero on hydro, remove "do not update" flag on hydro

I'm not sure how well the reika-block would work. If its a quasi-water, it might prevent other qualifying water sources from flowing down into the hydro where they should.

Edit: Don't think you can do 4) when I suggest it and still have water flowing to the hydro.

 

[Reika]

Help me identify loopholes in this?

When water hits the hydro (written in pseudo-BASIC)
1) do we need to update?
2) if yes, "trace" back to this water's source block (otherwise goto 7)
3) calculate "force": check adjacent blocks for water source blocks
4) Replace the block with a Reika-block to prevent any infinite-source-creation or water-placement-automation
5) Apply force to hydro. It will determine how long this source "fuels" the hydro
6) set "do not update" flag on hydro
7) deplete some duration on the hydro
8) if duration = zero on hydro, remove "do not update" flag on hydro

I'm not sure how well the reika-block would work. If its a quasi-water, it might prevent other qualifying water sources from flowing down into the hydro where they should.

Edit: Don't think you can do 4) when I suggest it and still have water flowing to the hydro.

I doubt this is compatible with the current algorithm, and do not see a way to meaningfully implement it.

 

[keybounce]

Don't make that your endgoal... At least make it a gas turbine...

Lack of time to learn RoC well enough to make quest lines.

One month is really short.

 

[Pyure]

I doubt this is compatible with the current algorithm, and do not see a way to meaningfully implement it.

Actually I don't really see any change required to the current algorithm (this would all be additional work)

I just can't see a way to implement 4) properly, and I have no idea how well 2) works (tracing back to the source block of a given flowing water block)

 

[Reika]

Actually I don't really see any change required to the current algorithm (this would all be additional work)

I just can't see a way to implement 4) properly, and I have no idea how well 2) works (tracing back to the source block of a given flowing water block)

The engine is already capable of finding the source block at the top of the column.

the problem is that it already requires a source block at the top of the column; there is no reliable and performant way to find the source of horizontal flowing water.

 

[Pyure]

The engine is already capable of finding the source block at the top of the column.

the problem is that it already requires a source block at the top of the column; there is no reliable and performant way to find the source of horizontal flowing water.

agreed

 

[Demosthenex]

I would like to find some way to bar just making a waterfall. Any ideas?

I was suggesting that instead of using a water column in the environment that you instead have water piped through your liquid pipes which already support consumption and pressure. Attach this to the reservoir blocks you've already coded, and you have water storage, pressure, and consumption.

I think the key question is would the pressure be height dependent flowing through your pipes?

This also may lead to a way to store power, pump water uphill to the reservoir, and then let it come back down the pipe and power hydros. Otherwise you still have to fill the reservoir somehow. ;]

 

[Reika]

I was suggesting that instead of using a water column in the environment that you instead have water piped through your liquid pipes which already support consumption and pressure. Attach this to the reservoir blocks you've already coded, and you have water storage, pressure, and consumption.

I think the key question is would the pressure be height dependent flowing through your pipes?

This also may lead to a way to store power, pump water uphill to the reservoir, and then let it come back down the pipe and power hydros. Otherwise you still have to fill the reservoir somehow. ;]

In my pipes, pressure is a function of liquid content.

You also have violated the first and second laws of thermodynamics if you want to make pumping water in yield more energy than the pumping took.

 

[Pyure]

I was suggesting that instead of using a water column in the environment that you instead have water piped through your liquid pipes which already support consumption and pressure. Attach this to the reservoir blocks you've already coded, and you have water storage, pressure, and consumption.

I think the key question is would the pressure be height dependent flowing through your pipes?

This also may lead to a way to store power, pump water uphill to the reservoir, and then let it come back down the pipe and power hydros. Otherwise you still have to fill the reservoir somehow. ;]

Perpetual motion machines for everyone! I for one see no issue whatsoever with this (teasing)

 

[Demosthenex]

In my pipes, pressure is a function of liquid content.

Ok, but the hydro could just as easily count your pipe blocks up to the reservoir just like it follows the water now. You also have more control over it that way.

You also have violated the first and second laws of thermodynamics if you want to make pumping water in yield more energy than the pumping took.

We store power that way IRL today. I didn't say it was lossless or 100% efficient. If the solar weather cycle isn't replacing the water you have to pump it. ;]

 

[Reika]

Ok, but the hydro could just as easily count your pipe blocks up to the reservoir just like it follows the water now. You also have more control over it that way.

You also have a lot more lag.

 

[Demosthenex]

You also have violated the first and second laws of thermodynamics if you want to make pumping water in yield more energy than the pumping took.

I could also argue that not consuming water and using MC water physics completely breaks the same laws. ;][DOUBLEPOST=1405959235][/DOUBLEPOST]

You also have a lot more lag.

TileEntityHydroEngine.java, function getRequirements, lines 74-77 you call isLiquidAColumn which traces the move water up looking for height. How's that any different than counting vertically how many of your pipes you have?

 

[trajing]

A solution for @Demosthenex's idea would be rainwater catchers! This would also make people not use water wheels all the time unless they have a weather changer of one sort or another set up.

 

[Demosthenex]

Help me identify loopholes in this?

When water hits the hydro (written in pseudo-BASIC)
1) do we need to update?
2) if yes, "trace" back to this water's source block (otherwise goto 7)
3) calculate "force": check adjacent blocks for water source blocks
4) Replace the block with a Reika-block to prevent any infinite-source-creation or water-placement-automation
5) Apply force to hydro. It will determine how long this source "fuels" the hydro
6) set "do not update" flag on hydro
7) deplete some duration on the hydro
8) if duration = zero on hydro, remove "do not update" flag on hydro

I'm not sure how well the reika-block would work. If its a quasi-water, it might prevent other qualifying water sources from flowing down into the hydro where they should.

Edit: Don't think you can do 4) when I suggest it and still have water flowing to the hydro.

On IRC we were discussing something similar to this algorithm, where you trace the water up and then have to find the effective volume of the water area (pool, lake?) to determine the flow rate or pressure. Unfortunately that is very intense for an algorithm. How often should it happen? Should it store the outcome? What if it's an ocean? That's why I was suggesting Reika's pipes and reservoirs, those already have capacity and pressure coded in versus having to recursively survey the world.[DOUBLEPOST=1405959581][/DOUBLEPOST]

A solution for @Demosthenex's idea would be rainwater catchers! This would also make people not use water wheels all the time unless they have a weather changer of one sort or another set up.

I think the key here is the concept of consuming water instead of the assumption of infinite flow.

 

[Pyure]

On IRC we were discussing something similar to this algorithm, where you trace the water up and then have to find the effective volume of the water area (pool, lake?) to determine the flow rate or pressure. Unfortunately that is very intense for an algorithm. How often should it happen? Should it store the outcome? What if it's an ocean? That's why I was suggesting Reika's pipes and reservoirs, those already have capacity and pressure coded in versus having to recursively survey the world.[DOUBLEPOST=1405959581][/DOUBLEPOST]

I think the key here is the concept of consuming water instead of the assumption of infinite flow.

Neat, fun discussion.

The point with my idea was that you didn't need to run the algo very often at all. Once the source-block was identified and processed, the programmer only has to decide how long that source-block provides power for. The rest of the iteration is skipped until the power provided by that source-block (which has already been added to the hydro) is exhausted.

But as Reika pointed out, actually narrowing down the sourceblock itself is tricky. I'm picturing a scenario where you have a hole in the ground, and in each cardinal direction from that hole, you have a single sourceblock (with no source block actually above the hole itself)

looking down from above:

_W_
WHW
_W_

Is it even possible to trace up 60 blocks to that (H)ole and determine which of those (W)ater source blocks is your specific source block? Does flowing water contain that info? I haven't the faintest idea.

More than just about anything in MC, water is a major pain in the ass.

 

[Demosthenex]

Neat, fun discussion.

The point with my idea was that you didn't need to run the algo very often at all. Once the source-block was identified and processed, the programmer only has to decide how long that source-block provides power for. The rest of the iteration is skipped until the power provided by that source-block (which has already been added to the hydro) is exhausted.

But as Reika pointed out, actually narrowing down the sourceblock itself is tricky. I'm picturing a scenario where you have a hole in the ground, and in each cardinal direction from that hole, you have a single sourceblock (with no source block actually above the hole itself)

looking down from above:

_W_
WHW
_W_

Is it even possible to trace up 60 blocks to that (H)ole and determine which of those (W)ater source blocks is your specific source block? Does flowing water contain that info? I haven't the faintest idea.

More than just about anything in MC, water is a major pain in the ass.

Reikas' function traces the columns of water to measure how high the falling water is for validation on placement (isLiquidAColumn). Then in the power generation he checks for the height of the column by iteratively tracing that column up until it encounters a non-water block (findWaterSurface). This has no consideration of source blocks or not, just whether it's water and when it ends.

To your point you can't assign a parent to a source block. I think you could code it to say that when you find the top of the water, remove one random water source block in an 5 block radius from the column (non-contiguous for simplicity) and generate your power based on a flow rate of 1 square meter of water for that second.. If the water eventually runs out, fine.

On the other hand I keep advocating using Reika's pipes and reservoirs because there is great difficulty in measuring water in the world. Measuring water in a pipe is a simple function call.

 

[Reika]

Reikas' function traces the columns of water to measure how high the falling water is for validation on placement (isLiquidAColumn). Then in the power generation he checks for the height of the column by iteratively tracing that column up until it encounters a non-water block (findWaterSurface). This has no consideration of source blocks or not, just whether it's water and when it ends.

To your point you can't assign a parent to a source block. I think you could code it to say that when you find the top of the water, remove one random water source block in an 5 block radius from the column (non-contiguous for simplicity) and generate your power based on a flow rate of 1 square meter of water for that second.. If the water eventually runs out, fine.

On the other hand I keep advocating using Reika's pipes and reservoirs because there is great difficulty in measuring water in the world. Measuring water in a pipe is a simple function call.

I want to keep it using in-world water, but I would like it if it somehow required a large "reservoir" of water at altitude. So you could use the side of a mountain, for example, as a functionally infinite source, but you could not use a simple bucket fall. That way, you would be forced to either find natural terrain or tolerate building a massive structure to use the engine.

 

[madnewmy]

Lack of time to learn RoC well enough to make quest lines.

One month is really short.

Want some help? You can get me in private message or you might want to check the official wiki page on RoC

 

[Demosthenex]

I want to keep it using in-world water, but I would like it if it somehow required a large "reservoir" of water at altitude. So you could use the side of a mountain, for example, as a functionally infinite source, but you could not use a simple bucket fall. That way, you would be forced to either find natural terrain or tolerate building a massive structure to use the engine.

So to limit the complexity of the algorithm, how about the flow rate for your equation be determined by the surface area (not total volume) at the water's surface at the top of the column?

You already trace the top of the water column. Use that as a starting point for findNearBlocks with a range of 10, though that would not be limited to the surface and give you more an idea of volume but your function is already written. It also would have a centered bias which might be a concern using the edge of a more natural formation than a hole in the center of a bowl. The flow rate could be a ratio against the count of water source blocks.

 

[Pyure]

I want to keep it using in-world water, but I would like it if it somehow required a large "reservoir" of water at altitude. So you could use the side of a mountain, for example, as a functionally infinite source, but you could not use a simple bucket fall. That way, you would be forced to either find natural terrain or tolerate building a massive structure to use the engine.

fwiw, monitoring the size of the reservoir would have the same performance issues noted above (and solving the problem would solve it in both places)