I recently discovered what appears to be an earlier iteration of Nova in the editor. The assets are included, but they're not attached to any units or actors. The unit model is identical to Nova except for her anime-style black pointy hair, but her portrait is pretty different. If anyone is interested, search the model files for Echo.
Anyway, I put her into the game by duplicating all of Nova's models and actors, then just replacing the assets for the unit and portrait models. This works almost perfectly, since all the animations for the unit line up perfectly. The only problem is with the portrait: her face gets all scrunched up and you can see her teeth showing through her jaw.
At first I thought this was just Nova's talking animations coming through, but I've disabled all the animations attached to those sounds. The result is that the portrait actually appears as expected when there's a voice-over (it plays the portrait model's talk animation, but the mouth doesn't move), but then her face just gets all messed up afterward. I also tried switching the facial controller attached to the portrait (and removing it entirely), but that doesn't seem to make any difference. There's no facial controller for Echo, AFAIK.
If you preview the asset itself and check all the animations, there are no problems, so I'm convinced that I'm just missing some point at which Nova's animations are being applied to this portrait (due to the duplication). I've removed everything from the portrait model itself (facial controller, required anims, etc.), so I'm wondering if maybe I'm missing something attached to the unit or one of the actors.
If anyone has any ideas of where else I might be getting the animations crossed, I'd really appreciate it.
P.S. - If anyone else decides to add echo to their map, duplicate the VO sounds and reduce the pitch by 2 semitones; the lower register fits the appearance of the portrait really well.
It might actually be worth it to go with your workaround, but I'm not sure how I would go about enabling/disabling the property in response to a validator check.
The way my mod is set up, players select a target ahead of time, and all targeted abilities target that unit automatically; so even though they're "Effect - Target" as far as the game is concerned, they actually appear to be "Effect - Instant" to the player. The result is that, for example, a medic could be running around spamming targeted healing spells on an ally without reselecting the target each time. The problem is that the medic has to either stop moving after each cast or deal with manually maintaining an appropriate range.
I've run into a dilemma regarding abilities and the "transient" property:
If the property is not checked, a unit will move into range when the player executes the ability against a particular target. If the property is checked, the unit will be able to execute the ability while moving, but it will not automatically move into range.
What I would like to happen when a player uses an ability is:
1. If the target is not within range of the caster, the caster should move close enough and execute the ability. Bonus points if the caster starts moving toward its previous destination after executing the ability, but that's not a requirement.
2. If the target is within range of the caster, the caster should execute the ability and continue along its merry way.
Both of these conditions should apply whether the caster is moving or not.
I've fiddled with the other ability properties to make this work, but no luck. I'm hoping that I just haven't found the right combination.
I actually found a workaround that offers a better solution than I had originally planned. I figured I'd post it, in case someone else runs into a similar problem.
The host can still select the arena, but the default option is "Vote," and each player has an arena selection attribute of their own. If the host selects "Vote," as they must in the public lobby, then the chosen arena will be the one most selected by the individual players.
When making Hugs Vs. Kisses, I spent a bunch of time putting together legitimate option selections for the host in the lobby, since I was never satisfied with the way most custom maps use dialogs at the beginning of the round instead.
Once I released it, though, I found out why most customs use the dialogs.... Once the host makes a game open to the public, they lose their ability to change the options. Since games created through the Join Custom Game menu are public by default, no one in those games can ever select an arena or respawn time for our map!
I've already thought up one workaround: make the options Player Attributes that only the host can see or edit instead of Game Attributes, then just use the options set by the host, but that's messy and unintuitive.
The ideal situation is one in which the host can modify the Game Attributes in a public lobby and the other players can see how they're set. Is there some solution or workaround to this other than the one I described? Is there maybe just some setting I'm missing?
I ran into this problem when I first started Hugs Vs. Kisses. It is very frustrating that it just clearly does not work as you would expect.
My solution was to completely disregard any starting position or team position settings that come with the editor and just make my own. It's really actually pretty simple once you think to do it this way.
using this method, you can allow people to switch teams or colors as much as they like in the lobby without disrupting placement.
1. Create a loop that goes through every active player and assign them to a player group based on their lobby team. This is essential to allow offline testing, since you'll be able to hard code player 1 into one of those player groups to test.
2. Create Normal Points on the map where you want the starting points to be.
3. Loop through each team player group and assign the player from any given team player group to the target point. This step is going to differ based on what you're using the starting point for, but in Hugs Vs. Kisses we basically just need to set it as their respawn point. In that case, it basically looks like this:
Initialize Starting Positions
Events
Local Variables
Team1Count = 0 <Integer>
Team2Count = 0 <Integer>
LoopVariable = 0 <Integer>
Conditions
Actions
Player Group - For each player LoopVariable in Team1Group do (Actions)
Actions
General - Switch (Actions) depending on Team1Count
Cases
General - If (0)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 001
Unit - Change ownership of Refinery [59.50, 32.50] to player LoopVariable and Change Color
Unit - Change ownership of Command Center [20.50, 75.50] to player LoopVariable and Change Color
General - If (1)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 002
General - If (2)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 003
General - If (3)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 004
Default
Variable - Modify Team1Count: + 1
Camera - Pan the camera for player LoopVariable to PlayerPoint[LoopVariable] over 0.0 seconds with Existing Velocity% initial velocity, 10% deceleration, and Do Not use smart panning
Player Group - For each player LoopVariable in Team2Group do (Actions)
Actions
General - Switch (Actions) depending on Team2Count
Cases
General - If (0)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 005
Unit - Change ownership of Refinery [38.50, 63.50] to player LoopVariable and Change Color
Unit - Change ownership of Command Center [77.50, 20.50] to player LoopVariable and Change Color
General - If (1)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 006
General - If (2)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 007
General - If (3)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 008
Default
Variable - Modify Team2Count: + 1
Camera - Pan the camera for player LoopVariable to PlayerPoint[LoopVariable] over 0.0 seconds with Existing Velocity% initial velocity, 10% deceleration, and Do Not use smart panning
Note that's for two teams of up to four players each; it works if fewer than four players join a team, and you can easily modify it to include more. You could also make it more dynamic, but that's not necessary considering the limit of fourteen players.
0
I recently discovered what appears to be an earlier iteration of Nova in the editor. The assets are included, but they're not attached to any units or actors. The unit model is identical to Nova except for her anime-style black pointy hair, but her portrait is pretty different. If anyone is interested, search the model files for Echo.
Anyway, I put her into the game by duplicating all of Nova's models and actors, then just replacing the assets for the unit and portrait models. This works almost perfectly, since all the animations for the unit line up perfectly. The only problem is with the portrait: her face gets all scrunched up and you can see her teeth showing through her jaw.
At first I thought this was just Nova's talking animations coming through, but I've disabled all the animations attached to those sounds. The result is that the portrait actually appears as expected when there's a voice-over (it plays the portrait model's talk animation, but the mouth doesn't move), but then her face just gets all messed up afterward. I also tried switching the facial controller attached to the portrait (and removing it entirely), but that doesn't seem to make any difference. There's no facial controller for Echo, AFAIK.
If you preview the asset itself and check all the animations, there are no problems, so I'm convinced that I'm just missing some point at which Nova's animations are being applied to this portrait (due to the duplication). I've removed everything from the portrait model itself (facial controller, required anims, etc.), so I'm wondering if maybe I'm missing something attached to the unit or one of the actors.
If anyone has any ideas of where else I might be getting the animations crossed, I'd really appreciate it.
P.S. - If anyone else decides to add echo to their map, duplicate the VO sounds and reduce the pitch by 2 semitones; the lower register fits the appearance of the portrait really well.
0
Thanks guys, these suggestions will give me something to experiment with.
The tip regarding the weapon attacks auto-acquiring enemies in particular; I always wondered why the Allow Movement flag didn't seem to do anything.
0
It might actually be worth it to go with your workaround, but I'm not sure how I would go about enabling/disabling the property in response to a validator check.
The way my mod is set up, players select a target ahead of time, and all targeted abilities target that unit automatically; so even though they're "Effect - Target" as far as the game is concerned, they actually appear to be "Effect - Instant" to the player. The result is that, for example, a medic could be running around spamming targeted healing spells on an ally without reselecting the target each time. The problem is that the medic has to either stop moving after each cast or deal with manually maintaining an appropriate range.
0
I've run into a dilemma regarding abilities and the "transient" property:
If the property is not checked, a unit will move into range when the player executes the ability against a particular target. If the property is checked, the unit will be able to execute the ability while moving, but it will not automatically move into range.
What I would like to happen when a player uses an ability is: 1. If the target is not within range of the caster, the caster should move close enough and execute the ability. Bonus points if the caster starts moving toward its previous destination after executing the ability, but that's not a requirement. 2. If the target is within range of the caster, the caster should execute the ability and continue along its merry way.
Both of these conditions should apply whether the caster is moving or not.
I've fiddled with the other ability properties to make this work, but no luck. I'm hoping that I just haven't found the right combination.
0
I actually found a workaround that offers a better solution than I had originally planned. I figured I'd post it, in case someone else runs into a similar problem.
The host can still select the arena, but the default option is "Vote," and each player has an arena selection attribute of their own. If the host selects "Vote," as they must in the public lobby, then the chosen arena will be the one most selected by the individual players.
0
When making Hugs Vs. Kisses, I spent a bunch of time putting together legitimate option selections for the host in the lobby, since I was never satisfied with the way most custom maps use dialogs at the beginning of the round instead.
Once I released it, though, I found out why most customs use the dialogs.... Once the host makes a game open to the public, they lose their ability to change the options. Since games created through the Join Custom Game menu are public by default, no one in those games can ever select an arena or respawn time for our map!
I've already thought up one workaround: make the options Player Attributes that only the host can see or edit instead of Game Attributes, then just use the options set by the host, but that's messy and unintuitive.
The ideal situation is one in which the host can modify the Game Attributes in a public lobby and the other players can see how they're set. Is there some solution or workaround to this other than the one I described? Is there maybe just some setting I'm missing?
0
I ran into this problem when I first started Hugs Vs. Kisses. It is very frustrating that it just clearly does not work as you would expect.
My solution was to completely disregard any starting position or team position settings that come with the editor and just make my own. It's really actually pretty simple once you think to do it this way.
using this method, you can allow people to switch teams or colors as much as they like in the lobby without disrupting placement.
1. Create a loop that goes through every active player and assign them to a player group based on their lobby team. This is essential to allow offline testing, since you'll be able to hard code player 1 into one of those player groups to test.
2. Create Normal Points on the map where you want the starting points to be.
3. Loop through each team player group and assign the player from any given team player group to the target point. This step is going to differ based on what you're using the starting point for, but in Hugs Vs. Kisses we basically just need to set it as their respawn point. In that case, it basically looks like this:
Initialize Starting Positions
Events
Local Variables
Team1Count = 0 <Integer>
Team2Count = 0 <Integer>
LoopVariable = 0 <Integer>
Conditions
Actions
Player Group - For each player LoopVariable in Team1Group do (Actions)
Actions
General - Switch (Actions) depending on Team1Count
Cases
General - If (0)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 001
Unit - Change ownership of Refinery [59.50, 32.50] to player LoopVariable and Change Color
Unit - Change ownership of Command Center [20.50, 75.50] to player LoopVariable and Change Color
General - If (1)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 002
General - If (2)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 003
General - If (3)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 004
Default
Variable - Modify Team1Count: + 1
Camera - Pan the camera for player LoopVariable to PlayerPoint[LoopVariable] over 0.0 seconds with Existing Velocity% initial velocity, 10% deceleration, and Do Not use smart panning
Player Group - For each player LoopVariable in Team2Group do (Actions)
Actions
General - Switch (Actions) depending on Team2Count
Cases
General - If (0)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 005
Unit - Change ownership of Refinery [38.50, 63.50] to player LoopVariable and Change Color
Unit - Change ownership of Command Center [77.50, 20.50] to player LoopVariable and Change Color
General - If (1)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 006
General - If (2)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 007
General - If (3)
Actions
Variable - Set PlayerPoint[LoopVariable] = Start Location 008
Default
Variable - Modify Team2Count: + 1
Camera - Pan the camera for player LoopVariable to PlayerPoint[LoopVariable] over 0.0 seconds with Existing Velocity% initial velocity, 10% deceleration, and Do Not use smart panning
Note that's for two teams of up to four players each; it works if fewer than four players join a team, and you can easily modify it to include more. You could also make it more dynamic, but that's not necessary considering the limit of fourteen players.