Make Unit Not Able to Attack Certain Unit

[Gnuoy]

Problem: Worried players will use boats with long range to cheese "bosses". I want to make the boats unable to target these bosses. First I made a trigger but that was leaking too much and causing other problem.

Solution? Was thinking make the bosses classified as "taurens" then make the ships unable to target taurens.

Question. How would I check off the target types to make this happen? Can anyone think of a better solution?

Spoiler: Edit Unit Value - Target Types

Thoughts?

Thank you.

 

[Nichilus]

Rather than tauren, maybe make the bosses 'Ancient' ? Then you can make the boats target only 'Non-ancient'

 

[Gnuoy]

there are a few ancients on the map, so ideally the boats could still attack those. very few though! so most games would not be a problem. non-ancient is a great solution but not 100% ideal. I'll try that for now tho. If anyone has any other ideas please share. Thanks.

 

[Nichilus]

Well, you could also try the 'Suicidal' instead (just going by what the 'Non-xx' options are in Targets Allowed.
I can see that Sapper unit has this classification, but I have no idea how this impacts the unit's behavior, so it may not be the best idea

 

[Footman16]

Well, you could also try the 'Suicidal' instead (just going by what the 'Non-xx' options are in Targets Allowed.
I can see that Sapper unit has this classification, but I have no idea how this impacts the unit's behavior, so it may not be the best idea

The only effect suicidal has is it cant be targeted by invisibility and also cant be loaded into transports.

 

[Chaosium]

If the targeting solution doesn't work, you can always create a very simple trigger like such:

• Anti Cheese
  • Events
    • Unit - A unit Is attacked
  • Conditions
    • (Unit-type of (Attacking unit)) Equal to Super Long Range Boat
  • Actions
    • Unit - Order (Attacking unit) to Stop

That'll probably give you more control about what you want to do exactly

 

[Pyrogasm]

Doesn’t the suicidal tag change how units auto-acquire that unit as a target? Or maybe it is general AI combat priority that I’m remembering it changes?

 

[Tristronic]

What if you gave the bosses a very long attack and acquisition range but low sight range so if a ranged unit attacks it it nukes them?

Attacking units become visible even outside of sight range as far as I know...

 

[Footman16]

Doesn’t the suicidal tag change how units auto-acquire that unit as a target? Or maybe it is general AI combat priority that I’m remembering it changes?

I'd need to test, cos Sappers also don't have an attack which reduces their auto-attack priority, but then again units also tend to not focus the clockwork goblins and they should have the suicidal tag too.

 

[Gnuoy]

If the targeting solution doesn't work, you can always create a very simple trigger...

doesn't this trigger event leak profusely?

What if you gave the bosses a very long attack and acquisition range but low sight range so if a ranged unit attacks it it nukes them?

yes i like this solution a lot, if it works o f course.

 

[Tristronic]

doesn't this trigger event leak profusely?


yes i like this solution a lot, if it works o f course.

The issue I'm thinking of now is that if they gain the visibility from their other units or their ally's units... not sure if you can afford to have them be owned by another player

 

[Chaosium]

doesn't this trigger event leak profusely?


yes i like this solution a lot, if it works o f course.

Why would it? There's no point reference, unit groups or anything of the sort. If your boats have an attack speed of 0.01 sure it will trigger a lot but heh

 

[Pyrogasm]

doesn't this trigger event leak profusely?

You fundamentally do not understand what a memory leak is if you are asking that question here. Please read a tutorial like this or start a thread and ask questions about leaks directly if you do not understand. My humorous take is that such a question is like asking

If I want to use the Air Conditioning in my car, doesn't that limit how slow I can drive in order to keep the air blowing fast enough inside?

Very much a "...what?" question.

 

[Gnuoy]

my understanding is some gui events create a leak such as 'unit takes damage'

 

[Pyrogasm]

Again I invite you to ask yourself "what would the 'leak' be?" and try to think through it. Because by following that thought here you will better understand.

• Something being considered a memory leak requires that:
  • an object is created
  • after being used, this object will never need to be used again
  • the object is never manually removed from memory (by removing/destroying it), so it continues to occupy that memory forever
  • the variable pointing to that object (or if there was no variable at all in the first place) is eventually assigned to something else, which means the original object can never be referred to ever again
• What you are referring to is a consequence of a workaround used because there used not to be a generic "any unit takes damage" event. Instead of being able to use this event (which exists now but didn't a few patches ago), mapmakers had to use the "<specific unit> takes damage" event.
• This event asks for a specific unit... so the practice was to add one such event to a trigger for every single unit that entered the map.
• That would generally work, but it meant that the trigger began to accumulate literally thousands of events added to it throughout a map. Since these events can never be removed from the trigger, but each event is only relevant until that unit dies (or is removed from the map), they are a type of memory leak. The only solution to this was to periodically destroy the trigger entirely and rebuild it.
• To be clear: the event didn't create a leak, the event was the leak.
• Now we have a generic "a unit takes damage" event that can be used like all the other 'generic unit events', which means triggers no longer need to have thousands of useless events for this and doesn't need to be 'cleaned up' at all.
  
  
• "a unit is attacked" is what is being suggested here (and it's one of the only reasonable uses of that event), which is:
  • Not "<specific unit> takes damage"
  • A generic unit event, which does not have this issue