Object Name Symbols
Quote from RomulanPaladin on August 6, 2013, 4:25 pmRom here. Still new at this stuff. This is where I am in understanding things:
If I want to make a working door instance, the "open" command goes through the gauntlet: Trigger (outside instance) to IO Proxy to Logic Relay to Door.
My question: what exactly do the "@" and "$" symbols in names do? Are there other name symbols? What exactly do I need to know about how to name things that use these symbols when sending commands through the trigger-logic gauntlet?
I think I saw something about this somewhere but I can't seem to find it again.
Rom here. Still new at this stuff. This is where I am in understanding things:
If I want to make a working door instance, the "open" command goes through the gauntlet: Trigger (outside instance) to IO Proxy to Logic Relay to Door.
My question: what exactly do the "@" and "$" symbols in names do? Are there other name symbols? What exactly do I need to know about how to name things that use these symbols when sending commands through the trigger-logic gauntlet?
I think I saw something about this somewhere but I can't seem to find it again.

Quote from TeamSpen210 on August 6, 2013, 5:11 pmNormally when an instance is added into a map every item inside it is renamed to something like instance_name-item_name. For example if you have a trigger named trigger inside an instance, and the instance itself is named door, then the trigger will be renamed automatically to door-trigger.instance properties do have the option to disable this or reverse it (so it is named trigger-door instead). The compiler will fix pretty much everything so things still work. If you name something starting with @, it'll prevent this from happening. The item name will never change. This is useful for communicating between instances.
Normally when an instance is added into a map every item inside it is renamed to something like instance_name-item_name. For example if you have a trigger named trigger inside an instance, and the instance itself is named door, then the trigger will be renamed automatically to door-trigger.instance properties do have the option to disable this or reverse it (so it is named trigger-door instead). The compiler will fix pretty much everything so things still work. If you name something starting with @, it'll prevent this from happening. The item name will never change. This is useful for communicating between instances.
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]
Quote from RomulanPaladin on August 6, 2013, 8:56 pmLet's see if I understand.
Say I have an instance for a door with a logic relay within it. The relay is named "door_open". I make this instance in my map and name the whole instance "this_door". Unless I mess with the Fix Name property or whatnot, my relay within my instance is now called "this_door-door_open".
Assuming that I have things right so far, when I want to trigger the relay outside of the instance, do I call for "door_open" in my trigger output or do I call for "this_door-door_open"?
Since it retains the name, should I be using "@" for object names within instances that I only make one of each map (such as an entrance elevator) and avoid using it for things that I make multiples of (such as doors)?
Let's see if I understand.
Say I have an instance for a door with a logic relay within it. The relay is named "door_open". I make this instance in my map and name the whole instance "this_door". Unless I mess with the Fix Name property or whatnot, my relay within my instance is now called "this_door-door_open".
Assuming that I have things right so far, when I want to trigger the relay outside of the instance, do I call for "door_open" in my trigger output or do I call for "this_door-door_open"?
Since it retains the name, should I be using "@" for object names within instances that I only make one of each map (such as an entrance elevator) and avoid using it for things that I make multiples of (such as doors)?

Quote from TeamSpen210 on August 6, 2013, 11:10 pmYou'd need to trigger this_door-door_open. I'd use a proxy instead. Basically treat the proxy as if it's the rest of the map. Name it something (usually 'proxy'), then give it an output that triggers the relay. You could then have the trigger send the input 'instance:door_open;Trigger' to the instance. (This will show up automatically). This works in reverse as well (input to the proxy, the instance will get an output.). The compiler will fix the I/O up for you so it'll link to the real instances.
You don't need to usually use @ unless talking between instances, like making a cube template instance and then spawning it from dropper instances for example.
The '$' prefix is used for parameters. Replace any property value with a name starting with '$', then add a func_instance_params. In here it'll list all the parameters and let you change the type. These will show up in the instance properties; they will replace the versions inside an instance. For example, if you set the delay property to '$delay' in a prop_button, then the instance will have a property to let you choose the delay of the button timer.
You could have a look at the PTI instances in instances/p2editor, they use this a lot. You probably don't want to use them normally in a hammer map though. (The instances use way too many entities compared to one made for hammer usage).
You'd need to trigger this_door-door_open. I'd use a proxy instead. Basically treat the proxy as if it's the rest of the map. Name it something (usually 'proxy'), then give it an output that triggers the relay. You could then have the trigger send the input 'instance:door_open;Trigger' to the instance. (This will show up automatically). This works in reverse as well (input to the proxy, the instance will get an output.). The compiler will fix the I/O up for you so it'll link to the real instances.
You don't need to usually use @ unless talking between instances, like making a cube template instance and then spawning it from dropper instances for example.
The '$' prefix is used for parameters. Replace any property value with a name starting with '$', then add a func_instance_params. In here it'll list all the parameters and let you change the type. These will show up in the instance properties; they will replace the versions inside an instance. For example, if you set the delay property to '$delay' in a prop_button, then the instance will have a property to let you choose the delay of the button timer.
You could have a look at the PTI instances in instances/p2editor, they use this a lot. You probably don't want to use them normally in a hammer map though. (The instances use way too many entities compared to one made for hammer usage).
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]

Quote from ChickenMobile on August 6, 2013, 11:45 pmRemember that you can use wildcards as well; these are incredibly useful when using both the prefix and affix fix up name.
e.g. I have 20 panels with affix panel1 - 20. I can reference a certain entity in all the panels by using the wildcard:
entityname*.e.g. I have 20 panels with prefix panel1 - 20. I can reference every entity in the panel1- instance by using the wildcard: panel1*.
Remember that you can use wildcards as well; these are incredibly useful when using both the prefix and affix fix up name.
e.g. I have 20 panels with affix panel1 - 20. I can reference a certain entity in all the panels by using the wildcard:
entityname*.
e.g. I have 20 panels with prefix panel1 - 20. I can reference every entity in the panel1- instance by using the wildcard: panel1*.
Quote from RomulanPaladin on August 7, 2013, 7:07 amSo as long as I include proxies with all my instances, I only need to know the internal name of the relay within the instance, not the map wide appended name, yes no? Do I never mention the proxy in my triggers?
My trigger output will generally look like this to talk to instances with proxies:
My Output: (some output)
Target Entity: (instance name)
Target Input: instance:(internal relay name);(command)Or, for this example:
My Output: OnStartTouch
Target Entity: this_door
Target Input: instance:door_open;TriggerIf that's how things work, then I know where I was getting confused: I was thinking that I needed to call the proxy name instead of the relay name.
So as long as I include proxies with all my instances, I only need to know the internal name of the relay within the instance, not the map wide appended name, yes no? Do I never mention the proxy in my triggers?
My trigger output will generally look like this to talk to instances with proxies:
My Output: (some output)
Target Entity: (instance name)
Target Input: instance:(internal relay name);(command)
Or, for this example:
My Output: OnStartTouch
Target Entity: this_door
Target Input: instance:door_open;Trigger
If that's how things work, then I know where I was getting confused: I was thinking that I needed to call the proxy name instead of the relay name.

Quote from TeamSpen210 on August 7, 2013, 12:38 pmThat's how it works, but the instance will have a list of inputs and outputs for you so you don't need to remember anything.
Just a bit of a bug to be aware of: if you send an output from an item to the proxy, then any other outputs won't work. Generally when outputting from an instance use a relay in between.
That's how it works, but the instance will have a list of inputs and outputs for you so you don't need to remember anything.
Just a bit of a bug to be aware of: if you send an output from an item to the proxy, then any other outputs won't work. Generally when outputting from an instance use a relay in between.
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]