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
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?
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?
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.
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.)
0
@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?
0
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?
0
@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?
0
@greythepirate: Go
My thoughts exactly. That's what we're implementing. Not as nice as the highlighting, though...
0
@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.
0
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.