- 24/7/09
- 1,422
- 2,843
- Thread starter
- #341
Chủ đề lần này là MUI nhé, lâu quá chả đụng tới topic này, giờ đào lên cho vui nhà vui cửa.
MUI là viết tắt của Multi-Unit Instanceability.
Nói một chút về tác dụng của MUI:
Các bạn thử tưởng tượng, các bạn muốn làm một spell slide bằng trigger, bình thường thì các bạn gán cho biến các giá trị có thể thay đổi (vd: tốc độ slide, gia tốc, góc, caster unit, hay target v.v....), như các bạn biết, các một trigger được CHẠY khi một event được thực thi, chứ không phải là khi event thực thi thì TẠO ra một trigger, vì thế, khi một trigger được chạy, các biến sẽ được gán lại các giá trị, tức các giá trị cũ sẽ bị chồng lên, tuy nhiên điều này cũng không ảnh hưởng nhiều tới một trigger thực hiện những "action" không kéo dài, tức là tất cả các "action" được thực hiện cùng lúc (tất nhiên thứ tự thực hiện các action vẫn từ trên xuống), còn đối với một trigger có "action" kéo dài như slide, dùng timer, thì khi trigger được thực thi trong lúc trigger đó vẫn đang chạy (tức là các "action" vẫn chưa thỏa điều kiện để trigger(timer) dừng) sẽ dẫn tới việc các biến sẽ bị gán chồng lên, target thay đổi, caster (có thể hoặc không) thay đổi, các giá trị thay đổi, và nếu "cái thứ mà bạn đang slide" nó đi ấy, là một unit(dummy, ở đây gọi là unit A cho tiện) thì chắc chắn nó đã được gán vào một biến unit (muốn sử dụng ở trigger khác thì tất nhiên sẽ phải gán vào biến), và khi biến unit đó bị đè lên, thì unit A ban đầu sẽ dừng lại, vì trigger timer chỉ tác động lên unit nằm trong biến unit kia mà unit A đã bị đá ra khỏi biến => unit mới được tạo thì vẫn cứ chạy, còn unit A ban đầu thì dừng lại và ở đó mãi vì các "action" vẫn chưa thỏa điều kiện để remove unit A đi hoặc là làm gì đó với nó. Các biến khác cũng tương tự vậy. Vậy thì MUI sẽ giúp chúng ta giải quyết vấn đề đó, tạo ra một unit mới hoạt động song song với unit cũ.
Thế thì cách giải quyết là như thế nào? Chắc chắn là....................làm thêm vài trigger nữa cho các player khác và xác định luôn từng hero cast spell, và từng unit được tạo ra. Đấy là cái cách mà tôi đã nghĩ đến khi chưa biết tới cách dùng array, tuy nhiên có lẽ nó vẫn MUI tốt trừ khi spell không có cooldown hoặc cooldown xong trước khi trigger dừng hẳn. Dù sao thì cũng không phải là một cách tốt vì khá tốn công copy&paste.
Thôi thì tìm tới array vậy.
Ờm thì ở đây giải thích luôn vụ array cho các bạn chưa biết.
Chúng ta có thể nhận thấy một biến có array sẽ như này : var[1], sau khi thấy cái tên của var hiển thị kiểu này, tôi thấy nó chả khác gì var1, tuy nhiên cái số ở trong [] có thể thay đổi, sẽ tốt hơn khi không phải copy&paste một đống var2, var3,....,varn. Ờm thì chắc chắn là var[1] cũng như var1 và var[2] cũng chả khác gì var2, nhưng quan trọng là var[1] khác var2 => var[1] khác var[2], nói vậy thì biết rồi đấy.
Ngoài ra tôi còn khám phá ra một ứng dụng thú vị của biến integer, có thể gọi là increase, với công thức i = 0, i = i + 1 và khi cái hàm i = i + 1 chạy thì i sẽ tăng. Và một điều tôi thấy nó liên quan kiểu không ngẫu nhiên đó là cái số ở trong [] là integer và hoàn toàn có thể đổi giá trị trong [] đó thành một biến integer (tất nhiên). Và thế là ta đã có var, kết hợp với cái kiểu increase kia thì ta có một đống biến var chả liên quan gì tới nhau mỗi khi trigger chạy các bạn ạ. Ví dụ nhé:
//===================
Event: every 5s
Action:
set i = i + 1
create 1 unit ....
set var = last create unit
//===================
Với một trigger như vậy thì chúng ta đã có thể phân biệt được các unit được tạo ra trong mỗi 5s bằng các var tương ứng. Ví dụ:
var[1] là unit được tạo trong 5s đầu.
var[2] là unit được tạo trong 5s sau (tức 10s kể từ khi bắt đầu game).
v.v...
Như vậy có nghĩa là khi dùng array cho các biến, và áp dụng như trên, thì các biến sẽ không bị đè lên nhau mà khác nhau hoàn toàn và có thể hoạt động độc lập.
Tiếp đê.
MUI là viết tắt của Multi-Unit Instanceability.
Nói một chút về tác dụng của MUI:
Các bạn thử tưởng tượng, các bạn muốn làm một spell slide bằng trigger, bình thường thì các bạn gán cho biến các giá trị có thể thay đổi (vd: tốc độ slide, gia tốc, góc, caster unit, hay target v.v....), như các bạn biết, các một trigger được CHẠY khi một event được thực thi, chứ không phải là khi event thực thi thì TẠO ra một trigger, vì thế, khi một trigger được chạy, các biến sẽ được gán lại các giá trị, tức các giá trị cũ sẽ bị chồng lên, tuy nhiên điều này cũng không ảnh hưởng nhiều tới một trigger thực hiện những "action" không kéo dài, tức là tất cả các "action" được thực hiện cùng lúc (tất nhiên thứ tự thực hiện các action vẫn từ trên xuống), còn đối với một trigger có "action" kéo dài như slide, dùng timer, thì khi trigger được thực thi trong lúc trigger đó vẫn đang chạy (tức là các "action" vẫn chưa thỏa điều kiện để trigger(timer) dừng) sẽ dẫn tới việc các biến sẽ bị gán chồng lên, target thay đổi, caster (có thể hoặc không) thay đổi, các giá trị thay đổi, và nếu "cái thứ mà bạn đang slide" nó đi ấy, là một unit(dummy, ở đây gọi là unit A cho tiện) thì chắc chắn nó đã được gán vào một biến unit (muốn sử dụng ở trigger khác thì tất nhiên sẽ phải gán vào biến), và khi biến unit đó bị đè lên, thì unit A ban đầu sẽ dừng lại, vì trigger timer chỉ tác động lên unit nằm trong biến unit kia mà unit A đã bị đá ra khỏi biến => unit mới được tạo thì vẫn cứ chạy, còn unit A ban đầu thì dừng lại và ở đó mãi vì các "action" vẫn chưa thỏa điều kiện để remove unit A đi hoặc là làm gì đó với nó. Các biến khác cũng tương tự vậy. Vậy thì MUI sẽ giúp chúng ta giải quyết vấn đề đó, tạo ra một unit mới hoạt động song song với unit cũ.
Thế thì cách giải quyết là như thế nào? Chắc chắn là....................làm thêm vài trigger nữa cho các player khác và xác định luôn từng hero cast spell, và từng unit được tạo ra. Đấy là cái cách mà tôi đã nghĩ đến khi chưa biết tới cách dùng array, tuy nhiên có lẽ nó vẫn MUI tốt trừ khi spell không có cooldown hoặc cooldown xong trước khi trigger dừng hẳn. Dù sao thì cũng không phải là một cách tốt vì khá tốn công copy&paste.
Thôi thì tìm tới array vậy.
Ờm thì ở đây giải thích luôn vụ array cho các bạn chưa biết.
Chúng ta có thể nhận thấy một biến có array sẽ như này : var[1], sau khi thấy cái tên của var hiển thị kiểu này, tôi thấy nó chả khác gì var1, tuy nhiên cái số ở trong [] có thể thay đổi, sẽ tốt hơn khi không phải copy&paste một đống var2, var3,....,varn. Ờm thì chắc chắn là var[1] cũng như var1 và var[2] cũng chả khác gì var2, nhưng quan trọng là var[1] khác var2 => var[1] khác var[2], nói vậy thì biết rồi đấy.
Ngoài ra tôi còn khám phá ra một ứng dụng thú vị của biến integer, có thể gọi là increase, với công thức i = 0, i = i + 1 và khi cái hàm i = i + 1 chạy thì i sẽ tăng. Và một điều tôi thấy nó liên quan kiểu không ngẫu nhiên đó là cái số ở trong [] là integer và hoàn toàn có thể đổi giá trị trong [] đó thành một biến integer (tất nhiên). Và thế là ta đã có var, kết hợp với cái kiểu increase kia thì ta có một đống biến var chả liên quan gì tới nhau mỗi khi trigger chạy các bạn ạ. Ví dụ nhé:
//===================
Event: every 5s
Action:
set i = i + 1
create 1 unit ....
set var = last create unit
//===================
Với một trigger như vậy thì chúng ta đã có thể phân biệt được các unit được tạo ra trong mỗi 5s bằng các var tương ứng. Ví dụ:
var[1] là unit được tạo trong 5s đầu.
var[2] là unit được tạo trong 5s sau (tức 10s kể từ khi bắt đầu game).
v.v...
Như vậy có nghĩa là khi dùng array cho các biến, và áp dụng như trên, thì các biến sẽ không bị đè lên nhau mà khác nhau hoàn toàn và có thể hoạt động độc lập.
Tiếp đê.
)
Tin rằng có bức đó giám khảo sẽ đánh giá bài mình tốt hơn cũng như ko bị raivor trừ điểm thế kia 
