SC2Mapster

Has anyone noticed these two defects?

A) Given a User Type U with k instances, the trigger function "Number of User Data Instances" of U returns 2k + 1.

B) In a requirement, the sum of the "Count Unit" function returns double the number of units (as does the "Count Unit" function using an alias as an argument).

C) Hiding the mouse cursor disables the "Any unit is highlighted" event. (I guess this is less a defect than a design choice; i was just wondering if anyone's found a work-around.)

Thanks, guys.

I set my dependencies to Void, and now Text Crawl looks like Protoss, despite race being set to Terran :(

@greythepirate: Go

I didn't think of that, but I can't use it in my situation because I don't hide the mouse directly: I set "Lock Camera Mouse Relative Mode" to on, which hides the mouse. I tried generating the same camera motion without this setting, but was unsuccessful.

@greythepirate: Go

My thoughts exactly. That's what we're implementing. Not as nice as the highlighting, though...

@coopdvil: Go

i noticed that the camera position of player is not as regulary updated as it was before 3.0. this might cause some odd behaviour

@FunkyUserName: Go

I don't mind odd behavior. We users can adjust to odd behavior. But simple functions like "Number of User Data Instances" and "Count Unit" returning the wrong values seems more like negligence. Are we the only ones to find these problems with 3.0?

Another random issue I found, causing me problems but easy enough to address.

Issue: When adding Void Dependancy to existing Arcade Map (no other changes) the Command Cards for some units (especially sub-menu cards) get seemingly random commands added. Where the added command button is above the intended command button, then you probably cannot get to the command you want. NOTE: only occurs if you have reused pre-existing submenus from game proper, not original sub-menu's with unique names

Bypass: Check all your command cards. Simply remove unwanted command buttons.

Resolution: Unknown.

Bump...

Or that's a "yes", we're the only ones who has seen these defects?

PS: The problem with the requirements only shows up when the conditions for the requirement change during the game. For example, when the requirement is

CountUnit(X) + CountUnit(Y) < CountUpgrade(Z),

it works fine at run time; but, during the game, when the number of upgrade Z changes for the evaluated player, the requirement actually evaluates

CountUnit(X) + CountUnit(Y) < (0.5) * CountUpgrade(Z)

The same problem exists when we use the expression

CountUnit(A) < CountUpgrade(Z),

where A is the alias of X and Y. We use it for evaluating the number of drones (burrowed and unburrowed), or the number of tanks (tank mode and siege mode). Anyone have a guess as to why this is?

post your requirement here plz

@FunkyUserName: Go

Thank you for the reply. The requirement nodes are pretty simple:

(CountUnit(Drone,QueuedOrBetter) + CountUnit(DroneBurrowed,QueuedOrBetter)) < CountUpgrade(NumberOfWorkers,CompleteOnly)

where "NumberOfWorkers" is a custom upgrade. I tried to replace it with something simpler,

CountUnit(Alias_Drone,QueuedOrBetter) < CountUpgrade(NumberOfWorkers,CompleteOnly)

but the error persisted. However, when I use

CountUnit(Drone,QueuedOrBetter) < CountUpgrade(NumberOfWorkers,CompleteOnly)

the requirement works just fine. Any ideas?