Wishlist

Favorites are great, and will vastly improve our Template for new projects. However, I have made a lot of new helpful favorites in our company template that staff want to use now, in their active project.

When I export any Favorites from the template that contain custom Profiles (to give to folks who want them now), I have to also manually export and then import those Profiles, and hope that adding by Index doesn't overwrite something important in the receiving file. I wish that exporting a Favorite would bring along any of it's attributes, even if I have to manage the Index numbering upon import in the receiving file.

This is most important for Curtain Wall favorites, because we use that tool for everything (usually with custom profiled frames), given that a dedicated ceiling tool doesn't exist.

The new experimental physical renderer appears okay for external building 3d views.  But for internal views there is a strong dark blue cast to shadows which makes the physical renderer useless and unusable for interiors.  This is quite a major oversight, please can you resolve this.  Support say I can't change this:  

'as it's controlled by the procedural skydome which the ambient colour cannot be changed. You can request for the control of this on our public wishlist'

Can this feature be developed into a proper feature as it has value.  I really like the current 'sketch-up' type aesthetic of the current 3d view, and the physical renderer is not yet good enough to use as an alternative.  Thank you.

Though it is welcome for new users this screen is bloatware for older users and we should be able to disable it completely and/or able to remove unnecessary bloat

In many workflows, there is a critical need to control the door opening angle individually per view, and per door, to reflect specific functional or regulatory requirements.

When producing evacuation plans for the fire department, we need to show certain doors along the evacuation route in the open position, while other doors marked “close in case of fire” must appear closed. This differentiation is essential for clear communication and compliance with fire safety regulations.

At present, door opening angles can only be controlled manually per object (static, not view-dependent), or globally via the Model View Options (MVO), which applies the same state to all doors in a given view.

This means we cannot have different doors shown open or closed within the same view;

We propose the following enhancements to door behavior in Archicad:

1. Per-view control: Allow the door opening angle to be defined differently per view.

2. Per-instance override: Allow exceptions per door object within a view—e.g., door A open, door B closed—without affecting all doors.

3. Integration options: This control could be added to:

   • The View Settings,

   • The Model View Options,

   • Graphic Override rules

   • As a new parameter linked to Properties or Classification.

    

Merge dimension preferences with calculation preferences – having these separate is confusing for teams and requires multiple settings. 

The ability to assign Properties to drafting tools, not just modeling tools - this would allow scheduling of additional tools. Perhaps by providing a "Drafting Tool" classification with readable data.

Hello Team

PS: based on feedback from Laszlo Nagy in the comments below, he confirmed that the Project Info fields are already accessible from Publisher.

So the outcome of my wish should just change to: "see everything as in all data access cases like this. If the data is too long, make the groups collapsible + make the list scrollable & searchable".

================

I want to propose / request to improve the ability to have access to Project Info (and all other data) fields from Publisher.

I have been looking for the most efficient way to build my template for ISO 19650 compliant naming of Auto Text on my Masters & output file names via the Publisher. The ISO 19650 file naming have some fields that are consistent for the practice (ie. Project Number, Originator) and others that are variable by Layout or Sub-Set.

This image shows my current setup where I "Rename" the Layouts in the Publisher with most of the ISO fields as custom Layout Info fields, apart from native Layout, Publisher, Changes & Revision fields.

Although I have come to a point where I have this working well, the limitation in Archicad for Publisher not able to access Project Info fields makes the entry & management of the ISO 19650 outputs (auto text on Masters & published file names) not ideal.

If it was possible to have access to Project Info fields from Publisher renaming function, then we can pull Project Number, Originator directly from one single entry in Project Info instead of having to enter it into Layout specific fields for every Layout in the project as well.

It makes sense (to me at least) that entering the consistent fields in one place & call it up everywhere needed (1) would save time and (2) remove the possibility for user errors (ie. missing the entry on some Layouts and (3) constantly going back to enter the same info on new Layouts created as we work.

When doing a Reflected Ceiling Plan (RCP), I usually need to show the finish of the beams as well as the slabs or the ceilings. Even would like to show the colour or different fills if they have different finishes.

Also sometimes you have different heights for them and you struggle to have a common cutting plane for the whole floor to show all objects with the fill and still cutting the walls at the correct height.

Even when we use the beam tool for other things it is useful to have the flexibility

Please provide a simple button to the toolbar which updates all modified hotlinked modules.

Now we always have to open Hotlink Module Manager first, wait for the modules to be checked, select modified modules and click update:

A quick acces button that automates this would save a lot of time.

As described in the image below, this can helmpfull to schedule exactly what we want, without extra filtering criteria.

a check box in front of each class item will fix it !  

Problem: "Toilet ADA" object has only floor mounting and "Cistern" Flush Types available; no option for Wall Mounting, or any of the other Flush Types that are available to the "WC" object.

Scenarios / Use Cases: The "Toilet ADA" object allows USA users to save a typical ADA water closet favorite, but only if the toilet is floor mounted and has a cistern. If the toilet has any other configuration, users can't use the "Toilet ADA" object, so instead have to manually place the "WC" object and three (3) grab bars, and make sure they are placed in the correct location to meet building and accessibility codes.

Wish: That the "Toilet ADA" object would have all of the same bowl options that the "WC" object does.

Currently, the text tool only allows a solid line for the text frame (text contour).

It would be a valuable improvement if we could choose any linetype available in the project file for the text frame.

This would make text annotations more flexible and consistent with the graphic language of the drawing.

We would like to request greater flexibility in the symbolic representation of doors, specifically the ability to apply different linetypes to various components of a door symbol in plan view.

In many real-world scenarios—especially in larger or more regulated projects—there is a need to visually distinguish between different functional parts of a door or to indicate special behavior. For example:

• Double-leaf doors where only one leaf is typically active:

  • The active leaf should show with a continuous line.

  • The inactive leaf (intended to remain closed unless needed) should show with a dashed line.

   

• Fire doors that remain closed in normal use, but open only during emergencies:

  • These doors should be represented with a dashed symbolic swing line or panel to distinguish them from standard doors.

   

This level of graphical differentiation is important for fire safety plans, evacuation drawings, access control plans, and any other documentation requiring visual clarity about door function and behavior.

Requested Enhancement

We propose that Archicad door objects support:

• Component-based linetype assignment for symbolic elements in plan view;

  • Active/inactive leaf;

  • Fire-rated doors;

  • Swing arcs and/or door panels;

    Control over linetypes for:

• Integration with:

  • Door settings UI;

  • Classification or custom property rules;

  • Graphic Overrides for view-dependent control.

Provide a table that lists all registry keys with a default value and description.

There are a number of keys listed and it is unclear what they do. Increasingly, there are a number of settings and fixes that need to be set through the registry as they are not accessible in the Work Environment. At this point, if Graphisoft keeps recommending changes within the registry, then the documentation should properly support it. 

Refer to how Unreal Engine lists console variables: https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-console-variables-referenc...

We experienced a lack of the following features while working on our projects:

— The thickness of the Truss is limited to 1m as a minimum. It seems that manufacturers can make it thinner, and on many occasions, it is quite important to know and show exactly how much space is left below an escalator. (I did a "subversion" of the escalator, where I changed the limit "wired-in", but I am sure many other practices would enjoy a bit more flexibility there.)

— The horizontal ends of the escalator often need to be longer, than the value automatically calculated by the script (blue areas on the screenshot attached).

I would greatly appreciate the possibility to customize commands available in the right click menu based on context (selected elements).

In my opinion this could be available next to Shortcut list in the Work Environment Settings.

Few examples:

• When selecting a Zone and using RMB we could see a command to update them,
• When selecting few lines/ polylines we could get a command to Join them.

I've found few topics about this wish, but it has never made to official Wishlist. One answer mentions some technical difficulties around it in some first try, but I truly believe that with some effort it could be possible. Links below to those topics below.

Modify Right Click Menu 

Can I customize right click menus 

Hopefully this is the correct place to post this.
Using internal elevations is painful, to be blunt. You can only move them, stretch etc by selecting the invisible line that is not automatically selected when you select the marker. Selecting the marker does not allow you to move the Int.Ele. The Internal Elevation tool does not allow you to use faded distant elements either. It is a worse version of the section tool in all ways in my opinion, to the point that I just use the section tool, but others still use the internal elevation tool and so must I. I think the tool needs to be at least as functional as the section marker, and to not have invisible lines you need to select to be able to move it.

Also, the naming and grouping of them seems to add extra unnecessary steps. You can have the group ID/Name, the actual Int.Ele. ID/Name, and the View Map ID/Name. Why do we need 3? The IE grouping in the project map is also fairly dysfunctional, a list would suffice if the ID's are correct, same as sections or elevations. Grouping them can happen in the View Map, but if absolutely required in the project map, make it functional, allow groups to be added to, or modified, however I think it should work the same as all the other parts of the project map. (Graphisoft is very good at making various tools function entirely different from the rest of the program every now and then, I advocate for the whole program functionality, menus etc to be homogenized.)

Often you will add internal elevations as required, which just creates a huge mess of single items taking up 2 lines because they are part of their own group because currently you cant add them to the existing groups. Or if you can it is some obscure work around that functions differently to the rest of the program.

Often, when doing renovations, a whole building or part of the building needs to be demoed. Then, we need to build a new building within the same footprint but with a different story height. Then, all the section and elevation story markers need to be added manually, creating confusion and extra manual work.

Also, when adding another story to the existing building, we need to clarify existing and proposed for a building permit. Then, if you need to demo a roof of a single story building, increase the ceiling height and add another story you need a new story setting for a new story that is different from the existing roof height.

This would complete the renovation option and add more usability to it.