Open AlphaOmega2020 opened 3 years ago
I had this fixed in one of my scripts. But after a while I noticed the missing delay made problems with building walls and the like. However this issue is solved, the solution should be tested throughoutly
Latest version should work, but needs testing and tweaking. The builder should upon arrival at construction site reduce delay until the next code exectution, estimate the time needed to turn into building direction and keep the construction animation short. It should still have too much slack, but I didnt have time to test optimum values.
Here is my working fast builder from the OPX mod. It builds as fast as someone not using caps lock. Kumu Builder.zip
Sorry I closed it by mistake...
I am still waiting for feedback on the differentiation issue. As I mentioned at the beginning of the month, all I need to know is if you want a suboptimal solution or if the chassis HP will be made available as a workaround for differentiation. ED trench speed was changed in patch 2.0 and the builders have differing build animation lengths in general. Either it gets decided if the scripts should do the optimal build speed for each of the builders, or have a suboptimal one shared by both. It can be done either way, but it has to be decided first. The better solution is not possible without handling the chassis issue.
The final decision as to which race can build faster using recording should be left up to the rebalance team.
My opinion is that all races use an equal but perhaps suboptimal builder script that is able to build at the same speed as using caps lock.
For those players who have minimal lag the builder speed may not matter. For those of us who live at a great distance to Europe and have some lag, I find that it helps especially in the first 5 minutes of game.
I am not going to criticize you working towards an optimal solution for all the races but it seems to me to be a lot of work for small time savings.
Both Builders should build close to their own optimum speed to keep the balance where it is. You can not force the UCS player to do his job manually, because his Builder only runs at 70-75% capacity, while the ED player gets his hands free, because the same script lets his builder run at 90%. Both builders should run at 90% capacity (of what is possible using CapsLock), which means having the script behave slightly different on both of them. We should not create an imbalance by script and expect the rebalance team to fix the issue later (which may not be possible). The builders have different speeds by design; the argument of 'making them different' hangs a bit in the air. Even patch 2.0 specifically states having (for example) the trench speed of the ED builder watered down. 96% of the work went into testing, research and making the algorithm. I dont see a reason not to spend some little bit more time on writing an if-else clause and differentiate by chassis. But in the end I don't really care all that much, and the builders only run at 85% of what is manually possible anyway (you may only guess the turning angle after arrival and set a maximum number of ticks to stay busy building). So good players may still want to manually steer them.
Is your feature request related to a problem? Please describe. Currently the builders have a 0.5-1second delay between each recorded order.
Describe the solution you'd like Remove this delay