Loading...
  OR  Zero-K Name:    Password:   

Post edit history

Central Build Widget

To display differences between versions, select one or more edits in the list using checkboxes and click "diff selected"
Post edit history
Date Editor Before After
4/16/2015 7:17:44 AMUSrankaeonios before revert after revert
Before After
1 [quote]It don't need reclaim because it's not meant to be independent of player. 1 [quote]It don't need reclaim because it's not meant to be independent of player.
2 \n 2 \n
3 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.[/quote] 3 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.[/quote]
4 \n 4 \n
5 There are a couple of problems with this. First of all CBA first and foremost distributes workers to jobs, and for that reclaim/repair/ressurect are no different from building jobs. You still have to give the orders for that to get on the queue at all one way or the other. Having to direct order workers means finding nearby workers manually, which for expensive jobs is fine but for reclaim is much more tedious. It's also inefficient if the reclaim job is far away from your workers, in which case you probably should just wait until they get around to that area again, or wait for new workers that may be closer. CBA already does that for other jobs, so it wouldn't add any extra effort. CBA can also prevent reclaim jobs from ever being performed if they're added with shift. 5 There are a couple of problems with this. First of all CBA first and foremost distributes workers to jobs, and for that reclaim/repair/ressurect are no different from building jobs. You still have to give the orders for that to get on the queue at all one way or the other. Having to direct order workers means finding nearby workers manually, which for expensive jobs is fine but for reclaim is much more tedious. It's also inefficient if the reclaim job is far away from your workers, in which case you probably should just wait until they get around to that area again, or wait for new workers that may be closer. CBA already does that for other jobs, so it wouldn't add any extra effort. CBA can also prevent reclaim jobs from ever being performed if they're added with shift. EDIT: ie it does this currently, which is bad, but would not if it handled reclaim correctly.
6 \n 6 \n
7 CBA also does not work well with other widgets that try to control constructors. The auto reclaim/repair/assist widget for example spams random fight orders and will prevent CBA from assigning them jobs. Letting CBA handle user-added reclaim commands would not have the same issues. 7 CBA also does not work well with other widgets that try to control constructors. The auto reclaim/repair/assist widget for example spams random fight orders and will prevent CBA from assigning them jobs. Letting CBA handle user-added reclaim commands would not have the same issues.
8 \n 8 \n
9 \n 9 \n
10 I figured out how FindEligibleWorker() works and what you did to get it to reassign queue-controlled workers. I simplified that slightly and removed some dead commented-out code to clean it up. I couldn't find the comment you referred to, but I'll add some for future reference. 10 I figured out how FindEligibleWorker() works and what you did to get it to reassign queue-controlled workers. I simplified that slightly and removed some dead commented-out code to clean it up. I couldn't find the comment you referred to, but I'll add some for future reference.