New Box Droppers
With these new droppers, there are several "dropper" instances (dirty, clean, underground...), each of which takes as a parameter the name of the template. Those templates are in different instances, each of which holds one instance of that cube or whatever and a point_template in a nodraw-box.
So to make a default PTI-like cube dropper, you would place a copy of instances/itemdropper/dropper_clean.vmf, then somewhere in your map a copy of instances/itemdropper/weighted_cube.vmf, then pass @weighted_cubeas the parameter to the dropper. For multiple droppers, you would only neeonee weighted_cube.vmf instance. This would also mke it easy to add, say, Reepblue's repulsion cubes--it only needs one instance, not a dozen or so for various droppers.
It's almost working now. I'll post sample instances when I'm done.
Do you think that this is a good idea?
clarify.
When I read "new droppers" I thought you meant the new dropper instances that came with the PTI and fit into a 128x128x128 block. They are slightly smaller than the common droppers. Only downside seems to be that their model apparently doesn't have the rusty skin for destroyed chambers.
In an instance I made that spawned different types of gel, I used names of relays that enabled or disabled based on the $values you put into the instance.
Gel Dropper instance
This might be handy to look at if you want to spawn custom cubes or by using names instead of numbers.
&
When you make the instance, it has a replace parameter. You give it the name of another instance (holding the cube) which you have elsewhere in your map. Through a bit of magic it spawns the template inside that instance.
I'll upload it shortly.
Right now I only have the various types of normal weighted cubes, and the normal and rusted droppers. I'll add more soon, such as custom cubes and underground and Portal 1 droppers.
&
I don't know, haven't tested them yet.
It's easy to rack up many unneeded or redundant entities in a map nowadays, because those generic instances are, well, generic, and contain a lot of stuff that is not used (coughglobal_ents.vmfcough), or could be shared between multiple instances, like the cube templates.
I already made a set of "whatever-droppers" that drop anything that has a certain name, but sticking the templates for common cases in an instance is even better.
HMW wrote:
I think this is a great idea. It significantly reduces the number of redundant entities.
Sorry, what is a great idea? Bit hard to follow when so many people post :S
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
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.
BenVlodgi wrote:
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
Unfortunately, there doesn't seem to be a 128x128 model with the rusty skin.
FelixGriffin wrote:
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.
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 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.
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.
FelixGriffin wrote:
It could even work with only RunScriptCode inputs, I'll probably do that later.
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.)