It becomes clearer that you guys do not really review the Editor bug posts in this forum section. No matter, we will solve this right here my good folks.
As an straight foward approach, Iâm going to make it up for you guys. There I shall make sure that the information gets itemized.
-
Update 5.0 Build ability now has the Smart flag. Ok, where now?
-
Ability cooldown event (actor events) no longer reacts since patch 5.0.0 or later (not sure which patch). As a matter of fact, I used to work with it before, and it worked fine. Since that X patch, it doesnât respond to anything, even on units I set it right back then. Iâve run numerous simulations, tried changing the abilityâs cooldown location: nada. It is broken.
-
Unit Compare Kill Count Validator Fixed by patch 5.0.3, thank you.
-
Referencing Duration Random Maximum/Minimum from a buff behavior have inverted text. For example, I want to use data reference from Duration Random Maximum, the text will appear as: <.d ref=âBehavior,SJHyperionRegen,DurationRandomMinâ/>
-
Unit Type Validator cannot validate types Tech Alias of units. It is unable to use see the value on other units. Same goes for requirements unable to see Alias Completed at unit. For example, a requirement cannot see Alias_Barracks completed at unit on a flying barracks. Do not confuse the Completed vs Completed at Unit on this. My bug is exclusively based on âCompleted at Unitâ.
Other Validators: Same goes for âUnit Order Queueâ which cannot trace either ability class, either ability alias related to training, building, Warp Train, Magazine, Research abilities. Now youâre gonna say itâs the queueable ability or queue? Cannot even find it. Summary, it cannot find Generic, Effect, Queue, Queuable, Train, Warp Train, Train, Magazine abilities.
- The âcannot dieâ flag on buff behavior can be outpassed by certain means. In some situations, even a death remove cannot override it. See the Buff behavior page for more info (Sc2 Mapsters).
One easy example on how to âbug itâ is to create a behavior with cannot die flag, and have the field Validator (Remove) : Target Life > 1. Naturally, the buff gets out at one hp, effect resulting from the cannot die blocking the damage, however, try killing this unit over again, you wonât be able to (even if the buff is totally gone). The only way to solve this, is to heal that 1 hp to a greater value, unblocking the glitch. An interesting test shown that using a modify unit effect right after that sets vital to 1 unglitches this bug, as if the number 1 isnât the same value as the one given by the Cannot Die effect.
-
A strange bug discovered with the Oracle. Casting reveal on the primary starting structure creates a duplicated model animation actor on the caster, even tho it is not carrying the behavior (which is on events as âBehavior On/Createâ). I found the exact location of this bug on the target filters of the search effect, the Invulnerable one. If set to allowed, the bug occurs. To reproduce, one must set filters to allow friendly search, used on an effect-target ability. I tried some other abilities, I couldnât reproduce it. Also, it seems to only affect the first structure of the game. Killing this Nexus/Command Center/Hatchery and replacing it by another one will not create the bug.
-
I am currently stucked with a modified âSYSTEM_ActorConfigâ Actor, that is forever edited (green), unable to reset it because I dared adding a Custom Death Priority and deleting it. Actually, I couldnât do it from the table view, I had to force delete it from removing the line in the XML view. Now, the field is grey, but each time I try reseting the field or the actor itself = big crash.
-
Reported and tested by @Biometrix#9544 / Alien#6946: Add Base Multiply doesnât work on damage amount fields (upgrades).
-
Some test made on the Sentryâs Guardian Shield modelâs actor seems to show that making the Create Persistent Effect that holds it âPersist Until Destroyâ or using the model for anything else that is longer than ~60 seconds seems to have the model disappear on its own. We created alternate actors and models, which worked in some cases, but other bubble models seems to freeze their animation, even if theyâre in complete animation bracket start non-stop. This irrational bug also indicates that there seems to be hardcoded errors about these actors/models.
-
Action Actor Launch Asset/Impact map have a âScaleâ option that just DOES NOT work. The only method we have to change a scale, is once again to spam/create more Generic Attack Launch/Impact Actors (Launch Model/Impact Model), that we attach on the action actor with a modified scale. Once again, why could we not spam less files, just for an option that is broken?
-
Modify unit effectâs cost field (that modifies cooldowns) cannot modify an [Arm Magazine] ability cooldown and [Behavior] abilities cooldowns. The process simply ignores the task.
-
Since patch 5.0.0, requierements checking for a behavior completed or completed at unit are no longer limited to behaviors being disabled. So, for example, if a unit has a behavior but that behavior is disabled, it is considered true by the requirement.
-
The new effect, [Last Target] gather type does not work properly, cannot trace any harvest ability what so ever.
-
âSelfâ as a required filter on a search effect does not filters well. It takes every possible target anyway. Using the âIncludeâ while negating all filters does not work as a work around either. The only method I found to outpass this broken feature is have the result of the search lead to an effect with a validator âTarget Is Selfâ unit filter with the self required.
-
Specialize ability cooldowns are ignored if the location is set to âAbilityâ. In other cases, it is ignored if the flag Transient is enabled. There is a terrible set up interaction between the fact that the ability is passive, having to put a queuable ability or not. It is very unclear.
Also, there is a bug related to auto-cast and stunning. If stunned, the auto-cast still keeps cast/spamming the effect, stacking the cooldown time used (for ex, if thereâs a cooldown of 1, it will spam over 25-30 times if the stun lasts ~2-3 seconds.).
-
Please fix the âWorker Requiredâ target filter on the medivac transport ability. Apparently it was fixed on the game, but not on the editorâs dependencies.
-
Ability Train: Kill On Complete is hardly traceable by actor events, and not even by Spawn behaviors that kill their spawns on spawnerâs death. The main problem here, taking a Larva for example, is that on the Eggâs death, the train ability would seem to expect a death event from the Larva. But since we changed actor here, the dying unit that gives birth has its track lost by the training ability that cannot make an event based on its death. It is the very reason why devs came up with the âCreate EggsplosionGenericâ. It still is considred as broken to me.
There is also another problematic with debuffs. When a debuff is applied to an egg, it does not transfer to the newer unit, because it is considered as a duplicate unit created off a dead unit. It would make sense to have behaviors follow up, the same way transfer behavior does for non-innate behaviors.
-
Annoying requirement glitch: When you change a number on a constant, if you dare not to click it twice, selecting another line (example: Upgrade Count) resets the new field that is clicked.
-
Vital accumulator used on âTargetâ location seems to still modify âUIâ value of the casterâs weapon âdisplay damage effectâ field ( that effect is influenced by the accumulator) if the caster has its vital conditions modified. Example: My High Templarâs weapon damage effect used an vital accumulator that has a ratio 5 âAddâ ârelativeâ damage amount with Calculate missing enabled, based on shields vital type, oriented at âtargetâ location (so the target of the effect). This causes my High Templar do deal 5 extra damage when the targetâs shield is at its lowest. Yet the damage dealt works fine, the numbers add up, but when I take down the shield of my high Templar (the owner of the weapon), its weapon shows an increase of weapon damage +5, which is false, but only visually (the real damage dealt isnât influenced). Yet, the casterâs shield shouldnât modify the display, since the accumulator only validates the âtargetâ location of the weapon, not the caster.
-
Data referencing a behavior (buff mostly) cost: cooldown time use (or any other cooldown source on it) is not able to trace that amount. In fact, even your devs seems to already know about that issue and never fixed it. We can see that they built a work around concerning the Immortalâs Barrier cooldown by building a dummy ability from which the cooldown is data referenced, instead of the relevant behavior that controls the Barrier timer. Itâs simple actually, the Passive button for the Immortal barrier cannot reference the REAL cooldown source, which the behavior itself.
-
Since patch 5.0.0 or 5.0.3 (Iâm not sure), the âWalk Animation Speedâ field on unit type actors no longer takes effect. Edit it appears to only affect certain custom models, and some models that belong to Blizzard ex: The Splittering.
-
Updating (or simply setting) the âFractionâ field on a damage does not update the numeric value on the weaponâs UI, although the damage is updated.
-
Unit Compare behavior can fail a simple task, discovered in a specific circumstance. Use an Effect-Target ability, and on the first effect, set a Create Persistent Effect or a Set Effect from which the location is target unit. Good so far. Now set a validator on that Create Persistent/Set first effect (Unit Compare Behavior Count that requires a X behavior on the caster), which stipulates that the caster must have X behavior greater than 0. Works so far. Now, still on the same validator, set that the Required caster of the behavior must be the target. FAILURE. I ran a situation in which the target was clearly the owner of the X behavior, and not only the ability could not aim at anything, it gave an error before I could even choose a target. Same faillure goes for Unit is Tracked Validator. Yes, I know, the failure seems to be that the validator is looking for the target that has not been targeted yet, which conflicts the ability, I get that. It is however, not rational, or proove me wrong, this is not the way that this validator is supposed to operate.
-
Cooldown time start for charges does not work on train, warp train abilities (the only 2 I tested yet), not until I set the location to something else than ability. The cooldown we put in there is simply âignoredâ.
-
Upgrades Cannot create a chance on behaviors (mainly buff behaviors as it is a popular request). For example, if a buff behavior has 0% chance on its damage response, and the modder wishes to activate the chance field by setting it to 1 with an upgrade, the behavior will never adjust, thus staying frozen at 0 chance to give any damage response. It only works if there was a tiny bit % of chance (the editor consideres the field as valid by then), but at 0, it seems that the behaviors consideres it as shutted down permanently. Of course, there is work around that makes the behavior all set on the unit and then only prevented by the requirement, but what of it? Why is the modder to be limited by this kind of restriction? This is another stubborn functionality of the editor that can only be known and told by veterans who identified this problem in the past.
-
I made a Morph Ability, which I needed it in my unitâs actor as an event to apply that unit its Group Animation B. I was never able to trigger the action in the events with the Msg Type: Ability Morph. I had to use the Msg type Ability instead. Sadly, this gives less option (as I cannot use the Cancel Event) and doesnât justify why a more morph specialized event cannot cover its own morph ability to execute the action. Take note that I did not use terms such as Morph From or Morph to. I used the ability directly in the source name.
That being said, it seems that any CActorModel, Sound actors etc, Model Styleoneshot and on and on have a terrible interaction with Morph abilities. They cannot trace any ability morph event. They can trace them however if used with a MSG type âAbilityâ event subname âStartâ, but cannot trace the subname âStopâ part when triggered.
-
On Modify Unit effects: It appears that the âCopyâ Flag from the Modify Flags field works, but in an inverted way. For instance, a Launch Location is where the information is copied from, sent to the Impact Location , which is the unit that should copy life, veterancy, kills, etc. A test has shown that those 2 locations invert the result: the Impact Location sends its information to the Launch Unit, and so, the launch unit gets to copy the Impact location. Careful though, this only concern the copy flag. All the other fields of the effect work well with the Launch/Impact logic, yet.
-
Action Actors refuse any other effect than âDamageâ effect in its âAttack Tokenâ or if there are no damage effect in the child effects. This doesnât seem to reflect the full ramification of what the action actor can do. But letâs pretend I obey to the rule, strict by the editor: My weaponâs first effect is an apply behavior. This apply behavior effect is the Attack Token of my action actor. Then, the only way my action actor will accept it as valid, is if the behavior has a Damage effect in its periodic/initial/refresh effect. Otherwise it is refused. How logic is it that the expire effect is not accounted for it? I mean, I could put it in a periodic effect that sets off .01 second before the expiration, it would do the same. Also, in case I wanna make a work around, I could make a dummy damage effect. But then, I just failed to improve the editorâs functionalities by avoiding to tell you guys about the bug, and I just spam more effects, a more massive file. Weâre talking performance here!
-
Your new field on upgrades: EDSTR_FIELDNAME_CUpgrade_LevelButton: I dont need a functionality that changes the button AFTER the upgrade is complete!? The upgrade already does that (ok perhaps not the upgradeâs âButtonâ, but how useless is this?). In fact, it only changes the button interface in the queue, not the button on the command board. Is it meant to be trivial as such, or do we have a broken feature right here?
EDSTR_FIELDNAME_CUpgrade_LevelRequirements: Works partially. After testing it, I would presume requirements to still be better than using this. Thinking I want to block an upgradeâs max level for example, I could use an impossible dummy requirement (that avoids creating a ton of data), but this doesnât work as expected. We cannot queue the last level of upgrade, not unless the first levels are completed, IF the requirement inserted in this field contains a blockade for the USE part that has nothing to do with the upgrade in itself. So there again, whatâs the point of having this field, if Itâs safer, better to use requirements? For sake, I can even change a requirement upon an upgrade.
-
I used a DeadAnimationRemoveMacro for units witha death time during enough time. Works so far, I could put events in it, but it doesnât work with death by blast, even if the Death Effect is all set up to be ignored on the blast section. This is not normal, or even logical. In fact I ran a test. I made it create an animation to see. The DeadAnimation macro did perceive a death by blast, but then, not able to use events based on a timer within my macro. AND yes, my unitâs death time covers it all, I understand enough of those strict untold mechanics.
-
Any wander behaviors prevent those units from triggering the âImpact Effectâ of a Launch Missile effect, when launched. For example, use a launch effect that throws a larva, you will never be able to trigger the Impact effect of the effect. To be fair, this was in a particular order of effects. I tested other situations in which a unit with a Wander behavior doesnât bug the impact, so Iâll leave it to you guys to contact me if you want to know how I built this bug.
-
On validators, using the Result-Failure âOKâ makes the validator ignored by anything. Also, leaving it to default âErrorâ while having a custom text negates that custom text.
-
On Actor Events, Effect Events using a Launch Missile effect cannot properly identify the âImpactâ Sub name moment in the occurance of the impact. It fails and launches the event at the very start of the Launch Missile effect that is mentionned. Whatâs the point of having âStartâ Sub Name if âImpactâ just ends up being the same.
-
The mechanics for attempting to change a unitâs Turret for another, disabling the old one, is a terrible set up on your side. The limitations to what we can do forces us to morph the unit to another, but yet again, this leads to many other limitations (trust me, Iâll give you the list of what). I canât even think of using a buff behavior, they dont work properly to change the turret and itâs not possible by uppgrades either. It is clearly a bug, because if in fact we cannot put 2 different turrets on a single unit, what is the purpose of a Modify Unit effects that can modify a specified turret ? Pointless, because units cannot handle 2 turrets. Please allow us to to be able to set up turrets on units as we want.
-
Unknown if itâs intended: Removing a behavior with âRemove Behaviorâ effect, based on itâs tech alias also removes the child behaviors created by that behavior, even if they do not own the specified tech alias.
-
Level up effects on veterancy behaviors doesnât do anything.
-
Ability Morphâs Automatic Unmorph does not work without Automatic being enabled. This is a huge problematic for underground turrets, which cannot use the unmorph coponent and an auto-cast at the same time. Contact me for more details on how to cause it.
-
When inserting validators in the info array of a build ability, using copy / paste to add others sometimes bug the Info Validator array and replaces them by âNoneâ when leaving the menu.
-
On unit data, âEnergy Regeneration Delayâ said to be a delay between energy uses doesnât work. You use energy from an ability and the energy still flows.
-
Validator âUnit Orderâ. Attempting to idenfity the auto-cast state of an ability (Set Auto-Cast + Set Auto-Cast On) causes an inverted result. If âSet Auto-Castâ is used only, the validator only checks that the auto-cast is on, which is false. The purpose of âSet Auto-Cast Onâ is to indicate that it is activated.
-
The combinaison of a Morph Placement with an unmorph array causes an unwanted bug, causing the unmorph unit to be unable to use any form of move ability. To reproduce this bug, it is essential to produce the âMorphedâ unit first, and attempt to unmorph it (which doesnât offer the placement function). The process will work, but keep suppressing movement. Producing the moving unit the other way around doesnât cause this bug.
There is also another bug with Morph / Morph Placement. If a unit that can use it, and the resulting unit has âaccelerationâ more than 0 (and 0 speed btw), this will cause a glitch that allows the unit (morphed one) to gain movement speed equivalent of the previous version of unit. The newer unit that shouldnât be able to move. I tested it, it happens on Siege Tank Sieged, and only if the morph ability has been used. Using a created Siege Tank Siege does not trigger the bug. The UI also reveals something, that once morphed into the Siege Mode, it has 0+ 2.7 movement speed (the equivalent speed of unsieged). The source seems to be a conflict between the 2 units. More precise testings on siege tanks have shown that: In any morph abilities, if the Collision delay isnât 0,1 greater than the value of the Mover delay (we donât talk about durations), this causes the immobile unit to gain movement speed from acceleration values. There seem to be a conflict between collision and mover values, but this canât reproduced on every unit. Yet, this is a good indication of where to look at.
-
Adding Acceleration Bonus on a unit, from a buff behavior, returns null if the unit has 0 acceleration as default. Why should it be fair to be able to add movement speed to a unit with 0, but not acceleration? In that case, the only way we can add acceleration on a unit is to have it innate or change the whole catalog for only one unit thatâs affected by a buff.
-
Adding an âAttackâ ability from triggers works, but doesnât sync with actual weapons on the unit (whether the weapon was innate or from a behavior). The only way a weapon responds to an attack ability, is if that attack ability was innate. Thatâs not logical from a system thatâs supposed to give us the privilege to add or remove abilities but to use them.
