[EDIT] Mod is ready for testing. If you want to start bug testing, get the zip file from here: https://github.com/smartguy1196/factorio-bad-chest/archive/master.zip

Hey I forked your repo on Github.

I'm working on "merging" this mod with blueprint signals, so that the deployer can output items required for the active blueprint. (To be clear I'm not talking about "how much iron," I'm talking what is directly in the active blueprint)

The idea is to adopt MoonLogic's concept for turning any entity into a custom combinator.
I am also adopting the usage of a decider-combinator as a base entity instead of a steel-chest, so that I can make use of the LED sprites that are on the larger combinators like the MLC in MoonLogic. I don't have a plan yet for using the LEDs, but I'm sure I can find one.

The steel-chest (deployer-chest) will be replaced with an invisible chest associated with the deployer via uid (unit number) (got this idea from mk-fg, the MoonLogic dev)

Don't worry. The original deployer-chest and it's original functionality will be maintained for compatibility with other mods. This new combinator will simply be added as a new entity called "deployer-combinator."

Anyway, I wanted to reach out to you, so I can work on this mod with you. I absolutely love it. You can contact me via email: smartguy1196@gmail.com

Oh one other thing. If you look at my fork on Github, all of my commit messages are super detailed, so if you want to follow along that way, it shouldn't be too difficult. The branch with changes is named "combinator"

EDIT: Mod is ready for testing

Progress so far:

COMPLETE:
- created new entity -
- gave new entity same "parts" (combinator needs to have an inventory, so I attached it to a chest)
- added output entity and attach it
- added copy-settings ability between different deployer types
- add output code for invisible output combinator

ADDITIONAL PROGRESS:
- added caching (more efficient code)
- added a "pseudo-compiler" (makes working with the code a lot a lot a lot a lot a lot x3000 easier)
--* this is just a nodejs script that concatenates files in a directory together; allows me to separate code into physical blocks of code for easy reading
- add destruction event handling (currently when a deployer-combinator gets destroyed, invisible artifacts get left behind which slows down the game and can break output side circuit networks)

WIP:
- Testing controls and functions

FUTURE:
- add combinator-LED control
- open to suggestions...

FUTURE FUTURE FUTURE (maybe...I'll consider it):
- add more deployers like a suit/vehicle deployer
- add logistic chest functionality

Related Thread: https://mods.factorio.com/mod/recursive-blueprints/discussion/5cc9bf8681d85c000b0f9a18

Mod is ready for test!!! YAY! If anyone wants to run my version of the mod and let me know what kind of whacky errors you get, you can download the zip here:

https://github.com/smartguy1196/factorio-bad-chest/archive/master.zip

I will be running tests throughout the week. I will update this thread when the mod is ready for official release

Would it be possible to keep the deployer functionality separate from the item output functionality by using different entities? This would increase performance when the player needs one but not the other.

For example, a constant combinator that must be built next to a chest (container or logistic-container). Or must be connected to the chest by a wire. This has the added benefit that you can scan a blueprint when it is not in a deployer chest.

Well they are already separate entities in the new mod. The original blueprint deployer chest doesn't have an output. The only feature I added to the base mod is caching of different variables, like the blueprint itself.

The second entity is functionally the same as a combinator merged with a deployer-chest. I personally think that changing it to a combinator that scans for chests in proximity/connected circuit network would slow it down, because I'm pretty sure I'd have to remove the caching. I'd have to remove it, because if the circuit network changed or if a chest was placed in closer proximity or removed, it wouldn't be detected. I'd have to find some clever way to detect those changes near the associated combinator, in order to avoid removing the variable cache.

(ignore this)

if a chest was placed in closer proximity or removed, it wouldn't be detected.

Combinators have a direction. Just scan the single tile it is pointing at during build/destroy events.

Combinators have a direction. Just scan the single tile it is pointing at during build/destroy events.

That could work. I'll add in a third one. Shouldn't be too hard. I'll have that up by this weekend as I am play testing the first new one.

Want to do some play testing tonight, but I gotta get up again in a few hours to go back to my job and get some midnight work that needs to get done.

I am still actively working on getting a mod-testing kit running. I'm also working with make-fg who wants one made for factorio. It's coming along, but I have a job that keeps me away from this. Both the mod and the mod-kit will be done by end of the month at the latest. (I'll be on leave, so I'll have more time at the end of the month to do what I love to do, which is writing up mods)

If anyone is curious about how things are going, here is my work tracker for Factorio:

https://forums.factorio.com/viewtopic.php?f=34&t=93708