The Situation
Our firm's project numbering convention encodes phase and package information directly into the project number, since we regularly run multi-phase projects with sequential submittal packages. For example, project AAA-123 ("Pretty Meadows") becomes 0103-AAA-123 for Phase 01, Package 03. Land F/X supports this — project numbers can be up to 12 characters.
The Problem
Each phase/package needs to be its own Land F/X project, and each of those projects needs its own unique Detail Folder. The trouble is that the Detail Folder code field is limited to 8 characters, while our project number is 12. That means we can't use our actual project number as the unique identifier for the Detail Folder — we're forced to compress it (e.g., single-digit phase + single-digit package + 6-character job code = 13AAA123), which:
Proposed Solution
Increase the Detail Folder code character limit from 8 to 12, matching the existing Project Number limit. This lets firms with phased/multi-package numbering conventions use the same identifier for both the project and its detail folder, with no compression, no separate lookup, and no risk of collision once a job exceeds single-digit phases or packages.
Additional Suggestion: Auto-Generate Option
Right now, setting a project's Detail Folder requires manually browsing to (or creating) a folder location. It would save a step — and reduce naming inconsistency across staff — if there were a checkbox next to the Detail Folder field, something like "Auto-create folder as [Project Number] - [Project Name]" — that automatically generates and names the folder using the project's own Number and Name fields, rather than requiring the user to browse/create it manually every time. This would pair well with the 12-character fix above, since it would let the checkbox produce a folder name that fully matches the project number without truncation.
Why This Matters
For firms running phased projects, this isn't a cosmetic issue — it directly affects whether our Detail Folder naming can be trusted to uniquely and permanently identify a project, and it affects long-term detail library organization across dozens of active phased jobs.
Our firm's project numbering convention encodes phase and package information directly into the project number, since we regularly run multi-phase projects with sequential submittal packages. For example, project AAA-123 ("Pretty Meadows") becomes 0103-AAA-123 for Phase 01, Package 03. Land F/X supports this — project numbers can be up to 12 characters.
The Problem
Each phase/package needs to be its own Land F/X project, and each of those projects needs its own unique Detail Folder. The trouble is that the Detail Folder code field is limited to 8 characters, while our project number is 12. That means we can't use our actual project number as the unique identifier for the Detail Folder — we're forced to compress it (e.g., single-digit phase + single-digit package + 6-character job code = 13AAA123), which:
- Breaks down entirely once we exceed 9 phases or 9 packages on a job
Requires staff to learn and consistently apply a compression scheme that doesn't match what's on our actual drawings/title blocks
Introduces a second, shorter identifier that has to be manually kept in sync with the real project number, purely because of a character limit mismatch between two fields that should be able to reference the same value
Proposed Solution
Increase the Detail Folder code character limit from 8 to 12, matching the existing Project Number limit. This lets firms with phased/multi-package numbering conventions use the same identifier for both the project and its detail folder, with no compression, no separate lookup, and no risk of collision once a job exceeds single-digit phases or packages.
Additional Suggestion: Auto-Generate Option
Right now, setting a project's Detail Folder requires manually browsing to (or creating) a folder location. It would save a step — and reduce naming inconsistency across staff — if there were a checkbox next to the Detail Folder field, something like "Auto-create folder as [Project Number] - [Project Name]" — that automatically generates and names the folder using the project's own Number and Name fields, rather than requiring the user to browse/create it manually every time. This would pair well with the 12-character fix above, since it would let the checkbox produce a folder name that fully matches the project number without truncation.
Why This Matters
For firms running phased projects, this isn't a cosmetic issue — it directly affects whether our Detail Folder naming can be trusted to uniquely and permanently identify a project, and it affects long-term detail library organization across dozens of active phased jobs.
Russell Stanford
set the type of the post as
Issue — 2 months ago
Russell,
The detail folder can be specified when creating the project and assigning the project number, which is the recommended practice. Further, we recommend using the Organization tab of the project dialog, to separate projects into logical groupings. When creating a project from the organization tab, the detail folder gets automatically assigned.
Character limits are a wild thing. They are always present, impossible to fight. There absolutely is an upside character limit for a detail number. Right now we are wrestling with a wish list request to be able to assign more than one detail to a plant or item. Some have requested as many as five details to be assigned to something, but it's looking like we'll need to limit this feature to three details, due solely to character limits. I bring this all up, because in general, allowing up to 12 characters for a detail folder can make sense, as long as the detail number fits in the detail. But at 12 characters per folder level, that could result in a truly massive detail number that simply doesn't fit in the detail template, or in any reasonable display in a dialog box. So just saying, we are always stuck between the needs of users and the limits of engineering.
Overall, I can totally see the rare need for more than 8 characters in a folder. But it's much easier for me to see the horror show that would happen if every detail number included a phase and package number. Meaning that one slight shift could easily result in dozens and dozens of details needing to be meticulously renumbered as they all move to the next package number. Is this same naming scheme in your dwg and sheet filenames? It just sounds like the standard act of adding a phase or combining a package set would suddenly require a considerable effort in renaming a tidy number of files across multiple xrefs. So while I'm certainly open to increasing the character limit, I would strongly strongly urge you keep the details numbered with just a project number and not the package and phase number.
But we've had multiple great conversations on this forum in the subject area of phasing. Multiple users have wanted an easier ability to split a project off into a phase - copying all the files, re-pathing the xrefs, and copying and renumbering all the details. I really enjoy learning more about the challenges of designers, and how we might engineer a solution. We will certainly chat more about how this fits in with our multi-detail assignment work coming up, and also encourage others to chime in on the matter.
--J
The detail folder can be specified when creating the project and assigning the project number, which is the recommended practice. Further, we recommend using the Organization tab of the project dialog, to separate projects into logical groupings. When creating a project from the organization tab, the detail folder gets automatically assigned.
Character limits are a wild thing. They are always present, impossible to fight. There absolutely is an upside character limit for a detail number. Right now we are wrestling with a wish list request to be able to assign more than one detail to a plant or item. Some have requested as many as five details to be assigned to something, but it's looking like we'll need to limit this feature to three details, due solely to character limits. I bring this all up, because in general, allowing up to 12 characters for a detail folder can make sense, as long as the detail number fits in the detail. But at 12 characters per folder level, that could result in a truly massive detail number that simply doesn't fit in the detail template, or in any reasonable display in a dialog box. So just saying, we are always stuck between the needs of users and the limits of engineering.
Overall, I can totally see the rare need for more than 8 characters in a folder. But it's much easier for me to see the horror show that would happen if every detail number included a phase and package number. Meaning that one slight shift could easily result in dozens and dozens of details needing to be meticulously renumbered as they all move to the next package number. Is this same naming scheme in your dwg and sheet filenames? It just sounds like the standard act of adding a phase or combining a package set would suddenly require a considerable effort in renaming a tidy number of files across multiple xrefs. So while I'm certainly open to increasing the character limit, I would strongly strongly urge you keep the details numbered with just a project number and not the package and phase number.
But we've had multiple great conversations on this forum in the subject area of phasing. Multiple users have wanted an easier ability to split a project off into a phase - copying all the files, re-pathing the xrefs, and copying and renumbering all the details. I really enjoy learning more about the challenges of designers, and how we might engineer a solution. We will certainly chat more about how this fits in with our multi-detail assignment work coming up, and also encourage others to chime in on the matter.
--J
- Page :
- 1
There are no replies made for this post yet.