Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wall.ByCurveAndHeight doing different things on subsequent runs #1029

Open
ghost opened this issue Jun 9, 2016 · 7 comments
Open

Wall.ByCurveAndHeight doing different things on subsequent runs #1029

ghost opened this issue Jun 9, 2016 · 7 comments
Assignees

Comments

@ghost
Copy link

ghost commented Jun 9, 2016

If this issue is not a bug report or improvement request, please check the Dynamo forum, and start a thread there to discuss your issue.

Dynamo version

1.0

Revit version

2016

Operating system

Windows 7

What did you do?

Placed walls by curve and height and level once, and edited the base offset of one wall.

What did you expect to see?

nothing strange

What did you see instead?

At the first run, all walls sat directly on the level (as expected). Then, I made a modification to the base offset parameter of ONE of the walls. Then, on second run, ALL the walls jumped up to the elevation of the curve from which they were generated, without any change to their base offset parameter. See screen capture here: http://www.screencast.com/t/7VEl5B33C5mw

@kronz
Copy link

kronz commented Jun 14, 2016

@andrewheumann I can't get this to reproduce on my machine. Can you send me your script?

@ghost
Copy link
Author

ghost commented Jun 14, 2016

I can reproduce this one consistently with the attached DYN/RVT. on first run, drops to level - modify the offset of one of the four walls, re-run and everything re-generates w/ an offset.

wallByCurveIssues (2).zip

@kronz
Copy link

kronz commented Jun 14, 2016

@andrewheumann Whoa, something very weird going on. OK, thanks, I can repro something similar to what you are showing with the rvt file you sent and a script I made. We'll take a look.

@kronz
Copy link

kronz commented Jun 14, 2016

Tracking internally as MAGN-10241

@kronz
Copy link

kronz commented Sep 23, 2016

Scheduled for 1.3 release fix

@ksobon
Copy link
Contributor

ksobon commented Jun 1, 2017

@kronz was this addressed in 1.3 release?

@kronz
Copy link

kronz commented Jun 2, 2017

@andrewheumann @ksobon Hmm, no, looks like this didn't make the cut. keeping open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants