Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: [SOLVED] Alliance Problem
[SOLVED] Alliance Problem
Oct 10 2011, 8:03 pm
By: IcY  

Oct 10 2011, 8:03 pm IcY Post #1

Cruisin' on that LSD

So in my map, the human players are allied to a computer player just so they have to click 'a' to attack the computer. Problem is, when I make a trigger for the human player to set other human players as allies constantly, (so no friendly fire) it also sets the computer player constantly as an ally so humans can't attack anything or one. Trigs look like this:
first trig
players: force 1(all humans) cond: always actions: preserve, wait 300mil, set player 7 and player 8 to ally
2nd trig
players: force 1 cond: always actions: set player 1 to ally, player 2 to ally, etc. all the way to player 5, then preserve trigger

This causes me to not be able to attack player 7&8

Also, I would like to know if there is an easy way to detect un-ally-ing




Oct 10 2011, 8:40 pm NudeRaider Post #2

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Any why wouldn't it? Your first trigger clearly states to refresh the alliance every 300ms which is every 4 trigger loops on fastest. Few units have fast enough attack animation to deal damage in 300ms. Why don't you delete the first trigger?

For the unally detection:
Make sure you have a location "detection" where every alive human player owns at least 1 unit. Improvement, courtesy of rockz: At the beginning of the game set a death counter 'detection' to 1 for Force 1
Trigger
Players
  • Force 1
  • Conditions
  • Foes brings at least 1 [any unit] to "detection"
  • Foes has suffered at least 1 death of detection
  • Actions
  • Set Force 1 to Ally
  • Display Text: "Don't unally!"
  • Preserve Trigger


  • Post has been edited 1 time(s), last time on Oct 11 2011, 7:33 pm by NudeRaider.




    Oct 11 2011, 8:22 am Wormer Post #3



    IcY, I guess it's a snipers map with player-controlled ghosts, right? Unfortunately it's not possible to block attacks to a specified player or group of players with constant allying in this case, because when you ally someone the map also refreshes all other alliance statuses (I believe it happens because SC must keep allied victory flag consistent for all allied players when you declare ally or allied victory to one of them and blizzards just coded it in this silly manner).

    NudeRaider's solution is the best when you want to keep players from unallying manually (unfortunatelly being in alliance doesn't make you invincible to allied attacks). I suggest to add the same unally failsafe for computer players too, because I recall there was a hack that allowed to unally computer players (I guess this is the reason you made your first trigger, which won't work well in this case because hack can unally every trigger loop and your trigger allies only once in approximately 300ms).

    In my maps I usually combine the method posted by NudeRaider with leaving detection subsystem in a "2 in 1" manner. I usually put preplaced terran addons (because they can't be accidentally or intentionally given to another player, lifted or used for the other purpose by players, take little space and could be stacked) on the "detection" location filled with vision-blocking unbuildable terrain so that for each player Pi there is a piece of land covered with a location "detection Pi" where he is the only player owning the addon. When I see a neutral building on "detection Pi" I know that 1) player Pi was in the game (since the building is there), and 2) player Pi has left the game or have been dropped. This setup also allows me to know which specific player was unallied (for instance one may use this information to inform victim about malicious intents).

    With snipers there is another option to detect whether ghost was targeted by the attack - EUD conditions (but this will make map not playable on Macs, at least without additional effort). So that you can execute ally action to terminate the attack only when one player actually targets another player's ghost. However this method puts a strong restriction: ghosts must be 1) preplaced and 2) must not die throughout the game (i.e. only 1 life or you must use a custom virtual HP system based on EUDs to imitate death).

    This said, simplest ways to do friendly fire failsafe as always are 1) usage of a large armor for human ghosts, 2) detection of humans killing a ghost (due to SC limitations it's impossible in general case to reliably answer either of the following questions: "Who the fuck is the owner of the ghost I've just killed?" or "Who the hell have just killed this ghost of mine?", so in this case there is a limitation that your map couldn't contain computer owned ghosts or you should turn this limitation into a feature as it was made in "Snipers RPG Classic" by Ch-Dpia).

    Finally, don't forget about the last option to not add this kind of failsafe at all. After all your map isn't responsible for all the fagots flooding the opens of Internet!

    P.S. Moreover in my opinion these two subsystems (ally status detection and leaving detection) are a must for almost any map pretending to be well made nowadays.

    Post has been edited 8 time(s), last time on Oct 11 2011, 8:40 am by Wormer.



    Some.

    Oct 11 2011, 3:35 pm rockz Post #4

    ᴄʜᴇᴇsᴇ ɪᴛ!

    unfortunately the EUD detection won't work on snipers. There's a certain strategy to the location of where to shoot, and it's literally one frame difference, so if there's a frame delay on the trigger, the other player can shoot, and it's a double kill every time.

    The other option is to have some system where each player has 2 units or the units killed are cycled, but honestly that takes too much thought.

    The best option is something like nude suggested, however all you really have to do is:
    1) detect a player's alliance status
    2) set the alliance status to what it should be.

    To detect alliance status, you have to use the "foes" or "allies" player. From there you can either detect a death count, an unkillable unique unit, or a mineral count. There might even be an EUD you can use.



    "Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"

    Oct 11 2011, 5:00 pm Roy Post #5

    An artist's depiction of an Extended Unit Death

    There is a way to detect alliances with EUDs, but they're stored as bits and are really difficult to write. Nude's solution is the most practical.




    Oct 11 2011, 5:09 pm Wormer Post #6



    Just to be clear, I refer to the EUD unit selection detection system which for instance is used there.



    Some.

    Oct 17 2011, 11:22 pm IcY Post #7

    Cruisin' on that LSD

    solved thanks




    Options
      Back to forum
    Please log in to reply to this topic or to report it.
    Members in this topic: None.
    [09:19 am]
    Linekat -- cool
    [01:56 am]
    Oh_Man -- cool bit of history, spellsword creator talking about the history of EUD ^
    [09:24 pm]
    Moose -- denis
    [05:00 pm]
    lil-Inferno -- benis
    [10:41 am]
    v9bettel -- Nice
    [2024-4-19. : 1:39 am]
    Ultraviolet -- no u elky skeleton guy, I'll use em better
    [2024-4-18. : 10:50 pm]
    Vrael -- Ultraviolet
    Ultraviolet shouted: How about you all send me your minerals instead of washing them into the gambling void? I'm saving up for a new name color and/or glow
    hey cut it out I'm getting all the minerals
    [2024-4-18. : 10:11 pm]
    Ultraviolet -- :P
    [2024-4-18. : 10:11 pm]
    Ultraviolet -- How about you all send me your minerals instead of washing them into the gambling void? I'm saving up for a new name color and/or glow
    Please log in to shout.


    Members Online: IlyaSnopchenko, Roy