archicad 12 (13-14-15-16) kívánságlista (a korábbi wishlistek alapján)
- általános:
- ezt az anyagot még a 12-eshez kezdtem el írni, de sajnálatos módon nem sok minden valósult meg belőle; s azóta én is folyamatosan egészítettem ki újabb ötletekkel
- usability issue (a legfontosabb kérdés az ergonómia, hogy a programban lévő funkciókat megfelelően használják is)
- kattintásszám csökkentése
- van még egy pár funkció, ahol fölöslegesen kell kattintani
- s a kattintásszám csökkentése jelentős produktivitás növelő tényező (lehet)
- példák:
- pet-palettes forgatásnál elhagyható volna a tengely megadása
- a sketchupban pl. egy sor jó ötlet található
- ne a "leprogramozhatóság", hanem a használhatóság legyen a fő szempont
- még ma is vannak a szoftverben olyan megoldások, aminél lenne jobban használható, de történeti okokból (meg mert nem teljesen használhatatlan) az maradt benne; pl.: terepelem
- de pl. ilyen az egész könyvtári elem kezelés is:
- régen fontos volt, hogy a takarékosság miatt a fájlokba ne kerüljenek elmentésre az összes könyvtári elemek, de ma ez már nem volna gond;
- s az is zavaró, hogy csak a mappával csatolt könyvtári elemek frissítődnek, az egyediként behúzottak nem (mert azok beágyazott elemek lesznek automatikusan)
- használható alapbeállítások, sablonok
- vagy legalább webhely a megosztásra
- akár úgy, hogy a szoftver közvetlenül innen veszi a beállításokat
- kedvenc-kezelés fejlesztése
- mappákba rendezhető kedvencek
- vizuális megjelenítéssel
- automatizálások itt is:
- automatikus kigyűjtés a projektekből
- ez alapvetően egy sql-lekérdezés
- a tervben már használatban lévő beállítások fölajánlása
- kedvenc-kezelő nélkül
- pl.: ajtóból alapvetően több kategóriát használunk (külső, belső ajtók)
- mentés:
- webes mentés/megosztás
- automatikus mentés a 'documents and settings' mappába
- a fájlböngészős lehetőséggel összevissza történik a mentés, pedig ez tipikusan olyan, amit a kezelhetőség miatt egy helyre érdemes menteni
- de az jó, ha fájlként kerül mentésre, így a 'profibbak' fájlként is tudják kezelni
- miért?
- egy tervben az elemkönyvtárból csak véges számú elemet használunk
- de azokat sokszor többféle alapbeállításban
- ha a lerakáskor már segít a pontos beállításokban, akkor elkerülhetőek a konszignációknál jelentkező problémák:
- egyformaként szándékozott ajtók különböző beállításokkal
- ideális elemkönyvtárak esetén az építőanyaggyártóknak nem egyedi elemeket, hanem csak egyedi elembeállítás-sablonokat kellene produkálniuk
- de minden paraméter alapos feltöltésével (IFC, ár információk stb.)
- közösségi, nyílt fejlesztési lehetőség erőteljesebb támogatása
- tudom, hogy létezik letölthető sdk
- de nem elég a lehetőség biztosítása, hanem erőteljes támogatás lenne szükséges
- s mivel az építészek között levés a programozó, így a programozási vonal is erősítendő lenne
- Miért?
- nagyon komoly lehetőségek vannak az ilyesfajta közösségi fejlesztésekben
- s nem is feltétlenül a linux-világra gondolok (inkább a sourceforge, vagy az iphone apps lehet a példa)
- projekt kezelés
- valamiféle külső program a különböző projektek kezelésére
- a verziók és a publikált fájlok automatikus kezelésével
- a lehető legtöbb dolgot automatikusan, a tervekből generálva
- automatikus tervmódosulás-napló
- szűrhető megjelenítendő változásokkal
- fa-struktúrás (kibontható) részletekkel
- a módosítások helyei is generálhatók a tervből
- égtáj szerint
- fólia szerint
- épület belső/külső szerint
- ügyfél, tervadat-kezelés finomítása
- legördülő listás választási lehetőségekkel
- terv-verzió kezelés (a jegyzetelési lehetőségnél kicsit "tolakodóbban"; nem opcióként, hanem használandó funkcióként - természetesen kikapcsolhatóan)
- minden mentsd másként választásakor
- illetve x számú szerkezeti változtatás után
- automatikusan felbukkanó ablakkal
- a mentés okainak kiválasztása listából
- új munka kezdése
- szakági változat mentése
- felbukkanó ablak:
- miért nem publikálóval készíted?
- verzióváltás, oka:
- tervfázis váltás
- engedélyes
- tender
- kiviteli
- jelentős tervmódosulás
- telepítés
- alaprajzi módosulás
- tömegformálás változtatása
- egyéb:
- egyéb
- egyéb
- az elmenthető kedvencek
- a projektkezeléssel integrálva
- tematikus beállítás-gyűjtemények kezelése
- az xml-es fájlkezelésnél user-friendlybben
- a beállítóablakot is egy kicsit átértelmezve
- mindenképpen strukturáltan, mappákba rendezhetően
- a projektkezelő segédprogrammal és a
- könyvtár-kezeléssel összekapcsolva
- adaptív működés
- tanulékonyság
- ha a tervhez egyéb projektinfók is csatolva vannak
- akkor ez az automatizmus nem is olyan bonyolult
- kiegészítő ügyek
- webkapcsolat fejlesztése
- a webpublikálásban ~8 (12) éve alig tapasztalok változást
- könyvtári elemek megosztása, webes alapkönyvtárak
- a javascriptes library-khoz hasonlóan
- a jelenlegi archicad-talkos megoldás viccnek is rossz
- közvetlen mentési, olvasási lehetőséggel
- helyi másolat a gyorsabb működéshez
- a fizetős elemkönyvtárak szerintem nem váltották be a hozzájuk fűzött reményeket
- bár valóban sok munka lehet egy könyvtári elem programozásában
- de a kölcsönösségben komoly előnyök rejlenének
- mindenek előtt: fejlesztett gdl-megjelenítő (plugin)
- komolytalan a jelenlegi, majd' 10 éves plugin megoldás
- alapvetően nem plugin kellene, hanem javascriptes megjelenítő
- a java-s és plugines megoldások (tapasztalatom szerint) már csak épp túlélnek
- a javascript-ben pedig óriási lehetőségek rejtőznek
- lásd a chrome alapelvét: nincs plugin, nincs semmi,
- de van atombiztos és gyors javascript értelmező
- a javascript jól kombinálható az xml-lel
- a bimcomponents nem sok jót ígér: gyakorlatilag egy tűrhető keresővel rendelkező webes gsm gyűjteménynek tűnik
- skiccelő (vázoló) modul
- az alapvető gdl parancsok viszonylag egyszerűen átfordíthatóak lennének javascriptre, vagy xml-re
- nem kellene "mindent" tudnia; elég volna, ha csak az alapvető vonalas szerkesztéseket tudná
- az svg-hez hasonló kiterjesztett xml-ként
- canvas parancs az újabb html-szabványokban
- pda-ra, fölméréshez, gdl jellegű kapcsolattal, fölméréshez
- tudom, hogy ilyen is létezik
- illetve weblapba illeszhetően
- pl.: on-line tervegyeztetéshez
- commonCAD
- konkrét szoftver működés
- eszköz finomítások
- eszköz beállítások
- a gyakran használt beállítások kiemelése a paraméterek dzsungeléből
- nem gondolnám, hogy lehetetlen lenne írni egy olyan szubrutint, ami figyeli, hogy a program használata során melyik beállításokat használjuk a leggyakrabban, és azokat összegyűjthetné egy "gyakran használt beállítások" menücsoportba
- ez az adatgyűjtés addig tartana, amíg azt nem tapasztalná a rendszer, hogy már alig változnak az arányok
- sőt, még a bevezetés ac_verziójában nem is kellene megjelennie a "gyhb"-nak, elég ha csak a következőben jelenik meg
- de az adatgyűjtés addig is hasznos infókkal szolgálhatna a fejlesztés számára
- de akár manuális rendezési lehetőséggel
- "felszabadítások", fölösleges elkülönítések megszüntetése, összevonások
- meghagyandó elemtípusok (amiknek altípusai maradnának a jelenlegi elemek)
- vonal tipusú elemek
- kitöltés tipusú elemek
- kitöltés
- födém
- tető
- felületelem
- tárgy tipusú elemek
- tárgy
- lámpa
- nyílászáró (fal nélkül is lehelyezhetően)
- tetőablak (tető nélkül is lehelyezhetően)
- kotta tipusú elemek
- pont
- hossz-kotta
- íves kotta
- szögméretezés
- szintkotta
- fölirat
- hivatkozás tipusú elemek
- metszet/homlokzat/falnézet
- részletrajz
- munkalap hivatkozás
- én adnék megjelenítő eszközt a konszignációknak is
- fal eszköz
- fal eszköz kellene az alábbi helyekre:
- nézetekbe
- homlokzatokba
- munkalapokba
- részletrajzokba
- metszetekbe
- megvalósítás fázisai:
- 1. csak 2d-s elemként, 3d-s tartalom nélkül
- 2. komplett 3d-s megjelenítéssel
- fal profilkezelő gdl leírással
- pontosabban az egész fal elemre vonatkozóan
- nem csak a keresztmetszetet, hanem az egész falat
- speciális, sorolt elemekből készülő falak lehetősége
- raszteres jellegű falak
- vázszerkezetek a falban
- paneles falak
- vízszintes falpanelek
- fal kitöltés pozicionálhatósága
- nyílászárók
- ne csak falba lehessen elhelyezni!
- metszet-homlokzat
- átalakítás egyikből a másikba
- célszerűen: a terv térképen egyszerűen áthúzással
- ferde síkú metszet
- tört vonalú metszet
- munkalap, részletrajz
- 3d-s tartalmú munkalap
- alapvetően a sketchup component mintájára
- de a meglévő "munkalapok", "szintek", "kapcsolt modulok" funkcióinak kiterjesztésével, összekapcsolásával (de akár még a tetszőleges irányú metszet is idekapcsolható)
- nem tudom, hogy ez mennyire klappolna a bimcomponentes elképzeléssel?
- de igazából ez lenne az irány: szét lehetne választani
- a könyvtári elemeket (gyártmányok);
- és az alaprajzon nem (vagy nehezen) megmodellezhető elemek kezelését
- általában
- ne csak tervlapra lehessen elhelyezni
- hanem bármely nézetbe, de akár másik munkalapra is
- szűnjön meg a különbség a külső rajz és a belső rajz között
- mappák a munkalapoknak a terv térképen is
- tudom, hogy a nézet-térképen mappákba lehet rendezni,
- de fontos, hogy alapesetben is strukturált legyen a munkalap halmaz
- ha elkezdem használni (a munkalapokat):
- gyorsan hozzá lehet szokni,
- és gyorsan nagyon sok lesz belőle
- munkalap másolása
- context menü
- tartalommal, vagy anélkül
- fájlon belül és fájlok között is
- behúzott külső rajzok
- dwg-k:
- tükrözhetőség
- szétrobbantás esetén: egy fóliára robbantás lehetősége
- fóliabeállítások állíthatósága
- függetlenül az archicad fóliáktól
- ez a 13-ban már elméletileg működik
- archicad rajz behúzhatósága, mint a dwg-knél
- konkrétan
- kitakaró részletrajz
- nem a gsm-es, régi megoldással
- listák, konszignációk a tervlapokon, pauszon
- de a tervlap lehetőség mindenképp fontos
- kottázható konszignációk
- fóliák
- új megközelítések
- dedikált fóliák
- a fóliakezelőben bizonyos fóliákat dedikálni bizonyos eszközökhöz, hogy csak azokra lehessen elhelyezni
- teljesen fölösleges például, hogy a tartószerkezet fóliájára kottázást lehessen tenni
- strukturált fóliák viszont hasznosak lehetnének, pl.:
- kották/szerkezet/tartó, kották/[tervfázis]
- szerkezet/tartó, szerkezet/térelhatároló/belső, szerkezet/térelhatároló/külső (bár ez az IFC tulajdonságok alapján is leszűrhető)
- alapelvek, megvalósítás
- a különböző elemeket nem szükséges, hogy bármely fóliára helyezhessünk
- pl.: nem szükséges, hogy kották -> falak fóliára (illetve fordítva) kerüljenek
- ugyanis a gyakorlatban nem szoktak ügyelni a fóliakezelésre
- a fóliakezelőben, a fóliáknál legördülő menüvel kiválasztani az adott fóliára elhelyezhető elemeket
- illetve az eszözöknél: a használható fóliákat
- workspace
- fóliabeállítás nélküli munkaterület, amin a szerkesztés folyik
- fóliákra helyezés
- adott számú elem elhelyezése után
- automatikusan a különböző beállítású elemek automatikus különválogatásával
- illetve az alapbeállítások 1 gombbal történő elfogadásával
- vagy pl.: 3d-s ablak, metszet aktiválásakor
- eszközváltáskor rákéerdezés a fóliára
- illetve az infótáblán a fóliabeállítás kiemelése
- indoklás, megvalósítás alapelve
- nem használják rendeltetésszerűen a fóliákat
- minden egyes eszközhasználatkor viszont nem célszerű a rákérdezés
- ("biztos erre a fóliára akarod elhelyezni az elemet?")
- célszerűbb, ha "csomagban" történik a rákérdezés
- tehát mindenképp cél, hogy megakassza a munkafolyamatot
- de ne legyen azért zavaró
- káosz a fóliakezelésben
- aki használja annál azért, aki nem igazán annál azért
- a jelenlegi: nehézkes
- s nem is szabványos:
- 2 független tervező archicades modelljének összefűzése gyakorlatilag lehetetlen
- elsősorban a fóliák káosza miatt
- emiatt mindenképp fontos lenne, hogy valamiféle oktorjált szabványt kényszeríteni a használókra
- vagy legalább a lehetőségét biztosítani
- megvalósítási javaslat:
- egy adatbázis alapú rendszerben a legkülönbözőbb lekérdezéseknek, leválogatásoknak nincs elvi akadálya
- szükséges tehát egy algoritmus, ami bizonyos szabályok szerint (a rendezési szabályokra rákérdezve) az új fóliákra rendezgeti az elemeket
- lehetséges esetleg, hogy a többszintű fólianeveknél a jelenlegi fólianevek csak egyfajta egyéni attribútumként kerülnek a végére
- gyorsfóliák
- minden kijelölése a kijelölt fóliáján
- pausz
- állapot elmenthetősége
- pontosabban az állapot "terv-térkép"-szerű megjelenítése
- nem egyértelmű, hogy melyik pauszokat menti el a tervfájlban
- tükrözhetőség
- gyorsan előhúzható szerkesztőpausz (ne kelljen mindenféle fóliákra szerkesztgetni, ezzel is dúsítani a fóliák számát)
- stílusok
- generál funkció, mint a szövegszerkesztőknél:
- egységes megjelenés a hasonló elemeknek (enélkül elég macerás pl. az esetenként több 10 rajzon az összes kottát átnézni pl.)
- de nem csak szövegeknél, hanem minden elemnél hasznos lenne
- szövegelemek kezelése
- szerkesztés
- kezdés is [ctrl+enter]-rel (mint a befejezés)
- illetve: freemind mintára
- kezdés: alt+enter
- sortörés: ctrl+enter
- befejezés: enter
- mivel az egysoros cimkék, szövegek sokkal gyakoribbak
- legördülő menüs adaptív szövegbeviteli segéd
- kották kezelése
- a jelenlegi "szoft" működés (hogy az asszociatív kottaelemekről csak egyenként rákattintva lehet információt kapni) elég idegesítő
- többször fordult elő, hogy a hosszas szerkesztés során bizonyos asszociatív kottáim elvesztek
- metszet/homlokzat esetében rendszeresen
- de alaprajzon is (úgy, hogy az asszociatív elem nem került kitörlésre)
- ezeket jó lenne elkerülni, s a javaslataimmal nem is volna túl nehéz
- semmi akadálya nem volna, ha a kottát kijelölve a következő szerkesztőelemek jelennének meg:
- segédvonal, ami a kottázott pontot és a kottapontot köti össze
- jelzés arról, hogy a kottázott pont asszociatív-e
- illetve arról, hogy a kotta asszociatív pontja megváltozott (törlődött, áthelyeződött) - hogy én dönthessem el, hogy mit akarok vele csinálni (törlöm, áthelyezem, régi helyén hagyom)
- esetleg fölhasználható volna ez az újragondolt kotta-eszköz a parametrikus szerkesztésre is: megadható egy képlet az adott pont helyzetének meghatározására (természetesen ez esetben a kottának kellene visszahatnia a tárgyra)
- kotta szöveg elhelyezés finomítások:
- 2012-ben már elvárható volna, hogy a kottaföliratok elhelyezésénél figyelembe vegye a tervlap egyéb elemeit (többi kotta, egyéb rajzi elem)
- kottaszöveg manuális mozgatásánál célszerű lenne, ha az alapértelmezett mozgatás a kotta elforgatásának megfelelő főirány volna (ferde hosszkotta mozgatásakor a kottavonal mentén ill. arra merőlegesen lehessen mozgatni, nem pedig a rajz főirányában)
- alaprajzi szintkottáknál a szöveg alapértelmezett távolsága túl nagy a jeltől; jó lenne valamilyen beállítási lehetőség:
- akár generál beállításként
- akár a méretezési készletnél
- akár egyedileg, a szintkotta beállítótáblán
- helyiségcimke
- összekötő vonal a pecsét és a horgonypont között
- ehhez csak a horgonypont koordinátára lenne szükség, de sem globális paramétert, sem reqest paramétert nem találtam hozzá
- helyiség átfolyás az ajtóknál
- lyukak a határvonalon
- az 1-2 cm vastag "köldökzsinórok"-ról gyanítható, hogy valószínűleg nem valódi helyiségrészek
- használat
- automatizálások
- helyiségnév kiírás metszeten
- a háló eszközhöz hasonlóan
- rétegrendek automatikus cimkeként
- bár ez lehet, hogy menne jelenleg is
- egy kis programozás után
- egyebek
- kitöltések 3d-ben
- szerkeszthetőség (origó beállítás) metszet/homlokzat ablakban
- egyedi 3d-s kitöltések (3d-ben is megjelenő kitöltések, hasonlóan az anyagokhoz rendelhető vektoros mintához)
- homlokzaton rajzolható vektoros síkbeli ábrák, homlokzati motívumok, föliratok
- kitöltés-, anyaglisták korrektebb kezelése
- a jelenlegi mátrixos, ömlesztett elrendezés helyett
- mappákba strukturált módon
- akár közvetlenül fájból olvasva is
- az attribútum kezelő helyett/mellett
- ugyanis nagy mennyiség esetén borzalmasan hosszadalmas a végiggörgetés
- szintaxiskiemelős gdl szerkesztés
- paraméterlistával
- szintaxis help-pel
- listák, konszignációk
- táblázatkezelő-működéshez közelítő használat
- összegzés és egyéb függvények beillesztési lehetősége
- így megszüntethetőek lennének a listázandó elemek mögötti jelecskékkel történő idétlenkedések
- illetve a nehézkesen használható kulcsok is részben kiválthatóak lehetnének
- cella-tulajdonságok megadása
- szám-formátumok
- betűtipusok
- cella-rendezés adatkapcsolattal
- egyedi összegzések, pl.: anyagkigyűjtéseknél
- megjelenítés
- átépítési beállítások -> változatkezelés
- az átépítés nagyon jó, de nem sok kellene hozzá, hogy tökéletes legyen
- ugyanis egy csomószor előfordul, hogy nem csak bontási és átépítési tervet kell csinálni, hanem egy tervhez több változatot (a, b, c, d változat), vagy több fázisban valósul meg a terv (amikről több fázisos tervet kell csinálni)
- nyílászáró megjelenítések
- még mindig nincs olyan, hogy az egyszerűsített alaprajzon a nyílászárónak csak a tengelye látsszon (minden vagy semmi), pedig vezérszinti alaprajzoknál nem haszontalan, ha a nyílászáró a tengelyével jelzésre kerül
- a nyílászáró kottázás beállításai is elég macerásak (a lényeges beállítások eléggé el vannak dugva)
- szerkesztés
- feltételes kiválasztás:
- jelenleg csak az aktuális nézetben, az aktuális láthatósági beállítások mellett lehet keresni
- ilyen beállítási lehetőség pedig nem kevés van:
- szerkezeti megjelenítés
- alaprajzi metszősík
- átépítési beállítások
- megjelenítési beállítások
- stb.
- hasznos lenne, ha a keresésnek volna egy eredményablaka, amiben az aktuálisan nem látszó elemek is megjelenhetnének - amiben az adott elemre kattintva kérhető lenne az adott elem megjelenítése (pl.: a tartalmazó nézetek listájával), vagy a megjelenítés nélküli beállítás lehetősége
- engem nagyon zavar, hogy a kiválasztási listában a semmire nem használatos tollszín van elöl (a fóliát pl. sokkal többször használom a kiválasztásnál)
- hiányzó kritériumok
- kijelölés:
- a vonalközép és vég teligombócos, azonos kijelölése több esetben zavaró lehet (pl. kis szögtörésű dwg-s rajzok átrajzolása esetén - mint pl.: geodézia)
- csoport kezelés
- alapvetően jó
- de számomra érthetetlen, hogy bizonyos elemeket miért nem lehet csoportba rendeszni, pl:
- cimkék?
- nyílászárók?
- kották?
- működés
- renderelés
- hálózati (megosztott) renderelés
- nem csak LAN
- hanem http-s megoldással is
- mindenképpen az archicaden belül
- a renderelés közben felmerülő módosítások miatt
- mindenképp macerás a külső renderelős megoldás
- elmenthető renderelés beállítások
- nem csak a nézethez menthetően
- hanem, mondjuk xml fájlként, vagy attribútum kezelővel
- tehát a programon belül is láthatóan
- export
- 3d
- direkt sketchup kapcsolat
- ne csak importálni, hanem exportálni lehessen
- a google earth kapcsolat ugyan létezik, de nem igazán használható
- a sketchup-ot nagyon jól lehet használni 3d-s megjelenítésre:
- részletrajzokhoz (sokkal szofisztikáltabb megjelenítési lehetőségei vannak, mint az ac12 3d-dokumentumnak)
- egyszerűbb animációk, bemutatók készítése
- általában: egyszerűsített modell exportálási lehetőség
- az összetett nyílászárók meglassítják a google earth-os megjelenítést
- a manuális egyszerűsítés pedig macerás
- a fal-elemek automatikus bitmappá generálása és felületre feszítése hasznos lehet
- alaprajzi metszősík beállítások
- nem megfelelő alaprajzi metszetszint beállítás esetén semmi nem látszik az elemből
- célszerű lenne valamiféle szellemszint-szerű, nem nyomtatandó megjelenítés
- bár a beállításnál fölhívja a figyelmet, de ez könnyen elfelejtődhet
- bug-ok, hibák, hiányosságok a működésben
- listák, konszignációk
- szint információk a konszignációban
- szint számot nem lehet kinyerni, csak a szintnevet
- szint+kategória+helyiségszám tipusú számozás beemelése (ez ügyben merült föl a szint-probléma)
- én ehhez csináltam helyiségcimkét, ami a megjelenítésnél tökéletesen működik, de a listázásuk meglehetősen macerás
- gerenda paraméterek hiányoznak
- szélesség (pontosabban: "hossz"-ként van megjelenítve)
- referenciavonal hossz (csak jobb- és bal oldal van)
- részösszegek
- többszintű listázás részösszegek lehetősége hiányzik
- szintenként ÉS kategóriánként
- mindkettő részösszegeivel
- bizonyos paramétereknél az összevont több elem esetén az összevont, összegzett értékek kerülnek a cellába, máskor viszont csak az egyes elem egyedi paramétere (pl.: 5 db 1 m-es elemnél a cellába 5m és 1m is kerülhet)
- lista exportnál az ezres tagoló szóközök benne maradnak a számokban
- egyedi paraméterek formátumát, mértékegységét nem találtam
- http://archicad-tapasztalatok.blog.hu/2008/10/30/hianyzo_lehetosegek_problemak_a_konszignaciokban
- nézet térképen elmentett konszignációnál nem módosítható a fóliacsoport (még az "ablak jelenlegi beállításai"-val se)
- egyéb apróbb kellemetlenségek
- nyílvégek
- http://archicad-tapasztalatok.blog.hu/2008/10/23/nyilvegek
- vonaltipusok (jó lenne, ha lehetne állítani a minta kezdőpontját, mint a kitöltésnél)
- 3d ablak beállításnál elcsúszik az előnézet, ha az alaprajzon a tájolás el van fordítva
- rajzok frissítése
- a konszignációk frissítése "megváltozottá" teszi a vonatkozó rajzokat, ergo egy frissíts mindent után további frissítendő rajzok keletkeznek (a vonatkozó rajzok ugyanis)
- célszerű lenne, ha a ez nem történne; nem is logikus: mert mondjuk az alaprajzokon lévő helyiségpecséteknek nem is kellene frissülnie (s remélhetőleg nem is frissülnek) csupán attól, hogy a tervlapon frissítettem a konszignációs (helyiség) listát; merthogy a tervlapon történő frissítésnek nem volna szabad befolyásolnia a helyiséglista állapotát. Esetleg azt, hogy az alaprajzon módosított pecsétek módosult adatai még nem kerültek legenerálásra a listában (de ez esetben egyértelműen az alaprajzi módosulások frissítése történik, tehát újra nem kellene visszahatnia).
- de ezen kívül is többször tapasztaltam ilyet (főleg beágyazott modul fájlokkal)
- ez azért kellemetlen, mert sok rajz esetén nagyon nem mindegy, hogy biztos lehetek-e benne, hogy tényleg minden rajz frissítve van a tervlapokon
- nincs érkezése az embernek kibogarászni a ténylegesen publikálandó rajzokat a frissítéshez
- mellesleg ez sem volna butaság: hogy a rajzkezelő interfészt egy kicsit átszervezve meg lehessen ezt is tenni
- rendes bugok
- ugyanazon falba nem lehet egymás alá sarokablakokat tenni
- gyanús, hogy a corner column elem leírásában van a hiba (legalábbis az biztos rossz)
- elmentett nézetek problémái
- fóliacsoport átnevezését nem követik a nézet térképen elmentett nézetek
- szerkezet megjelenítés és az átépítési állapot bizonyos mentett nézetekben nem módosítható (metszet, homlokzat, konszignáció)
- álmok
- alapelvi változtatás
- jelenleg:
- ahogyan "könnyű" volt megprogramozni, se ez korántsem a használat, a tervezés logikája a részletekben
- bár az egész archicad sikere pont ez volt: hogy "építészesen" gondolkodott, ez ma már nem feltétlenül igaz
- vagy ha igaz is, akkor sem biztos, hogy szerencsés
- pl.: 3d-s alakzat eszköz, héj eszköz
- macerás, egyedi megoldások, ahelyett, hogy egy programozható, sokkal egyszerűbb eszközt csináltak volna
- mint pl.: sketchup, ill. grasshopper
- ha mindent paraméterezni lehet, az nem feltétlenül előny; rettenetes időigény
- ahogyan működni kellene (konkrét példák alapján):
- konkrét termékeket választhassak, ne pedig a katalógusok lapozgatásával teljen az idő
- pl: nyílászáró, függönyfal
- jó példák:
- ami kellene ehhez; ahogy célszerű lenne a megoldása:
- eleve célszerű volna egy jól kezelhető eszközt fejleszteni ehhez a kérdéshez, ugyanis sokkal általánosabb kérdés ez
- a basic alapú gdl elfelejtése hasznosnak tűnne ehhez is
- taglist