sorry, but I cant’ work with 1.98.
Atom labelling in Avogadro 1.98.
Quantum chemists (working e.g. in Orca) do need atom numbering from zero. It really saves, and this is the feature why I chose Avogadro.
It was in 1.96-1.97 (Label → Index), but some non-programmer (I guess…) decided to make atom numbering (Labels → Numbers) from unity in 1.98. Please, return atom numbering from zero = Index. If both regimes are needed, save both of them (numbering from zero was called Unique ID in Avo1).
1.98 simply does not Open anything on Windows on my computer
Open - File - choose C:\Orca\1.hess.v006.xyz
“the file name contains invalid characters”
We released version 1.98.1, which includes this bug fix.
As far as numbering atoms from zero or one … certainly it can be an option. The vast majority of users prefer numbering atoms from 1. Most programs also output atoms numbering from one, even if they’re handled internally in a zero-based array.
In the meantime, you certainly can change the code yourself as a developer:
@imitrichev Would it suit your needs if there were a variable in Avogadro’s GUI (similar to e.g., select which force field to be used to optimize the geometry) if atom indexing starts by 1 (as in Lua, Julia, Fortran, etc.), or 0 (as the family around C/C++/C#, or Python)? I can imagine the very first start of Avogadro displays a widget asking the user to opt-in for either choice (similar to the first time’s setup in gabedit) – in any subsequent use, Avogadro would stick to this selection until one intentionally selects the other level.
Personally I think sensible defaults are better than a “first run” dialog. The way Microsoft Edge currently requires several user choices before Windows 11 can be used at all is extremely irritating in a Domain environment, so it should be possible to use Avogadro immediately after starting in my opinion.
As long as it is easy to find and switch the setting I think assuming a default is fine.
And I agree with @ghutchis that for non-programmer chemists indexing starting at 1 is overwhelmingly the expected behaviour and should be the default.
But having the option for 0 is definitely important, makes working with ORCA much easier. Relatedly, I think the indexing for MOs and frequencies needs also to either be user-defineable as 0 or 1, or they should be read automatically from e.g. ORCA files as currently the displayed MO/mode number and that in the ORCA output files is mismatched.