SCII Editor: Suggestions & Improvements Thread

Editor Discussion
Prev 1 7 8 9 12 Next
I have a new suggestion : you could add a new kind of validator that will prevent a unit from attacking an unit that it cannot sees. For example, I have an unit that is attacked by another unit on the top of a cliff. This new validator would prevent the unit at the bottom to counter-attack, even if you bring an air unit near (actually, in real life you cannot perfectly aim a target that is unreachable, like behind a wall or over a mountain). This validator could use the unit's line of sight and occlusion height (or vision height), not the player LOS.
wow blizz hasnt been here for over 100 posts :(
There was something that changed after 1.3.

Behavior - Combat (Tab) Modify damage - Triggers (more specifically, the "Event - Unit Takes Damage") now (as of the current patch) takes into account damage modifying Behaviors instead of ignoring it.

[Problem] -"Unit Takes Damage" used to ignore behaviors that modified damage and I took advantage of that (see below for examples).

Technically this was a "bug" and it's fixed but however can an option be added for Behaviors that toggles whether the modify damage amount affects trigger "Event - Unit Takes Damage" or not? Behaviors could have a "check box" that toggles whether the behavior affects "Unit Takes Damage" function or not (for example)

Specifically can there be an option added for "Behavior - Combat > Damage Response" to toggle whether the combat behavior affects triggers (the "Event - Unit Takes Damage") or not?

Now let me explain why and what I used it before:

1. There seems to be no way to currently "Prevent Damage Taken" (including "Fatal Damage") and take into the account the damage that was done.

2. I have things that require a way to take "Real" amount of damage taken and have that damage reduced completely (no fatal damage either).

One example is is a shield ability that absorbs damage dealt to a unit. The shield has health and requires a trigger that obtains the amount of damage dealt.

(Note - I already have Protoss Plasma Shields already used. I wanted an additional layer of shields that is completely triggered)

Most importantly it also prevents fatal damage (Example - the unit has 10 HP but with 100 triggered shield abilities. The unit takes 105 damage. This causes the shield to absorb 100 damage then dealt 5 damage to the unit).

I used Behavior - Combat - Damage response to modify the damage taken to 0. When the trigger detects damage taken, it edits the triggered shield amount (stored on "Custom Value" on a unit), removes the behavior that blocks all damage, deals damage to that unit, then reapplies the shield (if the shield still has hit points left).

Anyway I can't do that now it seems because Triggers (Event - Unit Takes Damage) now takes into account Behavior that modify damage.

I can do it by healing the unit but the problem with that is that it doesn't prevent "Fatal Damage" (see example above).

3. Also a WC3 armor system (where armor reduces damage by a percentages instead of a fixed amount) would also triggers to "ignore behaviors that modify damage".

Basically there are a lot of stuff map editors can take advantage.

Can there be something that lets Event - Unit Takes Damage ignore behaviors that modify damage (not armor just behaviors)? Behaviors could have a "check box" that toggles whether the behavior affects "Unit Takes Damage" function or not (for example).

It would be appreciated it because it opens a lot of damage editing possibilities.
Can you please allows us to change the "Parent" in many of the data editor menus you cannot change the parent and are stuck making your new data as whatever generic folder it sticks it in, changing it in the xml file creates errors most of the time
I figured out why my dialogues were not getting colored anymore. Since the big editor update, dialogues with color set to "white" no longer pay attention to the color of the text parameter (so if you use text with color in the text parameter it will still be white).
I only have a couple suggestion:
When I copy and paste terrain black holes "appears" in the ramps which I can fix by removing and replacing them, but it would be really nice if this was fixed.
And the ability to use a "++" in my code would be extremely useful.
I do not use the blizzard map/mod folders anymore because they were once wiped clean and I like to stay on the safe side. Sadly you cannot select local mods outside of the starcraft2\mods folder.

Allowing a free choice instead of a fixed directory would greatly decrease development time, uploading for every minor test is kind of a hassle (the default map feature does not help if you have to modify more than 1 mod).

Fixing the project setup for the final release is easy enough.
Make the quick test option for mods loads the trigger libraries from the mod, not depending on whether they are referenced or not. Editing the testmap whenever you want to test a mod kind of nulls the advantage of the "default map" test option...
Using the GUI it is not possible to create an operator type function (or action) that uses records.

If, for example, I try to create my 2DVector and want to create a Dot function it has to take x1, x2, y1, y2 instead of 2DVector1 and 2DVector2. This is rather inconvenient.

If using records was allowed, I could simply do the function like this:
(#PARAM(Vector1).lv_x * #PARAM(Vector2).lv_x + #PARAM(Vector1).lv_y * #PARAM(Vector2).lv_y)

It would be inlined like all the other operator type functions and not cause a problem at all.

Edit: added the lv_ prefix to the field names
Add a warning when trigger libraries are not initilaized...

It took me hours of work to find out, that in fact, there was no error in my code. The simple reason nothing worked is that setting an initial value in 'a variable in a library that is linked by a library that is linked by the main map' does not set anything at all.

A simple warning in the message window, that is spammed by other warnings which are way less important, for every library initialization that is not called would be nice.
Would be very useful if we could have a polar offset (IE a radius and a min/max range) for the periodic offsets in a Create Persistent effect. Be far easier to make random offsets than inputting actual grid offsets.
An additional Unit Manipulates Inventory event type would be nice:
Stacking items. (there is a "uses item" one, but why no gains charge?)
There is currently no event for that, meaning that you cant reference the item that got additional charges properly.
Or make the "gains item" event also fire on stacking.
It is possible to make an event like this fire via unit is removed from the game event, but this makes all the item functions useless.
The old Cutscene Editor used to load fairly fast. That way I can preview custom models, find animation names that I want to use for various models and animations, and easily find texture paths for texture declarations. Now the cutscene editor takes at least a full minute to load the resource-intensive little window just so I can look at model data and animations. Could you make a "simple" in-game model-viewer, where we can easily and quickly look at models textures, animations, and attachment points without the huge resource-intensive hassle of the cutscene editor?
I would enjoy seeing improvements to the cutscene editor. Some of the bigger ones are Texture Select by ID support, which realistically would require actor input, and turret rotation. Anything else with this would be terrific.

Trigger or data wise I would really like to see a feature to not just attach actors together but entire units together. This would have a plethora of uses.
Here's my simple suggestion for the trigger editor:

I would like to suggest a function that gives the height map of the Mouse Click Get World Z function that can be used for variables without using the mouse click. Here's why:

Doing some testing with world height mapping I noticed that the World Height at Ground function gives different results than World Z Height at Mouse Click. Looking into it, it seems as if the Mouse function for Z gives close results to how the visual world is represented.

This would allow maps that are sensitive to unit heights to have better performance. Personally, I've been working a lot with particles/projectiles (simple physics) that interact with terrain (bouncing, reflections, etc), and I can't get results that apply to the visual world. It would be nice to have this feature. Or you could make triggers able to use the actor physics engine that's in the data editor:)

Also, maps that are centered around flight and controlling flight like a third-person fight pilot game, would benefit greatly from this.
Could you fix the rally ability? I tried everything, but I cannot put more than 1 type of rally in the ability (you can go to 4), even if I take the hatchery rally. If I try to change the filter of the button, It always replace the first type of rally...
Bigger map options.. I feel the maps are way to small. Even the largest map option when in full expand (bounderies removed completely) still feels like its a medium sized map.


I never liked the organization of the editor and its lack of documentation, but what definitely set me off of learning anything about it was the limitation on map size and ground tiles/textures, because maps that require a lot of different places with distinct environments just happen to be the type I like to develop and I was not up to run that steep learning curve only to find that what I theorized is unachievable.

To give examples, I'll mention a few of the funniest (at least while in their golden days) Warcraft III maps: "LotR: Battle for Middle Earth", which used 256x256, "Azeroth Wars Strategy", which was much larger than 256x256, "The Kingdom of Kaliron", much larger than 256x256, being that the last 2 required a multitude of environments (and thus ground textures) as well.

What also required those multiple environments were RP maps (not RPG), in which you create your own cities, characters and the like and just roleplay (in short, RP maps are your own personalized RPGs where players themselves control everything and nothing is preset).

All of the above mentioned require a lot of terrain, something StarCraft II just can't provide at the moment, not to mention a 256x256 in SC2 is smaller than a WC3 256x256 in comparison, as referred by the poster I quoted.

It deeply saddened me that, on Warcraft III, we spent years trying to break these limitations only to see them consolidated into StarCraft II.

From me in the Europe forums.

By the way, tatatatate, sen²(x) = sen(x) * sen(x)
You're totally wrong man. Do the tests yourself and you will see that sen(x) * sen(x) = sen (x²)
07/10/2013 08:39 AMPosted by tatatatate
You're totally wrong man. Do the tests yourself and you will see that sen(x) * sen(x) = sen (x²)
actually if I recall yx * yx = y^2X^2
Terrain Texture EDGES

Okay seriously I have been wondering why the terrain in SC2 looks sooo crappy in comparison to WC3, an dthe answer is, EDGES, there are none in SC2.... and it looks cheap and bad.

Okay you might be thinking, what is that guy talking about, well I will show you...

now you may be thinking OH, so?, Well the thing is this little thing makes a huge difference, right now all terrain textures look like a bucket of paint was thrown on. and not that there is actual grass or concrete.

I believe that if this easy think is put into place that the game will become very beautiful.

I think the easiest way of doing this, would be to apply an Edge texture file in the editor, All it should be is attached to a texture and simply the painted aplha of the shape, Then have the texture actually control the paint on it. You could also add a priority number that lets the editor know which edge texture to create. and when two textures are the same priority number then simply have the newest one get the edge.

Join the Conversation

Return to Forum