- UID
- 354281
- 阅读权限
- 50
- 注册时间
- 2020-4-22
- 最后登录
- 2023-10-23
- 在线时间
- 635 小时
伯爵
- 耕战
- 100
- 鹰币
- 320
- 天龙币
- 0
- 回帖
- 30
|
本帖最后由 wangzhen 于 2022-6-30 12:34 编辑
组的考虑
先检测组人数 排除不在组
(up-remove-objects search-local object-data-group-flag !=
得到数量为空 再搜索现在有的 清空组 清空组标签 加入搜索的单位到组 加上组标签
(up-reset-group c: )
(up-modify-group-flag 0 c: )
(up-create-group 0 0 c: )
(up-modify-group-flag 1 c: )
(defconst gl-lumberwork 101) 记录伐木工人总数
(defconst gl-local-total 114)
(defconst gl-local-last 115)
(defconst gl-remote-total 116)
(defconst gl-remote-last 117)
(defconst gl-kanshu 118) 临时记录伐木工人数量
(defconst gl-lumbercamp-id 119) 记录第一个找到伐木场的地图ID
(defconst gl-lumbercamppointx 120) 第一个找到伐木场的位置坐标
(defconst gl-lumbercamppointy 121)
(defconst gl-lumbercamp-id2 122) 记录第二个找到伐木场的地图ID
(defconst gl-lumbercamppoint2x 123) 第二个找到伐木场的位置坐标
(defconst gl-lumbercamppoint2y 124)
(defconst gl-groupsize 125) 保存伐木场附近单位
(defconst gl-fangan 126) 开关
(true)
=>
(set-goal gl-lumberwork 0)
(set-goal gl-kanshu 0)
(disable-self)
)
(defrule
(true)
=>
(up-full-reset-search) 清除筛选清空搜索结果
(up-find-local c: villager-class c: 240) 找村民
(up-remove-objects search-local object-data-language-id != lid-villager-lumberjack) 排除不是伐木工人
(up-get-search-state gl-local-total) 获取搜索结果
(up-modify-goal gl-lumberwork g:= gl-local-total) 保存伐木工人数量
)
(defrule
(building-type-count lumber-camp == 2) 确定有2个伐木场
(up-compare-goal gl-lumberwork == 12) 确定有12个伐木工人
=>
;(set-goal gl-local-total 0)
;(set-goal gl-local-last 0)
;(set-goal gl-remote-total 0)
;(set-goal gl-remote-last 0)
(up-full-reset-search)
(up-find-local c: lumber-camp c: 1) 找到一个伐木场
(up-get-search-state gl-local-total) 获取搜索结果
(set-goal gl-fangan -1) 开关
(enable-timer 3 5) 周期性判断 5秒运行一次
)
(defrule
(up-compare-goal gl-fangan == -1)
(timer-triggered 3)
(up-compare-goal gl-local-total > 0)
(up-compare-goal gl-lumberwork == 12)
=>
;(up-chat-data-to-all "找到伐木场" g: gl-remote-total)
(up-set-target-object search-local c: 0)
(up-get-point position-object gl-lumbercamppointx)
(up-get-object-data object-data-id gl-lumbercamp-id)保存第一个伐木场地图ID
(up-full-reset-search)
(set-goal gl-local-total 0)
(set-goal gl-local-last 0)
(set-goal gl-remote-total 0)
(set-goal gl-remote-last 0)
(set-goal gl-kanshu 0)
(up-set-target-point gl-lumbercamppointx)
(up-reset-filters)
(up-filter-distance c: -1 c: 5) 在第一个伐木场5格内需要伐木工人
(up-find-local c: villager-class g: gl-lumberwork)
(up-remove-objects search-local object-data-language-id != lid-villager-lumberjack)
(up-get-search-state gl-local-total)
(disable-timer 3)
)
分三种情况 1每个伐木场附近都有6个伐木工 2第一个伐木场大于6个伐木工 3第一个伐木场小于6个伐木工
(defrule
(up-compare-goal gl-local-total == 6) 等于6个伐木工时候
(up-compare-goal gl-lumberwork == 12)
=>
(set-goal gl-fangan 0)
(up-reset-group c: 0)
(up-reset-group c: 1)
(up-jump-rule 7)
)
(defrule
(up-compare-goal gl-local-total > 6) 大于6伐木工时候
(up-compare-goal gl-lumberwork == 12)
=>
(up-create-group 0 0 c: 1) 保存大于6个伐木工
(up-chat-data-to-all "本地列表%d" g: gl-local-total)
(up-chat-data-to-all "找到超过6个伐木工" g: gl-local-total)
(up-modify-goal gl-kanshu g:= gl-local-total)
(up-chat-data-to-all "伐木人数啊是%d" g: gl-local-total)
;(up-modify-goal gl-kanshu c:- 6)
(set-goal gl-fangan 1)
(up-jump-rule 3)
)
(defrule(up-compare-goal gl-local-total > 0)
(up-compare-goal gl-local-total < 6) 小于6伐木工时候
(up-compare-goal gl-lumberwork == 12)
=>
(up-create-group 0 0 c: 0) 保存小于6伐木工
(up-chat-data-to-all "这个伐木场少于6个伐木工" g: gl-local-total)
(up-chat-data-to-all "伐木人数是%d" g: gl-local-total)
(up-modify-goal gl-kanshu c:= 6)
(up-modify-goal gl-kanshu g:- gl-local-total)
(up-full-reset-search)
(up-find-local c: villager-class g: gl-kanshu)
(up-remove-objects search-local object-data-language-id != lid-villager-lumberjack)
(up-remove-objects search-local object-data-group-flag != 1)
(up-set-target-point gl-lumbercamppointx)
(up-reset-filters)
(up-filter-distance c: -1 c: 5) 在第一个伐木场1到 5格找树
(up-find-resource c: wood c: 10)
(up-get-search-state gl-local-total)
;(up-get-group-size c: 0 gl-groupsize)
(set-goal gl-fangan 2)
;(up-jump-rule 1)
)
(defrule
(up-compare-goal gl-fangan == 2)
;(up-compare-goal gl-groupsize > 0)
(up-compare-goal gl-lumberwork == 12)
(up-compare-goal gl-local-total c:> 0)
(up-compare-goal gl-remote-total c:> 0)
(up-compare-goal gl-lumbercamppointx > 0)
(up-compare-goal gl-lumbercamppointy > 0)
;(up-compare-goal gl-lumbercamppoint2x < 0)
;(up-compare-goal gl-lumbercamppoint2y < 0)
=>
(up-chat-data-to-all "找到树%d" g: gl-remote-total)
(up-chat-data-to-all "找到其他伐木工来这个伐木场" g: gl-remote-total)
;(up-target-objects 0 action-default -1 -1)
(up-target-point gl-lumbercamppointx action-move -1 -1)
(up-full-reset-search)
;(set-goal gl-remote-total 0)
;(up-reset-group c: 0)
;(up-modify-goal gl-lumbercamppointx c:= 0)
(up-jump-rule 4)
)
大于6伐木工时候
(defrule
(up-compare-goal gl-fangan == 1)
(building-type-count lumber-camp == 2)
(up-compare-goal gl-lumberwork == 12)
(up-compare-goal gl-remote-total c:<= 0)
=>
(set-goal gl-local-total 0)
(set-goal gl-local-last 0)
(set-goal gl-remote-total 0)
(set-goal gl-remote-last 0)
(up-full-reset-search)
(up-find-local c: lumber-camp c: 1)
(up-remove-objects search-local object-data-id g:== gl-lumbercamp-id)排除之前找到伐木场地图ID
(up-get-search-state gl-local-total)获取搜索结果
)
(defrule
(up-compare-goal gl-fangan == 1)
(up-compare-goal gl-lumberwork == 12)
(up-compare-goal gl-local-total > 0)
(up-compare-goal gl-kanshu c:> 6)
(up-compare-goal gl-remote-total c:<= 0)
=>
(up-modify-goal gl-kanshu c:- 6) 计算多出来的伐木工
(up-set-target-object search-local c: 0)
(up-get-point position-object gl-lumbercamppoint2x)
(up-full-reset-search)
(up-find-local c: villager-class g: gl-kanshu)
(up-remove-objects search-local object-data-language-id != lid-villager-lumberjack)
(up-remove-objects search-local object-data-group-flag == 0)
(up-reset-filters)
(up-set-target-point gl-lumbercamppoint2x)
(up-filter-distance c: -1 c: 6)
(up-filter-status c: status-resource c: list-active)
(up-find-resource c: wood c: 1)
(up-get-search-state gl-local-total) 在第二个伐木场附近寻找树
)
(defrule
(up-compare-goal gl-fangan == 1)
(up-compare-goal gl-lumberwork == 12)
(up-compare-goal gl-local-total c:> 0)
(up-compare-goal gl-remote-total c:> 0)
(up-compare-goal gl-lumbercamppoint2x > 0)
(up-compare-goal gl-lumbercamppoint2y > 0)
;(up-compare-goal gl-lumbercamppointx < 0)
;(up-compare-goal gl-lumbercamppointy < 0)
=>
(up-chat-data-to-all "找到人和树%d" g: gl-remote-total)
;(up-target-objects 0 action-delete -1 -1)
(up-target-point gl-lumbercamppoint2x action-move -1 -1)找到的工人来第二个伐木场
(up-full-reset-search)
;(up-modify-goal gl-lumbercamppoint2x c:= 0)
;(set-goal gl-remote-total 0)
;(up-reset-group c: 0)
)
(defrule
(true)
=>
(do-nothing)
)
What is Frame Delay?: It's a hidden value that units and buildings have, but that only really matters for ranged land units (it's 0 for buildings and other kinds of units). It measures the amount of time a unit takes to "shoot" a projectile after you order it to attack something. Units with higher frame delay will take more time to shoot their target and vice-versa. It's mainly useful in micro-intensive "hit and run" tactics, where you shoot a unit, then move back and shoot again. Frame Delay is the reason units like Cavalry Archers are more difficult to "micro" since they take a considerable amount of time to shoot after you order them to attack something. On the other side you have Kipchaks, who have no Frame Delay at all, meaning they fire instantly after you order them to do so. Not to be confused with "Rate of Fire" (or Reload Time).
That's the easy way of describing it, but in reality the way the value works is much more convoluted and requires a more in-depth approach. The following is very technical so if you just want to check and compare the final values of each unit and see what changed in DE just jump to the end of the post.
---
First of all, you can't just compare the Frame Delay value (that you can find using the Advanced Genie Editor in the "Units" tab) of different units to determine which ones will shoot faster. That's because Frame Delay actually defines after how many frames of the unit's attack animation the projectile will spawn. What is important to know is that the Frame Delay value directly depends on the unit's attack animation, and since the length and speed of those animations change for every unit, that "base" Frame Delay value is useless by itself. For example, the "Archer" unit has a Frame Delay value of 15.
With that in mind we now have to know those extra values as well, which can luckily be found in the Advanced Genie Editor too. Each unit has an attack animation, and if you go to the "Graphics" tab you can find all the attack animation entries. The two important values to look for are "Frames per Angle" and "Anim Duration".
-Frames per Angle determines the total amount of frames the attack animation is made of. This varies for every unit. For the Archer unit it's 30 frames.
-Anim Duration defines the time in which the entire animation must be carried out (in seconds). This value is also different for every unit. The Archer unit has an Anim Duration of 0.7 seconds.
Alright, with all those values we can now get what I'm gonna call "Effective Frame Delay", which would faithfully reflect the amount of frames of in-game time units take to shoot a projectile and would let us properly compare the Effective Frame Delay of each unit.
Let's start: If you multiply the "Anim Duration" value by 60 (the amount of frames that comprises a second, since the game simulation runs at 60 frames per second) you can find out in how many frames of real game time (at a game speed of 1.0) the attack animation is displayed.
In the case of the Archer unit it's 0.7 x 60 = 42 frames, meaning that the complete attack animation of the Archer unit will take 42 frames of real game time at a game speed of 1.0. Since we also know that the Archer's attack animation is comprised of just 30 frames (Frames per Angle value), it means that they will be stretched to fill those 42 frames of in-game time.
However, the base Frame Delay value of the Archer unit is just 15. So, since the complete attack animation (30 frames) is displayed in 42 frames in-game, using the "rule of three" (math) we get that 15 frames of the attack animation (the amount of frames the projectile is "delayed") would get displayed in just 21 frames in-game (15 x 42 / 30 = 21).
You'll end up with the Effective Frame Delay value, which properly represents the actual frame delay as seen in the game (again, with a game speed of 1.0), and can be checked in-game if you record a video and then count each frame of the unit's attack animation till the projectile spawns in the recording (the game rounds up or down some values here and there, so you can sometimes get a +/-1 frame difference while testing). This is also an actual useful value for players to know (compared with the useless base Frame Delay value), and it can be easily converted to seconds or milliseconds as well if that makes it easier for people to imagine the amount of delay that a unit will have when shooting a projectile. To adjust this value for other game speed settings (1.5, 1.7 or 2.0) you just have to divide the Effective Frame Delay value by one of those speed settings. This means that the Archer unit would have an Effective Frame Delay of 21 frames at a game speed of 1.0 and 12 frames at a game speed of 1.7.
You may now probably be asking: "Ok, but have you figured out that magic value for every ranged unit in the game and then manually tested and checked in-game to see if the theory is actually right?"
The answer is YES! (it took a stupid amount of time though)
Here is a list that shows the Effective Frame Delay value for every ranged land unit in the game (at a game speed of 1.7-normal- since that's the most relevant speed):
Alright, with all those values we can now get what I'm gonna call "Effective Frame Delay", which would faithfully reflect the amount of frames of in-game time units take to shoot a projectile and would let us properly compare the Effective Frame Delay of each unit.
|
|