Hi, I'm pretty sure you're probably already aware of it, but I've found double-clicking on a unit to select all of the same unit on-screen is a little buggy. It only works sometimes, and at others it selects all and then immediately un-selects again.
Yep, its behavior was updated to try to reduce unintentional double clicks, but the results are a bit too good at preventing them. In the next build it should be more consistent.
Don't get me wrong, but was this really a priority ? I mean, if we check the bug tracker there are many other issues that would require to be fixed with a higher degree of priority. Double clicking tuning looks like to me some kind of cosmetic that could be tuned during beta. I have to admit that i hardly understand how you're moving forward on fixing priorities about what you're going to work on from day to day. I'm not blaming, just surprised that such a change has been made : as far as i know but i may be wrong, i've seen no one complaining about double click, and now we have people complaining that it's broken. In the mean time there are issues reported since a long time and not fixed yet. could you please elaborate a little bit more about how game develoment is moving forward, what are the plans for next weeks. Do you have some kind of schedule, priorities list ? how do you decide that you're going to work on a new feature implementation or fixing bugs ? how all this is balanced with such a small team ? Considering the number of bugs which have been reported, do you think the next two months will be enough to move to beta stage (meaning major features, units being in place) ? I don't want to be pessimistic, but while i'm discussing on many forums where people are also playing with akpha, or many people watching alpha, most of them do not really believe that it's possible to reach the final release before december, and hardly believe even more that alpha will be done within the 2 next months. I try to argue and convince them that Uber can do it, but providing good explainations about how this is possible is not allways easy :?
Maybe when you just finished fixing the bug you were working on and there is only a few hours before a build goes out it's plausible to work on something you can squeeze into the build instead of starting on something that won't make it in until the next next build. That's good because then if something needs further adjustment, as we see here, it can be identified much sooner and possibly be slotted in much like it was before. Mike
No, it's not high priority, but it's a "quality of life" kind of issue. If it's a problem that causes us annoyance in play testing and it's a quick fix we'll probably fix it even if it's not "high priority". It's also kind of a problem of many of the high priority bugs are items that require major features to be implemented or other work done by the very senior or specialized programmers on the team. Just because some people have some down time doesn't mean someone like myself (I'm a technical artist) can fix it. I may be able to go in and fix more minor issues so they don't have to. Many of the major UI issues might require 3 or 4 people working together to fix, and instead some of those people sitting around twiddling their thumbs waiting for those who are busy on other tasks they too can take a crack at the smaller issues. I also wouldn't say we necessarily work with a particular build in mind, though often times we'll get a major feature in and spend a little extra time doing some minor polish task we might not have if we weren't doing this publicly. A good example of that was the metal spots. We added actual metal spots, they worked in that mexs had to to be built on them, but there were other issues like you could build an infinite number of mexs on a single metal spot. If this was normal development that would of been ok, we would have just said "don't do that" internally and moved on. We've been playing internally with the rules of requiring to build on the fake metal spots for quite some time as well as no overlapping buildings. Instead we delayed the build and put focus on server side validation of placement. It wasn't about rushing to get a feature into the build, it was about delaying the build to accommodate the feature. We're doing builds internally and testing them all of the time, and usually we don't get much more warning than "doing a build for playtesting in 5 minutes, check in if you want it in this build." That's not usually enough time to do much more than a quick check to make sure your code compiles locally and works as expected.
What I have found out to deal with this little issue is to draw and box around your whole base as I you were selecting all units. Only attacking units get selected by doing this. Much more efficient than double clicking different types. If you use double click on labs to set a common rally point you can hold down shift and click the plants one by one. A lot slower but helps a little.
