What the point is instances ?
I know what instances are and how they work but was is the point in them, i find them so confusing to use. I find it easier to set up a cube_dropper as a prop_dynamic and add logic_relay and/or logic_autos. Today i thought i would attempt to create a paint_dropper instance was having no luck it took me about 5 min to put the paint_dropper into the ceiling and get it to stop and start on trigger (prop_button), but where i tried using the paint_dropper instance with the prop_floor_button i was having no luck at all took me about 20 minutes before i gave up for some help. I will tell you what i put into my button and paint_dropper, and could you tell me where i was going wrong also what are the pros and cons of using an instance other a prop_dynamic or prop_static?
Prop_Floor_Button
OnPressed - paint_dropper - instance:paint_dropper;Start
OnUnPressed - paint_dropper - instance:paint_dropper;Stop
Paint-dropper
$Trigger_to_start: Start
$trigger_to-stop: Stop
Oh one last thing i am using a rotating_panel one side has funnel and one side has metal. On trigger the panel rotates and shows the funnel however, this aint working i have partned the funnel to the panel with a 2 second delay to start on trigger but, yet again it does not work could you help me please
It depends on how well the instance is put together, and if you know how to use it. If both is good, then it makes mapmaking a whole ton faster, and can allow you to work a lot easier with it.
I normally use the included door and light instances, because it is no point making your own, if it is there for you, unless your door is used for anything other than... Well, being a door.
I am not an expert on instances, and i wont try to be one. I am sure there are some better uses for instances, but that is how i see them.
Instances are one of the best additions to the Source engine in the past few years.
In the old system of prefabs, lets say you have a door with a button to activate it. You add it to your map. It works fine.
You then add another of the same prefab. You now need to edit the second door and button so it's I/O's and names are unique to referencing each other and not the original door.
Instances don't require any editing. You can put 1000 of these in and you won't need to do ANY editing.
Instances are just a way of reproducing similar prefabs, without having to rename them individually yourself. They also act like a subroutine for programming where all instances of the same file will be changed if you edit the instance. The values created by the proxy's can also be changed for your purpose.
I'm not too fond of them myself because valve likes to stuff entities in every nook and crannie, making the map laggier. However they do make some things a whole lot easier, especially if you want consistency in design.
I'm not too fond of them myself because valve likes to stuff entities in every nook and crannie, making the map laggier. However they do make some things a whole lot easier, especially if you want consistency in design.
Thanks for all of the replies, think i will stick with my normal way i will only ever use instances for elevators maybe lights
It looks like you didn't create a fix-up name.
Basically, your instance has the .vmf name (like cube_dropper, or paint_bomb, etc.) and the fix-up name, which you assign to it in the object properties. From then on, anything which interacts with that instance must refer to it by it's fix-up name and nothing else.
So in your case, let's say button_01 is your prop_floor_button, and your paint_dropper instance is given the fix-up name paint_01, then:
button_01
OnPressed -> paint_01 -> instance:paint_dropper;Start
OnUnPressed -> paint_01 -> instance:paint_dropper;Stop
and that should do it.
Instances were very confusing to me at fist, and many times I still just build what I need, but there is no doubt that they make mapping easier for me. Things especially take off when you create your own instances.
Keep trying to mess around with them until you are comfortable with how they work, they really can save you hours of time when your map includes "complicated" elements like crushers, moving panels/platforms, and the like. Hell, they even have an instance which includes all the env_fog_controller settings, and all you need to do is pick the one you like and call to it with a logic_auto.
You then add another of the same prefab. You now need to edit the second door and button so it's I/O's and names are unique to referencing each other and not the original door.
(...)
A well-made prefab will create unique names on insertion.
http://developer.valvesoftware.com/wiki ... fab_tokens
There are many good properties of instances, but a big problem imo is that they can abstract away too much sometimes.
If you created an instance that requires input (paint dropper for example) you should add a func_instance_io_proxy. This is just a relay that can receive input from out side of the instance. For example, in your paint dropper instance, you could have a relay to turn the paint on (paint_on_relay) and a relay to turn the paint off (paint_off_relay).
You would then add the func_instance_io_proxy and give it outputs like such:
(onproxyrelay, paint_on_relay, trigger, 0.00) and
(onproxyrelay, paint_off_relay, trigger, 0.00).
Now when you put your instance in your map, you can trigger the paint dropper to turn on or off via a trigger or button by setting its output to:
(onpressed, "nameofpaintdropperinstance", instance:paint_off_relay;trigger, 0.00).
The cool thing about doing it this way, when setting up your outputs, the "Via this input" should auto-populate with the io_proxy settings of the instance.
I have an examplehttp://forums.thinking.withportals.com/downloads.php?view=detail&df_id=649 up on the Portal 2 extra files section with all the I/O of a coop checkpoint. there are actually 3 separate instances inside of the whole thing. The entrance door is the base instance, the exit door is just the entrance door instance with the exit logic/signage added. Instancing is actually a very useful time saver.
You would then add the func_instance_io_proxy and give it outputs like such:
(onproxyrelay, paint_on_relay, trigger, 0.00) and
(onproxyrelay, paint_off_relay, trigger, 0.00).
Now when you put your instance in your map, you can trigger the paint dropper to turn on or off via a trigger or button by setting its output to:
(onpressed, "nameofpaintdropperinstance", instance:paint_off_relay;trigger, 0.00).
The cool thing about doing it this way, when setting up your outputs, the "Via this input" should auto-populate with the io_proxy settings of the instance.
I have an examplehttp://forums.thinking.withportals.com/downloads.php?view=detail&df_id=649 up on the Portal 2 extra files section with all the I/O of a coop checkpoint. there are actually 3 separate instances inside of the whole thing. The entrance door is the base instance, the exit door is just the entrance door instance with the exit logic/signage added. Instancing is actually a very useful time saver.
However, the paint_droper already has a func_instance_io_proxy it would be pointless adding another one ? the instance i am using is th one from valve in SDK content