“Chamfer size” 29,3% seems to be close enough to make an octagon.
This feature is apparently not compatible with v5, so if you use it you have to stay in nightly builds. It’s like rounded rectangles were for v5 after v4.
Edit: this is also possible with chamfered pad because it has also rounding, actually it’s like a rounded rectangle + chamfers.
The more powerful bus handling will also be a good addition.
But to be honest the feature i await the most is the new schematic and symbol file format. (And yes i am aware that it will take a while till we get that one.)
This is 5.1.0-9-gc61ec8ee3. The version number scheme was changed when v6 development started. It’s a bit better than 6.0-…, at least it doesn’t give impression of v6 which is probably some years in the future. Personally I would prefer 5.1.0+n…, it would be a bit clearer, or maybe 5.2 (which would then be reserved only for development).
Unless I got an install issue, the nightly you’re pointing to has the project manager as version 5.1.0-9-gc61ec8ee3. but eeschema, pcbnew, 3d viewer, etc. are 5.1.0-rc2-47-g6eb84e42f which is a bit confusing. Anyway, no chamfered pads in this nightly. Will wait next night
BTW, the symbol library browser doesn’t display any version information when using Help / About eeschema… Probably a bug.
People, please, don’t share feature request in this thread! There’s a whole dedicated category for that. The usefulness of the thread diminishes considerably with offtopic posts because this will be a long thread and updated with new features along time, at least if I or someone else will have time to follow the development and report about it. Ideally someone could read the whole thread after using 5.1 for a long time and catch up with the new features. Noise would make it tedious.
EDIT: the feature itself is of course incompatible with earlier versions, but if you don’t use it, the file should be compatible with earlier versions.
The main usefulness of buses always was for using them to connect over hierarchical interfaces. The old bus could have a bus pin of the form bus[0…9] Which meant that single pin represented a parallel bus with indexes 0,1,…,9. As far as i understand it the new bus can define more powerful buses (for example a SPI with signal names CS, CLK, MISO, MOSI)
If you did not go over a hierarchical interface then buses in the past where simply graphical lines that showed users connections between local labels in a clearer way.
The new bus features will also add power to this usecase. (proper bus entry and exit via the alias and unfolding stuff)
I do not know if buses can now also go via global labels. (Nor do i know if this was possible in the past.)
If you look at your linked document then the vector bus is what has been available in previous versions. The group bus is what is new. (With all the tools needed to properly handle such a bus. Meaning bus unfolding and bus alias handling are also new.)
Another new thing is connecting two buses with each other. I am not sure how much got into this implementation (I think this was one of the topics that created problems during the implementation phase. Might be that there where feature reductions here. I don’t really see a detailed explanation in the document so it really might be something that got removed.)
(Right now it’s available only in the left hand toolbar and in a strange location. IMO it should be near the Show/Hide Board Ratsnest, and it’s called “airwires”. Also I suppose it will be available in the View menu in the future.)
I dropped this feature and will clarify this in the docs once the dust settles on all the bug fixing.
In addition to adding new bus features (like bus groups and unfolding) the entire connectivity/netlisting system got overhauled, which means some other neat things are coming soon
As part of that overhaul, I needed to clarify some of the “rules” for how net names are assigned and how they propagate / override each other when you use global/local labels, hierarchical sheets, etc.
The docs for this aren’t done yet but it’s on my todo list. I think the end result will be a more predictable behavior although in a few cases it will be different from what KiCad used to do.