Wall component abortes transaction


I’m glad of the great improvement achieved by RIR during these years but unfortunately I’m not really sure to understand why within the new wall components (line based or profile based) most of the time if there’s a sort of clash between geometries (new v.s. existing) the transaction is aborted and nothing happens. Probably there’s something that I didn’t get well…

I’ve attached here a screenshot where some walls that must be created with clashes as the they represents the exact geometry of another file.

Is there a way to avoid the transaction abortion and alllow the component to accept eventual clashes or simply output only the correct elements?
Can you please explain a bit the logic behind in order to understand what to do?
To be honest I’d really prefer to produce in Revit all the walls possible because the average between errors and proper geometries is 1 out of 50.

For istance for each time I’ve a problem within 1 wall I cannot make 49 walls which are corrects

ps. I’ve already tried to move outside the area of clash the base lines of the walls and it works fine

thank you very much!Please let me know if yuo need further info

Hi @massimilianobattisti,

For performance reasons all the changes are made using one big change to the model instead of one change per wall. Revit calls those changes transactions, and transactions are atomic, that meas is all or nothing.

When using the UI Revit warns you about those warnigs and errors and allow you to “Fix” those errors sometimes unjoining those conflicting elements or just deleteing them.

The missing part here is having a way to automate the answer to that dialog, right now the answer is always a “Cancel”.

I agree with you that would be nice to allow the user customize that answer.
Maybe as a list of allowed fixes like:

Allowed fixes

  • Allow unjoin conflicting elements
  • Allow delete conflicting elements

And why not an output with a list of conflicting elements and the reason the elements are conflicting.

Does it have sense to you?

Thank you very much.

If I’ve understood well it works with a single transaction whether I’m using a tree or a list. It’s a bit weird. It that the component cannot implement a loop for each element.

Hopefully it will be solved within the next upgrades as you suggested.

It seems that*…

turn around transaction.gh (12.5 KB)
I made this stupid turn around. It doesn’t really satisfy me but it works…any suggestions :grin:?