Archicad 29 is unusable due to Teamwork errors. Please review a measure to provide a partial refund

[Lee KiSeong]

Archicad 29 is unusable due to Teamwork errors. Please review a measure to provide a partial refund of the Archicad 29 subscription fee.

Hello.

This is the first time in 14 years I have had such a terrible experience.

The client computers are Macs. The server is Windows 11.

The time servers are all identical, set to time.apple.com. (I even attempted to unify the time on the Windows server using the UTC method, but it was of no use.)

The error shown in the image below appears 3 to 4 times a day, causing about 30 minutes to an hour of work to vanish each time. I am suffering significant financial loss.

I converted from a perpetual license to a subscription and prepaid for 3 years.

The exact same issue occurs in SaaS as well. Only in version 29!

Graphisoft has completely failed with version 29.

What is even more despairing is that I have seen many reports of similar issues to mine in the community.

Yet, Graphisoft has absolutely no idea what the cause is.

I received a response telling me to clear the cache files and test again.

If the cache files are the problem, then why does version 28 work perfectly fine without issues?

Please take a look at what I have gone through over the past 2-3 days.

[Patrick M]

I had a realization last friday and today. in both cases, 2 different files, we had 1 or more team members who's work was not visible by other team members. Some with warnings, some without. In all cases, the bimcloud manager reports that they sent, and even gives a sent data cache size.
with each send, the server shows that they sent. it shows that other team members are receiving.
...
at this point, I do not believe this is an archicad problem. I think this is a bimcloud problem. 
...
It appears that BIMcloud is recognizing users data is sent, but is failing to synchronize that data with the server caches. Now, wether this is because of a flaw in archicad or bimcloud, I don't know. I'm not a software engineer. But by all appearances, if I were diagnosing this as a structural or mechanical system, I'd say that this is an error BIMcloud; a foundational failure, not a mechanism failure.

[Patrick M]

happy to report that 29.1 has helped us a lot. We are no longer mysteriously losing work due to failed s/r.
we are still getting teamwork warnings; but this is back down to a "normal" frequency (which is still way too frequent to accept from a high end bim authoring tool).

Teamwork warnings/errors need to pop up when there are issues. Issues can not be a daily occurrence. 
If it requires every project team have an archicad expert dedicated to trouble shooting software malfunctions and file maintenance issues, whats the point? we're wasting as much time as if we were flat cad drawing buildings again (only speaking slightly hyperbolic here, its honestly a LOT of time that goes into maintaining files to limit teamwork mishaps)

[GCP]

@Patrick M  

Do you still experience loss of work? And what do you mean by “normal” frequency — once or twice a week?

The reason I ask is that, after experiencing the same problems everyone is frustrated about, we had to fall back to Archicad 28 once again.

If the 29.1.0 update solves the problem, we would consider migrating -again- to Archicad 29, since we also model MEP, which is much better in AC29.

Can you share a bit more about your experience with this new update and whether you are happy with it?

Has anyone else tried it?

[Patrick M]

AC29 had a bug that resulted in send/receive often either not working, often times user A and user B would have different local data, regardless of how many s/r they tried. The server showed sent caches from both. But no amount of teamwork attempts synchronized data. Reload from server or leave and rejoin resulted in lost work, as the server was NOT receiving, despite the server activity log indications.
Worse yet, there were several recorded instances where send/recieve would result in local data regressing to old server data, overwriting local data changes with outdated server data... effectively undoing all work done since the previous send, and sometimes even from the day before, even though subsequent sends had been recorded on the server logs.

...

As for "normal frequency" of teamwork operations; no amount of teamwork warnings interrupting the work day is acceptable, but I have noticed these warnings and hangups for over 2 years now. I generally expect in a clean and operational file to see warnings up to 2-3x a week per user. This is a massive PITA, and a horrible obstruction to efficient and effective work; and should in no way be swept under the rug.
I first brought up the frequency of teamwork malfunctions, warnings, and failures, like I said, 2 years ago... It's been met with general apathy, until it culminated in the most recent teamwork melt downs of AC29. Now that this recent bug has been fixed, I'm hoping to see continued persuit of improvements to bimcloud and teamwork operations; but that has yet to be seen.

[GCP]

@Patrick M  Thank you very much for your reply. 

[Brandon-W_DWa]

We are an office of ~20 AC users, almost exclusively within Teamwork Projects on our BIMcloud SaaS (of course we're on the new subscription too). We are all on AC28 (and don't plan to move to 29, as we skip every other version). A user just came to me today with the same error message in the OP scenario. My usual first troubleshooting step is to leave the project and rejoin, but after doing so, the user noticed about 3 hours of work from this morning was lost. They also had a weird symptom for roughly a day where geometry would not update visually in 3D, but the nodes/hotspots would accurately represent the desired location. E.G, an opening would be at x,y,z, but the nodes for the same opening would be at different coordinates.

I'm wondering what the best practice steps are to "clear TW data and cache folders"? I could probably figure it out, but I'd like to know the right/tried n' true way before I make assumptions. Thanks! Affected user has the same AC/Mac/macOS as my signature.

[Laszlo Nagy]

---

@Brandon-W_DWa wrote:

They also had a weird symptom for roughly a day where geometry would not update visually in 3D, but the nodes/hotspots would accurately represent the desired location. E.G, an opening would be at x,y,z, but the nodes for the same opening would be at different coordinates.

---

Do you guys by any chance model far from the Project Origin? These visual glitches usually occur under those circumstances.

[Brandon-W_DWa]

I wondered the same thing, as modeling far from the Origin was indeed a common problem in our office for years... but no, it's a clean model, with the origin in a logical location in relation to the building.

What was odd about the geometry vs. control points discrepancies is that they were only experienced by one user; i.e. other Teamwork users in the same file did not observe the 3D issues for the exact same modeled instance, which is why I am leaning toward the TW cache as the potential culprit.

[Laszlo Nagy]

This is just an idea, but I am thinking there may be another way this is issue can come up. It is when the bounding box of your whole project is extremely large.

The way this can come about is when your project is near the Project Origin, but some geometry (maybe only a few elements) is extremely far from the Project Origin. This happened to me before when I did not properly entered a drag distance and copies were created extremely far without me noticing.

You can check for this by showing all layers, then going through all your  stories one by one and activating Show All in the context menu, while will zoom out enough so it shows all elements. If there are elements extremely far, the zoom factor will be so low that it will be like 0.000001% or similar, plus you will not see anything on the floor plan because you are zoomed out so much. However, if you press CTRL+A to select all, the selection dots near one of the corners of the floor plan will give away the very far elements. Then you can delete those to handle the situation.

If all goes well and these are found and handled that shoulds solve the selection nodes vs. displayed geometry shift.

Unfortunately, this situation may be complicated by Renovation Filters (select one where all Reno Statuses are shown) and Design Options (the problematic element may be on a Design Option currently not visible).

Let me know if this helps.

[Davor P]

My 2 cents on getting around design options not allowing you to see everything all at once - save a pln then create one DO folder for each option and drag options around until each folder has only one DO. Then you can turn them all on.