func_instance and more
Hi guys,
I hope I am not offending anyone, but I'd like to confess that I have an issue with CS:GO and not with Portal. Since the issue is a bit more advanced than the average CS:GO map, I was hoping to find the expertise I need here.
Valve recently showed the CS:GO community ways of creating custom modes via cfg's, vscripts, logic_cases etc. In the example, they use control points. One or more flags in the map have to be captured in order for a team to win etc.
What I was wondering about, is if it would be possible that once a control point is captured, it creates a new control point somewhere else in the map and destroying itself. I couldn't find any entities that could destroy or hide a func_instance as a whole, or spawn/set visible to another.
The control point instance itself contains the logic_cases and such that loads the script(s), regs score and so on. I hope this isn't confusing anyone as much as it is for me. In case anyone plays Mass Effect 3; their king of the hill mode is comparable.
Thanks!
Func_instances are an internal entity, which means that they only affect the compiler and are not present in the compiled map. VBSP copies the entities from the instance vmf and fixes them up. If I understand what you are wanting to do, it might be better to modify the instance so you can enable/disable the entities inside it, then place a bunch of them all over the map; this way you could enable one at a time to make it look like it's moving.
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]
You'll want to add a relay called Kill to the instance, with various OnTrigger outputs to kill the entities in the control point. Then send an output from the func_instance_io_proxy to the relay, and it'll add a new input to the control point called instance:Kill;Trigger.
Glad to see that killing the instance, or at least things inside it, is possible at all. Forgive me my limited knowledge of the subject so far, doing my best to read up on it.
If the entities within the instance are adjusted so they can be triggered to kill, wouldn't that cause all of the instances of the same type to be destroyed at once, or can the io_proxy target a single reference of an instance without affecting other references of the same type?
Short answer: io_proxies target one copy of an instance, as long as the fix up name is correct.
Long answer:
Normally when an instance is added into a map and compiled every item inside it is renamed to something like in
stance_name-item_name. For example if you have a trigger named "trigger" inside an instance, and the instance itself is named "instance", 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, or just "trigger"). 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.
When using an io_proxy, you can treat it like it was the rest of the map. After giving the proxy a name, you could add a "ProxyRelay" output to the proxy and set it to anything. This will appear as an input option for the instance itself. When the map compiles these inputs/outputs are renamed to match the real entity names. You can also send the "OnProxyRelay" input to the proxy to add an output to the instance.
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]
That's very helpfull, thanks!
I was however thinking about this, and I noticed a flaw in the plan. The idea is to have -for example- 4 control points in the map, of which only one is active at the same time. Once a control point is taken over, or the points that can be gained for it depleted, it should vanish and activate a next one.
Whilst it seems possible that the instance (thats how Valve's example works at least) is getting destroyed, I still don't see how I could 'hide' the other control points in the map whilst still being able to set them visible when needed. If you use 'kill' as in/output that means the target is gone, and cannot be 'revived' anymore, correct?
I plan on (re)rewriting the control point script eventually, but I was hoping for an easier learning curve by using Valves examples, but the instancing part doesn't seem to make it any easier; haha 
.
Kill deletes that entity completely. What entities are used to make the control point visible, and why entities are used to detect players? It's probably possible to just enable/disable these to toggle things on and off (Enable/Disable are common inputs to turn things on/off).. You might want to check out the pickRandomShuffle input on a logic_case (chooses a random case that has an output, goes through every case before repeating).
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]
Hammer uses a func_instance to load the instance of a control point. A trigger will tell the related logic_cases and such that a player is in range of the control point.
The control point instance currently contains a flagpole models with 2 types of flags for both teams that will be raised if a player is in range.
To register all the events, there are 12 logic_relays, 1 logic_script, 1 func_instance_parms and 1 logic_auto.
Entity Type; Name; Targets Does;
logic_relay relay_add_player_T script_control_point RunScriptCode AddPlayer_Terrorist()
logic_relay relay_add_player_CT " " RunScriptCode AddPlayer_CT()
logic_relay relay_sub_player_T " " RunScriptCode RemovePlayer_Terrorist()
logic_relay relay_sub_player_CT " " RunScriptCode RemovePlayer_CT()
logic_relay relay_CT_CapturedPoint " " PlaySound
logic_relay relay_T_CapturedPoint " " PlaySound
logic_relay relay_CT_LostPoint proxy ProxyRelay
logic_relay relay_T_LostPoint proxy ProxyRelay
logic_relay relay_T_CapturedPoint_output proxy ProxyRelay
logic_relay relay_CT_CapturedPoint_output proxy ProxyRelay
logic_relay relay_make_CT_ONLY relay_add_player_T Disable
logic_relay relay_make_CT_ONLY relay_add_player_CT Enable
logic_relay relay_make_T_ONLY relay_add_player_T Enable
logic_relay relay_make_T_ONLY relay_add_player_CT Disable
func_instance_parms is the proxy as far as I understand (too much in/output to type 
)
The logic_auto targets the script and on mapspawn it resets the capture points to 0.
The logic_script loads the script and is tied to all those entities.
The basic flagpole on which the teamflags will appear is a prop_static.
Come to think of it; it could be sufficient to set the trigger (that regs if a player is in range to take over/score points) and the flagpole (+flags?) visible/active or the opposite to turn them off? The logic could stay in place, but as long as there are no visible models and it isn't going to register points, that should be fine. Can a trigger_multiple be hidden/disabled; and the same for the prop_static flagpole and dynamic flags?
One other thing is noticed is that the example uses a env_message to display an alert about points being taken over; is it at all possible to show dynamic (hud, not simple chat) messages (showing score) in multiplayer games?
Sorry if it doesn't entirely match the topictitle anymore, haven't worked with vscript before 
The control point instance currently contains a flagpole models with 2 types of flags for both teams that will be raised if a player is in range.
To register all the events, there are 12 logic_relays, 1 logic_script, 1 func_instance_parms and 1 logic_auto.
Entity Type; Name; Targets Does;
logic_relay relay_add_player_T script_control_point RunScriptCode AddPlayer_Terrorist()
logic_relay relay_add_player_CT " " RunScriptCode AddPlayer_CT()
logic_relay relay_sub_player_T " " RunScriptCode RemovePlayer_Terrorist()
logic_relay relay_sub_player_CT " " RunScriptCode RemovePlayer_CT()
logic_relay relay_CT_CapturedPoint " " PlaySound
logic_relay relay_T_CapturedPoint " " PlaySound
logic_relay relay_CT_LostPoint proxy ProxyRelay
logic_relay relay_T_LostPoint proxy ProxyRelay
logic_relay relay_T_CapturedPoint_output proxy ProxyRelay
logic_relay relay_CT_CapturedPoint_output proxy ProxyRelay
logic_relay relay_make_CT_ONLY relay_add_player_T Disable
logic_relay relay_make_CT_ONLY relay_add_player_CT Enable
logic_relay relay_make_T_ONLY relay_add_player_T Enable
logic_relay relay_make_T_ONLY relay_add_player_CT Disable
func_instance_parms is the proxy as far as I understand (too much in/output to type )
The logic_auto targets the script and on mapspawn it resets the capture points to 0.
The logic_script loads the script and is tied to all those entities.
The basic flagpole on which the teamflags will appear is a prop_static.
Come to think of it; it could be sufficient to set the trigger (that regs if a player is in range to take over/score points) and the flagpole (+flags?) visible/active or the opposite to turn them off? The logic could stay in place, but as long as there are no visible models and it isn't going to register points, that should be fine. Can a trigger_multiple be hidden/disabled; and the same for the prop_static flagpole and dynamic flags?
One other thing is noticed is that the example uses a env_message to display an alert about points being taken over; is it at all possible to show dynamic (hud, not simple chat) messages (showing score) in multiplayer games?
Sorry if it doesn't entirely match the topictitle anymore, haven't worked with vscript before
Both prop_dynamic and trigger_multiple respond to the inputs Enable and Disable. If you want them to start disabled, there's a KeyValue for that. Prop_statics aren't really entities, so they can't be disabled. Just switch the flagpole to a prop_dynamic and it'll work.
If you want to show a custom HUD message, try a game_text entity. You can set all its properties through inputs in a vscript.
Thanks for the reply; after a lot of mucking about I finally understand how the instances, logic cases etc. work! After changing the model to a prop_dynamic and adding two logic cases to disable/enable models and triggers, and then adding those logic_cases to the IO manager so they can be accessed from the outsite, I have it working!
Thanks a lot everyone for the help, I should be able to continue now, coding makes more sense to me than those logic cases did a few hours ago