things that are broken in AC23

[SenecaDesignLLC]

linking railing to roof nodes by association removes posts. this is so stupid
columns only show center node if that is selected as the structural point.

how the H*ll do they mess up the basic things that should not be changed??? Im so un impressed with this version. they are luck there isnt something better yet. there will be if they dont pull their heads out of ......

really they should give us all our money back for this release. this is BS

oh and its by far slower than v22. which ive now reverted back too

step it up graphisoft you set expectations now meet them.

modumate is coming for you. they basically have me at this point. pending pricing and if i can unload these licenses im stuck with.

[Ralph Wessel]

rob2218 wrote:
I wonder why the programmers do that. Take away great functionality in one version, and put it back in in 2 or 3 version down the line?
Can't they just LEAVE the code that works well enough alone?
I mean, I suppose it may have something to do with that when they program a new parametric...it may not work properly with existing parametrics and then something has to give.

I think you've answered your own question reasonably well. The reality of programming (and IT in general) is that something left 'well enough alone' will die. Nothing in IT stands alone - our code relies on much deeper foundations, e.g. the hardware, operating system, programming languages and development tools. All of these things are constantly changing and evolving, and one consequence is that code will not continue to work the way it did indefinitely. Who hasn't had the experience of having to let go of a tool you really liked because no one was maintaining it anymore and it no longer functioned in the latest OS?

The other major issue is scalability - the restrictions and requirements you target in programming are always moving. At some point you can't just keep adding new stuff - otherwise you end up with something that seems unstable, bloated and brittle. It's like deciding you want to build an extension over your garage - the first step is often to demolish the garage and put in new foundations because it wasn't designed to do anything more. Programmers sometimes need to take an axe to a lot of seemingly 'working' code because it wasn't designed for the scale of the current requirements. The only way to get it right is to design a stronger foundation and structure and rebuild. It's painful for customers, but even more so for developers. You somehow have to keep everything working while simultaneously ripping up and rebuilding the foundations of your (much-loved) work.

[DGSketcher]

Ralph wrote:
At some point you can't just keep adding new stuff - otherwise you end up with something that seems unstable, bloated and brittle.

You mean like AC23? I can't help but think one of two things are happening at GSHQ, either 1. There is so much legacy data that they are struggling to keep it stable, or 2. They are outsourcing with limited QA to keep costs down and those contractors are changing parameters with unchecked consequences.

I do recall GS were supposed to have done something about refreshing the code in the move to 64-bit a few years ago which was meant to bring huge stability & development benefits... doesn't seem to have quite gone to plan. There is also a desperate need to streamline the user interface for consistent & simplified tools. Even as a long time user I get frustrated jumping between different palettes / dialogues searching for attributes to get things looking correct on the final layout. I probably won't win any fans by saying this, but the mindset of tools having a specific named architectural function is holding back development. The new column & beam tools are an example of where I think this is causing problems. We now have what could have been a single geometric linear element, taking two diverging development paths with similar but different user interfaces. And what is the primary difference between them? 1 degree! GS have declared that beams can't be vertical and columns can't be horizontal. Rant over...

[Ralph Wessel]

DGSketcher wrote:

Ralph wrote:
At some point you can't just keep adding new stuff - otherwise you end up with something that seems unstable, bloated and brittle.

I do recall GS were supposed to have done something about refreshing the code in the move to 64-bit a few years ago which was meant to bring huge stability & development benefits... doesn't seem to have quite gone to plan.

Software on the scale of ARCHICAD can't be completely overhauled in a single step - apart from the mind-boggling scale and complexity, it would certainly break everything that went before. And if it changed so abruptly, would we still like it? Change in this context can only be done incrementally. It would be simpler in some respects to start from a blank sheet, but GS is taking great care to preserve the long legacy that its customers have accumulated.

And I've seen a lot change over the years (under the bonnet). GS has moved on many technical challenges (like 64-bit code) much faster than many others. It's not possible to please everyone either - notice how in this thread alone we're seeing some asking for things to be left alone where others want to see radical change. The reality of this situation means that progress on ARCHICAD will always end up somewhere in the middle of those extremes.

[Bricklyne Clarence]

rob2218 wrote:
I wonder why the programmers do that. Take away great functionality in one version, and put it back in in 2 or 3 version down the line?
Can't they just LEAVE the code that works well enough alone?
I mean, I suppose it may have something to do with that when they program a new parametric...it may not work properly with existing parametrics and then something has to give.

I dunno.

That's what happens when you do program development with little to no feedback from the actual end-users that use the program or when you rely on a really small sample base from which to draw your input.
It's also what happens when you try to re-invent the wheel all the time and fix "problems" that don't exist (rather than the ones that actually do) and end up just providing "solutions" looking for actual problems to address.
Graphisoft is perpetually guilty of this sort of thing, because....as has been noted here and elsewhere,...they simlpy don't listen.

I'm reminded of a little example from the release of ArchiCAD 21 with the new stair tool after a complete revamp, more or less, of the tool it turned out that they had not provided any functionality for noting on the stair the "Down" (DN) direction on the arrow, because...in the experience of the guys who made that decision, in their locality the requirement was only to always indicate the "UP" direction on a stair even in circumstances where it wouldn't make sense for that to be the only option (like at the top level of a building. Which, of course forced users to have to work-around this "solution" by turning it off in the stair tool and then putting an actual text note indicating the "Down" direction because wierdly enough in some other localities they require to show which direction the stair is going (either "up" or "down") from whichever level or slab the stair connects.
(as a side-note, I strongly feel that this problem is partly the result of the inability to have multi-level stairs in ArchiCAD as exist in some of their other competitor programs because in multi-level stairs, you kind of have no option but to indicate both since the stair does go in both directions).

In any case it turned out that the real annoyance arose from the fact that the issue had ACTUALLY been brought up during the beta-testing stage by some beta-testers, and was summarily dismissed and ignored, or at least not addressed until the release when even more people complained about it and it turned out that it seems like in more places than the developers were aware did the situation require what they assumed the tool didn't need to do.

Long story short, they corrected it in the following version (or possibly the next Hotfix; I can't quite recall), but all I remember having an impression from that whole experience was what a total waste of man-hours, development efforts and time in ignoring a problem that simply could have been "fixed" had they just listened in the first place or gotten more feedback first before making such a.....well, maybe in that case not so drastic, but still in the larger scheme of things, time-wasting on our end decision.

I mean, who else are you developing the tool for if not for the end-users who might have an opinion on how best it might or should work for them to produce the best work, and what's the point if you're just going to ignore what you're told (aside from your very special and very select group and team of "insiders", who can't possibly have the kind of over-arching reach you need to get a well-rounded opinion).

And this almost always happens whenever they do one of these big "re-do"'s of a major tool - as is the case now with the column and beam.

And yes, I do agree that having to make a poll to get them to return the functionality that already existed before is beyond ridiculous when you consider the fact that they don't even seem to pay attention to the polls already existing in the wishlist sections asking for functions that don't even exist at all.
I'm not against Graphisoft refreshing or re-doing tools to add more functionality and bring more usefulness to end-users. But just listen to what people might have to say and pay attention to how people use your tools and don't just assume there can't possibly be any contribution of value from our end and maybe you might just save yourselves (and us) a lot of wasted time and effort just going around in circles.

Just a thought.

[rob2218]

I guess I get the feeling that the analogy is "using a hammer as a screwdriver....just doesn't do the job right".

I hear what you are saying...........LOUD and clear.
and partially I think you are correct.
GS has programmers who have 'strayed away' from what the end-users needs are in a real-world scenario.

A story comes to mind that I had a supervisor (super nice guy BTW) who always used to say "Ahh..this BIM thing is a P.O.S.!"..............Mind you HE, my supervisor, never drew once on either 2d Autocad NOR "ANY" BIM software. WE, the peeps were in the trenches....yet MY supervisor had the audacity to make those claims without ever really knowing how Autocad, Revit, nor Archicad ever operated....

I think its sad that folks who have never shoveled cow dung make statements that read "I hate shoveling cow dung"................How can you make that statement if YOU have never done it?

[jl_lt]

One question guys, have a curation effort been made to try to stablish some of the most critical wishes out of the thousands that there are out there? Do you think something like that would help?

[DGSketcher]

Ok I get the "Hammer / Screwdriver" tool analogy, but this is as much about the coding behind the scenes as well. Each tool comes with its own user interface, which despite having some commonality GS seem to be able to make each aspect of that commonality different, "Show on stories" being a prime example. To take my "extremist" consolidation further you could even consider walls as a linear element. The new beam tool could work as a wall with doors & windows with a little tweak to the openings script. So making the beam, column & wall tools all use the same code that's a huge chunk of the coding & UI design process consolidated. There is also scope to consolidate the slab, roof, shell & "ramp" requirements; the principle difference between these tools is the ability to adjust their angle from horizontal. Consolidate these and you are then left with two pieces of code requiring connection solutions rather than trying to connect six different elements. And as proof of concept all the walls in the attached simple model were drawn using the beam tool and the roof formed with a shell.

Keep it simple. Work smarter not harder.

[DGSketcher]

jl_lt wrote:
One question guys, have a curation effort been made to try to stablish some of the most critical wishes out of the thousands that there are out there? Do you think something like that would help?

Not really.
1. I doubt GS would want a readily accessible wish list in the public domain for the competition to pick through.
2. The provision of wishes is at the whim of GS and their tests:
[list=]

A. It would require a major rewrite. Not happening. (Applies to my previous post)
B. Critical bugs are a priority, and they need fixing before wishes.
C. Wishes to address long standing bugs have work arounds. Not a priority.
D. Repeat wishes are number ### in the queue.
E. The new feature in release ## is taking longer than expected to implement. See B.

[Anonymous]

Easy guys! or you will soon get some heart disease.

I think that this mess has to do with the Opengl engine substitution.
Perhaps this is what Ralph is telling us between the lines.
BTW good to see you Ralph around here outside the Developer Forum

[Lingwisyer]

They really should just drop the yearly turn around. It is good for no one except the short term pocket... Things might actually work as intended upon full release then.