The stacker from shapez isn't here. Just "rotate 180 and stack" as well as "rotate 90CW and stack" which only consume items without actually doing anything to them. This isn't how stackers are supposed to work.

Stacker was not included because furnaces can't actually have more than one input item. The pseduostackers rotate one of the same shapez before applying the stacking operation.

It was late in development when I realized I had to actually incorporate the swap box to allow for all shapez to be created.

I could actually add the stacker - it would be forced to be in the same way I implemented the swap box. Having to choose between a 4095^2 is unwieldy - any shape modifying recipe should just happen when you put the inputs together - this means I have to use the furnace prototype.

Stacker was not included because furnaces can't actually have more than one input item. The pseduostackers rotate one of the same shapez before applying the stacking operation.

It was late in development when I realized I had to actually incorporate the swap box to allow for all shapez to be created.

I could actually add the stacker - it would be forced to be in the same way I implemented the swap box. Having to choose between a 4095^2 is unwieldy - any shape modifying recipe should just happen when you put the inputs together - this means I have to use the furnace prototype.

I see, but I can't find any information as to why the furnace prototype can only have 1 or 0 input slots... wouldn't it be feasible to just force only recipes with 2 inputs if the furnace has 2 inputs? (that way, 2 items can uniquely define a recipe for that furnace instead of 1)
The pseduostackers don't actually work, just outputting 1 of the items that went in.

I tried having furnaces with multiple inputs - Factorio gave me the error. It isn't documented, but it happened.
Even if it did, I don't have recipe budget for 4096^2 recipes. Max prototype limit is 16^4 or 8^4 off the top of my head. Would have to be done with the runtime magic - similar to the swap box.

The pseduostackers don't actually work, just outputting 1 of the items that went in.

No it works as intended. Any shape layers that stack are discarded. Try using the one 180 pseudo stacker on a half shape.

I tried having furnaces with multiple inputs - Factorio gave me the error. It isn't documented, but it happened.
Even if it did, I don't have recipe budget for 4096^2 recipes. Max prototype limit is 16^4 or 8^4 off the top of my head. Would have to be done with the runtime magic - similar to the swap box.

The pseduostackers don't actually work, just outputting 1 of the items that went in.

No it works as intended. Any shape layers that stack are discarded. Try using the one 180 pseudo stacker on a half shape.

As for the prototype thing, I asked the factorio community and they said there was no general prototype limit. They also said that the recipe prototype limit was probably around 2^32, which is way higher than 4095^2. Though, I admit that the control scripting option does sound like the better solution.

I ran into the prototype limit in development, and the shapez limit reflects that. Looking back on discord chat, that limit is 65535. It is not possible to have 4 shapes, 1 blank quarter, 8 unique colors.

I forgot where I wrote my calculations, but I only left 5,000-10,000 available prototype slots. I didn't even have enough to recipe budget to have auto paint recipes for all the shapez. (Assuming fluid input works.)

Formula for managing shapez budget is q^4-1 (null shape can be a product, but you can't use in recipes.), where q is the number of unique quarter pieces. q = s*c+1. s is the number of shapez, c is the number of colors, +1 for the empty slot. Remember, I can't eat up all my prototype budget on shapez items, I have to add recipes. Each recipe that performs one operation on a single shape (like rotation) has to be added for each shapez, so it costs q^4 .

Scales up fast, so runtime scripting is a must for complicated operations. While using shapez as items comes with the prototype limit, it comes with the boon of being able to define them as a science, see the item on the belt, and use them normally in recipes.

When I figured out runtime scripting for shapez, I also figured out how to add all possible shapez - but at a significant complexity cost. I would define a new item prototype of type blueprint. It would be a shapez print. Blueprints have editable data at runtime, and that data would be shapez string that could be operated on. All machines would have to function as a swap box - but it might be possible to handle the inventory magic on working machine. However, this method has two downsides - no clue how get the science from shapez print objects, and all shapez would look the same on the belt. Even though I could modify the shapezprint preview. Thus, I decided to stick with shapez lite approach.

Additionally, cache management of entities is not trivial. I used the same method I did on Corrundum, and it cost me a lot of sanity to perfect it. Can't call get entities every tick because of the massive ups cost.