Simikolon

Comments and reviews are highly appreciated

Thanks, patch is submitted now!

Finally, we fixed the bug we initially wanted to fix (#1624). Based on your patch (leper) we introduced a new function in UnitAI to move into formation. Also we added a new order "MoveIntoFormationOrder"to the formation controller to apply a new formation. We did this for conceptual reasons, as changing the formation is now also treated as an order. We think that this is more consistent. We adapted the function MoveIntoFormation in Formation, which actually applies the formation, so it's possible now to get in formation without replacing all individual orders of the formation units. This is the actual fix for the bug #1624. We now would like to submit the patch as an update to leper's patch attaching it to #1716. Unfortunately we can not do so, since registering for the Trac was not yet successful, because we never get a confirmation email to verify our account (tried two different mail addresses).

ok sorry. checked it and it looks you are right. when the units are in the INDIVIDUAL.COMBAT.ATTACKING state and then get a command to move into formation they never leave this state again. we will try to fix this small issue. thanks for your help so far.

We had a look at your patch and actually this is exactly how we would have done it and how we suggested to do it. This patch fixes the issue we described. However, unfortunately when testing the patch, we discovered that there are still issues when changing the formation more often during an attack. After changing it two or three times the units are just standing still and won't attack on their own anymore (usual aggressive behavior). They are not even defending their selves when being attacked. We had a detailed look at your changes and the UnitAI, but could not figure out why this happens. Maybe you have an idea?!

Hi, we explored the task "Units stop the attack after changing formation" and therefore jumped into the UnitAI. The issue is that when doing an attack with a group of soldiers in some formation and changing the formation while they approach the target, the group will stop attacking and just take the new formation. Responsable for the bug are the not yet implemented parts in the formation cotnroller (orders "atack" , "heal", "gather", "gatherNearPosition", "retournResource" and "garrison") marked with TODOs. What is missing is always the approaching part. Adding this fixes the issue. Anyway, we have to make shure that the current order is finished (e.g. "atack": kill unit, then process next order), so we thought of adding a new state for this in the formation controller (e.g. "attacking"), where we then can finish the order if the target was killed. Hence, we would end up with 6 more states. Do you think it's possible to abstract from these 6 states to decrease complexity? Before implementing stuff we wanted to make shure that this approach is reasonable to the developers of this project that have contributed to it for a longer time. Yannick & Simon

Thanks for your info. Indeed, we can't spend too much time, so larger tasks are unrealistic. We thought of about 8 hours of work. It's not that we don't want to do more, but as we have other commitments we have to keep this terminable. Anyway, we'll really give our best to help this project with this small contribution. The game play feature status overview is very helpful, thanks. Simon

Hey, we are two computer science students in the major grade and we are taking a lectuer on software engineering where we should contribute to an open source project. Since we followed the development of 0 A.D with great interest for some time already, we would be very happy if there is something that we can do for you. We know C++ and JavaScript both very well and also have a basic understanding of computer graphics. Of course we checked out the starter tasks and we found the summary screen improvement task quite appropriate, but we noticed that there are already people working on it (http://www.wildfiregames.com/forum/index.php?showtopic=16716). Maybe somebody has another nice and small issue that needs to be fixed or a neat feature to be implemented. Otherwise we will just choose another task from the list of starter tasks. Yannick & Simon