Icons:
Sc2 has this right I if recall. When I import an image, I don't want to have to add a border. I don't want to have to make a disabled icon. I don't want to have to set the path to "ReplaceableTextures\CommandButtonsDisabled\DISBTNName.blp". These should be automatically generated when I save.
The button manager is sort of nice, but having to make and import components is frustrating. In addition, my research long ago convinced me the perfect disabled icon (fits original wc3 disabled icons) was made from -50 saturation and -50 brightness in the hue/saturation of a very old edition of Photoshop that I used to have (and of course the additional border). Also, larger images, when turned to an icon, usually looked better with the Sharpen filter applied.
The button manager only applied about -25 to the saturation, making disabled icons that had more coloration than I was used to -- and they were fuzzier without the Sharpen filter. The perfect editor would let me set a picture for a unit and generate all necessary icons, or prove to me this old knowledge was wrong and behave like button manager. When setting an autocast ability to a nonautocast game icon, an autocast icon would be generated. The same would be true of passive abilities. For users who deeply desired a map-wise customization to all of these templates, there should probably be some changeable but out of the way setting buried in something like Gameplay Interface.
Models:
For building models, since all of them usually have the same birth animation, the editor should let you specify what birth animation to generate for a specific group of models. For example, all buildings in an undead race should have a BirthLink attachment node that displays until the last few seconds, at which point a transparent green copy of the building model appears briefly. Night elves are the same but scale up in the last seconds, appearing to 'grow' through the trees in their BirthLink model. The fact that these systematic animations are the same for all models means they should not be baked into the model. However, SC2 makes each building birth animation its own model. This would, I presume (Haven't done a lot of SC2 modding), be an obnoxious time cost for developers who don't actually want to specify which birth model (or generating procedure) for individual buildings. They only want to specify it for groups.
Organization:
After my mention of groups, another dumb limitation of the current editor is brought to light. The races/folders of the unit editor are nice as defaults for rapid development for learning modders, but there needs to be a system for introducing custom folders. It should be easy as a developer to drag a unit from one folder to the other; it should be a feature, and should not lag. In addition, selecting many units at one time and editing a field should allow me to specify one value for that field across all selected units. This would not only apply to "race" (or some redesigned setting that moved what folder they were in) but something like editor suffix could be set for all selected units at a time.
Then, the birth model for buildings, and other settings like which Build ability is used, would be specified on a per-folder or per-group way. Really, building death animations could be specified in this way as well, although non-building units typically have unique and interesting non-generatable death animations.
Also, I definitely should be able to update a unit's Unit ID and have gameplay constants, triggers and JASS, and all object data update its references to that unit ID to be the new one. None of this nonsense about making a new copy in JNGP and redoing everything in it's entirety to refer to the new ID.
Also, because modding routinely requires exploiting game mechanics to produce a desired output, helper dummy units and abilities should be allowed to be stored "inside" other units as though the Parent object was a folder.
Abilities should each have a field, along with their other properties, to put JASS code (or a high level like vJASS or wurst or whatever others are to be used) that would be run when the abilities was cast (EVENT_PLAYER_UNIT_SPELL_EFFECT), toggled on or off (would be custom scripted), channeled (pretty sure there's another JASS event for this), channeling was cancelled (same), and the other relevant JASS events.
Also, I'm pretty sure that the "Abilities - Hero Abilites" list on units and "Stats - Hero Ability" in the Ability tab is super redundant. If an ability is a hero ability, and the unit is a hero, then when you give the unit the hero ability it should be on the hero ability list. I think there's really no good reason for having two lists ("Abilities - Normal" and "Abilities - Hero"). Correct me if I'm wrong.
Techtrees:
Really, the way I tend to think about it, it almost seems like the Techtree fields that reference other rawcodes ("Abilities - Normal", "Abilities - Hero", "Abilities - Default Active Ability", "Techtree - Structures Built", "Techtree - Units Trained", "Techtree - Units Sold", "Techtree - Items Sold", "Techtree - Items Made", "Techtree - Upgrades Used", "Techtree - Researches Available", "Techtree - Dependency Equivalents", tier halls, and the few others that I am not remembering off the top of my head) could all be automatically filled in in most cases. This may be only true of Alternate Melee modding, however, which I have done a lot of for Heaven's Fall and am considering writing software to automate for me. The idea here being that the software would allow rapid development of a techtree with an in-editor 3D model editor, asset manager, data editor, and script editor, that saved something akin to a map file but that could compile to EXE.
These are some basic ideas, I might edit and update with more as they occur to me. The challenge is that not everyone wants the same, so we have to be sure new 'features' aren't too restrictive.
Edit: Cleaned out a lot of typos. Originally typed this post while on my phone at lunch.
