[956276] Tabbing between fields doesn't focus them

Making this thread to hopefully increase chances for a fix before 2017.2 releases.

Using tab for moving between inspector fields has broken at some point between 2017.1.1f1 and 2017.1.1p4. The issue is present in 2017.2 betas/RC's too. OS is Windows 10.

E.g. moving between x,y,z of the transform component using tab will select the field (blue outline), but doesn't focus it (blue overlay). This is a major annoyance as I've for years now zero'd transform fields using key combination "0 -> tab -> 0 -> tab -> 0" which doesn't work anymore.

 

Yep

 

I'm having the same problem, no matter which fields, and it's really annoying to have to use the mouse to edit multiple fields in a row...

 

I'd just like to add that this bug affects the Mac version too.
It's really irritating, so I was looking into reporting it when I found this.

 

Unity 2017.1.2f1 was just released with this bug as well.

@LeonhardP do humans test Unity builds before release or is everything automated? There seems to be more and more bugs creeping back into releases after the great delay and cleanup around v5.3.

 

Yeah if we go by feely-craft I have to say builds in general do feel more buggy.
Still, my game is in dev so it's hardly threatening.

 

I imagine it isn't particularly fun for Unity engineers to work on a perhaps buggy code base either. Fix one bug here, three more pop up there. I at least never enjoyed working on a product with an old and big code-base.

I actually printed various id Software early principles and put them up in the office, to remind people of things we tend to forget easily.

Perhaps it's the kind of decoration missing in Unity offices.

 

I apply both to my game dev, but I am the sole programmer.

The testing part... 100% agree with, I absolutely do accuse some Unity programmers of being a bit lax testing their own fixes because some of those bugs are frustratingly obvious, and should never have made it out.

Perhaps it takes them too long to make a build?

The second one I'm not so sure about. 100 engineers: what if your bug is in their code base and they're working on that? or they are waiting for a piece to be put in place by other coders, etc.

If it's your own bit of the code base then yeah totally agree to fix it on the spot. Sometimes I don't fix it on the spot but log it clear as day on trello because it may well require a planned bit of tech I haven't done yet to "fix". These are more missing functionality to complete issues, than actual bugs though (for me, that I don't fix immediately).

 

The early id software team had two programmers only at that time, if I remember the talk correctly, so I imagine they didn't really have that issue either.

The 2nd principle could be applied to the own testing phase for example. If you work on feature X, the "we're our own best testers" makes sure you thoroughly test all your stuff. If you find an issue, you fix it right away. You do not file a bug-ticket or put a note on your monitor to fix it next week, you start working on a fix now.

Other than that, I agree that it's probably (more) difficult as teams get bigger. I believe it also makes not much sense that just any developer who runs in issue X tries to fix it. A person who is not familiar with a particular part in the code is likely to introduce new issues.

In that sense, perhaps it makes sense to prioritize bugs over new features, in order to get all those bugs out of the system at one point and don't continue to build new code on a buggy code base forever.

 

Some feely-craft for sure ...but I'm also submitting more bugs that are being accepted, and some of them seem painfully obvious at a glance. We generally seem to be hitting more bugs and frustrations again this year after a few major releases without too much pain.

Overall, Unity QA are definitely responding much faster and better than a few years ago which is great, particularly when using the current release or patch release, but this is often addressing some things that probably shouldn't have made it out the door in an 'f' release, or maybe a patch release either. I've stopped using the patch releases as often because many of them lately have broken more things than they've fixed (for us). If a patch release fixes one of our bugs then I will obviously check it, ie. use the patch releases as intended.

I realise the engine is large and complicated and there are a huge number of use cases for everything etc. but if I can open a new version and hit a basic bug immediately it feels pretty frustrating. I know that Unity do things like build the Adam demos to explore and build new features, but it feels to me like they might need to dog-food their own tools a bit more in general to add more layers of testing and QA before things are released. eg. Timeline at a glance looks pretty useful but we only needed to use it once to hit the wall on some really basic use cases, and the API makes my head hurt. There are lots of other systems that cause us problems too but I'm sure this is the same for many other devs so I won't ramble on.

And... documentation. Easy to fall into a bit of a rant here too. Fingers crossed for some updates to outdated docs and basically undocumented parts of the API soon. (Editor docs, I'm looking at you.)

Like @hippocoder I'm our sole dev so it can feel like things pile up a bit and I'm sure some team learning would go a long way to helping smooth some of the bumps at times, but I often find myself saying that I'm happy to not be working on more complex applications with a larger team because they must surely be hitting more bumps than us.

Still, we're working on or have delivered apps for desktop, mobile, interactive table installations, VR experiences, and console this year so it's certainly a long way from doom and gloom

 

It's worth considering that most of the grumbles seem to be centred more around authoring in Unity than the runtime or general engine capabilities.

If we want we can get a better timeline or plug needs on asset store. It's disappointing, but I would be quite quick to move elsewhere if there was an actual problem with the Unity engine that made anything I wanted to try too painful.

 

Yep, that's pretty much our experience. We're not close to jumping engines by any means. There's plenty of good features on the horizon that should be landing sooner or later... and if they're well documented and have good API's then even better There will always be bugs and pain points and hopefully they keep getting addressed at a reasonable clip.

 

I have a feeling there's some kind of marketing monster at Unity driving out these releases asap and the engineering and/or QA team don't have any say when a new version pops out.

Release candidates for 17.1 and 17.2 have been good examples of broken releases. In general in software engineering a "Release Candidate" means your best shot at a version that should work like a real release. However for both first release candidate versions now I've had to instantly downgrade my project back because I've encountered a fatal crash or freeze bug completely preventing me from using the supposed release candidate.

I mean these do get fixed before the public release, but still they're supposed to be release candidates...