Snapper.id
are streamed into the drawings (Actually, the field id
is defined in the Entity
class but more about that later). The purpose is to have a, within the drawing unique ID, that is also stable over save and load. It is also stable over undo operations. The field is a 32-bit integer.
What Can I Use This For?
You can use these IDs to identify snappers outside CET. For example, it's possible to export an XML file with drawing information from CET where you are referring snappers by ID, and later you can import that XML to CET again and use the snapper IDs to bind the information back to the original snappers.
Restrictions
Regarding Souls
The Soul ID (which is the same as the Snapper ID since both extends Entity) is not preserved through save and load, which means that you cannot refer to souls by ID externally (but for souls its possible to use the soul key instead).
ID Uniqueness and Blocks
If snapper A with ID 1 is encapsulated within a block, and that block is copied to multiple places in the drawing, snapper A will still have the ID 1 in all the blocks. That's simply because the blocks are referring to the same snapper, so it cannot possibly be any other way. But it means that the snapper A can be called multiple times to produce parts for instance, and those parts may end up in separate lines in the calculation dialog, even though they originate from a single snapper.
Comments
0 comments
Please sign in to leave a comment.