Anuken / Mindustry

The automation tower defense RTS
https://mindustrygame.github.io
GNU General Public License v3.0
22.55k stars 2.95k forks source link

The implementation of #45 isn't the most ideal. #47

Closed skybldev closed 6 years ago

skybldev commented 6 years ago

First off, let me just say that I don't mean to be rude, but I couldn't find any other word that correctly and accurately describes my feelings towards the merging of #45.

There are 2 very obvious reasons.

  1. It wastes time and resources. I literally have to make a filter out of splitters just to regulate the input to my Smelters and Crucibles. Even then, literally every minute or two the Smelter/Crucible clogs the heck up. I have to march right back down there and replace the block, wasting a lot of resources and time. This is obviously just sucks. I mean..."let's make the crucible/smelter not accept any items until you replace it"... you must be kidding me right?

  2. It makes production of [resource] slower. This is a result of the clogs I mentioned earlier. You're gonna have to constantly go to and from the block replacing it frequently to get the speed you want.

If you think I'm wrong, then keep it. But just so you know, It would be really good if you just rolled that back and not include it in the next release. Thank you.

polak-jan commented 6 years ago

The implementation certainly isn't ideal. How else would you solve it though?

Tener commented 6 years ago

I guess I'm doing something differently because I don't have to replace a thing. No permanent clogging anywhere. Can you share your setup? I can see how using a single belt instead of two might be an issue. Anyway using routers which are omnidirectional is also a way to solve this.

On Tue, Jan 2, 2018, 20:54 Jan Polák notifications@github.com wrote:

The implementation certainly isn't ideal. How else would you solve it though?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Anuken/Mindustry/issues/47#issuecomment-354860046, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJr-OcjGL8IvkjKdP7_Ig5ISqsbHbniks5tGolYgaJpZM4RRAUX .

polak-jan commented 6 years ago

image Yep, works just fine ...

Tener commented 6 years ago

Now that looks buggy, the green bar should not be that long...

On Tue, Jan 2, 2018, 21:05 Jan Polák notifications@github.com wrote:

[image: image] https://user-images.githubusercontent.com/11616898/34498159-a3b1481a-f000-11e7-8802-94b3437e985b.png Yep, works just fine ...

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Anuken/Mindustry/issues/47#issuecomment-354862593, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJr-NXMm8S8EjMJJDOgDp17p7IMS_isks5tGowLgaJpZM4RRAUX .

Tener commented 6 years ago

@BeefEX green bar issue fixed as of merged PR #49.

skybldev commented 6 years ago

@Tener I would normally have one conveyor with all items flowing in for compactness. I don't see why that has to be avoided.

image

(game version after eed70fe)

skybldev commented 6 years ago

I see now. You have to use one line for one type of item instead of one for all items in resource input. Acceptable but still makes things less compact and more complicated.

Tener commented 6 years ago

Try experimenting with routers. Assuming you handle overflow items you should be able to have just one line (in total, versus two in your design on the top of this thread) plus a single sorter somewhere.

On Thu, Jan 4, 2018, 16:07 Luxray5474 notifications@github.com wrote:

I see now. You have to use one line for one type of item instead of one for all items in resource input. Acceptable but still makes things less compact and more complicated.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Anuken/Mindustry/issues/47#issuecomment-355305959, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJr-HTz5TxDSdKtTJelgEDAsQWROdyaks5tHOlJgaJpZM4RRAUX .

skybldev commented 6 years ago

90%+ efficiency and workload image

image

image

Too much work for one smelter, so i put two image

Anuken commented 6 years ago

Just tried this out for the first time with a friend in multiplayer, and I have to say I don't like it at all. The way buffers work is confusing unless someone has explained it to you: often, the smelter would clog up for seemingly no reason, when the real problem was with one of the input buffers being full of iron/coal.

There's two problems, currently: One, the capacity bar above smelters is misleading, as the smelter can be clogged without having a full capacity bar. This doesn't match how other blocks (like extractors) work, where a full capacity bar means it's full of one type of input items. Two, I feel like the system is un-intuitive and difficult to maintain, especially for new players (and older ones like Luxray who are used to a one-conveyor system).

Here's the 'fixes' I came up with: To begin, stop displaying the output buffer and pool together both input buffers, so a "clogged smelter" is always one with a full capacity bar. Perhaps even create a display where each input resource is displayed by color on the smelter.

Then, implement one of these two options:

  1. Make extra unbalanced items be automatically discarded, with a particle effect to indicate that the smelter is doing so. That is, if you have 20 coal and 1 iron enters the smelter, 1 coal will be thrown away. This seems like a hacky method, and probably is not the best choice.
  2. Change how smelters (and crucibles?) work altogether. Instead of requiring 1 coal + 1 iron to make one steel, have coal be used as fuel for the smelter, where one coal will increase the "burn time" of the smelter, just like it works in a coal generator. In this system, one coal could be used to smelt more than one unit of iron if set up correctly. Also, a maximum throughput speed could be put on the smelter, to increase building more of them.

The latter system, I think, is better in two ways: One, it solves half the problem with clogging, as there will always be more coal needed (as fuel is consumed regardless of iron contents), therefore a surplus of coal on your conveyor belt will always eventually get processed. Two, it makes more sense. While it's still completely unrealistic, burning the coal to make steel seems more reasonable than just mashing a chunk of coal and iron together. It's also more intuitive: the idea of separating conveyors for fuel and input comes more naturally than separating conveyors for two different inputs.

What do you guys think?

skybldev commented 6 years ago

I agree with you on the second one. It seems more reasonable and you don't have to modulate the coal collection that much. It also works well if you spawn in a map with not so much coal, if you have WAY more iron than you do coal, or you want to have a whole giant supply of steel constantly.

skybldev commented 6 years ago

Smelter rework is in place right now. Closing.