Collaboration with other software
About model and data exchange with 3rd party solutions: Revit, Solibri, dRofus, Bluebeam, structural analysis solutions, and IFC, BCF and DXF/DWG-based exchange, etc.

what does or does not work with the 13 upgrade

Anonymous
Not applicable
VBe?
MEP modeler?
Google Earth connection?
Objective?


Cadimage requires upgrades...they are available now....for a price, but before I actually get 13. Anyow, Add-ons have been problematic with past upgrades. Anyone able to speak to this.

Thanks in advance, Cary
30 REPLIES 30
Fabrizio Diodati
Graphisoft Alumni
Graphisoft Alumni
This one must have hurt.
quite hurting for the developer...
on the other hand I'm also the Italian ArchiCAD Distributor so... what I loose from one side I gained from the other one!

Friendly
Fabrizio
Fabrizio Diodati
Graphisoft Italy Srl | Via Rossignago 2/A Spinea Venezia 30038 Italy
Fabrizio wrote:
This one must have hurt.
quite hurting for the developer...
on the other hand I'm also the Italian ArchiCAD Distributor so... what I loose from one side I gained from the other one!

Friendly
Fabrizio
Fabrizio, I think if it is possible, you should still release your CurtainWall tool. (assuming you haven't completely abandoned it, and assuming you aren't under any pressure from GS to not take away any thunder from their AC12 Flagship feature).

Just because a tool already exists in the ArchiCAD toolset doesn't necessarily mean that the GS developers have addressed their customers needs in the most intuitive, logical and easy-to-use manner, nor does it mean that that same functionality can't be provided in a much better and more developed and robust format in the form of a third party-addon. Look at the native Stair Tool in ArchiCAD (which is universally hated) versus your ArchiStair or even CadIamge's Stairmaker. Both Third party tools are far superior to what we get out of the box in ArchiCAD. And then there's the Mesh tool versus the various Landscaping tools and Terrain modeling tools (ArchiTerra, ArchiForma etc.), the deplorable ArchiCAD Window and Door Libraries versus the Door and Window (and Cabinet) maker tools that you third-party developers provide.

I could go on and on and on, and give you lots of reasons why just because the tools exist in AC (or at least just because GS calims they exist) does not mean that you guys shouldn't provide alternatives (which more often than not are more popular and easier to use) that show there' a better way of approaching these issues.

But I'll stick with the Curtain Wall tool and just point out how demented or deluded it is, in that, as far as it is implemented in ArchiCAD 12, one cannot edit it in plan view despite the fact that this is supposed to be an element that's supposed to be in agreement with other elements on plan (and some of which are ONLY accessible from the plan view) such as structural grids and elements (columns and beams), openings and such - you can only edit it in the 3D window, where there are already enough problems with snaps and snapping in 3D to existing elements - and where I might add, one can't draw 3D polylines or lines. Apparently this little mishap has been somewhat addressed to some degree in the AC13 CurtainWall tool (it is editable to some degree on plan), but the fact that you roll out such a feature with such a glaring screw-up, and highlight that as a major feature of your new release, is part of the reason why it would be nice to have an alternative that shows how this could have been done right some other way. That the GS developers even thought it was a good idead to have such a major tool of such a major element that is only editable in the 3D window, is just part of what boggles the mind as to whether these guys actually know how architects design or think.

In any case, I would still implore you, if possible to still release your CW tool and not completely give up on it. History is on your side insofar as developing tools that work in more intuitive and easier ways than what we usually get from AC. And I would also like to echo Necko's point, that our frustration is not primarily aimed at you guys, third party developers (especially fellows like yourself and Ralph who are here on these boards more often and frequently than GS developers themselves and more responsive to user needs - often putting GS to shame), but is primarily aimed at GS itself for their deluded yearly upgrade cycle which seems to make not sense for anyone from, they themselves - who can't seem to keep upgrading the product at a reasonable enough pace, to you third-party developers who are forced to keep up and keep recompiling your products, all the way to us the customers who are perpetually presented with watered down and diluted upgrades each year. And also for the fact that their reluctance to improve their toolset, means that we increasingly have to depend on you third party developers to not just provide alternatives to what already exists in ArchiCAD, but also in more and more scenarios, to plugin and make up for what doesn't exist in AC( but should) because GS refuse to look at their own users' wishlist.

Again, guys like you and Ralph provide an invaluable service (and products) to what would otherwise be a very frustrating user experience in this program, so please take our frustration as not being aimed at you.
Anonymous
Not applicable
Well I must chime in here, guess I'm board at the moment.
Even though I'm only an end user, I get it that the third party developers need to charge for upgrades to newer Archicads'
Nobodies forcing me to buy a new Archicad and as long as the add-ons still work for the version I bought them for, I got what I paid for.
If I buy a new 2010 Chevy pick up and buy some accessories for it from a different accessory parts house; what a fool I'd be if I latter buy a new 2011 truck when it comes out and demanded that the accessory parts house give me new accessories for free for my new truck.

lec
Dwight
Newcomer
Absolutely:
The trouble is in the false expectation of the user rather than the promise of the vendor.
Dwight Atkinson
Anonymous
Not applicable
Fabrizio wrote:
That means 5 of our 15 add-ons (and the most sold) have been deeply affected by the changes coming with ArchiCAD 13.
The fault is not yours, but it certainly a major GS fault.

IFF Archicad had a PROPER api, then all these would never have happend.
And what does proper means? Propers means, a set of functions that hide all the functionality from the programmer, allowing the api creator to change the underlying layer as often as he wants, without affecting the upper structure.


p.s ADD RUBY TO ARCHICAD. (or any other proper scripting langruage)
Ralph Wessel
Mentor
oreopoulos wrote:
Propers means, a set of functions that hide all the functionality from the programmer, allowing the api creator to change the underlying layer as often as he wants, without affecting the upper structure.
Encina - and presumably other API developers - have developed wrappers for the API to provide this kind of protection. None of Encina's add-ons make any direct reference to the ArchiCAD API at all; changes are entirely absorbed at the wrapper level. This means I can effectively do a simple recompile for every add-on. However, the wrapper still has to be updated for API changes and - more significantly - every function still has to be checked in every add-on.

For example, Rod Jurich picked up a flaw we missed in OBJECTiVE for AC13 that only occurred with one tool in section/elevation. This wasn't due to a function or parameter change, but because the methodology - i.e. the required steps before and after the function call - had changed. This can only be found by extensive checking, and the time it takes can be quite significant.
Ralph Wessel BArch
Anonymous
Not applicable
Ralph wrote:
oreopoulos wrote:
Propers means, a set of functions that hide all the functionality from the programmer, allowing the api creator to change the underlying layer as often as he wants, without affecting the upper structure.
Encina - and presumably other API developers - have developed wrappers for the API to provide this kind of protection. None of Encina's add-ons make any direct reference to the ArchiCAD API at all; changes are entirely absorbed at the wrapper level. This means I can effectively do a simple recompile for every add-on. However, the wrapper still has to be updated for API changes and - more significantly - every function still has to be checked in every add-on.
What you are doing should be done at GS level. So actually no recompilation would be ever needed. For me its just bad programming from GS side, or old code without that in mind.

In any case, GS should change that YESTERDAY.
Anonymous
Not applicable
oreopoulos wrote:
In any case, GS should change that YESTERDAY.
And you should have changed for another soft a loooong time before YESTERDAY.
In fact the best would be if you had (YESTERDAY) rewritten the entire soft yourself, because you seem to know much much better that any of us what good CAD programming should be. Something that works perfectly in whatever 16, 32, 64 and 640000 bits, PC, Mac, Linux and Playstation; of course without any need for any kind of add-on.
And don't forget scripting, we'll love it.
owen
Newcomer
oreopoulos wrote:
a set of functions that hide all the functionality from the programmer, allowing the api creator to change the underlying layer as often as he wants, without affecting the upper structure.
Does oreopoulos not have a point here?

Notwithstanding the significant structural changes that AC13 must have introduced to enable TW2, the API should insulate developers from underlying changes to how ArchiCAD goes about doing certain functions. New features would obviously need new API functions, but the point is existing API functions should not change from version to version .. therefore existing addons/plugins should not be broken.

Again as he pointed out, other applications seem to be able to handle plugins from old versions without this need for developers to upgrade them each time there is a new version of the host program. What is stopping this principle from applying to ArchiCAD?

I'm not trying to be difficult - just genuinely interested as these questions and frustrations are raised by clients who understandably can get irritated when faced with multiple plugin/addon updates which cost money or lost productivity (when the plugin update is delayed - e.g C4D Exchange for AC12).
cheers,

Owen Sharp

Design Technology Manager
fjmt | francis-jones morehen thorp

iMac 27" i7 2.93Ghz | 32GB RAM | OS 10.10 | Since AC5
Ralph Wessel
Mentor
owen wrote:
Does oreopoulos not have a point here?
New features would obviously need new API functions, but the point is existing API functions should not change from version to version .. therefore existing addons/plugins should not be broken.
- just genuinely interested as these questions and frustrations are raised by clients
This is difficult to answer - there are many facets to the problem. In broad terms...
  • 1) The ArchiCAD API is relatively large; smaller than the API for Windows or the Mac OS, but far larger than some I've used for database plugins etc., and provides a huge array of data structures that change significantly over time. Providing a compatibility layer isn't impossible, but would be expensive. Some changes, like the shift to 64-bit, would break compatibility anyway.
    2) The user and developer base is relatively small. If I developed for the iPhone/iPod Touch, I would have a potential market of 40 million users. Apple have sound economic reasons for maintaining compatibility as updates are rolled out. I don't know how many ArchiCAD users there are, but I suspect it would be something like 2% of that figure. Development for ArchiCAD is relatively risky and difficult, and consequently there are very few who do it. This means that the expense of providing a compatibility layer for the API would be borne by fewer users, and would eat up a proportionally larger chunk of Graphisoft's development budget.
I think Graphisoft should have provided some kind of OO wrapper for the API that both simplified initial development and migration, but it's a bit late for that now (committed developers have already done it).
Ralph Wessel BArch