Change Details

It's not mandatory to set the group leader to be the trigger owner. You can make the player the group leader and the trigger owner to be one of your subordinate units. That way you won't have to kill anybody. The effect will be the same. As you can see this is game breaking for missions that were designed with AI or playable units for Multiplayer. If the trigger owner gets killed the triggers won't work. The only solution right now is to not use triggers with owners (except for "Owner Only" activation). I don't know if I should post this here but I would also like to suggest: When you fix this bug, can we receive the ability to set a group entity in the editor as the owner of a trigger (this should automatically remove the "Owner Only" activation option in a trigger with group entity set as owner and only allow the other 3 options - "Whole Group", "Group Leader", "Any Group Member"). My reasoning is this: If you create a multiplayer mission and you set a playable unit from a group as the trigger owner, if the players in the multiplayer lobby don't pick the slot for that unit and disable it's AI, then the trigger will not spawn / work. For example, a multiplayer co-op mission where you have a whole squad of playable units. The group leader is the trigger owner of the trigger that has to end the mission with "Whole Group" Present activation. If nobody picks the group leader slot and disables it's AI the trigger will not work and the mission will not end. Alternatively, you can program the trigger to automatically detect that it's owner doesn't exist at mission start and look for other units in the owner's group (but NOT for "Owner Only" activation triggers as that would make no sense). This problem also exists for trigger owner units that have probability of presence <100% or condition of presence that might return false. This idea is inspired by the, now overcomed inability, to initialize group variable name. In the past mission makers had to initialize their group variable name in every playable group member unit's initialization field to avoid cases where a playable unit that has group initialization code was not picked in multiplayer and it's AI disabled. By putting the group variable name in the group entity's name field, this problem is now solved.

It's not mandatory to set the group leader to be the trigger owner. You can make the player the group leader and the trigger owner to be one of your subordinate units. The effect will be the same. As you can see this is game breaking for missions that were designed with AI or playable units for Multiplayer. If the trigger owner gets killed the triggers won't work. The only solution right now is to not use triggers with owners (except for "Owner Only" activation). I don't know if I should post this here but I would also like to suggest: When you fix this bug, can we receive the ability to set a group entity in the editor as the owner of a trigger (this should automatically remove the "Owner Only" activation option in a trigger with group entity set as owner and only allow the other 3 options - "Whole Group", "Group Leader", "Any Group Member"). My reasoning is this: If you create a multiplayer mission and you set a playable unit from a group as the trigger owner, if the players in the multiplayer lobby don't pick the slot for that unit and disable it's AI, then the trigger will not spawn / work. For example, a multiplayer co-op mission where you have a whole squad of playable units. The group leader is the trigger owner of the trigger that has to end the mission with "Whole Group" Present activation. If nobody picks the group leader slot and disables it's AI the trigger will not work and the mission will not end. Alternatively, you can program the trigger to automatically detect that it's owner doesn't exist at mission start and look for other units in the owner's group (but NOT for "Owner Only" activation triggers as that would make no sense). This problem also exists for trigger owner units that have probability of presence <100% or condition of presence that might return false. This idea is inspired by the, now overcomed inability, to initialize group variable name. In the past mission makers had to initialize their group variable name in every playable group member unit's initialization field to avoid cases where a playable unit that has group initialization code was not picked in multiplayer and it's AI disabled. By putting the group variable name in the group entity's name field, this problem is now solved.

It's not mandatory to set the group leader to be the trigger owner. You can make the player the group leader and the trigger owner to be one of your subordinate units. That way you won't have to kill anybody. The effect will be the same. As you can see this is game breaking for missions that were designed with AI or playable units for Multiplayer. If the trigger owner gets killed the triggers won't work. The only solution right now is to not use triggers with owners (except for "Owner Only" activation). I don't know if I should post this here but I would also like to suggest: When you fix this bug, can we receive the ability to set a group entity in the editor as the owner of a trigger (this should automatically remove the "Owner Only" activation option in a trigger with group entity set as owner and only allow the other 3 options - "Whole Group", "Group Leader", "Any Group Member"). My reasoning is this: If you create a multiplayer mission and you set a playable unit from a group as the trigger owner, if the players in the multiplayer lobby don't pick the slot for that unit and disable it's AI, then the trigger will not spawn / work. For example, a multiplayer co-op mission where you have a whole squad of playable units. The group leader is the trigger owner of the trigger that has to end the mission with "Whole Group" Present activation. If nobody picks the group leader slot and disables it's AI the trigger will not work and the mission will not end. Alternatively, you can program the trigger to automatically detect that it's owner doesn't exist at mission start and look for other units in the owner's group (but NOT for "Owner Only" activation triggers as that would make no sense). This problem also exists for trigger owner units that have probability of presence <100% or condition of presence that might return false. This idea is inspired by the, now overcomed inability, to initialize group variable name. In the past mission makers had to initialize their group variable name in every playable group member unit's initialization field to avoid cases where a playable unit that has group initialization code was not picked in multiplayer and it's AI disabled. By putting the group variable name in the group entity's name field, this problem is now solved.