BluSunrize / ImmersiveEngineering

Wires, transformers, high voltage! Bzzzzt!
Other
783 stars 389 forks source link

[Discussion] Powerconsumption for Conveyors #1668

Closed Deshiba closed 7 years ago

Deshiba commented 7 years ago

I'd like the (configurable) option to have the conveyor belts require RF/T that increases for each connected conveyor belt because:

Is this at all possible?

KnightMiner commented 7 years ago

Most other mods that add item transport pipes do not require a fuel cost. Plus powering every treadmill would be a pain, even if you just do stations.

mindforger commented 7 years ago

okay i am gonna digging my own grave now, watch and enjoy :D

as an idea as i like this too: take a dynamo and craft it with a few additional components to make it a motor, this is then a new multi purpose block

it can be placed adjacent or below a conveyor belt and powers this + all other conveyors adjacent and proper aligned to the one beeing powered, increasing the power consumption for every connected conveyor

also the pump could then become a REAL multiblock, by placing the pumphouse (former crafted pump) and then place a motor on top

same goes for the core sample drill, motor on the bottom + drill block on top

PS: make the conveyor thing optional, it would increase immersion but as KnightMiner already wrote it could get worse

Deshiba commented 7 years ago

Most other mods that add item transport pipes do not require a fuel cost. Plus powering every treadmill would be a pain, even if you just do stations.

There are definitely mods that work in this fashion

ArukaAlter commented 7 years ago

Buildcraft pipes require an engine to extract, not to run. AE cables need energy to maintain the matter<>energy link.

mindforger commented 7 years ago

that is why i pointed out to only make one power source block attached to conveyors powering each connected conveyor, comparable to the AE System

MalkContent commented 7 years ago

Idk. maybe there could be regular conveyors and powered conveyors. A bit like RP2 with the accelerated pipes. The difference being that those only required power on input (and exit? idk, it's been a while) into the accelerated system, not for every segment of the faster version.
That being said, I don't think the current conveyors should be powered. Basically would make them obsolete in the face of other logistics systems. Hell, it probably would be outdone by vanilla carts.

BluSunrize commented 7 years ago

Could have sworn I responded to this. Odd.

It's a fair topic to discuss, I'll say that much. Yes, most mods don't require power to transport items. IE staying with that trend seems sensible also for making it appealing to use. No, IE is quite often aimed to be not like most mods, so this change would help differentiate it from the mainstream tech mods, at the cost of accessibility and appeal.

So let's look at the options. As I see it, we have 4 choices for making conveyors require power. 1) Separate power for each conveyor: Yeah, consider the wiring and that's a nope. 2) A motor per one-directional section: Sure, would be immersive, and the idea of having one motor for a long stretch seems appealing right? Until you get to a tight corner or something to wriggle through, and suddenly you need 6 motors and have to route power to them, see 1. 3) Use a "network" of conveyors powered by a single access block: While a lot more sensible for wiring than 1 and 2. those kinds of networks are a pain in butt to code. I noticed it over and over again with pipes. And the efficiency decreases drastically with the size of the network. It's a maybe, but a tiny one. 4) Use power to move items faster: What sounds like a good idea, speeding up items, is actually not that easy. IE's conveyors use entities, and Minecraft hates fast moving entities. That would backfire terribly. Also, it would require another set of textures, since conveyors are currently coded to move items somewhat in sync to their animation. And I cannot increase animation speed in code.

Now, all of that leads me to go with a "No." for now For the near future, IE will not have power-dependent conveyors. The user appeal is one of my main limiting factors to that. A config to make it opt-in is possible, and the "network" option seems the most accessible atm, but then you have a block that has zero use if you're not opting in.

I will leave this issue open as thread for further discussion.

AEnterprise commented 7 years ago

what about item capacity? without the support of the extra motor the conveyors have only a limited 'push' power to move items around, if there are to much items on the long one-directional section the entire section would stop

corners would not be a problem with this at all, in a tight corner the conveyers would have enough power to move 1 them just around the corner (as they go in another direction, the conveyors would only need support on longer straight lines)

sections going up could have a smaller capacity, downward sections a higher

this way the motor is not required even, if people break up the long conveyer into multiple smaller ones by adding turns they can bypass the requirement (at the cost of needing more conveyers, more space and longer distanse so slower transport)

MalkContent commented 7 years ago

3) Use a "network" of conveyors powered by a single access block: While a lot more sensible for wiring than 1 and 2. those kinds of networks are a pain in butt to code. I noticed it over and over again with pipes. And the efficiency decreases drastically with the size of the network. It's a maybe, but a tiny one.

You could get around doing a real network. Just have a power block that always consumes the same amount as long as it's connected to a conveyor. Then have the "power" propagate through the conveyors like a redstone signal, as an int/byte decreasing with distance. They don't really consume power on their own, they just are powered as long as they have a neighbor with a powerlevel one higher than theirs, eventually ending the chain with the conveyor that's connected to the power block.

This could require multiple of these power blocks per setup, be a neat reason to have the conveyors off the ground and the somewhat stubborn "flatrate" of powerconsumption could lead to people building nifty setups to get the most out of it and feeling accomplished.

mindforger commented 7 years ago

@BluSunrize don't you already have algorithms to check, wether there is an adjacent conveyor with adequat dfacing to remove the border and let it connect visually? can't you use the same code to propagate the power? also this would allow the conveyors from machines to power the attached belts without using an additional motor block ?

EDIT: also i don't get what you mean with the tight corners ... i just wanted to power all belts that fall under your visual connection rule

BluSunrize commented 7 years ago

1) Redstone signals are one of the fucking jankiest systems in the history of Minecraft. They are the worst example on how to handle power. xD 2) @mindforger the algorithms exist yup. They're not great though. These systems get worse for processing the bigger they grow. And for tight corners I meant spiraling upwards for instance. Or going zigzag between already built stuff. That would give you not singledirectional connection and would therefor require one motor per conveyor.

MalkContent commented 7 years ago

well it would only be propagated /like/ redstone, so could do it way unjankier. and it's not like you'd propagate power, it's just a range check.

Runesmacher commented 7 years ago

Coming back on this discusion: I am working on conveyer systems IRL. Our big conveyers are powered by 1 motor, but ofcource the amount of pull a motor can provide is limited. (bigger engines, requiring more power is posssible but there is still a limit)

So my sugestion would be to have different tiers of engines that can run 1,5,10 conveyers or so, making a hard limit on the size of the "network" that would be required.

Corner Conveyers are usualy handled by a motor each, but for simplicity sake i would make these conveyers to use the same mechenic as the straight ones.