Renerabbitt

see video 260917 (3).mp4 I would write a rule so that they dump the location of the folder that contains all csv's, and your note parses the csv according to the note type, so that they dont have to setup different individual file locations for each note/schedule pair. Also if you did it this way, I would have no problem adding a schedule and note to the library that I include with My Pro Plan and adding a sub-chapter for Tru Struc integration. the note would inject a macro for the file reading bit I just mentioned, and I wouldn't mind writing the macro to read it. I would just need to know the csv output names from trustruc to parse that logic based on the note type

You have a project in project browser, name it todays date and whatever design version or iteration you are on and your initials. 260917-Rabbitt-RR. nothing needs to be open, no tabs need to be active. Select your project in the project browser, then hit the delete key The delete key does not prompt you for what files to include, hit Export and Delete Choose the location for the export, maybe thats in the cloud, or on a NAS Next time you need to work on that file, just double click it to open it. Rename it in project browser to the appropriate date version and technicians initials. when done, go back to step 1 No need to overwrite the other file, leave it as historical data. You can set the older versions to online-only if in the cloud 260917 (2).mp4

I'm in a pretty unique position on the installation side of this because I've installed thousands of versions of my products for people over the years, and having the user put an .rb file in the Scripts folder is a BIG pain in the arse once this gets out into the real world. I'm going to play the "trust me bro" card pretty hard on this one. I would never even attempt to document every installation problem I've seen because the list would be ridiculous, but here's the reality: a LOT of users cannot successfully follow four written instructions, four recorded instructions, or sometimes four written AND recorded instructions. I'm not trying to insult anybody either...this is just what happens when you sell software/tools to a large enough group of normal users. I've had users who couldn't figure out how to download the product after purchasing it. I've had users who couldn't unzip the downloaded folder. Asking somebody to locate the correct Chief data folder, find the Scripts directory and install a Ruby file into it? That actually used to be part of my system and it generated a shocking amount of support. It became enough of a problem that I wrote actual Mac and Windows installers whose entire purpose was basically to put the required files where they belonged. People still managed to break that. And here's another one you're going to run into immediately: the Scripts directory is very likely sitting somewhere inside a OneDrive-backed Chief data folder for a bunch of users. A lot of people have OneDrive set to Files On-Demand/selective sync, meaning portions of that folder can be online-only. So right out of the gate you're potentially dealing with a script that looks like it was installed correctly but isn't actually local when Chief goes looking for it. Now you're troubleshooting why Ruby isn't being read at all, why OneDrive hasn't hydrated the file, why one user's Documents folder is redirected and another user's isn't, why somebody's Chief data folder lives somewhere unexpected, etc. At that point you're no longer troubleshooting SmartSTRUC. You're troubleshooting everyone's individual Windows/OneDrive/file-sync configuration because you chose an installation method that exposes you to all of those system-level problems. Eventually this is one of the reasons I created an Assisted Install service. And I mean this very specifically: my year 3 garnered no profit. None. Technical support consumed all of the profit for that entire year. That wasn't "support reduced my margins." It wiped out the profit. So if you're planning to scale this beyond technically sophisticated Chief users, my biggest product-development advice would be: KEEP IT WAYYYYY SIMPLER than you think it needs to be. Every additional manual installation step, external dependency, folder somebody has to find, path somebody has to maintain, file somebody has to move, update somebody has to understand, or OS/cloud setting somebody can have configured differently eventually becomes a support ticket. The architecture can be technically brilliant and still become commercially miserable if the end user has to understand any of it. That's also why I'd still encourage you to spend a few minutes testing the schedule approach before completely writing it off. The current Pro Plan you already have is actually set up where you could test this with a CSV export in probably two minutes. And I think there's an important distinction between: dynamically creating exactly the number of Notes you need and pre-populating WAY more Notes than you could ever reasonably need and letting the external data determine what gets reported. If your maximum realistic beam schedule is 50 rows, put 100 Notes in there. Same for footings, headers, whatever. Now you don't have an end user adding and deleting Notes every project. The container already has more available schedule objects than the data could realistically consume. The external lookup populates the ones that have data and the unused ones simply don't need to report anything useful. That's much closer to how I would productize it. And I think it's worth testing because once you're using actual Chief schedules you inherit a ridiculous amount of functionality for free. You can change column widths, reorder columns, reorder or filter rows, add columns later without rebuilding a text-table generator, add information that isn't coming from SmartSTRUC, supplement the imported information with information coming from Chief, perform additional calculations, expose additional fields, create different schedules from the exact same underlying data, change formatting without rebuilding the table parser, and generally let the end user manipulate the output using tools they already understand inside Chief. That's the part I'd be reluctant to give up. Your single text-box approach is undeniably clever, and I completely understand why the unknown row count led you there. Four members or sixty members requires no additional setup on your end. That's a legitimate advantage. But my concern is what happens AFTER you sell it. Someone is absolutely going to say: "I just need one more column over here..." Then another person wants to move this column. Someone wants an extra calculation. Someone wants to add a field manually. Someone wants one piece of Chief information mixed into the structural data. Someone wants the footing schedule formatted differently from the beam schedule. And they're going to start hacking at those text boxes because that's what users do. Schedules give them a structured system for doing all of that without touching your underlying data mechanism. Also, using schedules does NOT mean giving up the external JSON/CSV as your single source of truth. You can still have the external data driving everything live. You're just changing the presentation layer from one generated text string into Chief schedule objects. So your portable JSON can absolutely remain the product output format and source of structural truth. Another reason I'd test this before dismissing it is that you've already made the best architectural decision for schedule performance: you're putting this into a dedicated non-model plan. You're not drawing walls there. You're not inserting windows there. You're not rebuilding the model there. It's basically a schedule container being sent to Layout. So you have a LOT more freedom to abuse schedule evaluation there than I would ever recommend inside someone's actual working model. Your concern about %schedule_number% being positional is also something I'd attack as a scripting problem before deciding schedules can't work. I would not want the integrity of a structural schedule dependent on: "row 17 means JSON record 17 forever." I agree with you completely there. I'd want a stable identifier/key involved so the schedule object asks for its member, not simply whatever happens to currently occupy its index. That's another place where I think there may be more room to develop this than it initially appears. And since you already own the current Pro Plan, you don't have to speculate about whether any of this feels workable. Export some dummy structural data as CSV, throw a ridiculous number of Notes into a schedule-only test plan and abuse the hell out of it for half an hour. Add members. Delete members. Reorder the source data. Add more rows than you think you'd ever need. Change columns. Add a calculated column. Mix a Chief value into it. See what breaks. If after that the text-table approach still clearly wins, then you've validated the decision. But I wouldn't make the decision solely because dynamically maintaining the exact number of Notes per project would be awful...because I wouldn't maintain the exact number at all. I'd massively over-provision the available Notes once in the template and never make the user think about them again. The same philosophy applies to the installer: If the end user has to understand how the clever part works, simplify it again. That's probably the single most expensive lesson I've learned selling Chief tools.

Only pain points I've run into is that a team member opens the caproject file in chief, does some work, hits save and shuts down and thinks that the caproject file they opened is updated. Just had to teach them that they have to delete and export every single time...IOW teach them that save doesnt exist, and relate the process to doing Save As every time

I did miss that detail but believe it or not we could do this over 10 years ago with a plugin for POVray that no longer exists and it was easy to do but it was from fixed position spherical renderings which looked better than this, it just didnt give you free range of movement, but effectively you were rendering a seen with every color option. it would take 24 hours to render out so I had a second machine doing it but then the options were all html based and switching an option effectively just switched the loaded page through a viewport window but you could still look around, even in VR. I know Epic Unreal engine can currently do this with Epics Product Configurator Template which uses Unreals Variant Manager/Level Varient Sets

I used to offer this and truth be told not all that expensive. Hosted in twinmotion cloud, the end user can walk around the project in twinmotions web based cloud viewer. I'd have to do a bt of work to bring those projects back outside of the archive but it was simpler than you might think. I could probably put together an example in the next few weeks

Ahh okay, that fills in some of the missing context, but I still think there’s one piece I need clarified before I completely accept the SecurityError explanation. I still don’t believe Chief is natively handing you something that is tainted simply because you’re obtaining it at runtime. I’ve been reading external files from Chief at runtime for years without needing to broadly untaint the path, so I still suspect something in the way the directory/path is initially being established in your script is creating the condition. For example, something as basic as this is perfectly capable of reading an external file: path = "C:/Users/rener/Dropbox/DROPBOX PROJECT DIRECTORY/file read.txt" a = open path b = a.read a.close b And I’ve also used systems where I start with a known static root and combine that with information Chief is providing: base_path = "C:/Users/rener/Dropbox/DROPBOX PROJECT DIRECTORY" path = File.join(base_path, $document, "file read.txt") a = open path b = a.read a.close b So runtime evaluation itself isn’t inherently producing the problem. If you post the small initial chunk of code where you obtain the document directory and then hand it to File.mtime, I could probably identify where that security condition is actually being introduced. The other thing I need clarified is what you mean when you say: “The JSON is written into the project folder.” Chief calls these Projects regardless of whether Project Management is turned on or off. The plan/layout still live as a Project in the Project Browser either way. I currently use Project Management and I don’t want to switch it off just to test this, so what I DON’T know is whether Chief has added some functionality in the non-Project-Management workflow that lets you actually bring an arbitrary external file such as a JSON file into the Project Browser itself. If that exists now, that would be new to me. So when you say project folder, do you mean a normal Windows folder outside of Chief, something like: C:/Projects/Smith Residence/ containing: Smith Residence.plan Smith Residence.layout SmartStruc.json and another application is simply writing SmartStruc.json into that Windows folder? Or are you saying the JSON is actually being imported/stored somehow as part of the Chief Project itself through the Project Browser? I’m assuming you mean the first one, but that distinction matters quite a bit in understanding why you’re running into the error. If the JSON is simply an external file on the Windows filesystem, there is no requirement that it physically live beside the Chief plan at all. It can live anywhere on the machine that Chief has permission to read. And that leads into your question about Project Management. Yes, I’ve solved the managed-mode lookup problem You don’t actually need to know where Chief is physically storing the managed .plan. Instead, leave the JSON outside Project Management in a normal filesystem location and use information Chief DOES expose about the current project to locate the corresponding external file. This is actually very similar to a system I used in an older version of Pro Plan. If you still have that version, there was an external CSV-reading system in there that you could probably reverse engineer pretty easily with the additional information I’m giving you here. The basic concept was: static master directory combined with a Chief-derived project-specific directory combined with the known external filename So for example, suppose you maintain projects externally like this: C:/Dropbox/Projects/Main Folder/Folder 1/Example.json You can establish: C:/Dropbox/Projects/ as the known/static root. Then Chief only needs to determine: Main Folder Folder 1 Example from information already associated with the project. You can derive that from Project Information, NVPs, the project name, document name, or whatever naming convention you decide makes sense. So you're not trying to determine: “Where did Project Management physically hide this plan?” You're asking: “Which project am I currently working in?” and then using that identity to resolve an entirely separate external data location that YOU control. I went into this concept in a couple ChiefTalk discussions. This one gets into using project/client information and expanding the available information: https://chieftalk.chiefarchitect.com/topic/45226-designerclient-information-extended/page/2/?tab=comments#comment-337659 And this one gets directly into using a static project root and rebuilding a project-specific path in the Project Management workflow: https://chieftalk.chiefarchitect.com/topic/46157-new-idea-to-export-and-backup-x17-project-files-within-the-project-manager/?tab=comments#comment-329669 That second discussion with Joe Carrick is basically the architecture I’m describing here. Conceptually you can do something like: $dir = "C:/Users/rener/Dropbox/Projects" and then build everything underneath that from Chief’s project information. So if Chief knows: Client = Smith Project = Kitchen Remodel Version = Design A you can resolve something like: C:/Users/rener/Dropbox/Projects/Smith/Kitchen Remodel/Design A/SmartStruc.json without ever knowing or caring where Chief’s managed .plan is physically located. You can make the naming convention whatever you want. For example, you could use: 12345-Smith-Addition and establish a rule that each - represents some directory or subdirectory level. Or you could use separate Project Information values. Or project number + project name. Or client + project + version. There are a bunch of ways to do it. If you post what you would LIKE the external hierarchy to look like, for example: C:/Projects/Smith Residence/Structural/SmartStruc.json and tell me which portions you want Chief to derive automatically, I’m happy to post either the relevant portion of the Ruby or just write the complete lookup for you here. Your JSON would still live outside Project Management just like any other external resource. We’re simply using the Chief project to identify WHICH external JSON should be read. One other option you already have access to I believe you may also have the older Pro Plan version containing my original external CSV lookup system. If you still have that, feel free to reverse engineer the lookup portion. Take this response as explicit permission from me to adapt that particular system for SmartStruc if it helps you get to the final result. The newer BuilderTrend/JobTread implementation in Pro Plan went in a slightly different direction and uses a fully static resolved path. The convenience part is that the user can copy a Windows path and paste it into Chief, and the macro cleans/parses that pasted path into the static address it needs. That implementation is documented here: https://renerabbitt.github.io/ppx18-manual/?chapter=jobtread-buildertrend-spreadsheet-linking So I’ve used both approaches successfully: static root + controlled variable project path and fully static path with automated parsing of a copied Windows address Which one makes more sense really depends on how automated you want SmartStruc to be. Also, why didn’t you like Chief schedules? Now that I know you’re already putting all of this into a dedicated non-model plan, I’m curious what specifically pushed you away from actual Chief schedules. Was it formatting? The inability to create section headings? Control over columns? Something else? The performance issue I mentioned before becomes MUCH less important when the schedules live in a dedicated plan where nobody is actually modeling. If you’re not drawing walls, inserting windows, moving objects, etc. in that plan, you aren’t repeatedly paying the same evaluation cost throughout the normal modeling workflow. And I’ve been able to make actual Chief schedules look very similar to the output you’re generating. I’ll post a screenshot of my Area Analysis as an example. It’s completely schedule based. One obvious advantage your text solution has is that you can insert subsection headings directly into the text output. A single Chief schedule obviously doesn’t give you that same freedom. But you can reproduce essentially the same visual result by splitting the information into multiple schedules and stacking those schedules together. So instead of one schedule with: FOUNDATION ... BEAMS ... HEADERS ... you use multiple smaller schedules, each representing one section, and visually assemble them into the same overall table. That lets you get the headings/divisions while still using actual schedule formatting. It's also way easier to scale into sales and/or additional functions and even calculators derived from a model And if your primary reason for building the custom monospace font was getting the box-drawing characters to align while also matching your drawing set, using actual schedules could potentially eliminate that requirement entirely. That may or may not be useful to you — the custom font approach is clever and obviously already working — but since this is all contained in a dedicated schedule-only plan anyway, I’d be curious what limitation made you abandon the native schedule route. Either way, I think the managed-mode portion is very solvable. And before we completely write off the original SecurityError as Chief simply providing a tainted directory at runtime, post that first little chunk where you establish the directory. I still think there’s a good chance the security condition is being scripted into the lookup somewhere rather than being an unavoidable property of the directory Chief is returning. Also, no way shape or form am i trying to hijack, this thread, if you want me to edit anything out for historical data just lmk, happy to

First off, congrats on even getting this far with it. Building something like SmartStruc and getting Chief talking to an external data source is quite an endeavor. A few things jumped out at me because I’ve spent a pretty ridiculous amount of time working through this exact behavior in Chief. 1. I don’t think the security issue is actually what you think it is The SecurityError is most likely coming from the (assumption) that you’re trying to construct an entirely variable filesystem path. I am guessing because all of the information isn't here, but that's where I would look first. Chief/Ruby will let us read external files, but the path needs to be structured correctly. You can’t simply derive the entire path from variable information and expect it to pass the security parameters. IOW, a completely variable path is something that can potentially be manipulated, which is why it gets flagged. I've actually used two different approaches to this over time. My older external CSV system used a static address combined with a variable system address. Conceptually: static trusted root + variable project-specific portion + known lookup filename That allowed Chief to automatically locate the correct project-specific CSV without making the entire filesystem path variable. That system was live. Chief could continuously parse the CSV and rewrite the cached information as you worked in the plan. The newer BuilderTrend/JobTread system works differently. That system ultimately uses a fully static resolved address. Instead of Chief dynamically constructing the filesystem path every time, the end user can copy the path directly from Windows and paste it into a note. The macro then automatically cuts, cleans and parses that pasted Windows path designation into the properly formatted static address Chief actually uses for the lookup. So there are at least two ways I've already implemented this successfully: static + controlled variable path or fully static path with automated parsing of a copied Windows path Neither requires broadly untainting every filepath. I believe you may actually have a version of my Pro Plan containing the older CSV system, and I believe you also have the current version containing the newer BuilderTrend/JobTread implementation. You can look at the current implementation here: https://renerabbitt.github.io/ppx18-manual/?chapter=jobtread-buildertrend-spreadsheet-linking And take this response as explicit permission from me to reverse engineer/adapt that particular lookup system for SmartStruc if it helps you finish what you're building. Chief also has a Ruby Safe Level setting directly in Preferences. If you completely trust everything being executed through Chief, you could also change that setting and remove some of those restrictions. Personally I’d rather structure the path correctly than globally lower the security level, but the option exists. 2. mtime isn't what makes Chief capable of seeing new data mtime is simply the file's modified timestamp. It can absolutely be used as a trigger. Joe uses it in some of his macros as well. I personally wouldn't consider it ideal as the default mechanism because timestamps can be somewhat volatile, but that's really an architectural decision for you to make depending on exactly what you want this system to do. The important distinction is that Chief does NOT need mtime in order to reread an external file. My earlier CSV implementation proves that. That system was essentially live. Chief would reevaluate the macro during normal plan manipulation, reread the CSV information and continually rewrite the cached information. Draw a wall, move something, place a window, etc. and those calls execute again. So Chief absolutely can continuously reread external data without restarting the Ruby interpreter. In that implementation the amount of information I was producing was relatively small, so the performance penalty wasn't substantial enough to make that architecture a problem. Where I would be more cautious with what you're doing is the word schedule. I don't know from your post whether these are actually Chief schedules generated from notes/objects or whether they're text boxes populated with characters and simply made to LOOK like schedules. Those can be very different performance scenarios. A text box populated by a macro essentially needs to evaluate the macro and display the resulting text. If you're manipulating a note/object that subsequently drives an actual Chief schedule, Chief potentially has considerably more to evaluate because now the parameters of that object are feeding the schedule and that schedule has its own evaluation/rebuild process. I've measured situations in my own development where those evaluations were adding somewhere around 350ms. 350ms isn't particularly meaningful once. It becomes VERY meaningful when drawing a wall, placing a window, moving an object, etc. causes the same evaluation repeatedly throughout normal drafting. So mtime may be perfectly acceptable for what you're building. Or you may decide you don't want the cache rebuilding automatically every time the external file changes. That part is really up to you and depends on exactly what these “schedules” are and how expensive their regeneration actually is. 3. Restarting Chief is one refresh mechanism. It isn't the required refresh mechanism. This is where I think the difference between the systems I've built may help. I've actually used BOTH approaches. My original external CSV system was effectively live. Chief continually reread that external CSV information and rewrote the stored information during normal plan operations. Later, when I built the BuilderTrend/JobTread lookup system, I intentionally chose a different architecture. That lookup is purposely allowed to become stale. Not because Chief requires a restart before it can reread the file. It doesn't. I chose that behavior because this was going into a product being used by end users, and I didn't trust every end user to understand some complicated cache invalidation system or remember which obscure trigger they needed to manipulate. The simplest possible refresh mechanism is: Restart Chief. Everybody understands that. Restarting Chief clears the existing global state and the lookup gets rebuilt when the system initializes again. But restarting Chief is only ONE possible trigger. You could use mtime. You could use an explicit revision value. You could use a timer. You could place an object. You could move an object from one XY coordinate to another. You could change a Project Information field. You could create a dedicated refresh control. There are any number of ways to intentionally cause that data to rebuild. So when you say the parsed data remains stale “until the Ruby interpreter dies on an app restart,” you're describing what your particular cache architecture currently does. You're not describing a limitation of Chief. Chief can continuously reread and rebuild external data. My older CSV system did exactly that. Your scripting decides whether you actually WANT it to. And that's really the important distinction here. There are three different things: Chief reevaluating the macro external data being reread your stored/global cache being rebuilt Those do not have to happen together. You can make all three occur continuously. You can make Chief continuously evaluate while leaving the cache intentionally stale. Or you can create some completely separate deliberate event that invalidates the cache only when you want it refreshed. Your .rb comment is also a separate issue again. If you're bringing the Ruby file in with require, then you've specifically chosen a Ruby mechanism intended to load that code once. That's a code-loading decision. It doesn't establish a requirement that the external DATA itself can only be refreshed by restarting Chief. One other thing I should probably disclose This isn't meant as a brag or some kind of ownership claim. It's just a potentially relevant truth of how I think this very specific information made its way into the AI knowledge you're using. I can't prove model provenance from the outside, obviously, but I'm fairly confident that at least some of the connections being made here originated with work I did developing these systems. And I don't mean that I was “training my AI.” I mean that over roughly the last 3½ years and thousands of hours of scripting, I was feeding the AI systems themselves Chief-specific information they did not otherwise know, correcting their assumptions and showing them how these particular behaviors could be connected. This wasn't broadly documented or open-source information when I started doing it. There were only a few other relevant sources I knew of doing remotely similar things. The important part is that some of what I taught those systems represented earlier iterations of my own development. I hadn't solved every piece yet either at the time that I SHUT DOWN the option to train open source. IOW the current models are still missing some more information that I had solved, especially when it comes to utilizing schedule numbers, which was an expansion on knowledge I gained from Mike and Joe, and the ruby team at chief. So the models can potentially have fragments such as: external file → global lookup → cache information → avoid unnecessary parsing while missing later information about: static + variable path construction → fully static paths parsed automatically from copied Windows addresses → continuous live rereading when appropriate → intentionally stale data when appropriate → performance consequences of repeated schedule evaluation → deliberate cache invalidation when you actually want it That particular combination of correct concepts and missing context is what I'm recognizing in your post. Again, I'm not mentioning that to make some braggart claim to it. It's useful because I know where some of those earlier ideas came from, what problems I subsequently ran into with them and how I eventually worked around those problems. The broader architecture You really have several choices here depending on what you want SmartStruc to do. You can use a static root combined with a controlled variable project-specific address, which is how my older CSV system operated. You can use a completely static resolved path, which is how the newer BuilderTrend/JobTread implementation works, and simply make entering that address easier by automatically parsing a Windows path the user copies and pastes into Chief. Once you've reached the file, you can make the lookup completely live if the performance is acceptable. Chief can continuously reread the external file and rewrite your stored information as the plan changes. I've done that. Or you can cache the parsed information and deliberately allow it to remain stale until some chosen condition tells it to rebuild. I've done that too. Restarting Chief seems easy enough, though I bet if we really were faced with the task of making something better we could do it. It isn't a technical requirement. For your application, I would decide that part based on how expensive those 15 schedules actually are to regenerate and how often the underlying engineering information genuinely needs to refresh while somebody is actively drafting. On #4 I don't have enough information to comment on that one. I'd need considerably more context about how you're constructing the table, what exactly you mean by a schedule here, how the text is being generated, the text box setup and exactly what behavior you're trying to solve before I'd make any assumptions. Happy to help you work through any of this here in the thread if that was part of the intent of the post. I know you're building SmartStruc and I'd genuinely like to see what you do with it. I'm happy to be an audience for it and help where I can. BTW, my big pro tip here is this...if all you're doing with this data is generating schedules, then pull the training wheels off entirely. You don't necessarily need to cache anything at all. Use either the static + variable path method or a fully static path and just let Chief continuously read the external file every time the schedule evaluates. Then create a separate non-model plan whose only purpose is to hold all of these schedules. Nothing gets modeled there, nothing gets drawn there, and you aren't constantly triggering evaluations from drawing walls, placing windows, moving objects, etc. That means the performance hit from continuously reading the external file should be negligible compared to doing the same thing inside an actively modeled plan. So that plan basically becomes a catch-all schedule sheet. Generate all of your schedules there, then send them to Layout through linked views/layout boxes. Now the external data can stay completely live with no cache or stale-state management at all, while the actual working model remains completely unaffected by whatever evaluation cost those schedules have.

The Tray Ceiling tool is effectively creating a set of custom ceiling planes to form the tray. When Recessed is checked, the tool is essentially cutting a hole into the existing ceiling plane and then creating another ceiling plane above it. You can prove this pretty easily yourself. Create a custom ceiling plane in a room with a floor above, cut a hole in that ceiling plane, and then look at the floor structure above. You’ll see that the opening also cuts into the floor structure. That explains why a recessed tray does not work when there is a floor directly above. The program would effectively have to cut a hole through that floor system in order to raise the tray above the room’s existing ceiling height. When Recessed is unchecked, it works differently. The existing ceiling effectively remains intact with no hole cut into it. The tray is then created using additional custom ceiling planes below the elevation of the existing ceiling. Those lower ceiling planes can have the necessary openings in them because they are below the actual ceiling/floor platform and are not cutting into the structure above. So in simple terms, Recessed means the tray is trying to go up through the existing ceiling, while Recessed unchecked means the tray is built downward below the existing ceiling using additional ceiling planes. If you want the appearance of a recessed tray where there is a floor above, define a room on the floor above that matches the size and location of the tray. Then reduce the floor structure thickness in that room by the amount you want the tray recessed. After creating that space within the floor system, generate the tray ceiling with Recessed unchecked. You are essentially creating the recessed space manually in the floor structure above, while letting the Tray Ceiling tool build its custom ceiling planes below the remaining ceiling line without cutting a hole through the floor system.

from what button in what dialog box were you attempting to find the 3d molding? rotating it in the cladding menu is 2d, you likely needed to rotate the original symbol from the library instead, whcih you can do from the cladding menu by selecting it and clicking on the edit button(this is from memory, i am not at my desk right now so the button names may be incorrect)

Distribute this graphic to a team

I guess they don't explicitly state that 3d cladding is just distributed moldings, but yes thats what 3d cladding is.

it needs to be converted to the symbol category of molding, then apply that molding in the cladding dbx

fun fact, the templates I sell are project management based. When you include the number of distributed copies multiplied by the number of revisions, patches and updates, testing, these project files have been effectively installed over 10,000 times. There is no better method for distributing projects than project management... it simply takes less management, less instructions, and less networking. Method is simple, in project management, name your project yymmdd-street/client name-version-technicians initials, such as 260910-Clancy-V1-RR. Done with your work, select your project, hit the delete key, Then this pops up Click Export and Delete Export it to your NAS/Cloud etc. When the next person needs to work on it, they just go to the cloud location and double click it to open it It's a single file that contains all assets. It also can contain additional information and multiple design iterations. There is also no easier way to create a design iteration which includes a layout pre-linked with populated views, but independent from the design it originated from Which results in: Just to reiterate about how to share with a team...you get to press a button(delete key), then click a button(export) to store a single file (with all of its incluuded images assets/pdfs/design iterations/other files) on your favorite cloud service for the next person to work on. The only complicated part about the inter-office sharing part of this, is training people to unlearn the complicated things they were doing before PM was created. If people want to learn about the more complex things you can do in project management, such as creating warehouse detail plans, complicated link swapping, reference file swaps, and pre-loaded linked layout templates etc. PM can do some crazy things, but sharing across a team is not a complicated part of PM, its just .. Delete...click...done.

Right click on the project itself..unless you are not in managed mode