What the point is instances ?
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
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.
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.
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.
chickenmobile wrote:
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.
Thanks for all of the replies, think i will stick with my normal way i will only ever use instances for elevators maybe lights
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.
Enraged wrote:
(...)
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.
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.
Marlovious wrote:
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.
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
Enraged wrote:
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.
wrong, no need to edit the second door and button with prefabs. But actually with an instance you need to edit the second button to reference to the second door, and the second door too (even if only the prefix)...
Prefabs are still better than instances.
In MY opinion:
Instances:
Instances are like includes in Php. Only useful if you add lot of similar thing into a map or other maps, and you want to modify the included thing, for example adding a light or changing the brightness of a light instnce or changing a custom sound etc in an instanced door. You only need to modify the instance and recompile the map (and the other maps if needed). Or when using rotated instances. You can insert an instance rotated, but if needed, you modify the original instance normally and there is no need to mess with vertex manipulation or rotate everything back like you must do with prefabs. Ah, and maybe because of the directory structure, its more organized. Thats all.
But if I think back, I never used instances just so I can modify them later or never rotated them for example 45 degree.
I usually end up collapsing inserted instances, because for example stock observation rooms dont have a door or have few objects, and I either just add them in the instance (I mean not by editing it, I just put them inside) or I collapse them.
Its pretty hard sometimes to control them and they cant be customized unless edited. proxies? i/o? prefixes? No thanks (even if I totally understand them)
Prefabs:
They can be modified freely, and modifying them dont mess up other maps. With instances, you neeed to save them with a different name so they do not mess up other maps using them.
Prefabs can be moved after insertion if they still grouped.
And about inserting multiple brefab doors:
If you use &i in the prefab names, it will automatically number them (replace) so if I create a prefab door with a doorname door&i and a triggername opendoor_&i, and I insert 2 of this prefab, they will be door_1,opendoor_1 and door_2,opendoor_2 etc, so after insertion you must set one button to trigger opendoor_1 the other to trigger opendoor_2. Ofc if you dont know this then yes, instances can be better. the output still need to be modified but its the same with instances too.
So for me pros and cons:
INSTANCES:
pro:
- well organized directory structure when browsing for instance vmfs
- can insert them rotated but edit them normally
- to change multiple ocurence of an insertedgrouped thing (instance) only need to modify one
- the main vmf is smaller
cons:
- sometimes hard to control them
- even if you get used to it (controlling), if you want to customize, you need to edit and save the instances with a different name or collapse them, but this way the instancing lose its purpose and becomes similar to prefabs
- need to include all used instance with the main vmf, and the map loads longer into hammer
- annoying tint around instances (even if it can be turned off if the instance is not selected)
PREFABS:
pros:
- doors buttons etc can be just inserted and they auto-name themselves if named correctly
- simple to control/trigger/edit, no weird triggernames etc.
- can modify anything, and they are customizable
- modifying one inserted prefab in the map will not mess up others
cons:
- larger main vmf size
- if you want to modify something in all inserted prefab, you must modify them all one-by-one
Example:
Adding 5 door and 5 button then setting them up individually (so b1 open d1, b2 d2 etc) is like 30 sec for me in hammer (I have buttons having their triggered door names also numbered _&i so I just insert 5 door then 5 doorbutton and they work without modifying anything, only 1-1 number in the button output. Using instanced doors with instanced buttons... well, its a bit longer, and if you need to modify things like the open time or 2 button-1 door setup, or changing the paintdropper's density paintangle etc you must edit them and save with another name or collapse them into the main map.
If someone interested, I can post my custom door and custom button doorbutton prefabs for example. Ah, and if someone find it hard to properly insert/position prefabs (so if because of some entity its always off the grid), you need to surround it with a skip block that can stay around it after insertion or can just be removed later when doesnt needed.
[rage]I totally agree that instances are a nuisance. In fact, in Portal, I mainly collapsed all the instances because Valve put a load of crap in that I didn't need. Edited to my preferences and voila! In my eyes a better map.
Using their instances too: I got an error "Error: No free alocs". I never get that error and looking it up it means that there is too many named entities (or dynamic entities) inside the map. I fixed this by deleting a lot of the stuff that wasn't used in the instances. In fact: the only instance I kept original for my map is the ending instance for the coop disassembler machine. I did this because it looked like too much work to edit myself.
Plus they hardly use a nodraw/optimised it. I don't know if they did this because they expected these instances to be extremely flexible or what. [/rage]
I really think that Valve used instances because they have level designers that aren't very good at entity logic (i.e. artists) and because they are constantly changing how their levels work and look. This will increase development time when it comes to updating in consistency in design.

I'll show 3 method:
- using official valve instances
- using my custom door instance
- using my custom prefabs
Maybe I open a thread for it
Marlovious wrote:
What is the name of the .vmf you are using?
paint_dropper.vmf
Quote:
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.
wrong, no need to edit the second door and button with prefabs. But actually with an instance you need to edit the second button to reference to the second door, and the second door too (even if only the prefix)...
Prefabs are still better than instances.
In MY opinion:Instances:
Instances are like includes in Php. Only useful if you add lot of similar thing into a map or other maps, and you want to modify the included thing, for example adding a light or changing the brightness of a light instnce or changing a custom sound etc in an instanced door. You only need to modify the instance and recompile the map (and the other maps if needed). Or when using rotated instances. You can insert an instance rotated, but if needed, you modify the original instance normally and there is no need to mess with vertex manipulation or rotate everything back like you must do with prefabs. Ah, and maybe because of the directory structure, its more organized. Thats all.
But if I think back, I never used instances just so I can modify them later or never rotated them for example 45 degree.
I usually end up collapsing inserted instances, because for example stock observation rooms dont have a door or have few objects, and I either just add them in the instance (I mean not by editing it, I just put them inside) or I collapse them.
Its pretty hard sometimes to control them and they cant be customized unless edited. proxies? i/o? prefixes? No thanks (even if I totally understand them)Prefabs:
They can be modified freely, and modifying them dont mess up other maps. With instances, you neeed to save them with a different name so they do not mess up other maps using them.
Prefabs can be moved after insertion if they still grouped.
And about inserting multiple brefab doors:
If you use &i in the prefab names, it will automatically number them (replace) so if I create a prefab door with a doorname door&i and a triggername opendoor_&i, and I insert 2 of this prefab, they will be door_1,opendoor_1 and door_2,opendoor_2 etc, so after insertion you must set one button to trigger opendoor_1 the other to trigger opendoor_2. Ofc if you dont know this then yes, instances can be better. the output still need to be modified but its the same with instances too.So for me pros and cons:
INSTANCES:
pro:
- well organized directory structure when browsing for instance vmfs
- can insert them rotated but edit them normally
- to change multiple ocurence of an insertedgrouped thing (instance) only need to modify one
- the main vmf is smaller
cons:
- sometimes hard to control them
- even if you get used to it (controlling), if you want to customize, you need to edit and save the instances with a different name or collapse them, but this way the instancing lose its purpose and becomes similar to prefabs
- need to include all used instance with the main vmf, and the map loads longer into hammer
- annoying tint around instances (even if it can be turned off if the instance is not selected)PREFABS:
pros:
- doors buttons etc can be just inserted and they auto-name themselves if named correctly
- simple to control/trigger/edit, no weird triggernames etc.
- can modify anything, and they are customizable
- modifying one inserted prefab in the map will not mess up others
cons:
- larger main vmf size
- if you want to modify something in all inserted prefab, you must modify them all one-by-oneExample:
Adding 5 door and 5 button then setting them up individually (so b1 open d1, b2 d2 etc) is like 30 sec for me in hammer (I have buttons having their triggered door names also numbered _&i so I just insert 5 door then 5 doorbutton and they work without modifying anything, only 1-1 number in the button output. Using instanced doors with instanced buttons... well, its a bit longer, and if you need to modify things like the open time or 2 button-1 door setup, or changing the paintdropper's density paintangle etc you must edit them and save with another name or collapse them into the main map.
If someone interested, I can post my custom door and custom button doorbutton prefabs for example. Ah, and if someone find it hard to properly insert/position prefabs (so if because of some entity its always off the grid), you need to surround it with a skip block that can stay around it after insertion or can just be removed later when doesnt needed.
and thankyou for putting time and effort it to that learnt loads, quick question can you turn lights on and off i am using the light instances (instances/lights/bts_light_fluorescent _01_128a.vmf) how do i keep them turned off then when i press a button or use a trigger they turn on. I got the sound working just not the lights my outputs for each lights are:
OnMapSpawn >>> instance:lights_01 >>> Disable
OnMapSpawn >>> instance:lights_01 >>> Disable
OnTrigger >>> instance:lights_01 >>> Enable
OnTrigger >>> instance:lights_01 >>> Enable
Idolon wrote:
I find it very easy to work with instances, if they're made well.
Exactly! You must make (modify) instances to work better. And doing it they lose their purpose.
Also you must make several instance for example a door with white surrounding or with the darker, etc. or using just a core door instance then selecting a "skin", a solid circle block for the door. Or must collapse and apply the texture you want. With prefabs, just put one down and apply any texture without editing and saving the instance with another name.
I just made a youtube turorial video, starting to put screencomments on it (since I cant really speak anglish well and got a shitty microphone). Will link it here when ready.
The tutorial was made mainly to show why instances are bad and hard (and takes more time) to handle compared to prefabs:
- First I make 3 door and 3 button (each button opens its paired door) only using official valve instances
- Then I use my custon door instance (its better but still not faster)
- Then I use custom prefabs. Its really 2-3 times easier and faster than using instances. They (prefabs) auto-number themselves upon placing if they have &i in their targetnames...
- Then I transform the buttons into ball-buttons and add 3 weighted edgeless ball
- After that I show a 3 button 1 door combo, when the door only opens if all 3 button is activated
- Then I add doorstate indicators for the 3 button and one that only activates when all 3 is yellow (when the door opens)
- Then I put down some indicator strip
- Then I place a vertical switch, that opens the door and closes after 4 second, with a timer sound. I also show how to prevent retriggering before the timer ends
- Then I show how to just open the door that stays open and the button can't be used again
http://www.youtube.com/watch?v=qYUyDXmU_LU
This is you using instances.
Instances are what prefabs should have been from the start. Instances are everything prefabs are, and much much more. Refusing to use them because they are "too hard" is, well...
- When I used stock instances like paint droppers, boxdroppers or doors, I always ended up modifying them or adding more: Observation rooms are low in detail, if the glass is not fractured, then even from a distance it clearly visible that they dont have any door, and sometimes there is just a desk or maybe a chair. Of course it can be deal with without modifying them, I just put those missing details on top (inside) the instance cube.
- droppers can't be configured fully, I ended up modifying their properties (min max angle, blop per second, min max speed, starting height, or if the dropper's door is open all the time or opens/closes etc)
- With doors, I wanted different texture on the frame. Collapsed it.
- Lights have fixed color and brightness (and panelskin). Used my own.
- The only instances I used without modifications are the non-interactive ones like destroyed walls, or the elevators but again, had to modify the transition ents, and also collapsed the player start so I can check its "master" property
- If all instances were prefabs, I can browse them faster (like when I enter "cube" as an entity name and it filters the list so I only see cubemap weighted cube, etc. And then place them in the same way, I can move/rotate them in the same way (grouped), I still can use their triggers etc but can access them directly, and if the prefabs were made right, I don't even need to modify anything in them or even changing the fixupname.
So what can instances do better than prefabs? Only to modify lots of them at once. Lets say I made a very detailed column (greek style), placed 50 of them then I realized I have a badly aligned texture and I need to curve a hole in them or whatever. I can just edit the instance and all changes. Can't do this with prefabs. This is it.
With prefabs I just place my box dropper, I change 1-2 trigger parameter and I can turn it into a multicube dropper in 1 min (so lets say it drops 2 ball 1 refcube 1 storagecube by default, and whichever gets destroyed, the dropper drops a new one. or I can just place this 4 starting box whenever I want and the dropper only gives a new one if any of them gets destroyed.
Or placing 3 door and 3 button and making them work in 30 sec, and I can edit whatever I want on them later. With instances I can barely put down and setup one that fast, and I only can use the triggers and events that they offer (thru proxies or direct access). And yes, I know well how to use all valve instance, I just don't like them. And since they dont have any prefab alterego yet, they are the only "gallery" to place bts walls, lights, boxdroppers instead of making our own. But if someone provides a similar prefab pack, then I'm sure everyone will start to use them instead.
This is my opinion. I'll make some common prefab and post here for those who find the instance controlling confusing, or just want more control over them without modifying and creating their own instances. Instances not really ment to be modified or collapsed all the time.
msleeper wrote:
This is you using prefabs.
This is you using instances.
At least those kids are learning creatively and I definitely wouldn't want to grow a beard.