• 0

    posted a message on Ability target minimap

    There are several abilities that allow the player to target the minimap and it will select the closest valid unit (chrono boost, spawn larvae, nuke, attack, etc.) What is allowing these abilities to do this? Is it hardcoded? I've been looking at these abilities and it doesn't seem there's a flag or anything that would indicate that minimap targetting is allowed. I realize this can be done with triggers but I was hoping for a data solution.

    Thanks in advance.

    Posted in: Data
  • 0

    posted a message on [solved]Fog: Visible but not attackable?
    Quote from DrSuperEvil: Go

    Maybe the Has Vision validator in the first effect of the weapon

    Interestingly enough, that worked.

    Posted in: Data
  • 0

    posted a message on [solved]Fog: Visible but not attackable?

    So I have these structures that need to be able to be seen at all times, so I made the UI - Fog Visibility: Dimmed which seemed to work pretty well. However, long range units can now attack these structures even if they do not have vision. What I want is for these structures to be visible (dimmed) to all players so that they can see where they are and who controls them at the time but also not able to be attacked by units who do not have vision of them. Is there any way to do this? I am open to trigger solutions as well.

    Posted in: Data
  • 0

    posted a message on [Solved]Veterancy question.
    Quote from Rice87: Go

    @peranzormal: Go

    Hey, So what you are saying is, Apply this behavior and it will make the unit invisible have no collision(for some time) invulnerable And then it will be moved to a respawn location. I assume moving it to this respawn location happens with triggers? what happens to the death animation of the unit? What do i do with my triggers that are referenced to the death event of a hero? does the behavior have all these things on the whole time the behavior is active? so i just remove the behavior with triggers at the time the unit has to respawn?

    thnx for the anwser, sry for the questions, it just saves me a lot of time :)

    Yes you will have to move the unit with triggers. Upon the hero gaining the behavior, create an actor of that hero, face it in the direction of the dying hero, play its death animation. Change your "death event" triggers to be instead triggered on the "Apply Behavior" effect that is activated when the hero receives his "fatal" hit. Yes, just remove the behavior with triggers or make it have a duration if the respawn time is dynamic.

    So your heroes should all have the Hero Death Prevention behavior, which, when receiving fatal damage, modifies the damage to 0 and applies the hero's "death" behavior, which is the behavior you use to make it invisible, invulnerable, not selectable, no attack, no collision, etc.

    Posted in: Data
  • 0

    posted a message on [Solved]Veterancy question.

    @Rice87: Go RE: 1 Usually the easiest way to make heroes is to have a revive system in place and make it so they never really "die" (see Valerian Death Prevention behavior). The idea is that when they are hit by the killing blow it doesn't actually kill them but makes them invisible, invulnerable and have no collision for some time and then moves them to a respawn location before making them visible again. This way, nothing about the hero has to be saved prior to death as you are still using the same unit because it never really died.

    Posted in: Data
  • 0

    posted a message on New Mapmaker

    Prepare to become an indentured slave to your map if you want to produce any sort of quality product.

    Posted in: General Chat
  • 0

    posted a message on What are the map tags?

    Under Map Properties there's a new tab called Tags, which have a name and difficulty field you can set. What's the purpose of this?

    Posted in: General Chat
  • 0

    posted a message on Baneblade

    I think this just confirms that Kueken is a minor deity.

    Posted in: Data Assets
  • 0

    posted a message on Killing unit's player

    @norbak: Go

    I don't know precisely what you're trying to accomplish so I'll describe two examples and hopefully one of them fits what you want to do:

    If you want this trigger to be exclusive to player 1, you can do something like this:

    • Event: Unit - Any unit dies
    • Conditions: Owner of (Killing Unit) == 1
    • Actions: Modify player1size: +1

    If you want this to work for any player, then you need to make playersize an array of length (number of players in the game). Then do this:

    • Event: Unit - Any unit dies
    • Actions: Modify playersize[Owner of (Killing Unit)]: +1
    Posted in: Triggers
  • 0

    posted a message on [SOLVED]Play animation on attachment when host attacks
    Quote from DrSuperEvil: Go

    Odd. Should work. Is the model playing the BSD animations?

    /sigh all I had to do was add the BSD on actor creation and now it works. Thanks.

    Posted in: Data
  • 0

    posted a message on [SOLVED]Play animation on attachment when host attacks

    Basically, I have a unit actor and an attachment, and I want the attachment to play its attack animation when the unit attacks. I added a Weapon Start-> AnimPlay Attack event to the attachment, but it doesn't seem to be working.

    Posted in: Data
  • 0

    posted a message on Better Custom Map Ratings! (Example inside!)

    @DarkRevenantX: Go

    You seem defensive or insecure about your map, which you shouldn't be. Mafia is a fantastic and very well done game and has already risen above 99% of the other maps. You've been on the front page for many months. It doesn't really matter what the reviews reflect if your map is already beyond successful, and I think we can safely say that the majority of the sc2 custom map scene has played it by now and knows what to expect rather than depending on reviews to learn about it. At any rate, some of those top reviews just sound trolly and maybe you can get blue to remove them.

    Posted in: General Chat
  • 0

    posted a message on Halo on actor to show only for owning player

    This seems like a pretty simple thing but I think its impossible. I've tried:

    • Creating an actor with 'invisible' model with filter set to show only for self and having it send start halo message to the host actor. This didn't work because the halo is still applied to the host actor (which is a unit actor and thus can't be filtered) so it still shows for everyone.
    • Perfectly aligning an attachment of the same model as the unit actor has, with filters set and halo on and opacity to 0, but the opacity also makes the halo invisible. Can't really have it have opacity 1 because it fidgets at different times and just makes the unit look like it has a double.

    The reason I need to do this is because I need to have this unit very noticeable to the player who owns it but have him sort of blend in with the crowd to enemies. At this point I've basically resigned myself to not being able to use halo and instead having to attach some sort of indicator to him with the filters set. I'm just wondering if anyone has found a way to get something similar to this to work.

    Posted in: Data
  • 0

    posted a message on Actor issues with 1.5
    Quote from TheAlmaity: Go

    @peranzormal: Go

    The first was mentioned in a couple of threads already. You have to use a prefix for texture select to work now.

    The prefix of the Texture or under Texture Declarations - Prefix of the Model? And what would it be if the texture has no prefix, such as how Tassadar has EnergyPlane3.dds with no Tassadar_ in front of it?

    Quote from Kueken531: Go

    2 used to happen a lot with imported WoW models pre-patch, now it happens for a lot of other stuff as well -.- Previously, a solution would be to use a different model without these issues, a Marine was working for pretty much anything (attach stuff to invisible marines attached to the point), but thats obviously a little tedious.

    The new Attach message can be used like this: Add a new actor, type Model, based on ModelAnimationStyleContinuous (or whatever suits your needs)

    Add a new event to that, reacting to the birth of your unit: UnitBirth.x -> Create

    Add a new event to the unit (!) actor (or to the attachment, targeting the unit actor): ActorCreation -> AttachOffset

    Pick the newly created actor in the Actor field, pick the attachment point at the Attach Methods (you might want to use Direct)

    Pick a local offset and rotation to your liking. Offset should be obvious, rotation needs to be in format "x,y,z a,b,c" (without the "") while xyz is the forward vector and abc is the up vector.

    Add any site operation you like (or none), but some of them might mess up the previously defined offsets and rotations.

    Thanks. I was able to get it working with that AttachModelOffset message. Still a big question mark as to why the problem arose in the first place though.

    Posted in: Data
  • 0

    posted a message on Actor issues with 1.5

    So #3 was solved, I'm still clueless about #1, and I still can't get #2 to work properly:

    I tried renaming and recreating all the actors and that didn't fix it. Apparently if my attachment actor uses any Local Offset or Explicit Rotation site ops, it breaks. I tried coming at it from a different angle by using the new Attach actor message on the unit actor, but that didn't work either. No matter how I changed that message it kept giving the error "cannot resolve actor by ref name 'blank'" where blank is the name of my attachment actor. So I'm still pretty confused about this one.

    Posted in: Data
  • To post a comment, please or register a new account.