topic Re: a couple of wall-related bugs . . . in Modeling

a couple of wall-related bugs . . .

__archiben — Fri, 26 May 2023 13:03:54 GMT

un-reported yet. i'd appreciate some feedback first . . .

1. first off, parameters:
using the syringe ('pick up parameters') command in automatic walls takes everything bar the level values (top and bottom heights). should it? or is this operationally correct for automatic walls?

example: my wall height values are from 0 to +3000 ('b' and 't') . . . i go to the first floor (second floor for you guys across the pond) and syringe an auto-wall placed between +3000 and +6000. when i try to place it i get the "as a result of the last operation elements have been created on others stories..." alert. a quick check in the info box shows my wall height values never changed during the syringe operation and thus the wall is created back on the ground floor.

now, i can see that you might want this to happen in reverse - which is why i'm hesitant about reporting it as a bug - but is there a logic i'm missing in this scenario?

2. next, editing the heights of multiple walls in the 3D window:
it has been discussed previously and the bug supposedly 'fixed' (here). but it seems now that we can only stretch the heights of multiple walls in the 3D window if their reference lines all connect (i.e. form a polyline). i'm trying to stretch the heights of two unconnected parallel walls at the same time and finding i cannot!

did i speak too soon in that thread above? i'm pretty sure that this was previously possible in AC9 (but i can no longer open it to check without resorting to WIBU madness) . . . so is this still a bug?

getting kinda fed up with graphisoft's half-arsed implementation, supposed 'fixes' and constant scissors-and-cellotape workarounds built on top of flaky technology and added-on with fingers crossed . . .

~/archiben

Re: a couple of wall-related bugs . . .

Link — Thu, 05 Oct 2006 00:20:30 GMT

1. Seems logical enough to me mate, what did you expect to happen? It stores everything in the Wall Settings dialog, including the height and elevation, but the elevation is always relative to the story you're on. This is where the Info box may be misleading you?

2. This is a bug, and yes they are aware of it.

You? Fed up?? Pinch me, I'm dreaming...

Cheers,
Link.

Re: a couple of wall-related bugs . . .

Anonymous — Thu, 05 Oct 2006 00:35:31 GMT

1. You want wall's settings to be relative to current storey, sounds reasonable. Maybe a(nother) preference setting.

"Make automatic wall's base and top heights relative to current storey "

Re: a couple of wall-related bugs . . .

Aussie John — Thu, 05 Oct 2006 00:38:21 GMT

~/archiben wrote:
un-reported yet. i'd appreciate some feedback first . .
1. first off, parameters:
using the syringe ('pick up parameters') command in automatic walls takes everything bar the level values (top and bottom heights). should it? or is this operationally correct for automatic walls?
~/archiben

Yes this has been annoying me. I would prefer that the syringe picks up all the parameters.

Re: a couple of wall-related bugs . . .

__archiben — Thu, 05 Oct 2006 00:50:37 GMT

Link wrote:
It stores everything in the Wall Settings dialog, including the height and elevation, but the elevation is always relative to the story you're on. This is where the Info box may be misleading you?

ah - there's the problem. unfortunately, is this another case of our "consistency" lecture shooting ourselves in the foot again? although that maintains the consistency with the logic of legacy wall behaviour, maybe that logic needed to be thought through with the introduction of auto-walls? i'm with john - i want the absolute levels to be picked up by the syringe, NOT the relative-to-floor-level . . . and wouldn't that cover relative-to-floor-level for non-auto walls anyway?

2. This is a bug, and yes they are aware of it.

glad to hear it - you're sure they're aware this is a distinct aspect of the first 'stretch multiple walls' bug and they don't think that they've already got it fixed? wouldn't surprise me . . .

You? Fed up?? Pinch me, I'm dreaming...

yeah. can you believe it? revit here i come . . .

Re: a couple of wall-related bugs . . .

__archiben — Thu, 05 Oct 2006 00:53:38 GMT

s2art wrote:
"Make automatic wall's base and top heights relative to current storey "

or better still - define a relationship between a wall's top and bottom levels and slab-x/storey-x levels . . . the marquee works great for handling horizontal relationships, but vertical relationships are still awkward, inconsistent and a pain to resolve quickly and efficiently.

~/archiben

Re: a couple of wall-related bugs . . .

Link — Thu, 05 Oct 2006 01:36:49 GMT

Maybe GS should consider Parameter Transfer Preferences, similar to the Favorite Preferences?

Cheers,
Link.

Re: a couple of wall-related bugs . . .

__archiben — Thu, 05 Oct 2006 03:13:09 GMT

Link wrote:
Maybe GS should consider Parameter Transfer Preferences, similar to the Favorite Preferences?

no. then it gets too confusing. default logic should work the way you expect it to. it's too easy to propagate an application with settings and options at the greater risk of causing even more confusion and conceding 'ease of use'.

but hang on: there is still something mysterious happening here.... i have an inkling that this only occurs if the syringe-clicked wall is one that has originally been created out of it's 'home' storey. whatever's going on, it's wrong.

the thinking man's solution would surely be to divorce the wall reference line from the wall base elevation? (but hang on i hear you shout: an automatic wall doesn't have a 'vertical reference point' does it?!). graphisoft clearly haven't been thinking too much in recent years. they've just been making it 'work' in a "let's-deal-with-80%-of-required-solutions-and-hope-for-the-best" kind of way.

Re: a couple of wall-related bugs . . .

SeaGeoff — Thu, 05 Oct 2006 16:10:10 GMT

Link wrote:
Maybe GS should consider Parameter Transfer Preferences, similar to the Favorite Preferences?

Not preference but option. Normal syringe=all parameters transferred. Syringe+modifier=options dialog with include/exclude check boxes.

Re: a couple of wall-related bugs . . .

Karl Ottenstein — Thu, 05 Oct 2006 17:26:36 GMT

Geoff wrote:
Not preference but option. Normal syringe=all parameters transferred. Syringe+modifier=options dialog with include/exclude check boxes.

I like this idea, Geoff....

Karl

Re: a couple of wall-related bugs . . .

Djordje — Fri, 06 Oct 2006 10:32:11 GMT

~/archiben wrote:
ah - there's the problem. unfortunately, is this another case of our "consistency" lecture shooting ourselves in the foot again?

Not in my book. It is consistent, until the Stories are the main vertical identification. Speaking of Revit, until the Levels are implemented (I hope never) that can or not have implication of a Storey or a plan, it should be like this.

~/archiben wrote:
yeah. can you believe it? revit here i come . . .

Installed XP already? 😉 BTW, both 9 and 10 work on MBP under XP ...

Re: a couple of wall-related bugs . . .

__archiben — Mon, 09 Oct 2006 21:29:34 GMT

Djordje wrote:
Installed XP already? 😉

i'd done that by day 4 with the MBP! but i was running it through apple's boot camp, so didn't really have the inclination to dual boot. but now that parallels is stable, officially release and patched, i've installed that. still on trial at the moment, but i don't think it will be long before i buy the license.

BTW, both 9 and 10 work on MBP under XP ...

anything that runs on win XP will run on win XP through parallels, so yeah: both 9, 10 and revit all fire up without any trouble . . .

~/archiben

Re: a couple of wall-related bugs . . .

Thomas Holm — Tue, 10 Oct 2006 10:00:35 GMT

~/archiben wrote:
BTW, both 9 and 10 work on MBP under XP ...
anything that runs on win XP will run on win XP through parallels, so yeah: both 9, 10 and revit all fire up without any trouble . . .

Ben, can you run AC 10 in XP and in OSX simultaneously under Parallells? No Wibu key issues?

Re: a couple of wall-related bugs . . .

__archiben — Tue, 10 Oct 2006 21:31:24 GMT

Thomas wrote:
Ben, can you run AC 10 in XP and in OSX simultaneously under Parallells? No Wibu key issues?

ah. no. unfortunately parallels does steal my WIBU key from the mac OS and doesn't give it back too easily.

~/archiben

Re: a couple of wall-related bugs . . .

Thomas Holm — Tue, 10 Oct 2006 21:40:05 GMT

~/archiben wrote:
ah. no. unfortunately parallels does steal my WIBU key from the mac OS and doesn't give it back too easily.

Sigh...
Another nut to crack for the Wibu bunch... This one is even harder than the yet unsolved AC10Macintel+AC9Rosetta issue, I'd guess.

Eh.. How 'easily'? Do you have to restart? Or just quit Parallells? (if restart is the answer, I guess BootCamp is just as well for the moment)

Re: a couple of wall-related bugs . . .

Anonymous — Sun, 29 Oct 2006 07:58:55 GMT

Stupid question but have you tried removing the key & then reinstating it when in Parallels may be worth a shot. (i am not sure why any one would want to bootcamp into Windows camp) when there is Parallels)

Re: a couple of wall-related bugs . . .

__archiben — Sun, 29 Oct 2006 22:24:41 GMT

Martin wrote:
Stupid question but have you tried removing the key & then reinstating it when in Parallels may be worth a shot.

i haven't - but i will next time i get a chance to play around a bit . . .

(i am not sure why any one would want to bootcamp into Windows camp) when there is Parallels)

simple. performance and hardware sharing. although parallels is not doing much emulation because the chips are intel now, there is still a minor performance drop in running one system inside another. combined with the memory handling (two 'systems' using addressing the RAM at the same time?) and hardware issues like the WIBU key thing above, booting directly into windows is always going to be the preferred option when using 'pro-app' heavy duty processing stuff . . . for the moment . . .

~/archiben

Re: a couple of wall-related bugs . . .

Gerald Hoffman — Mon, 30 Oct 2006 17:54:42 GMT

I was under the impression that there was a performance hit in Parallels with video. Is this true or has that been corrected. I think it was due to a lack of video drivers for Windows or was this just in Bootcamp? I am in the market for a new laptop and have never considered a Mac before now but this is starting to get interesting. I have a 24" Dell panel which I would hook up to in the office but would want to be sure I can run it in native resolution and that there wouldn't be any issues with OPEN GL.

I would rather run AC in Windows until they fix the lack of docking in the Mac so I would not want to take any performance hit.

This is probably the wrong place for this question but you guys were discussing Parallels here so thought I would ask.

Thanks,

Re: a couple of wall-related bugs . . .

__archiben — Mon, 30 Oct 2006 20:50:43 GMT

Gerald wrote:
I was under the impression that there was a performance hit in Parallels with video. Is this true or has that been corrected. I think it was due to a lack of video drivers for Windows or was this just in Bootcamp?

bootcamp is essentially a hardware-driver generator for your specific hardware setup. i think they've got most of it nailed now, but i doubt we'll see the real-deal, gold-master drivers from apple until they release bootcamp officially as a part of leopard (OSX 10.5). i believe it's due in the first quarter next year(?) i would imagine - i don't know for sure - that parallels piggybacks the bootcamp driver development?

I have a 24" Dell panel which I would hook up to in the office but would want to be sure I can run it in native resolution and that there wouldn't be any issues with OPEN GL.

dual-monitor problems such as this are actually more dependent on the graphics card in the machine you opt for . . . the trouble with macs is that you don't have the hardware flexibility that you do with PCs: what you get in the box is what you get. there is no changing graphics cards later, etc... it sounds like you're after a laptop. this is the top spec of the new range of macbook pro's released last week:

"Apple MacBook Pro 17" Tech Specs" wrote:
Dual display and video mirroring:
Simultaneously supports full native resolution on the built-in display and up to 2560 by 1600 pixels on an external display, both at millions of colors

it is also only a 256MB card: so if you were hooking up an extra monitor, this is automatically going to halved to 128MB each per monitor. not so good . . . if you were looking at workstation though, you can build your own mac pro xeon with 2x 512MB cards: one for each monitor

I would rather run AC in Windows until they fix the lack of docking in the Mac so I would not want to take any performance hit.

but have you tried the mactel build of archicad running on intel chips from within OSX?! might make you reconsider your (minor?!) palette docking issue?

~/archiben

Re: a couple of wall-related bugs . . .

TomWaltz — Mon, 30 Oct 2006 20:55:53 GMT

The cool rumor I've seen circulating is that you could turn on fast user switching and switch between Windows and Mac OS... WAY better than rebooting!