I have a map 99.9% finished, which is created in hammer by using 2 maps from PeTI originally loaded as Prefab. I have item_droppers in the PeTI area and in the hammer chambers - but there is one item_dropper in a hammer chamber, which spawned two(!) cubes instead of just one.
I had used the PeTI instancce item_dropper with a standard cube. Replaced that one meanwhile with an underground dirty cube dropper, but i still get two cubes spawned at that location. Adjusting the weighted cube func to standard only is no option, because i have sphere droppers, too.

Any idea what may cause that one of many cube droppers to drop two cubes instead of one?

The problem with one of the default cube droppers is that the cube has a name starting with @; this gives problems with other cubes. The best way to avoid this is using the instances that have _multiple in their names; instead of your normal one that should do the trick!

That fixed it for that dropper. Never the less i would like to understand why PeTI can use the same instance (item_dropper) many times but it's causing issues if placed manually in Hammer. I guess, that PeTI is modifying a relay in on placement, which is not modified if placed manually. Does anybody know how PeTI is able to use as many item_droppers as requested without multiplication of spawning cubes?

Another common cause for this type of problem is if you have multiple dropper instances with the same fix-up name. For example, if you copied one of the PTI droppers to the Hammer part of your map and didn't update the fix-up name to something unique.

(The puzzle maker always gives each instance a unique name, so this problem doesn't occur there.)

if you have multiple droppers, they will all need differant names so the paths are not crossed or else they mess with eachother. Here is an example i have been going with

Entity_maker1 - point_template1 - box1
Entity_maker2 - Point_template2 - box2

of course what the names are is your choice entirely. Also the entity maker is completely optional as you can even tell a template to forcespawn.

Effectively you can make multitudes of an object in-question react in unison. If you name a dozen cubes each differantly and tell cube number 1 to fizzle, only that cube will fizzle. If you name all twelve cubes the same and tell a cube to fizzle, they will all burst into fizzle bits.

@Fracture;
that is only the case if you actually use outputs to kill specific cubes.
(For example; Ontrigger; cube1; dissolve)
Normal fizzlers will only fizzle the cube that activated. Making a gazillion different instances with a gazillion different cubes is a bad idea.

The problem with the normal cube dropper is that the cube_dropper_box has the output onfizzled; @cube_dropper_autorespawn; trigger.

That causes to fizzle all the cubes; and spawning new ones

Lpfreaky90 wrote:
@Fracture;
that is only the case if you actually use outputs to kill specific cubes.
(For example; Ontrigger; cube1; dissolve)
Normal fizzlers will only fizzle the cube that activated. Making a gazillion different instances with a gazillion different cubes is a bad idea.

The problem with the normal cube dropper is that the cube_dropper_box has the output onfizzled; @cube_dropper_autorespawn; trigger.

That causes to fizzle all the cubes; and spawning new ones

I was actually making a general example of what can happen under improper naming of entities, it was not by any means a viable method of making a test. And I hope to God no-one goes and makes a gajillion cube-droppers. No way I would even contimplate doing that test