| 1 |
hello @aeonios !
|
1 |
hello @aeonios !
|
| 2 |
\n
|
2 |
\n
|
| 3 |
Its great that you are interested in CBAI, but also worrisome when you said most of its components was redundant.
|
3 |
Its great that you are interested in CBAI, but also worrisome when you said most of its components was redundant.
|
| 4 |
\n
|
4 |
\n
|
| 5 |
As a defence I will help elucidate the working component.
|
5 |
As a defence I will help elucidate the working component.
|
| 6 |
\n
|
6 |
\n
|
| 7 |
[quote] I also need xponen to help me comment his changes regarding continuous reassignment and keeping items on the build queue until they're completely finished[/quote]
|
7 |
[quote] I also need xponen to help me comment his changes regarding continuous reassignment and keeping items on the build queue until they're completely finished[/quote]
|
| 8 |
First, focus on myQueue[hash], this is a remake of Spring's build-queues, it list the coordinates and type of build. Remove its content will remove the available job for constructors and also the UI green box.
|
8 |
First, focus on myQueue[hash], this is a remake of Spring's build-queues, it list the coordinates and type of build. Remove its content will remove the available job for constructors and also the UI green box.
|
| 9 |
\n
|
9 |
\n
|
| 10 |
To make job re-assignable, keep its entry undeleted. The entry will be scanned by GetWorkFor() when assigning job, and emptied by widget:UnitFinished() when build finishes and occasionally by CleanOrders() when obstruction is detected. ( note: new patch that fix CleanOrders() in ZK-test )
|
10 |
To make job re-assignable, keep its entry undeleted. The entry will be scanned by GetWorkFor() when assigning job, and emptied by widget:UnitFinished() when build finishes and occasionally by CleanOrders() when obstruction is detected. ( note: new patch that fix CleanOrders() in ZK-test )
|
| 11 |
\n
|
11 |
\n
|
| 12 |
10 worker are collected at one time by FindEligibleWorker() to be assigned for jobs. (it is limited to 10 due to performance concern)
|
12 |
10 worker are collected at one time by FindEligibleWorker() to be assigned for jobs. (it is limited to 10 due to performance concern)
|
| 13 |
\n
|
13 |
\n
|
| 14 |
The job assignment loop isn't redundant, each loop find something necessary:
|
14 |
The job assignment loop isn't redundant, each loop find something necessary:
|
| 15 |
1st iteration, find the closest job for all 10 worker (GetWorkFor())
|
15 |
1st iteration, find the closest job for all 10 worker (GetWorkFor())
|
| 16 |
then, it find worker nearest to its job and assign it to that job ( GiveWorkToUnits())
|
16 |
then, it find worker nearest to its job and assign it to that job ( GiveWorkToUnits())
|
| 17 |
2nd, it repeat them with next 9 worker...
|
17 |
2nd, it repeat them with next 9 worker...
|
| 18 |
3rd, repeat for next 8 worker..
|
18 |
3rd, repeat for next 8 worker..
|
| 19 |
then, 4th -> next 7, 5th -> next 6, ect...
|
19 |
then, 4th -> next 7, 5th -> next 6, ect...
|
| 20 |
\n
|
20 |
\n
|
| 21 |
When 1 worker got new job it changes the environment for other worker, so next iteration need to rescan the queues (eg: whether to assist job or create new one).
|
21 |
When 1 worker got new job it changes the environment for other worker, so next iteration need to rescan the queues (eg: whether to assist job or create new one).
|
| 22 |
\n
|
22 |
\n
|
| 23 |
[quote]The biggest issue right now is that the method for assigning jobs to workers is inconsistent, which causes workers to run around in circles starting random jobs without completing them and sometimes jobs never get finished at all.[/quote]
|
23 |
[quote]The biggest issue right now is that the method for assigning jobs to workers is inconsistent, which causes workers to run around in circles starting random jobs without completing them and sometimes jobs never get finished at all.[/quote]
|
| 24 |
Useful feedback, thanks, this is a bug.
|
24 |
Useful feedback, thanks, this is a bug.
|
| 25 |
\n
|
25 |
\n
|
| 26 |
A code labelled "--Collect busy worker for reassignment--" (latest version from ZK Github) control the re-assignment. Its currently very simple and by removing "queueType.buildQueue" from "matchAssistOrBuildQueueType", you will at least make 1 worker stay on its job.
|
26 |
A code labelled "--Collect busy worker for reassignment--" (latest version from ZK Github) control the re-assignment. Its currently very simple and by removing "queueType.buildQueue" from "matchAssistOrBuildQueueType", you will at least make 1 worker stay on its job.
|
| 27 |
\n
|
27 |
\n
|
| 28 |
Improving this code will give smarter reassignment.
|
28 |
Improving this code will give smarter reassignment.
|
| 29 |
\n
|
29 |
\n
|
| 30 |
p/s: I didn't see this bug because I usually keep queue short
|
30 |
p/s: I didn't see this bug because I usually keep queue short
|
| 31 |
\n
|
31 |
\n
|
| 32 |
[quote]The recent changes also included a function which favors expensive jobs, however I never saw a necessity for such a feature and I intend to remove it. Also now whenever you queue up a singu or anything in that cost range or greater your workers will all unanimously abandon their jobs, for example building porc at the front line, to go and help on the stupid singu or whatever.[/quote]
|
32 |
[quote]The recent changes also included a function which favors expensive jobs, however I never saw a necessity for such a feature and I intend to remove it. Also now whenever you queue up a singu or anything in that cost range or greater your workers will all unanimously abandon their jobs, for example building porc at the front line, to go and help on the stupid singu or whatever.[/quote]
|
| 33 |
This is reassignment bug, not Singu! Don't remove the code. More worker to Singu is a correct choice. If worker didn't abandon porc due to re-assignment then everything work perfectly.
|
33 |
This is reassignment bug, not Singu! Don't remove the code. More worker to Singu is a correct choice. If worker didn't abandon porc due to re-assignment then everything work perfectly.
|
| 34 |
\n
|
34 |
\n
|
| 35 |
[quote]The code also contains several functions that attempt to stop units from suiciding into enemy territory, however some of them may conflict and in practice they cause very stupid behavior. Basically the only one qualified to make those decisions is the player,[/quote]
|
35 |
[quote]The code also contains several functions that attempt to stop units from suiciding into enemy territory, however some of them may conflict and in practice they cause very stupid behavior. Basically the only one qualified to make those decisions is the player,[/quote]
|
| 36 |
Another feedback, thanks, it need improvement.
|
36 |
Another feedback, thanks, it need improvement.
|
| 37 |
You should use Direct command to build in enemy territory, else if you use Queue it obey CBAI rules (such as de-prioritize your Queue or remove it).
|
37 |
You should use Direct command to build in enemy territory, else if you use Queue it obey CBAI rules (such as de-prioritize your Queue or remove it).
|
| 38 |
\n
|
38 |
\n
|
| 39 |
[quote]Currently it does not handle reclaim at all, which sucks. [/quote]
|
39 |
[quote]Currently it does not handle reclaim at all, which sucks. [/quote]
|
| 40 |
It don't need reclaim because it's not meant to be independent of player.
|
40 |
It don't need reclaim because it's not meant to be independent of player.
|
| 41 |
\n
|
41 |
\n
|
| 42 |
I had widget that control reclaim without conflict with CBAI. Why CBAI is awesome? because it never conflict with other AIs and user. With dedicated widget I can get more advance behaviour.
|
42 |
I had widget that control reclaim without conflict with CBAI. Why CBAI is awesome? because it never conflict with other AIs and user. With dedicated widget I can get more advance behaviour.
|
| 43 |
\n
|
43 |
\n
|
| 44 |
[quote]1: In previous iterations items were removed from the build queue as soon as a constructor started working on them, so that in order for another cons to assist it had to either copy the order from the working constructor or use a guard order. Since xponen fixed it so that jobs stay on the queue until completely built this is no longer an issue.[/quote]
|
44 |
[quote]1: In previous iterations items were removed from the build queue as soon as a constructor started working on them, so that in order for another cons to assist it had to either copy the order from the working constructor or use a guard order. Since xponen fixed it so that jobs stay on the queue until completely built this is no longer an issue.[/quote]
|
| 45 |
Certain worker had limited buildOptions, such as Athena. So GUARDing is never obsolete.
|
45 |
Certain worker had limited buildOptions, such as Athena. So GUARDing is never obsolete.
|
| 46 |
\n
|
46 |
\n
|
| 47 |
[quote]2: Orders given by direct command without shift were never added to the queue, so the only way to assist those jobs was through extra logic. I've modified that code so that now all build jobs are added to the queue whether shift is held or not, although the constructor that was given the direct order will still carry it out immediately as it should.[/quote]
|
47 |
[quote]2: Orders given by direct command without shift were never added to the queue, so the only way to assist those jobs was through extra logic. I've modified that code so that now all build jobs are added to the queue whether shift is held or not, although the constructor that was given the direct order will still carry it out immediately as it should.[/quote]
|
| 48 |
Direct command is already stored in myQueue[hash] (this is contrast to the claim). Its hash start with "queueType.buildNew", while hash for Queue start with "queueType.buildQueue".
|
48 |
Direct command is already stored in myQueue[hash] (this is contrast to the claim). Its hash start with "queueType.buildNew", while hash for Queue start with "queueType.buildQueue".
|
| 49 |
\n
|
49 |
\n
|
| 50 |
[quote]The new cost/assignment model will also eliminate the need to differentiate between 'primary' and 'assisting' constructors in general.[/quote]
|
50 |
[quote]The new cost/assignment model will also eliminate the need to differentiate between 'primary' and 'assisting' constructors in general.[/quote]
|
| 51 |
Removing "assistBuild" tag will loose the core idea/concept of unit interaction, which is "one builder--many helpers".
|
51 |
Removing "assistBuild" tag will loose the core idea/concept of unit interaction, which is "one builder--many helpers".
|
| 52 |
\n
|
52 |
\n
|
| 53 |
The tag could be used to code for more behaviour or for UI.
|
53 |
The tag could be used to code for more behaviour or for UI.
|
| 54 |
\n
|
54 |
\n
|
| 55 |
[quote]This was supposed to cancel build orders when allied wrecks or 'dragon teeth' (whatever that means) are in the way. This was disabled by default with no interface for enabling it, and, as far as my experience goes that kind of thing is not a major issue in real games anyway. [/quote]
|
55 |
[quote]This was supposed to cancel build orders when allied wrecks or 'dragon teeth' (whatever that means) are in the way. This was disabled by default with no interface for enabling it, and, as far as my experience goes that kind of thing is not a major issue in real games anyway. [/quote]
|
| 56 |
CBAI is proud to maintain portability with any Spring mod. In old days, tweaking widget directly is normal.
|
56 |
CBAI is proud to maintain portability with any Spring mod. In old days, tweaking widget directly is normal.
|
| 57 |
\n
|
57 |
\n
|
| 58 |
[quote]I did figure out how pathing is calculated. It turns out it's calculated redundantly in 3 different places, and at least once globally for updating myQueueUnreachable over all units. I found out the global calculations are only used in a few peripheral functions that aren't actually necessary. It also turns out that the GetWorkFor function calculates the pathing in every iteration anyway, but I'll probably just clean up the IsTargetReachable function and use that instead. One of the functions for calculating pathing looks to be entirely redundant and not entirely functional.[/quote]
|
58 |
[quote]I did figure out how pathing is calculated. It turns out it's calculated redundantly in 3 different places, and at least once globally for updating myQueueUnreachable over all units. I found out the global calculations are only used in a few peripheral functions that aren't actually necessary. It also turns out that the GetWorkFor function calculates the pathing in every iteration anyway, but I'll probably just clean up the IsTargetReachable function and use that instead. One of the functions for calculating pathing looks to be entirely redundant and not entirely functional.[/quote]
|
| 59 |
CBAI don't use pathfinding for job assignment but use 2D distance for cost reason.
|
59 |
CBAI don't use pathfinding for job assignment but use 2D distance for cost reason.
|
| 60 |
\n
|
60 |
\n
|
| 61 |
(
low
res)
Pathfinding
is
still
used
to
check
for
inaccessible
build
site
(
eg:
sea
<->
inland
<->
wall
barrier)
and
de-prioritize
them.
Its
done
periodically
and
when
we
add
Queue.
|
61 |
Periodic
pathfinding
check
for
inaccessible
build
site
(
eg:
sea
<->
inland
<->
wall
barrier)
and
de-prioritize
them.
|
| 62 |
\n
|
62 |
\n
|
| 63 |
It's stored in "myQueueUnreachable[unitID][hash]" as integer 0(clear),1(enemy!),2(blocked)
|
63 |
It's stored in "myQueueUnreachable[unitID][hash]" as integer 0(clear),1(enemy!),2(blocked)
|
Central Build Widget