What do you think should be done to get Archicad a bigger market share ?

[Anonymous]

I personally find ARCHICAD way more powerful, easy to use, faster and all in all innovative than other solutions like Revit. However since Revit is backed up by Autodesk and long years of Autocad dominance, ARCHICAD isn’t leading in terms of market share, what do you think GRAPHISOFT should do better? Do you think it’s enough for them to just push for a better product ? Or is there something else you would do ?

[Bricklyne Clarence]

gavinNZz wrote:
I see the main problem being that Archicad is a piece of 1990's software trying to wear some 2010's clothing but still dances like it's in the 90's. I have been with Archicad since V8 (15+years) and there are some functions that have not been touched in that time. How is that even possible??.......

Lots of good points you raised and I have thoughts on plenty of them.
Lots and lots of thoughts....


Like you I have been an ArchiCAD user going all the way back to version 8.1 (and the disastrous version 8.0 that it was immediately released to follow and clean-up after), and even briefly with version 7.2 for a little while, so as you can imagine I have a major built-in backlog of issues and things that I feel nee to be improved in the program as well as general gripes with GS themselves.

- Layers and Layer control:-
Couldn't agree more, especially with the whole "nesting" layers, and even some additional things like using layers to over-ride object properties (like lineweights, pen colour, fill colour and type,etc) or to change opacity on the fly using a slider (think of how useful this would be in fading out funiture layers, for example, when sending out drawings to consultants or third-party partners, or for fading or reducing the opacity of mechanical layer objects and plumbing fixtures, etc.
You would think that the fact that they've been working in conjunction with the folks at McNeel over the Rhino/Grasshopper bridge would have given them some ideas to improve their own layer control set-up and functionality.
As is, it's beyond even just 1990's-level of backwardness. Even AutoCAD in the 1990's offered more control and versatility through layers than ArchiCAD does NOW.
That's embarrassing.


-GDL programming and custom object creation:
Double double agree.
With extra cheese and toppings.
Once again the fact that we speak of Revit's FAmily editor as being a vastly superior way of creating custom parametric objects for Revit (which has ultimately given them the edge in terms of the availability of Revit third-party fully-parametric library objecta available online and from suppliers) in comparison to ArchiCADS literally archaic line-coding to create the same, is agonizingly embarrassing.
Line-coding is wuite literally how we define the 1980's guys. I mean, come on.
Anytime you see one of these nostalgia '80's movies or TV shows where they show someone using a computer or doing something "Advanced" (for back them) it's almost always typing out line codes in C++ or BASIC or some such thing in a clunky console or terminal.
That's were ArchiCAD and the GRaphisfot folks STILL are in relation to how they expect their users to create some of the most complex objects in this, their advanced software and tool.
Shameful.

-BIMCloud
- Can't really chime in much on the whole BIMCloud angle since from the start I always felt that Graphisoft were missing the entire point (and potential) in the whole wave to move software and digital work to the 'Cloud' or to use the cloud to advance their users' workflow, and it would seem I was right.
See also : BIMComponents (remeber that? The GRaphisoft attempt at launching a Google (now Trimble) Sketchup-like Google Warehouse repository of online objects availble to user to share and add to? And how it went nowhere? In light of the limitations of being able to create custom versatile parametric GDL objects, something about putting the cart before the horse comes to mind, right about now).

-On Teamwork
-One (somewhat adjacent) thought about Teamwork is that I recall when they introduced 'Teamwork 2.0' a couple of versions back and a few years not too long ago, and one of the big selling points in its overhaul was the notion that when you work in Teamwork with physically remotely located teams sharing the same teamwork project file online, that the program now would only send changes as opposed to the entire database, which would ultimately increase the speed and efficiency with which teams could collaborate online.
Which seemed very smart if not the logically inevitable practical way it should have worked all along.
But then I thought to myself : "Well, why the hell doesn't the entire parametric change engine of the program itself work this way at a local level in one's own workstation?"
As is, whenever I make even a simple change and switch views (especially to the Sections or Elevations) you can easily fnd yourself waiting several minutes (or more) -especially for bigger and more complex projects - waiting for the program to regenerate the view and drawing just to update JUST THE SINGLE WALL you moved when nothing else changed. It is especially egregious and noticeable with Sections and Elevation windows but also with 3D views as well (the raw 3D windows and really really badly with 3D Documents).
The program seems to use an archaic parametric change engine and tracker which, rather than intelligently just keep track of, and update only just the changes, has to certify the entire model or drawing with every single view switch or change, which, from a workflow perspective is just torture.
I guess what I'm trying to say is that the ArchiCAD change engine and it's own kernel badly need updating - particularly to take advantage of the more robust (and more readily available) hardware (and software technology available today.
Gone are the days when they could sing from the rooftops that they are first (and only) in market with a BIM product that was fully multi-core aware,
To wit: Graphics cards and GPU's nowadays have literally hundreds of cores, and yet we're still stuck on a single monitor use workflow (on the PC side at least).
That picture just doesn't feel right (on top of being constrained........to one monitor)

-Visuals
I'm guessing you mean visualization rather than the look of the program and in this regard, I would be careful what you wish for in terms of Grephisoft getting into bed with third party partners to produce tools to substitute for (rather than supplement) what they themselves have failed to produce natively in the program or at least are doing a poor job of maintaining and developing themselves.
I'll give you a couple of examples.
The first one involves a trip down memory lane.
Being a long-term user (or as long as myself), I'm sure you would be familiar with the term,...."Maxonform"?
For those not aware, Maxonform was a "bridge" that Graphisoft developed way back in the day (I believe before Nemetschek bought both them and Maxon out) in conjunction with Maxon and their Cinema4D program as a means of allowing ArchiCAD users to access the power of modern 3D modelling tools found in 3D modeling programs like 3ds Max and Cinema4D - but from within the ArchiCAD user environment (......sort of....).
At least that was the idea...
Except it didn't really work out that way (in terms of being very clunky, both the program/plugin itself as well as the workflow and also the general coordination between the two companies). It was a great idea.....or at least it seemed that way at the time,.....but ultimately poorly executed and in hindsight questionable on many levels and ultimately they gave up on the effort not long afterwards, right before devoting their own resources to developing a internal and (truly) native powerful modelling tool for the program on their own which we now know as the Morph tool. But the path of getting to the morph tool (which itself, while a great improvement to ArchiCAD's toolset, could still use some improvements and a Morph Version 2.0 upgrade of its own integrating SubD polymodeling and NURBS translation) was truly tortured one and littered with lots of bad decisions along the way.

Graphisoft has had a little but more luck working with third-party partners in developing external tools for users in recent years and versions (the Grasshopper/Rhino bridge comes to mind. And also while not STRICTLY a pure third-party tool on its own, the Cinerender engine also falls in the same vein of not developed purely by Graphisoft themselves), but they still face the same issues that this kind of development strategy tend to elicit (like not being in total control of the schedule and timetable during which their partners release their upgrades in keeping with most recent ArchiCAD version releases. For example, the Cinerender Engine inthe current ArchiCAD versionis always an entire version behind the actual current Cinema4D internal render engine, and even in the case of Grasshopper/Rhino - of which, McNeel have a more forgiving release schedule whence they release a new version every 5 or so years - you still have gaps in when you can get the most recent version of the plugin working with the most recent version of Rhino or ArchiCAD respectively.

And you can see from the current delayed release debacle and fiasco of ArchiCAD 23 on the one hand and also the expected release of the new version of Twinmotion (which was itself also delayed from late last year to,....."sometime in early 2020" ...or "first quarter of 2020", depending on which press release you're reading. I understand that they're having issues integrating the Real-time raytracing RTX engine that Graphisoft have already gone out of their way to promote in their own ArchiCAD version 23 promotional videos. Go figure. That's what holding yourself to someone else's promises will get you), this kind of relationship becomes rife with potential problems and risks.

What happens if Twinmotion gets delayed until sometime in early summer, for example? It will mean that ArchiCAD version 23 users who were promised a free version of the lates Twinmotion with their version 23 purchase will only be getting a couple of months worth (at best) use of free Twinmotion before it becomes a paid product again (and this also assumes that GRaphisfot themselves are back on schedule this year with their own releaase cycle.
Graphisoft themselves have no control over what happens over at EpicGames in terms of the development of Twinmotion or the release schedule and this is what you tend to get.
And when you've already promoted YOUR own program using THEIR product (which you have not control or say over), then you have issues.
What also happens if the Twinmotion new version is released (even in the next couple of weeks) and it turns out it's buggy as hell as to be practically unusable?

So I don't really know about using this as a viable strategy going forward - even while I can understand the necessity to have to outsource some of these development functions to outside parties or specialized interest groups with a view to keeping a tight grip on your own limited and strained resources (.....though,....again, they only have themselves to blame here if they feel stretched thin because they're the ones who decided to go on a yearly release cycle that seems to have been nothing but a bane to the existence of both users and developers (on their end) alike. Stop letting the bean-counters and accounting/numbers guys run your company and make strategy decisions for you,....That would be a good start)).

Like I said, ....I have thoughts.

And these aren't even the half of them.

So I'll distill my simple advice and suggestion to Graphisoft to one simple thing:-

You want to increase your marketshare?
Listen to your users and improve your interaction and overall relation with them (beyond those largely useless (IMHO) 'Key Client User' meet-greets and hobnobs that only give you a blinkered perspective and not a well-rounded picture or the necessary tough-love feedback you so often clearly and badly need).
Don't under-estimate how much free-marketing you often can get from happy and satisfied users who feel their needs are being met and their money is well-spent and justified.

Ignore them at your own overall peril.

[jl_lt]

Wow! lets keep it up!

@Mr. bouhmidage

Totally agree with you about the SEO and morphs. What i meant is that if you turn an SEOed wall into a morph it actually projects correctly on plan, so its not like GRAPHISOFT has to reinvent the wheel on this, as they can already do it. Its just a matter of applying it to a normal wall object (of course there might be an underlying coding reason to it, most probably something related to the simbolic projection instead of real projection they seem to use to save on computer resourses. Someone might illustrate us on this).

@Mr. TonnySmith

As the OP, what do you think of all the rants going on here? Great points are being made!.

This is not a wishlist, but a lot of the comments imply that wishlists are seldom listened to, if ever. Wishes may or may not come true and a lot of hard work is required in either case, but assurance that at least these wishes are heard and acknowledged would be nice. I can see in the forums that most wishlists have 4 or 5 comments. As the numbers of separate wishlists increases, the focus is lost. Can a post become so big that the guys at Graphisoft have no other option but to check it out?.
There is a big post dedicated to how things are broken in A23. At the end, everything balances out.

(as a side note about wishlists, i think Mr. James Murray´s post about the "Standard Element" https://www.onland.info/archives/2008/01/the_standard_element.php should be a main guideline for our wishes. Progress has been made though.)

@Mr. Moonlight

You make interesting points about how it would be better not to make a graphical interfase for GDL scripting, specially about the amount of resources it would take that could be better spent somewhere else. However, I found this video which probably many have seen:



Amazing Stuff!. Of course, everything becomes easier when you have a team of programming gurus with you, but still, i can only imagine if we had something like this at our disposal.

@Mr. Bricklyne Clarence

Please, don´t hold back, spill all your thoughts out!

[Nader Belal]

@jl_it

1. Thank you for considering me as a guru.

2. In relation to the video you have shared, I will say what I have previously said in ArchiCAD España FB group, the Chinese team did a very good job, but it was only possible since that they had time and resources to develop it.

3. How did the chinese team did it, I don't know since I didn't have the chance to see their script, but I can speculate that some of the possible methods used in their example have been already explained various times by Graphisoft. And about the User interface, well GDL have that.

4. On the other hand, we have people that did have the expertise to rival that level of library parts of creation that were ignored for countless years, such as myself, Carlos Lopez, and others (which I can't remember all their name at the time of writing this comment).

5. Many times, even when we find that using GDL can actively reduce project time elaboration, either we are being ignored at our jobs, or we have to fend other tasks that leave use with zero time for GDL creation.

6. When we try to offer our professional services, we usually get a "No" as an answer, whether the other part was a firm, a company, or a professional.

7. The only method of graphical Library Part creation I have a minimum knowledge of is that of Revit, and I´m sorry to tell you, that is not a good example to follow, since that it may appear quicker, but the amount of resources that is spilled for simple tasks is quiet huge, and can steal the capacity to optimize library parts' script that we usually tend to use.

8. Most of the people here, does not want to learn GDL, better said they act like people of advanced age that although they have the brains, they actively ignore modern technology.

9. Why would you create a graphical GDL ??? I´m sorry to tell you, but GDL was designed to optimised for model creation and some simple info handling. On the other hand we have Grasshopper as an example for graphical programming interface that can do that and more, and creating a Graphical GDL will be like reinventing the wheel.
PS: All Grasshopper users already know that at one time they may need to write a programming script either in Python or C# or Visual Basic, so I guess you may understand why I say it will be like wasting resources.

10. I want to draw the attention to something that is more immediate, Rhinoceros, although being a younger program already have a greater number of API users, the opposite is true with ArchiCAD.

[bouhmidage]

Mr. Moonlight
i don't know why graphisoft doesn't hire people like you to develop more and more it's GDL content,
let's back to GDL Graphic editor,
is it possible to create a Plugin inside grasshopper like archicad connection ?, let's say GDL connection, all gdl commands can be transformed into nodes with inputs and outputs, is it possible ? or it's a programming issue ?How GDL will loose it's power in such a situation ?

[Nader Belal]

@bouhmidage

Theoretically it can be done, practically scripting will you will be better off to stay in scripting GDL.

[Bricklyne Clarence]

Moonlight wrote:
@jl_it
.......
8. Most of the people here, does not want to learn GDL, better said they act like people of advanced age that although they have the brains, they actively ignore modern technology

I'm sorry, but this is extremely reductive and dismissive of why there's a lot of resistance, and reluctance to learning or using GDL scripting (and dare I say, even some inability) among among ArchiCAD users but also seemingly sadly indicative of the mindset among Graphisoft developers and decision-makers on this whole GDL topic and the need for a better interface to develop customized parametric objects in ArchiCAD.

Speaking personally for myself (before I get into a more generalized view), I have no doubt in my mind that if I put my mind and effort to it I would take to GDL fairly well and be able to do fine with it.
But that's because I do have some limited computer programming background back from my University days - as in way waaay back in my first or second year when I was still dabbling with the notion of possibly going into Computer science rather than Architecture.
I ultimately decided to commit to Architecture, and while writing code had been an enjoyable hobby for me up until then (something that my father had gotten me into when I was younger), it was not something I would be able to devote much of my attention and efforts to, as I went farther into Architecture since, as anyone knows, the demands of this profession - even just learning it - are considerably extensive.

Which brings me to the more general circumstance in the wider user community.
It's not that most ArchiCAD users (majority of whom I presume are largely architectural professionals or at least trained and educated in the field) lack the aptitude or motivation to learn GDL.
But rather, given the demands that this profession imposes on most here,.....
....and also given the fact that, (I would harzard to guess), most users are either small firm users or even solo practitioners, with limited resources to devote to something like personally learning it on the one hand, or even having someone on staff learn and specialize in GDL (and sometimes on nothing else but GDL)....
.....it ultimately becomes a question and matter of resource economics and availability, that ultimately is the limiting factor for most here.
Your client will not be paying for you to learn something that will ultimately (more directly) benefit you, rather than them, which means that those are not billable hours that you'll easily justify losing. And while yes, you could argue it's an "investment" that would ultimately benefit you or your firm long term - there's also the additional question of the type of thinking conditioning and training that goes into being comfortable scripting and writing lines of code.
Most people (if not all) in this profession are trained to think visually, to work out problems visually and graphically, and to solve problems in the realm of the 3 dimensional rather than in lines of logical code arguments.
So it's hard to get a designer to get into the mindset of having to write hundreds of lines of code to get this chair or door panle design that they can easily model with ArchiCAD's tools in the 3D window to parametrically change attributes like leg length or material/surface setting, trim type- which is easy enough to visualize - but hard to distill into code to prevent you from having 10 different versions of the same in your custome library.

I often liken it to buying a car from a dealer and then finding out that it is limited in how it deals with different weather and road conditions and when you ask the manufacturer if you can have more options for, say tire types, for example, you instead get an instruction manual for how to build your own snow tire from scratch.

That's GDL scripting to get the program to do what you want it to do,....in a nutshell.
From the perspective of the (untrained and unfamiliar with coding) user.
It's almost like the developers are saying "...here, do a little bit of what WE do, to get the program to do what YOU want it to do".

And I can get why you would see that it shouldn't be hard for most people to learn, but don't forget that A) you ALREADY know how to code in gdl. and B) line coding and scripting is in many ways a fairly antiquated way of getting programs to do more nowadays. And a lot of developers of other software know this.
That's why you have node-based scripting in Grasshopper, or even for things like material creation in 3ds Max, or in other programs. Or why VISUAL C++ and other component-based coding languages were created and developed.
Yes, you still write lines of code, but if computers today can handle giving users that extra layer of convenience and efficiency in writing their code (even in actual programming languages like C++) - using visual and graphical feedback, then why wouldn't you take advantage of it as a developer and instead force users to have to resort to literal 1980's and MS-DOS -level of computer interaction and a relic of program creation in many ways?
Makes no sense to me.

Moonlight wrote:
>>>>....
9. Why would you create a graphical GDL ??? I´m sorry to tell you, but GDL was designed to optimized for model creation and some simple info handling.....

.....over THIRTY years ago!
30 years ago!
Don't forget that part.

Moonlight post_id=306718 time=1581331216 user_id=60097 wrote:
>>>>....On the other hand we have Grasshopper as an example for graphical programming interface that can do that and more, and creating a Graphical GDL will be like reinventing the wheel.

And its telling that between Grasshopper and GDL-scripting, one of them looks, feels and behaves like it was invented in the 21st Century.
Also something you shouldn't neglect to mention is that Grasshopper was create and invente as a plugin and supplement to Rhino3D AND to work within Rhino and that environment.
Which means that in order to access and use it, you have to learn how to use Rhino first - which most people here might not even be familiar with in the first place.
It also likewise means it customized to work in a Rhino3D workflow and way or working and NOT towards an ArchiCAD (or Revit, .....or Vectorworks..... or Sketchup) workflow.

So creating a custom graphical GDL object creator for ArchiCAD would in fact NOT be like reinventing the wheel because you would be creating a tool for the sole purpose of working within the ArchiCAD environment, geared towards an ArchiCAD workflow, optimized for ArchiCAD elements, objects, and library objects, and which (most importantly) wouldn't be subject to the different upgrade cycle of a different program or force users to have to learn a new way of working, with new commands and whatnot.

They could even feel free to steal or "borrow" ideas from how Grasshopper works and adapt them to such a tool. ArchiCAD has been the source of many a great idea that has been appropriated by other programs over the years (including by the likes of AutoCAD and even Rhino), so this wouldn't be any different. Besides which, such a tool wouldn't even be like a competitor to Grasshopper or anything since that wouldn't be it's intended use (as a generative design interface and algorithmic designer).
It would merely be an adjunct to a function that ArchiCAD users already have to deal with in what is now a clunky way (short of the resources to either learn GDL or hire a GDL specialist to parametrize your custom library)

Moonlight wrote:
>>>>.....PS: All Grasshopper users already know that at one time they may need to write a programming script either in Python or C# or Visual Basic, so I guess you may understand why I say it will be like wasting resources.

Indeed.
And we all know that asking for Graphisoft to develop such a tool or function will not automatically mean the end of GDL scripting altogether.
RhinoScript still exists and can be wrapped into Grasshopper components for those that need even more versatility and control.
But not every Grasshopper user needs to know or learn Rhinoscripting or even know how to code at all.

But if "wasting resources" on GS' end is what you're worried about, then might I submit as exhibit A,B and C, prime "new" features and tools of some of the more recent versions of ArchiCAD,....a 'hole in the wall',,.....or... a children's playground library object. (version 20, I believe it was).....

Not to say that these aren't useful additions or features to the program (for some,....I'm sure).
But rather to point out that if they DO have the resources to work on presenting these as new features (that presumably people have been requesting and asking for), then 'm fairly certain they should have more than enough resources to place someone on a side project working on the beginnings of something like this.... a feature that people have been requesting only for as long as I've known and used this program for in over 2 decades now,, easily going into the third one.

Moonlight wrote:
>>>>.....10. I want to draw the attention to something that is more immediate, Rhinoceros, although being a younger program already have a greater number of API users, the opposite is true with ArchiCAD.

There's a (non-coincidental or accidental) reason for that.
McNeel as a company have a very encouraging and fostering attitude towards their user community that the Graphisoft environment has been lacking for a considerably long time now.
Let's not forget that Grasshopper - arguably their most well-known and most popular plugin was invented and created by David Rutten, who was just an enthusiastic Rhino users (And advanced scriptor) who had a lot of encouragement and support from the McNeel folks in his side- "project" that ultimately became a full-blown and full-fledged feature of their program now.

Such a thing could never happen on the Graphisoft/ArchiCAD side
(nowadays, at least).

All you have to do is look at how differently the two companies approach their beta-testing processes of their programs' next versions to see how and why you never get a new Rhino version that's lacking in a ton of useful (and requested) new features for users, and why you can never say the same on our end.

In a weird ironic way, this newfound partnership they have with McNeel might (eventually) only serve to highlight and (unflatteringly) contrast how they themselves fall so sooo short nowadays in user-interaction and outreach, by contrasting with a company that has its finger on the pulse of what its users are thinking and need.

[Da3dalus]

In response to @Moonlight many pages ago, suggesting that ArchiCAD provide Facilities Management tools...

Graphisoft has, or rather had a Facilities Management solution: ArchiFM. You even occasionally find references to it in ArchiCAD library parts. I believe it was spun off into another company, and I don't know how functional or robust the business is. Check this out as well.. ArchiCAD can even serve as an effective FM tool on it's own, given the new Classifications, Properties and Expressions.

That being said, CAFM is a tricky market. It has to be continuously maintained in order to produce results, and it is often seen by the bean-counters in an organization as a financial loss, as there is no profit margin to the expenditure. Therefore, it often gets unfunded or neglected, rendering the database less effective. A Facilities Manager needs to constantly justify their existence as a type of insurance, and produce reports vigorously. Plus, there are no real laws or regulations in place in the US to encourage such reporting (such as Carbon Credits or Energy Efficacy standards). In the end, it is up to the Owners and Operators to see the value. Therefore, it isn't as pervasive as the architectural community knows it could be.

[Anonymous]

You all deserve a round of beer.

Now seriously: Thank you guys for your time trying to make Archicad better. Really!

Bricklyne wrote:
You want to increase your marketshare?
Listen to your users and improve your interaction and overall relation with them (beyond those largely useless (IMHO) 'Key Client User' meet-greets and hobnobs that only give you a blinkered perspective and not a well-rounded picture or the necessary tough-love feedback you so often clearly and badly need).
Don't under-estimate how much free-marketing you often can get from happy and satisfied users who feel their needs are being met and their money is well-spent and justified.

Totally agree Bricklyne Clarence.

Cheers,

[Nader Belal]

@BRICKLYNE CLARENCE

I see that I wasn't clear in my previous explanations.

1.

Moonlight wrote: ↑
10 Feb 2020, 10:40
>>>>....
9. Why would you create a graphical GDL ??? I´m sorry to tell you, but GDL was designed to optimized for model creation and some simple info handling.....

.....over THIRTY years ago!
30 years ago!

Although GDL was created about 30 years ago, I think that Graphisoft hit the Jackpot in terms of a really good idea for an optimised BIM object creation, as it is simple to learn, have a small foot print, can incorporate data, and it's programming style is quiet similar to how architects think.

Unfortunately, my narrowed opinion was based on what I have experienced and seen by other users, and that I´m not asking to create a complex object, in fact I will give you this example,

Few years ago, in ArchiCAD España FB group, a member asked how to do something (I don't remember what was it exactly), so many proposed many different ways, and I proposed to use Grasshopper to do simple operation, since it was going to be quiet quick to preform, and I would stay online to give that member the indications to create the algorithm step by step in case he didn't knew how to use Grasshopper.
Then a member started to laugh and to joke to undermine the idea of using Grasshopper, long story short, he said, I don't want to program, nor to learn programming, I want something that does what I want when I want to it to be done how I want it to be done.

And as far I know and seen, most ArchiCAD users are like that whether it was for Grasshopper or GDL, except for a minority and those who are really busy and don't have some free time to dedicate it to learning.

2. About Graphical GDL & "reinventing the wheel":
2.01. Many of you may not know that GDL is capped in what is refereed to bi-directional communication data exchange (i.e: the data that is sent/received between library parts and the program is limited), when right now, our practices are in the verge to conversion to adopt IT technologies and data, which is something that is somehow is already/almost solve/WIP solved with Grasshopper... so creating a Graphical GDL will not solve the problem of increasing ArchiCAD's user base.

2.02. We already have many solutions for something similar to Graphical GDL, you have Lena from BIM object which I judge as a good intent, but in fact it have been badly executed for reasons I will not mention in this thread, and you have Marionette from Vectorworks that as much as I know (correct me if I´m wrong) didn't increase the number of users that would like to adopt the program.

2.03. The other example we have is Revit Families, and adopting this method will lead to add an overhead that is huge and unnecessary that will take off all GDL benefits that we have now.

2.04. Graphisoft still have some homework to do with GDL, like adding some hard codded data parameters that we can use for data exchange related to MEP, such as for electricity and HVAC system.

And those is a very short idea of what is happening.

@DA3DALUS
Thank you, I already knew about that, but my idea was that I have seen some IT companies creating a Graphical interface for FM management, and I though that if you took what you already have and modified it minimally to that purpose it may lead to open up the market.

@Braza
Thanks.

As an old ArchiCAD user, I have found out that Graphisoft is not that type of company that will do what ever that is asked for to do, but will give you the answer you need, but lately I'm starting to have my doubts

[henryL]

Moonlight wrote:
8. Most of the people here, does not want to learn GDL, better said they act like people of advanced age that although they have the brains, they actively ignore modern technology.

Most people here don't have time to learn GDL, most people outside here (archicad user majority) don't have time and don't want to learn GDL .

Moonlight wrote:
9. On the other hand we have Grasshopper as an example for graphical programming interface that can do that and more, and creating a Graphical GDL will be like reinventing the wheel.

Not true because
1- only people who own a Rhino license can use Grasshopper
2- Grasshopper is limited because as far as i know, it can't deal with a symbolic coherent 2D representation of a 3D element
Also if you look at other software houses they all "reinvented the wheel" Revit has Dynamo, Allplan has Visual Scripting Vectoworks has Marionette

Moonlight wrote:
PS: All Grasshopper users already know that at one time they may need to write a programming script either in Python or C# or Visual Basic, so I guess you may understand why I say it will be like wasting resources.

Yes "at one time" common users will have to use them 0,01 % of times