Battle.net

Example: Set the palette size to 16. Change -directly- to the pathing layer and observe that the physical size of the displayed palette is 16, but the actual palette size is 0.5 (and will paint 0.5).

Work-around: After switching to the new layer, change the size of the palette to a different value and then back to the original value.

Expected behavior would be for a new action definition to be created.

I haven't nailed down precisely when this occurs yet, but it seems to occur most often after reorganizing a trigger library by adding new folders and placing new definitions in the new folder.

UPDATE: Happens also when changing the definition of an existing function. Recompiling the scripts have no effect. The only solution is to close the map and reopen it.

It only gives the supply change for losing the cargo ship, but does not count the units inside that also died.

UPDATE: In 1.2.0, some of the units inside the cargo ship are counted, but not all. For example, if a cargo ship filled with 8 marines is killed, the Supplies Used Changes event is only triggered twice, each with a value of -1. Note that the cargo ship is not counted unless it is empty. This behavior differs from the last patch, but is still faulty.

Whenever a unit completes building, the event is fired. This should not happen as the supplies did not change upon unit completion. It does correctly fire upon initial unit training.

Furthermore, the behavior after a unit completes is inconsistent - when 2 zerglings finish morphing, the reported supplies changed is 0.5 (i.e. the cost of 1 zergling). However, when the construction of 2 zerglings begins, a value of 1 for supplies changed is correctly reported.

1.3.0.18015: It is still inconsistent, but different. When 2 zerglings finish, the reported supplies changed (Real) is 0, but when a drone finishes the reported supplies changed is 1. Either way, the event should not fire upon a unit completing.

native point UnitGetAttachmentPoint (unit inUnit, string attachment);

This funtion is suppose to return the coordinate of a specificed attachment point in a unit. But it always return null. Thus the great funcion become no use.

native void PathingModify (region inArea, int inType, bool inAdd);

This function is suppose to modify the terrain pathing of a specificed region. But it never works. I need this function to do a random maze system. Will there be a fix?

native void UnitInventoryMove (unit inItem, int inContainer, int inSlot);

In this build, when you use UnitInventoryMove() to move item slot, the inSlot parameter could not greater than the total slot count of given container, otherwise the item cannot be moved.

It's a bug since the inSlot index of a slot in galaxy doen't equ to the slot index in data editor. Slot[1] in data editor with row="1" Column="7" would be consider as inSlot=8. So the max inSlot of a item Container like WoW Character will definitelly great than the total slots count of this container.

The diablog item type neither labeled as "Blizzard only" in Native.galaxy or in Trigger Editor, but if you try to create a flash item, there will be a script error message :"Calling 'CreateDialogControl' is not authorized".

Starcraft II is better than Warcraft III in the robustness of the game. It crash less than WC3. But when you trying to create a dialog item with a illegal template (DialogControlCreateFromTemplate() ) it will crash the game.

When we try to debugging the actor system, these two galaxy function does nothing. We can't get the debug information of actors before blizzard do some fix.

Addition note: In fact, all "Dump" message in Actor system does nothing.("AnimDumpDB", "RefDump", "RefTableDump", "TextureDump" and "TextureDumpDB".)
DebugString(), DebugUnit(), DebugInt(), DebugFixed(), DebugPoint() does nothing either.

native bool UnitBehaviorHasFlag (string inBehavior, int inCategory);
The inCategory parameter in this function is suppose to have 11 option:

// Behavior categories
const int c_unitBehaviorFlagPermanent = 0;
const int c_unitBehaviorFlagRestorable = 1;
const int c_unitBehaviorFlagTemporary = 2;
// Behavior buff flags
const int c_unitBehaviorFlagChanneled = 3;
const int c_unitBehaviorFlagChanneling = 4;
const int c_unitBehaviorFlagCountdown = 5;
const int c_unitBehaviorFlagExtend = 6;
const int c_unitBehaviorFlagDisableBuilding = 7;
const int c_unitBehaviorFlagRemoveDamageResponseExhausted = 8;
const int c_unitBehaviorFlagRefreshStack = 9;
// Behavior info flags
const int c_unitBehaviorFlagHidden = 10;
But the inCategory actually accept 0 or 1 only (c_unitBehaviorFlagPermanent & c_unitBehaviorFlagRestorable). So the other 11 flags cannot be checked by this funcion. Though we have CatalogFieldValueGet(), so we are not really need UnitBehaviorHasFlag(), but it would be good if blizzard could fix it.

Disable Black Mask is suppose to make the entire map look like has been explored, clear all masks darker than normal fog of war and we can see enemy building's snapshot.

Disable Fog of War is suppose to reveal all explored areas, and all explored areas will no longer be fogged.

So disable both will reveal the entire map. Like "Sawnoutofmemory" cheat.

But now there is bug in this function VisEnable(), disable Black Mask with VisEnable(c_visTypeMask, false) does nothing, and disable fog of war alone with VisEnable(c_visTypeFog, false) will reveal the entire map, not the explored area only.

Using ActorScopeCreate() to create an actorscope will aways throw a error message: Trigger Error in 'xxx': Could not create actor scope.

In despite of this, the actorscope will indeed created, and works fine.This is not a big problem, just some annoying error message, but it would be fine if blizzard could fix it.

It's strange, that send actor message with trigger behaviors different with send actor message in actor editor.

If you write a actor event in actor edit, that let actor A to create actor B, the ::Creator reference of created actor B will be set to A.

But if you send message with galaxy: "ActorSend(A, "Create B")." B will created successfully, but it's ::Creator reference will not be set to A.

If you send actor message with ActorRegionSend() function, and pass the "terms" parameter with a actor event, it will crash the game.

For example, if you try to pass "UnitBirth.Marine" to the "terms" parameter, the game will crash.

I know passing actor event is not supported, but it would be good if there will be some error message instead of just crash the game.

Since 1.2.0 ptr, using action "Melee - Set default melee options for all players" will disable all XP gaining. I reported this in ptr, but no fix.

The Larva Unit has the following properties under CUnit_CardLayouts_LayoutButtons:

AbilCmd: ((##id##Train,Train1|##id##Train,Train2|##id##Train,Train6|...))
Row: ((0|0|0|...))
Column: ((0|2|2|...))
Face: ((Drone|Zergling|Zergling|...))

Notice that Train2 and Train6 have the same properties here. What this means is that when you click on the larva, the image at the 1st row and 3rd column (index 0,2 respectively) is the "Zergling" image, which when clicked should either execute one of Train2 or Train6, or both.

Now if you search for the LarvaTrain ability and look-up Train2, you'll see that it makes 2 Zerglings. Train6, on the other hand, does nothing. Giving Train6 a unit to produce doesn't appear to do anything, so I don't believe it's being run at all; that being said, it's still a fragment hanging around in the code that should be removed.

If you set CBehaviorBuff.Modification.ModifyFlags[SuppressTurning] to true, then the unit which carry this buff can't turn around, but it will also lost the ability to move, even if you set the Turn Before Move flag of this unit to false.

Suppress Turning with galaxy function UnitSetState() however, will works properly, the unit can still move.

Editor string "EDSTR_WATER_ALTERNATESETTING" should not localizable since the value will save to the WaterData.xml.

If it localized as Chinese Characters or other characters, there will be bugs. Since XML files shouldn't have localized data, these characters will become messy code.

If we use zhTW(traditional chinese) Editor, which EDSTR_WATER_ALTERNATESETTING=交替設定. If we create an alternate water state, the water state name in XML will be messy code.

If we open this map with editor again, there will be error message: Error (XML: not well-formed (invalid token)) occurred while loading Water from game data file 'Base.SC2Data\GameData/WaterData.xml'.

And if we try to use triggers action "Set Water State" to change the water state to the alternate state, we can't even save the map, because there is messy code in map script.

WaterSetState("Agria|?o¤???è¨-???", 1.0, c_wtcLinear);

So the editor string "EDSTR_WATER_ALTERNATESETTING" should not localizable. Or blizzard could just make a change, save the alternate water state name into gamestring.txt.

For exmaple, if we have a marine, whose bounty XP is 10, and we use "Set Unit Property" to make it's bounty XP to 500. Then we use "Get Unit Property" to check, it will shows that we have successfully set it's bounty XP to 500.

But if a enemy hero kills him, the hero could only get 10 XP. So it doesn't really work.

If we did any modify in the Data Module and save, then open the map again, the GameData in Import Module preview will show the wrong content.

While we select any xml file under Base.SC2Data/GameData/ the preview actually shows the file with the same name in the last Mod the map depends.

For example:

If we create a map,depending "Liberty"&"Liberty Multi" mods, and change the Marine hp to 100, the content of "Base.SC2Data/GameData/UnitData.xml" will be

<?xml version="1.0" encoding="us-ascii"?>
<Catalog>
<CUnit id="Marine">
<LifeMax value="100"/>
</CUnit>
</Catalog>

And if we save the map, and open it agagin, find the file in Import Module and look the preview, it will shows the content of "Mods\LibertyMulti.SC2Mod\Base.SC2Data\GameData\UnitData.xml" it is a file from "Liberty Multi" mod.

We got a new item type CItemAbil since 1.2.0. But if we put a ability into these items -- for example a Psi Storm Item, it won't send "Abil.PsiStorm.Cursor" event to the actor system, since the abilities in items are not "True" abilities. Thus, there is no way to create cursor splats when we try to cast a item ability. Add a new term like "item.xxx.cursor" event into actor system will be good.

03/10/2011 12:28 AMPosted by Chriso

There are lots of typos and grammar mistakes.

Seriously? Updating the bug list by checking the patch notes only?

In fact almost all of them got fixed in 1.3.0 PTR, Or I would have already added them into my own bug list thread. And I started my own bug report thread just because this thread haven't updated for a long time, and almost all of them have been fixed.

03/15/2011 6:10 PMPosted by SiNiquity

For example, it is easy to verify the Ctrl+W bug still exists in the current patch (highlight an action definition, hit ctrl+w, watch a function definition get created).