New Box Droppers
from what I've read this doesn't sound like a better idea
the default instance determines what type of cube to drop the exact same way you choose a type of cube... with parameters
there are no redundant entities in that instance, it kills the monster spawners on mapspawn if a different type of cube is desired
the PTI instance is actually the best box spawner I ever seen, very compact and easy to use
if you want to be able to change the type of box dropper it is... like overgrown/destroyed, just copy that instance and change the textures + the skin of the dropper
But what if, say, you wanted Reepblue's gelcube? Or the unfizzleable cube from Blue Portals? Or Skotty's ?rial faith cube? Those aren't included in the PTI instance, so you would need to add even more relays and logic_cases inside to determine which to use. And as those contain multiple entities, the logic would get even worse.
The purpose of these instances is so that custom cubes can be used as well as prop_weighted_cubes and prop_monster_boxes. Even if you use them for normal cube droppers, the instance it reads the properties from doesn't need to know about every different type of cube, so it contains fewer instances than the equivalent PTI instance.
if you want to be able to change the type of box dropper it is... like overgrown/destroyed, just copy that instance and change the textures + the skin of the dropper
Unfortunately, there doesn't seem to be a 128x128 model with the rusty skin.
I dont think you understand how the instance works, the PTI instance is both compact, and optimized... there is not a ton of different cubes, just 2... and if you want instances which have 1 type of cube each, then use the original instances
I understand the PTI instance. This one isn't meant for standard cubes, although it can be used for that (I posted the normal cubes with it as a demo because I don't have many custom cubes yet). It's meant to be useful for a mod which includes several new cubes, or for a mod using many themes (destroyed, old aperture, new), so that only a few instances are required. The PTI one is efficient at what it's meant for: clean style, with the cubes from the original game. But you'd need a new instance for destroyed theme, and one for a custom cube, and one for destroyed theme + custom cube, et cetera. That is what this aims to prevent.
I see, you could add items to the pti dropper, or make an instance with shared dropper stuff then make another instance which has the prop stuff
On second thought, the centralised template approach does not seem such a good idea to me.
I tried to implement it with my custom droppers, but the savings in entity count you get from that is entirely offset by the things you need to add (scripting!) to track which cube belongs to which dropper. Unless you have some horribly complex custom thing that you want to spawn, I don't think this is a worthwhile approach.
For simple custom things, BenVlodgi's idea is probably fine: have one 'generic' dropper instance and include that in another instance that adds all of the specific stuff.
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
I agree with that. I tried to make the script as simple as possible by using parenting to get an info_target to remember the name of its own box, and it should work as long as there's a physics object in each cube, and only one thing needs to be out at a time from a single dropper. It could even work with only RunScriptCode inputs, I'll probably do that later.
I mostly made this for my forcefield cubes, which I might even need two templates for (there are more than sixteen entities per cube). Those are complex enough that it would be more efficient to use a shared template.
But you're right. Although hopefully not requiring as much logic as the PTI dropper, individual templates would suffice for most levels.
Though I must say that your approach of attaching this 'marker' to the spawned box is very clever! It's probably the most efficient way to solve this problem, if you do need to have a centralised template.
Cool, just remember that you can't pass string literals via RunScriptCode. The double quotes will screw up the data structure of your vmf. There are other ways to get that done though. (Creative entity naming + EntityGroup[whatever].GetName() comes to mind.)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic