Dec 15th 2010, 4:18:01
Couple upsides:
1. Less queries/data exchange to server
2. Easier war set up
3. If a "if bounce" statement could be put in, it could save some wasted turns on speed hitting
Couple downsides:
1. Unfair advantage to hitter in killing (walling would be virtually impossible, unless there was a .refresh command inserted to make them not instant).
2. readiness management would be awfully difficult, and could be thrown off by rounded #'s of hits
3. Could potentially create 10 bounced hits if target bought up between spy op and hits being sent, instead of just one (see "if bounce" comment)
Couple thoughts in general:
1. Not a fan of the idea overall. I think it takes the level of automation a bit too far for my taste. I personally enjoy spamming hits, and know that if you know what you're doing sending hits quickly is quite easily.
2. It would be nice to cut down on DB connections, but I'm not sure if this is a good way to do it due to the dynamic nature of war.
3. IF this were to be implemented, I would suggest a max of 5 hits to allow for a little bit better readiness management. Another option would be to allow the user to designate the number of hits to be made - so for example, I could select 18 hits for a tyr to run readiness to %25.
4. As an alternative, would it be possible to create an ajax interface which syncs to the DB say every 5th hit and registers unit loss/gain internally instead, and then verifies synchronized elements with the DB after 5 hits? This would cut down on db exchanges, and speed up page load times locally for the user.
1. Less queries/data exchange to server
2. Easier war set up
3. If a "if bounce" statement could be put in, it could save some wasted turns on speed hitting
Couple downsides:
1. Unfair advantage to hitter in killing (walling would be virtually impossible, unless there was a .refresh command inserted to make them not instant).
2. readiness management would be awfully difficult, and could be thrown off by rounded #'s of hits
3. Could potentially create 10 bounced hits if target bought up between spy op and hits being sent, instead of just one (see "if bounce" comment)
Couple thoughts in general:
1. Not a fan of the idea overall. I think it takes the level of automation a bit too far for my taste. I personally enjoy spamming hits, and know that if you know what you're doing sending hits quickly is quite easily.
2. It would be nice to cut down on DB connections, but I'm not sure if this is a good way to do it due to the dynamic nature of war.
3. IF this were to be implemented, I would suggest a max of 5 hits to allow for a little bit better readiness management. Another option would be to allow the user to designate the number of hits to be made - so for example, I could select 18 hits for a tyr to run readiness to %25.
4. As an alternative, would it be possible to create an ajax interface which syncs to the DB say every 5th hit and registers unit loss/gain internally instead, and then verifies synchronized elements with the DB after 5 hits? This would cut down on db exchanges, and speed up page load times locally for the user.
