SCII Editor: Suggestions & Improvements Thread

Editor Discussion
Prev 1 2 3 12 Next
- We are all aware of the input lag online problem and we know that fixing the issue could require a lot of time. However I thought a couple of temporary solutions that could alleviate the problem:
1) Even single player maps are affected by the input lag issue, can we have a flag to set a map playable only in single player? When the flag is enabled the map is hosted locally with no input lag!
2) The main issue of the lag is the lack of feedback given to players when they press a button or use the mouse. My solution is to allow the use of special triggers that run instantly on client side. These functions would allow only actions that can't break player syncs. Only local variables can be written (globals can be read only) and only graphical stuff can be shown to the player instantly (ex. crosshair actor following the mouse on the world, instant sound and graphical feedback when a player clicks a custom ui button, instant camera movement while moving into an FPS, etc). A native function to show actors only to a single player is required for this purpose.

- Add an easy way to publish a map on different regions, changing the regkey and restarting the editor is quite boring. I saw there is an option in File => Preferences => Battle.net to change region but the feature is not working?!?

- Players coming from "fun or not" are thrown immediatly inside games. However, if a map has a tutorial feature, the player is not warned, forcing him to play a game that probably he won't be able to play. They will probably leave the game and when the rating window pops out they will rate 1 saying that the map is too complex. An alert to request players if they want to try the toturial before playing would be nice.

- Actually there is no way to set render priority of dialogs created by triggers (only for dialog items inside the same dialog). The only solution to this problem is to create them in the correct order, the last one will be rendered on top of the others.
Render priority for dialogs is already supported in the UI xml editor, it would be nice to have a native function to do the same to trigger created dialogs.

- Possibility to attach trigger dialogs to static UI dialogs (I don't think it's possible now)

Also I approve some ideas posted before like:
- Right click detection on dialogs
- Showing play statistics of our maps
- Join in the middle of a game
- Server side banks
- Add collision to doodads created by trigger (if it doesn't lower the performances of the game)
- Code obfuscator (better if a real binary compiler)
- Better map protection
I got asked by a dev to post this here:

Suggestion: Trigger Debug Window

Basically its like this:

If we test via the map editor we can open this dialog that allows us to monitor trigger activity, overhead, threads etc..However not everything performs or behaves the same way when its being hosted off bnet servers.

So I suggest that for private matches you allow the map maker or add a command that allows a player to open that same (or modified) debug window.

If we can monitor trigger usage server side as well as network traffic it would make it much easier to optimize our maps to work on Blizzard servers. This means that we gain because we have less chance of lag and Blizzard gains because we can make our maps less performance intensive on your bnet servers by optimizing code etc to reduce the chance of lag. One method may work better than another when applied to Blizzard servers.

I have noticed more than a few instances that one way of coding a feature will work better on multiplayer than another method of coding the functionality of the same feature.

I would also suggest the following addon. Give us the option to test our maps in the map editor bust hosted off the bnet servers rather than on the local machine. Same reasons as above.
I got asked by a dev to post this here:

Suggestion: Trigger Debug Window

Basically its like this:

If we test via the map editor we can open this dialog that allows us to monitor trigger activity, overhead, threads etc..However not everything performs or behaves the same way when its being hosted off bnet servers.

So I suggest that for private matches you allow the map maker or add a command that allows a player to open that same (or modified) debug window.

If we can monitor trigger usage server side as well as network traffic it would make it much easier to optimize our maps to work on Blizzard servers. This means that we gain because we have less chance of lag and Blizzard gains because we can make our maps less performance intensive on your bnet servers by optimizing code etc to reduce the chance of lag. One method may work better than another when applied to Blizzard servers.

I have noticed more than a few instances that one way of coding a feature will work better on multiplayer than another method of coding the functionality of the same feature.

I would also suggest the following addon. Give us the option to test our maps in the map editor bust hosted off the bnet servers rather than on the local machine. Same reasons as above.


I'm not sure if I understand your words right, but if you want to open Debug Window when you are playing your map on BN. You can use the 'Open or Close Debug Window' action:


Debug Window
Events
UI - Player Any Player presses C key Down with shift Allow, control Allow, alt Allow
Local Variables
Conditions
Actions
Debug - Open the trigger debugging window
Yep, I'm already using the debug window online and it's working.
The only requirement is to run the game in windowed mode (not fullscreen)
When a new object is created (just about any tab), you have the option to define race, category, etc. (xml field e_editorcategories). Now, normally our options are limited. For example, units tab allows us to set an Object Family (Campaign, Melee, Storymode), Race, and Object Type (Unit, Structure, Item, etc). Now, these presets are pretty limiting. However we can overcome them after the unit is created by going to data view (ctrl+d), double clicking the editor category field, and typeing in a new value. Ex. e_editorcategories "ObjectFamily:MyMod,ObjectType:Special\Heroic\CustomUnits". Now, heres the question. Once we have set up a custom definition, how easy would it be to have the editor detect these customizations and allow us to pick that field for future units/items that are created?

Ex. I setup a unit and change the editorcategories to read "ObjectFamily:MyMod". I then go to create a new unit. I hit ctrl + =. A window pops up to set the id, category fields, and default values. When I click the tab for Object Family, I should see a new addition: "Melee, Storymode, Campaign, and MyMod".

It would also be beneficial if there was an option in the dropdown "Custom Family", which added a input box below the ObjectFamily dropdown, that allowed us to type in a new value (which would add the value to the unit, and also add it for future selections)
I'm not sure if I understand your words right, but if you want to open Debug Window when you are playing your map on BN. You can use the 'Open or Close Debug Window' action:Debug Window Events UI - Player Any Player presses C key Down with shift Allow, control Allow, alt Allow Local Variables Conditions Actions Debug - Open the trigger debugging window


Does it include network traffic?
Nope but you don't need it.
Traffic is usually related to syncronization between players, more triggers running at the same time means more used bandwidth. Then you should include the amount of units and things active on your map obviously.
It would be nice if in user types when we click on an instance instead of having a new window pop up the instances fields would pop below the instance list and above the misc properties like Editor Name, Editor Prefix etc.

Also it would be nice if icons would display in either the instances list or in this new window previously mentioned.

Another thing that would be nice is the ability to add editor only names etc to fields like if I have an integer field and each integer is representative of say an objects name in game I could have a Comment like section to name that field. This would basically need to be like a preset in the trigger editor, where I can assign an editor name to an integer value.

As an example I have a user data type for weapons in my game. Weapon ID# 30 is a "Sword". In the editor if I assign one of my items a 30, while I do know its a sword it would be nice if I could have a "sword" comment show up next to the 30 in <> or () or something. This would also help if I didnt work on a section for awhile and went back I could remember what things were.
A lot of the editor work I've done is in the Data Module, and some of it involves levelable abiliies. These in particular can become tedious to make because it's usually easiest, or at least most straightforward, to replicate an ability's entire effect tree for each level, and if core elements of the ability's functionality are changed the map maker has to make sure to update them in every level. There are two things, one small change and one larger piece of functionality, I would appreciate to help reduce the tedium of creating many similar effect trees.

First is the small change. I have noticed that if one data object, Child, has parent object Parent, then Child only meaningfully inherits from Parent when it is created, or when any of its fields are reset. That is, if a field, say, "Effect", in Child is left at default (in xml view, not given a value), and after Child's creation the Effect field of Parent is changed, the editor quietly modifies Child so that it retains the default value it was created with. To me, this is highly counter-intuitive and essentially defeats the purpose of having inheritance at all. I fail to see what the use of this system is. I would like to simply have this changed, so that fields in Child left at their default value will continue to inherit from Parent if Parent is altered. If Blizzard employees have foreseen a context I'm overlooking where the current behavior is desirable, I would hope that we could have either continuous inheritance when the parent has "defines default values" checked, or a new flag/option to create child objects with continuous inheritance. With this feature I could create six levels of an entire effect tree, with levels 2-6 inheriting from level 1, so that the basic functionality could be updated by modifying the level 1 tree alone.

The larger piece of functionality I would love to see is the ability to create what I will call "Prototype" objects. "Template" would also be a descriptive term. The idea is that this is more than a simple parent, because it represents a collection of objects, but appears as a single object. To explain in detail I will jump straight into an example. Let's say that I like "aura" behaviors, that affect units passively in a large area around the source unit. A typical aura behavior consists of two Buff Behaviors, a Search Area Effect and an Apply Behavior Effect. Many of the fields of these objects are either unused or predetermined. I would create a Prototype called Aura to save myself time/trouble by:
- Creating all the objects comprising a complete aura behavior in one shot
- Hiding fields I have no use for in this context
- Displaying useful fields of the component objects together in one place

To do this I would open the Define Prototype dialog, where I would have a list of fields coupled with default values, and a list of component objects. I would be able to add and remove component objects much like in the main window of the Data Module, but they would be local to the Prototype, I'd be required to have at least one, and in my mental image, ids would only be required to be unique within the Prototype. I would be able to add and remove fields much like the adding and removing of tokens in the main window of the Data Module, but the fields of the Prototype would all (with the exception of editor description, etc., which would require special treatment to produce intuitive editor display behavior) map to a field in one of its component objects, though the names of the Prototype's fields would be up to the user. The Prototype would be defined by the user as a certain class of object, in the case of my Aura, a Behavior, but in my opinion there needn't be restrictions requiring this classification to be meaningful. After defining my Aura Prototype I would be able to select "Aura" from the Type dropdown when creating a new Behavior, and the four component objects would be created, though hidden, or at least optionally hidden (perhaps visible only under "view raw data"), with their internal ids prepended (or perhaps combined by a more complex mechanism) to the id of the apparent Aura object I was creating (there would however have to be measures to detect conflicts with these ids)

To substantiate, my Aura Prototype would have the four components:
BuffServer (Behavior, Buff)
Search (Effect, Search Area)
Apply (Effect, Apply Behavior)
BuffClient (Behavior, Buff)
The fields of Aura would consist primarily of the fields of BuffClient, under more or less their standard names, but the duration fields would be excluded. Search Radius, Search Filters, and probably Maximum Count would show up, but I would have not need the Apply fields on a per-Aura basis, and probably nothing more than cost, name, and hidden flag would be visible from BuffServer. This would give me full control over the radiated Buff of each Aura, and a few other important parameters, while hiding irrelevant and predetermined items.
I think this feature would be widely useful, especially if it were easy to use the same Prototypes across multiple maps, and have a degree of flexibility befitting the editor's design goals.
Actually it is not nessary to replicate the whole effect trees to create levelable ablilities in 1.5.

We now have validators to check the ability levels.
If you right click on a field you changed in the parent, you have the option "Apply value to children". This should propagate your changes to the children elements.
Suggestions
(New Ability Type) Ability: Upgrade
Using the research ability is great from learning from a building, however there are times we want our units (note: heros) to learn an “upgrade”. This requires tricky work arounds. I propose a new ability type of “upgrade” be added. This would function similar in nature to Ability: Behavior, but would apply an upgrade instead of a behavior.

(Modification) Effect: Modify Player
In addition to the above, we could use an effect that allowed players to force an upgrade when an effect is cast. Recommend place is the effect: modify player object.

(Modification) Ability: Behavior
1. It would be beneficial if modders could specify how many stacks of a behavior should be applied at each level. This would fall under the “Behaviors+” field. Currently modders have to use long work arounds for passives, which includes setting this field with multiple duplicate fields (ex. Behavior 1, Behavior 2, Behavior 3). Lets say we have a behavior that increases damage by 10. Currently, if we want 3 levels, each increasing by the same amount, we have to define 3 behaviors, and later if we want to change it we have to go to those 3 behaviors and modify them individually. If we could specify the stack count, we could use 1 behavior and apply different stacks of that behavior at each level of the ability.

2. Modders could use a “passive” flag for Ability: Behavior. This would force the behavior to always be on, regardless of situation, as long as the hero had that ability. In addition, the commands for the ability would be modified to have Turn On, Turn Off, and Passive (new). The Passive command would allow us to specify the ability is passive in units command card. Setting the command to passive would ignore any turn on/turn off commands and default to the passive command.

(Modification) Ability: Learn
The base ability needs an Effects+ field to allow players to trigger an effect when any indexed learn ability in the object is used. Additionally, Each index needs an Effect:field where players can specify specific effects to trigger when a particular learn index is used.

(Modification) Ability: Train
It would be beneficial if players could specify validators in the indexes of a train ability to limit what can and cannot be trained.

(Modification) Effects: Apply Behavior
Players need a way to specify the number of points to add to a behavior (for attribute behaviors)

(Modification) Upgrades
Players need a way to modify the stack count/# of points a behavior has.

(Modification) Buttons
Make tooltips an indexed array so players can set multiple tooltips inside of one button

(Modification) Tooltips
String Parsing
-- Currently you cannot nest reference links due to the way strings are handled. Eg, <d ref="Behavior,Levels[Effect,LevelCounter,Amount[0]],LevelGainEffect"/> will not work (note the nested reference). Would be helpful if we could nest references

Add dynamic tag to account for automatic numbering. Eg. <d ref="Effect,GaussRifle,Amount[0]" dynamic="true"/> would show the current output damage for that effect as related to the picked unit (caster, source, target, etc) (Functions the same in nature to Weapon: UI Display Effect, except pertains to tooltips)

(Modification) Effect: (Any): Display Flags [This also applies to other objects with the “Display Flag”]
Add a “Dynamic” Flag. This will force tooltips to always show the current value including buffs etc in tooltips. When unchecked, it will use the default/normal value, or the value as set by the dynamic=”true/false (default false)”.

(Modification) Ability: Morph
Allow morph/cost indexes so this ability can be leveled/learned.

(Modification) Behavior: Conjoined
Flags need the following options:
- Share Inventory
- Share Behaviors
- Share Attributes

Bugs
- Incorrect sale price on items
Consumable items with high max charge and a low starting charge do not sell for the right price. Ex. Set the Items Max charge to 200 and the starting charge to 1. Set a pawn ability that buys your item with a refund of 200. When you sell a stack 10 you'll get back < what you paid for the 10 items. When selling a stack of 100, you'll get back more than you paid for them.

- Effect: Damage
Units do not respect the Combat: Attribute Factor+ field. E.g. if your effect deals 100 damage and you set the attribute factor for light to -0.9 (note, 10% damage), the effect will still do 100 damage to light units, not 10. (This is a new bug to 1.5)

Triggers
The following functions should be added:
-- Create Dialog Item in Panel (Achievement)
-- Create Dialog Item in Panel (Button)
-- Create Dialog Item in Panel (Checkbox)
-- Create Dialog Item in Panel (Image)
-- Create Dialog Item in Panel (Label)
-- Create Dialog Item in Panel (Panel)

Additionally, “Show/Hide Dialog” should default to “show”, not hide (considering created dialogs start off hidden).
This is more of a suggestion for the entire engine.

Max StarCraft 2 map size is only 256x256 and it looks like, at times, you don't dare expand that for fear of massive graphical lag due to rendering area.

But there may be ways around that.

Lets assume that the StarCraft 2 map is divided into 256x256 squares, each 1x1 units in width and length.

Now I sort of do this already and will be making a guide on this in the next few weeks but if it can be more formally supported other things are possible.

Now lets assume I do the following:

1. Zoom in the camera (this leads to terrain looking fuzzy).

2. Set the farclip to just outside a 22'' widescreen (1910x1080).

3. Make units around half size.

4. Increase the resolution of the ground textures from 1024x1024 to 2048x2048 (to take care of fuzzy terrain - I found your engine does support this and I'm not noticing much in the form of performance cost).

At this point what I have is terrain that looks clean (minus cliff edges) but I still have squares that are 1x1 in size.

2 things:

1. A full set of 2048x2048 terrain textures is over 60MB in size. Thats a LOT to download and most players won't wait that long. Is it possible that a full set of 2048x2048 versions of the terrain be added to a future patch? To actually make these all you have to do is rescale the current textures in photoshop. About a max of 15 seconds per texture.

2. Is it possible for you guys to add a feature that "tricks" the game engine into thinking 0.5x0.5 is actually 1x1? I know this means a lot of manual actor scaling but it I think it would be a good way to increase the effective map size without having to modify your graphics engine to support 512x512.

Every square gets split into 4 and footprints are scaled to this as well.

One of the major flaws is having small units but placement footprints still 1x1.

Actually come to think of it maybe adding more subdivisions to the footprint to allow for this might do the same thing.
Its not a engine limitation. Heck, some people have managed to make 512x512 maps. Problem is it gets extremely laggy, even on higher end pcs, because all the units and doodads filling up that space takes processing power. What's really needed is something like Mod/Map compilation, where modders can setup a list of maps their mod uses. Lets take Pobes vs Zealot. Instead of packing 5 maps into one large arena, you set them each into individual map files. Then in the lobby you add an options for players/hosts that allows the host/players to set the "map" or choose random. Much like the ladder map pool. Maps, of course, would have to be tied to the same account to be able to use this feature though.
08/20/2012 06:52 PMPosted by JPNyt
Its not a engine limitation. Heck, some people have managed to make 512x512 maps. Problem is it gets extremely laggy, even on higher end pcs, because all the units and doodads filling up that space takes processing power. What's really needed is something like Mod/Map compilation, where modders can setup a list of maps their mod uses. Lets take Pobes vs Zealot. Instead of packing 5 maps into one large arena, you set them each into individual map files. Then in the lobby you add an options for players/hosts that allows the host/players to set the "map" or choose random. Much like the ladder map pool. Maps, of course, would have to be tied to the same account to be able to use this feature though.


I'm talking about grand strategy maps like SC1 is known for.

And yes it is an engine issue because other games can take far higher unit loads and not have these issues. The fact that a large unit count puts little to no load on the graphics card (in fact many of them run almost idle) shows that the engine was not designed as well as it could have been.

Now the thing is they have stated that they won't allow 512x512 maps so I'm trying to find a way to encourage them to use us effectively the same thing.

You CAN take high unit loads if you set the farclip down. I hear its the render distance but I can't confirm this.
Could we get GUI support for more than 4 command cards? I know for a certainty that it's possible to get at least 5 using XML (and I've heard it's possible to have up to 16). The only problem with that is that once 5+ command cards are implemented via XML, you can't access the command card field using the GUI unless you want your command cards past card 4 to be wiped. Basically, this would get the GUI's functionality to match what you can do using the XML view.
Would be nice if we could get an option in the data module to lock tabs in place. That way we dont accidentally reposition them (ex. when switching from behaviors tab to effects tab)
It would be REALLY nice to have some sort of dialog previewer, maybe as its own module. The dialog previewer should be able to either have some parameters, like color, text, width, height, etc., or even better, take a direct trigger and create all the dialog items that were created in that trigger. That way, we can focus on the whole dialog, instead of just 1 dialog item at a time.

I am sure this has been suggested before, but I feel like we really need this. It isn't very fun to launch Starcraft 2 every 5 seconds :/
yes I have a simple suggestion.

Can you make it so that by default we have 10 instead of 4 menus on the Command Card

With 4 I couldnt Have 1 for each race, and 1 for Special Buildings, and a main page :(

Plus I dont know how to edit XML
What about Hero's am I wanting improvements on, well at the moment Better XP Leveling Formula support, more modification of Hero Stat's in WarCraft 3 Hero Stat's were built in and preset to Strength, Agility, and Intelligence. In StarCraft II we can Name them and setup how they work but only add or subtract to them currently. I find the current Hero support not enough for what I'd like to do, so here are some improvements I'd love to make it easier to do.

The Hero XP setup is currently best done with a 3rd party tool in my opinion, were you can set the max level (say 100) and a basic XP Multipled by Level. So you Can Set Level 1 to level up 100 XP aka (Hero Level) 1 * 100 then Level 2 would be 200 XP to level up, ect until Max Level. You could make it a 1000 Multiplier per level too, or any value per level you want. I hope that was clear enough basically I want to set a Max Hero Level and how much XP per Level is needed to gain the next level without typing it out once for each level.

I would love it if in the Editor you could set a Formula for XP Required to Level. That way you Could have even more complicated Level Up formula's very fast compared to typing it out manually for each level currently. A example would be Set Max Level 100, XP Formula Hero Level * 1000 + Random Number between 1 and 999. something like that would be incredible as Level 1 might need 1374 XP and Level 2 might be 2987, ect. Then go in to the current system and edit more specifically if you want Level 2 to be 2980.

The other thing I'd like is Multiplying and Dividing of Hero Stats, as of Patch 1.5.2 you can modify a Hero Stat you created by Adding or Subtracting to it, but no Multiplication and Division. I'm not sure why that's been removed since Warcraft 3 had this for hero's. I'm hoping it just got overlooked after Adding & Subtracting was added, if the problem is that the data editor does not currently know what a Hero's current Strength, Agility, Energy (Intelligence) is can you please add support for this.

I'd also like to be able Set different XP Leveling Formula's, Example Set XP Formula for Level 1 to 10 to be Hero Level * 100 then Level 11 to 40 to be Hero Level * 1,000, Level 41 to 80 to be Hero Level * 10,000, and last Level 81 to 100 to be Hero Level * 100,525. If my Math is correct Level 100 you Should have 2,441,500 XP.

Thanks so much I hope this can be done before Heart of the Swarm, if I'm not clear enough ask me in this forum and I'll try t clearify.

Join the Conversation

Return to Forum