It seems the Set is an unused relic, probably an alternative way to ensure the main target takes a hit, which is now done via the Effect-Initial field on the persistent effect.
So, I copied my map onto a USB stick (which works fine for other things), and when I loaded it on my laptop I noticed that some actor data had vanished. These were files I had changed right before copying it onto the stick, so I thought maybe they simply were corrupted from the start.
But then I saved the map onto the stick again and loaded it on my "main" computer some random actor data I hadn't touched in days had simply vanished. It's only actors though, the corresponding units are still there (heck, even the "editor prefixes" of the actors are still saved and return when I recreate the actors) The affected actors were created via the "duplicate" option along with the units, and then renamed.
I didn't get an error message on startup, so I'm not sure this actually is an internal bug, but I'd still like to know what causes it/how to prevent it and whether I can get the data back (I don't have a suitable backup :( )
System is windows 7 on both computers and the USB stick was properly "disconnected" via the windows app after the map was saved, if that matters.
@mods: sorry if this is the wrong section, I don't know whether it's actually a bug, and I only lost actor data so I thought I'd post here.
Increase mining time and carry amount. Only 1 worker can mine at a time, so if they spend more time mining while still bringing in the same amount of resources spreading the workers over more mineral patches is better.
Aiming for a specific income rate is a lot of work, as you'd have to work out the average time a worker spends moving to and from the resource node. Instead I suggest you run a test map with 10 or so fully saturated bases and let them mine for several minutes (you can use triggers to give the initial mine orders simultaneously)
You can add a search effect to the default weapon. That will work like WC3 multishot, i.e. the weapon will hit up to 5 targets, but if there are less than 5 units in range the additional firepower is lost. Also you can't select the targets ingame. There's also a "prefer unmarked units" setup (a search validator/priority filter) which can be used to not waste the firepower.
If you want to allow manual selection of the targets you'll probably have to make an ability to "paint" targets, then make the weapon fire at all "painted" targets to a maximum of 5.
First of all, please improve your demo maps. Add an indicator to anything you want looked at (editor prefix/suffix of "#+" is always helpful). Deleting melee triggers and adding comments on the intended function of things is also helpful for more difficult problems.
Now to your problem. The timed life is applied by the MorphToKerrigan ability of the egg, under Info+, in the "effects" list. (the second scrollable list in the morph details window). Set all entries to "nothing". (there should be only one, called "swarm - timed life" or something)
Your visual problems are caused by the Actors of the units. To simply fix your problem, do this:
1. On the Kerrigan Egg/Cocoon actor, open up Events+ and add:
AbilMorph.*.Finish
=>MorphFrom KerriganEgg (the cocoon unit's name)
Destroy
2. On the Kerrigan (char) actor (the one used for your Kerrigan unit), again open up Events+ and add:
AbilMorph.*.Finish
=>MorphFrom KerriganEgg (same unit as above)
=>MorphTo KerriganChar (your Kerrigan unit)
Create
This will cause the cocoon to instantly turn into Kerrigan upon completing the morph, with no animations whatsoever. Animations can be added via the actor Events+ fields, in this case use the AbilMorph event as a trigger (and adjust Start/Finish/Cancel/whatever). "=>" denotes "arguments", which basically are actor-event-specific validator systems. I added them to ensure that the Kerrigan actor doesn't duplicate itself whenever she burrows, and of course to make sure the events only trigger when morphing the unit an actor is responsible for (standard setup being "=>MorphFrom ->Destroy" and "MorphTo ->Create")
You can also set either the "egg timed life" or the "morph time" to 0 and increase the other one, that will make it easier for the player to discern the total morph time. Or you can use the transition to start an animation (e.g. Cocoon starts to "burst" when the timed life explires, and Kerrigan does her "rising" animation during the morph, just like in the campaign)
Once the timescale is changed to what you desire everything about the unit will move at that speed. When i mean everything i mean every single thing about the unit is affected.
Except buffs/effects that are explicitly set to use a different time scale reference :) (this is actually used by the chronoboost buff itself)
But yeah, it works on attack speed by default. Note that chronoboost also increases things like shield regen rate, so explicitly increasing the attack speed might be preferable to you, while doing both will buff the unit twice.
Looks like you messed up something else. Copy the Marine's Stimpack ability, delete the Effect+ field, remove the prerequsite for use (research check), adjust the costs to your liking. Worked for me in a quick field test anyway.
Maybe some fields were set to undefined/illegal values when you created the abilities.
Mostly the "vertical throw" one. The ability is cast at 0 range, requiring the caster to be perfectly immobile before casting. The mover is set as a downward throw with no acceleration that never blends into anything. The missile hits the ground right next to the target, but doesn't register as "arrived" (until a timeout or something over 10 seconds later...). The now-frozen missile model literally is less than a milimeter away from the "placement model" on the screen.
And the "guided" one with all "face upwards" options on the mover activated randomly changes its 2D rotation, usually "jerking" for 90-180° in an instant.
"Illogical" probably is the wrong word, but the most logical explanation I can come up with is shoddy programming, in which the vertical throw doesn't intersect with the 0-range ability impact point, guided missiles never going perfectly vertically downwards and/or unit facing calculations for missiles using the impact point as a reference, and subsequently going haywire if the 2D coordinates are too close.
The guided "face upwards" mover actually worked well until I set the "extra range"? field to 0 as well as the default ability range ("extra" explained as how far the target is allowed to move from its original position during cast before the ability is canceled, sorry, but my editor isn't in english)
0
Make the bevahior also set the "Passive" flag, as used by Ghost - Hold Fire.
Or deactivate the weapon/suppress attacks if you want to prevent the player from manually attacking as well.
0
There already is a CasterIsStationary validator.
But yeah, just put that in the Validators(Disable)+ field on your cloak buff.
0
The "armor type" (Light, Armored, Structure...) is a list of flags set on the unit (Unit - Attributes+)
Or do you want a Wraith and a Banshee to share the same armor value while in play, including all buffs/debuffs?
0
Nope, not a single one. Only added a prefix of "+ # #" to everything I edited, but as I said those were still there.
At least I managed to recreate most of the losses now.
0
It seems the Set is an unused relic, probably an alternative way to ensure the main target takes a hit, which is now done via the Effect-Initial field on the persistent effect.
0
So, I copied my map onto a USB stick (which works fine for other things), and when I loaded it on my laptop I noticed that some actor data had vanished. These were files I had changed right before copying it onto the stick, so I thought maybe they simply were corrupted from the start.
But then I saved the map onto the stick again and loaded it on my "main" computer some random actor data I hadn't touched in days had simply vanished. It's only actors though, the corresponding units are still there (heck, even the "editor prefixes" of the actors are still saved and return when I recreate the actors) The affected actors were created via the "duplicate" option along with the units, and then renamed.
I didn't get an error message on startup, so I'm not sure this actually is an internal bug, but I'd still like to know what causes it/how to prevent it and whether I can get the data back (I don't have a suitable backup :( )
System is windows 7 on both computers and the USB stick was properly "disconnected" via the windows app after the map was saved, if that matters.
@mods: sorry if this is the wrong section, I don't know whether it's actually a bug, and I only lost actor data so I thought I'd post here.
0
Increase mining time and carry amount. Only 1 worker can mine at a time, so if they spend more time mining while still bringing in the same amount of resources spreading the workers over more mineral patches is better.
Aiming for a specific income rate is a lot of work, as you'd have to work out the average time a worker spends moving to and from the resource node. Instead I suggest you run a test map with 10 or so fully saturated bases and let them mine for several minutes (you can use triggers to give the initial mine orders simultaneously)
0
You can add a search effect to the default weapon. That will work like WC3 multishot, i.e. the weapon will hit up to 5 targets, but if there are less than 5 units in range the additional firepower is lost. Also you can't select the targets ingame. There's also a "prefer unmarked units" setup (a search validator/priority filter) which can be used to not waste the firepower.
If you want to allow manual selection of the targets you'll probably have to make an ability to "paint" targets, then make the weapon fire at all "painted" targets to a maximum of 5.
0
That also prevents the player from manually targeting the unit (not sure if that's what s/he wants)
Edit: Updated demo map with input from DrSuperEvil. HSM still cannot be cast on a unit already targeted by another missile.
0
First of all, please improve your demo maps. Add an indicator to anything you want looked at (editor prefix/suffix of "#+" is always helpful). Deleting melee triggers and adding comments on the intended function of things is also helpful for more difficult problems.
Now to your problem. The timed life is applied by the MorphToKerrigan ability of the egg, under Info+, in the "effects" list. (the second scrollable list in the morph details window). Set all entries to "nothing". (there should be only one, called "swarm - timed life" or something)
Your visual problems are caused by the Actors of the units. To simply fix your problem, do this:
1. On the Kerrigan Egg/Cocoon actor, open up Events+ and add:
2. On the Kerrigan (char) actor (the one used for your Kerrigan unit), again open up Events+ and add:
This will cause the cocoon to instantly turn into Kerrigan upon completing the morph, with no animations whatsoever. Animations can be added via the actor Events+ fields, in this case use the AbilMorph event as a trigger (and adjust Start/Finish/Cancel/whatever). "=>" denotes "arguments", which basically are actor-event-specific validator systems. I added them to ensure that the Kerrigan actor doesn't duplicate itself whenever she burrows, and of course to make sure the events only trigger when morphing the unit an actor is responsible for (standard setup being "=>MorphFrom ->Destroy" and "MorphTo ->Create")
You can also set either the "egg timed life" or the "morph time" to 0 and increase the other one, that will make it easier for the player to discern the total morph time. Or you can use the transition to start an animation (e.g. Cocoon starts to "burst" when the timed life explires, and Kerrigan does her "rising" animation during the morph, just like in the campaign)
0
Except buffs/effects that are explicitly set to use a different time scale reference :) (this is actually used by the chronoboost buff itself)
But yeah, it works on attack speed by default. Note that chronoboost also increases things like shield regen rate, so explicitly increasing the attack speed might be preferable to you, while doing both will buff the unit twice.
0
Looks like you messed up something else. Copy the Marine's Stimpack ability, delete the Effect+ field, remove the prerequsite for use (research check), adjust the costs to your liking. Worked for me in a quick field test anyway.
Maybe some fields were set to undefined/illegal values when you created the abilities.
0
Mostly the "vertical throw" one. The ability is cast at 0 range, requiring the caster to be perfectly immobile before casting. The mover is set as a downward throw with no acceleration that never blends into anything. The missile hits the ground right next to the target, but doesn't register as "arrived" (until a timeout or something over 10 seconds later...). The now-frozen missile model literally is less than a milimeter away from the "placement model" on the screen.
And the "guided" one with all "face upwards" options on the mover activated randomly changes its 2D rotation, usually "jerking" for 90-180° in an instant.
"Illogical" probably is the wrong word, but the most logical explanation I can come up with is shoddy programming, in which the vertical throw doesn't intersect with the 0-range ability impact point, guided missiles never going perfectly vertically downwards and/or unit facing calculations for missiles using the impact point as a reference, and subsequently going haywire if the 2D coordinates are too close.
The guided "face upwards" mover actually worked well until I set the "extra range"? field to 0 as well as the default ability range ("extra" explained as how far the target is allowed to move from its original position during cast before the ability is canceled, sorry, but my editor isn't in english)
0
Tank mode actor gets merc tank mode model (TankMercenary)
Siege mode actor gets merc siege mode model (SiegeTankMercenary)
Both morph models get the merc morph model (SiegeTankMercenaryMorph)
Add matching death models to the sieged and unsieged actors.
0
@DrSuperEvil: Go
The attachment works just fine.
I'm just struggling to understand why meddling with the missile itself does nothing at all, or produce illogical problems if meddling with the mover.