Re: [MOD 0.16] Miniloader
Posted: Sat Oct 13, 2018 8:21 am
hide-alt-info also hides filter icon display.eradicator wrote: Sat Oct 13, 2018 8:21 am I requested the "hide-alt-info" flag (api doc) quite some time ago to do just that :p.
Why do you always have to complain about minor details :P.Therax wrote: Sat Oct 13, 2018 8:28 amhide-alt-info also hides filter icon display. :)eradicator wrote: Sat Oct 13, 2018 8:21 am I requested the "hide-alt-info" flag (api doc) quite some time ago to do just that :p.
I'd considered the chest idea, but having another entity on the tile that's a valid inserter target (has an inventory) doesn't work too wel. I actually never considered a constant Combinators, but it sounds like a great idea. I'll have to try it out.eradicator wrote: Sat Oct 13, 2018 8:42 amIf you're already "manually" applying filters to the loader component you could abuse a chest or constant combinator to show the icons.
Even a chest shouldn't be a target if it has no collision box at all.Therax wrote: Sun Oct 14, 2018 6:45 amI'd considered the chest idea, but having another entity on the tile that's a valid inserter target (has an inventory) doesn't work too wel. I actually never considered a constant Combinators, but it sounds like a great idea. I'll have to try it out.eradicator wrote: Sat Oct 13, 2018 8:42 amIf you're already "manually" applying filters to the loader component you could abuse a chest or constant combinator to show the icons.
Sadly, that's not how inserter logic works: I'd also forgotten, constant combinators don't show their output as icons in info mode.eradicator wrote: Sun Oct 14, 2018 7:02 am Even a chest shouldn't be a target if it has no collision box at all.
Who says it's out of my hands?Medium9 wrote: Fri Oct 12, 2018 8:53 pm Ahhh, now I see what you mean. The arrows cover a good bit of the filter icons. Mhhh, that's nasty. If they were juuuust a bit smaller, but I fully understand that this is out of your hands.
Eehrm...wasn't there some weird difference between "no collision" and {0,0,0,0}? Maybe i'm imagining that. With 0.17 you could simply overwrite the pickup/drop target, but you'd have to attempt to detect every inserter placed which is somewhere between insane and impossible on the difficulty scale. (Or make it an indescructible hostile chest :P)Therax wrote: Sun Oct 14, 2018 11:30 pmSadly, that's not how inserter logic works:eradicator wrote: Sun Oct 14, 2018 7:02 am Even a chest shouldn't be a target if it has no collision box at all.
(Probably defaults to off...)Therax wrote: Sun Oct 14, 2018 11:30 pm I'd also forgotten, constant combinators don't show their output as icons in info mode. :?
Pretty sure you're confused with combinators. Inserters don't have a prototype reference to any sort of overlay.Cadde wrote: Mon Oct 15, 2018 1:54 pm But the combinators and inserters have their overlays defined in their prototypes don't they?
Or maybe i am confusing them with the decider combinators "texture" change depending on their mode?
This prototype was made by setting collision_box to nil in the Lua. I think by the time it hits the C++ it's just four 0's.eradicator wrote: Mon Oct 15, 2018 10:43 am Eehrm...wasn't there some weird difference between "no collision" and {0,0,0,0}? Maybe i'm imagining that. With 0.17 you could simply overwrite the pickup/drop target, but you'd have to attempt to detect every inserter placed which is somewhere between insane and impossible on the difficulty scale. (Or make it an indescructible hostile chest)
But filter inserters have a sprite showing their filter. That's why i assume but i haven't bothered to check.Therax wrote: Mon Oct 15, 2018 6:35 pmPretty sure you're confused with combinators. Inserters don't have a prototype reference to any sort of overlay.Cadde wrote: Mon Oct 15, 2018 1:54 pm But the combinators and inserters have their overlays defined in their prototypes don't they?
Or maybe i am confusing them with the decider combinators "texture" change depending on their mode?
Yes, and it's an innate part of the alt-info for a filter-inserter, in the same way that a chest has an innate sprite showing its contents as part of its alt-info. It's not possible (as far as I know) to create a freestanding version of such a sprite, and the arrows and the filter display come together as a unit where filter inserters are concerned.Cadde wrote: Mon Oct 15, 2018 10:38 pm But filter inserters have a sprite showing their filter. That's why i assume but i haven't bothered to check.
You're a mad man! I like itTherax wrote: Mon Oct 15, 2018 1:57 amWho says it's out of my hands?Medium9 wrote: Fri Oct 12, 2018 8:53 pm Ahhh, now I see what you mean. The arrows cover a good bit of the filter icons. Mhhh, that's nasty. If they were juuuust a bit smaller, but I fully understand that this is out of your hands.
https://mods.factorio.com/mod/arrowtweaker
At first glance it looks like there's a bug with loader snapping when a miniloader is adjacent to a diagonal rail track. For now you have a couple of options:npuldon wrote: Mon Oct 22, 2018 9:47 am Got this error in my server log yesterday. Then my server crashed. Any ideas?
[October 21, 2018 9:19 PM] __miniloader__/lualib/util.lua:65: invalid direction passed to rotate_box"
The general principle was to trust people's blueprints and not modify them. Particularly so with snapping since it can be order sensitive and bots build ghosts in unpredictable order. Miniloaders also support some pretty strange use cases (single-belt rebalancing and the old priority splitter setup) which don't necessarily have them aligning with belts in the normal way, so I do snapping only for by-hand placement, and not when robots are filling in blueprints.Optera wrote: Tue Oct 23, 2018 8:57 am Speaking of snapping, is there a reason for miniloaders not snapping according to bot placed belts?