XML addon & script location

Home Forums Problems and solutions in GDL GDL add-ons XML addon & script location

This topic contains 2 replies, has 2 voices, and was last updated by  Michael Herse 1 week, 4 days ago.

  • Author
    Posts
  • #3667

    Michael Herse
    Participant

    Hi All

    I have what is probably a simple question. If I have library parts that are generating their geometry and obtaining parameter values (for scheduling) from the values in stored in an XML file, which script should I be be reading the XML file in.

    The concern is that if I use the parameter script, object’s will not update to changes in the XML until a user opens their settings and presses OK. If I use the master script, and I have a 1000+ of these object, then I may be creating quite a performance problem for any large file (assuming that AC runs the master everytime the object appears in 2D or 3d – not sure if this is actually the case)

    Has anyone been down this path and found one location better than the other, or another alternative?

    Also, a quick question for the gurus at GSHQ. If I change the value of an object’s parameter in a schedule, should this cause the Parameter script to run, or has this been disabled to help schedule speed?

    Any insight would be appreciated.

    Cheers,
    Michael.

  • #3669

    Gergely Fehér
    Keymaster

    Hi,

    Parameter changes from interactive schedule will initiate a paramscript run in the selected object(s).

    The best way of reading an xml file depends on many things:
    – how often the source will change,
    – will it be a part of the library, and loaded together with the objects,
    – and the purpose of using external data…

    You should tell me more about the details, to be able to suggest a solution.

    Gergely Fehér
    Team Leader, Library Team
    GRAPHISOFT SE

  • #3674

    Michael Herse
    Participant

    Hi Gergely. Thanks for the help. Some more info below.

    – and the purpose of using external data…

    The goal is to allow users to create and assign ‘user defined types’ to doors and their sub-elements (frames, leafs, seals, size, vision panels, finishes etc) that impact the 3D model + some other things such as locking, door stops, closer, hinges etc. that will be stored with a door type for scheduling purposes. The external file is used to centrally store the values of the parameters for the user defined types, and push any change to a defined door type of sub-element through the model. Types will be specific to each project. Some project will have 1000+ doors. One of our current projects has about 5000+ doors made up of about 250 different door types, spread across 4 teamwork files, and is the reason why we are investigating this to see if it will provide an efficient way to push change through the projects and standardise door settings for doors that are meant to be the same, but aren’t in the model.

    – how often the source will change

    Not too often I hope. There will be times when the changes are intense, but hopefully that will be limited to only a couple of periods during the life of the project (late DD and Mid CD). Most of the time, I expect people will just be adding new doors and assigning a type to them, or changing individual doors to a particular type.

    – will it be a part of the library, and loaded together with the objects

    I haven’t got that far yet. Ideally the external file will live in the project library, but the projects will be teamworked, so I need to investigate the implications of this further. At the moment, while we are testing & developing things, the XML is hosted on our file server (OSX)

    Cheers,
    Michael.

You must be logged in to reply to this topic.