Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Detecting unit origins
Detecting unit origins
May 15 2014, 8:08 pm
By: sethmachine  

May 15 2014, 8:08 pm sethmachine Post #1



Hi,

This is a problem that's found in every map that uses a so called "garrison system." The garrison system is a way of automatically protecting a player's resources which does not require actual defenses or units. Instead it works like this:

***********
Each "resource" is some building or structure
The controlling player of the resource receives income from it

When an enemy player brings a unit within X range of the resource, units (garrisons) are created for the player controlling the resource to protect it.

If the attacker drives of all enemy units defending the resource (same as range), then the resource is transferred over to the attacker.

If the attacker backs down or retreats, the garrison units within X range of the resource are removed, and the resource does not change hands.
***********

Now one problem I have seen in maps that use this system is the following case, which I call "wandering" garrison:

1. An enemy attacks the resource
2. A garrison spawns, but the defender also has non-garrison units in range
3. The defender moves the garrison units out of the range of the resource
Result: Whether the resource is defended successfully, or captured, the garrison units are not removed and the player has effectively gained free units that are not meant to be in armies except when defending.

In my implementation of this garrison system, I able to handle one sub-case of the wandering garrison: when the resource is defended successfully.

This is done by detecting if a player's resources are being attacked at all. Since it is impossible to tag or mark each unit instance in a way that ties it back to a particular resource (I am sorry there is no way to do this), I instead increment a variable each time a player's resource is engaged. Then, if the player defends successfully, this variable is decremented. When the variable is at 0, it means the player is not being attacked anywhere.

Thus, if the player controls garrison units but the variable is at 0, it is a case of wandering garrison. Then all such garrison units are removed.

However, if the player's resource is captured, I have no way of decrementing their variable to indicate it's no longer in battle. This is because while the spawn and successfully defend triggers are run by the defender, the capture trigger is run by the attacker.

Thus I would like to know if there is a way to capture this last sub-case of wandering garrison without significantly modifying the triggers I am currently using, as attached below.

Sample Garrison triggers


Wandering Garrison detection (only 1 sub-case)




None.

May 15 2014, 9:46 pm Wormer Post #2



Okay, I was telling you (here, or it wasn't you?) how I'd do these triggers if I was doing the system. But the question here is how to make it work with less possible changes.

Let's work with what we have. The idea is to split capturing into 2 events: for defender lose town (give to player 12), for attacker capture town (take from player 12). 1) You're adding a trigger for defender that gives the town to player 12 (and decreases the counter) once there are no allied units nearby. 2) You're changing the capture trigger to capture depots from player 12 when there are no any other player's units nearby. This will also work as failsafe for the event when players leave the game because their units are automatically given to player 12.



Some.

May 15 2014, 11:16 pm sethmachine Post #3



Thanks again Wormer.

I used your method and it seemed to work, except something weird.

I have two resources (Protoss Nexus and Terran Supply Depot). The triggers for the Protoss Nexus all work perfectly using this method. So I just used text macros to make the ones for the Terran Supply Depot.

However, while the Protoss Nexuses work flawlessly, the Terran Supply Depots don't!

Here is what happens for the Terran Supply Depot:

1. An enemy unit approaches
2. Garrison spawns
3. Enemy unit leaves
4. Depot is turned over to P10
5. Garrison recaptures depot
6. Garrison never despawns.

(Note: About 10% of the time the Terran Supply Depot does the correct behavior.)

Correct behavior (what all the Nexuses do):
1. An enemy unit approaches
2. Garrison spawns
3. Enemy unit leaves
4. Depot does not change hands
5. Garrison despawns

I cannot see why this is happening and I would appreciate a fresh set of eyes for helping to find why there is this difference in behavior. I glanced at both sets of triggers side by side twice and they look exactly the same to me, because I used a text macro from the triggers handling the Protoss Nexus, which worked. Logically it should behave the same for the Terran Supply Depot but it does not.

Protoss Nexus (Working AFAIK)


Terran Supply Depot (failing miserably :()




None.

May 16 2014, 7:22 am Wormer Post #4



Quote
Okay, I was telling you (here, or it wasn't you?) how I'd do these triggers if I was doing the system.
Oh, I'm sorry it wasn't you. Triggers look alright. Can you please post the map? Also what does the "Duke Turret type 2" DC do? It looks like it prevents fighting for multiple towns at a time.

Post has been edited 2 time(s), last time on May 16 2014, 8:07 am by Wormer.



Some.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[2024-5-12. : 8:51 pm]
l)ark_ssj9kevin -- Are you excited for Homeworld 3?
[2024-5-12. : 8:44 pm]
l)ark_ssj9kevin -- Hi Brusilov
[2024-5-12. : 4:35 pm]
O)FaRTy1billion[MM] -- Brusilov
Brusilov shouted: Hey, what happened to EUDDB? Is there a mirror for it somewhere? Need to do a little research.
my server that was hosting it died
[2024-5-10. : 8:46 pm]
NudeRaider -- Brusilov
Brusilov shouted: Hey, what happened to EUDDB? Is there a mirror for it somewhere? Need to do a little research.
https://armoha.github.io/eud-book/
[2024-5-10. : 8:36 am]
Brusilov -- Hey, what happened to EUDDB? Is there a mirror for it somewhere? Need to do a little research.
[2024-5-09. : 11:31 pm]
Vrael -- :wob:
[2024-5-09. : 8:42 pm]
Ultraviolet -- :wob:
[2024-5-08. : 10:09 pm]
Ultraviolet -- let's fucking go on a madmen rage bruh
[2024-5-08. : 10:01 pm]
Vrael -- Alright fucks its time for cake and violence
[2024-5-07. : 7:47 pm]
Ultraviolet -- Yeah, I suppose there's something to that
Please log in to shout.


Members Online: lil-Inferno