![]() In any case, if you want guaranteed diversity and don't want to wait whoever-knows-how-long for someone to agree with your issue, write a patch for it, get it merged in and pushed out in a new release, your safest bet as josh said is to use ulog to monitor what is on nearby belts and enable/disable belts accordingly. The discrepancy between regular belts and plastanium could be because they use different code paths to handle bulk-to-bulk transfers. The behavior may change depending on orientation and the order things are created. If that hasn't changed in 6.0, then the reason why one input belt gets "preferred" over the other is simply that the rate at which the junction is checking whether it can move stuff happens to make the offset line up with the same belt most of the time a spot opens up in your current setup. Still a huge improvement over unconfigured unloaders and similar blocks systematically outputting resources in numerical order of resource ID before then. I have read README.md to make sure my idea is not listed under the "A few things you shouldn't suggest" category.įrom what I remember working on my Threshold Unloader fork back in 5.x, the way blocks pick which other block to transfer stuff into is by scanning possible inputs/outputs and offsetting the position it starts checking from with each call to get some degree of rotation going on, some of it being my own patch that got merged in to improve (but not guarantee) output diversity. ![]() I am familiar with all the content already in the game or have glanced at the wiki to make sure my suggestion doesn't exist in the game yet.I have checked the Trello to make sure my suggestion isn't planned or implemented in a development version. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |