UpdateDefFromBlockEx

Updates a material definition from block text (same definition format as would be contained in the material library file) by library type (using definition folder name). This scripting command directly supports the .AMAT (or .ASURF) definition formats.This resembles the UpdateDefFromBlock command, except UpdateDefFromBlockEx also allows for:

updating a definition using a block where the name has changed without triggering a rename of the definition being updated
updating multiple definitions from the same block
renaming a definition to something other than the name in the block

UI Access

N/A

Parameters

Name	Type	Description
<targetDefName>	String	Name of the target definition, i.e. the name of the material to update. Name of the target definition, i.e. the name of the material to update (string). Name of the target definition, i.e. the name of the material to update (string).
<desiredDefName>	String	New name to use for a rename. If this is the same as targetDefName, it means the definition is not being renamed. If this is blank, the block name will be used for this purpose instead.	New name to use for a rename. If this is the same as targetDefName, it means the definition is not being renamed. If this is blank, the block name will be used for this purpose instead.	New name to use for a rename. If this is the same as targetDefName, it means the definition is not being renamed. If this is blank, the block name will be used for this purpose instead.
<defBlock>	String	Text of the updated material definition in block form. (Same form as the defBlock input to the AddDefinitionFromBlock and UpdateDefFromBlock commands, for example.) Note that, unlike in the UpdateDefFromBlock command, the name of the definition in the block can be ignored, provided that desiredDefName is set.
<defFolderName>	String	Library type (by definition, folder name).
<newTimeStamp>	String	New timestamp string (time_t as integer, number of seconds since 1/1/1970 12:00am), default is current time.
<continueIfConflict>	Boolean	A flag for whether to continue processing if there is some sort of conflict. A conflict only comes from the target definition being in use, such as a material assigned to a particular part, and if trying to rename the target definition. If this argument is True, and there's a rename conflict, the tactic is to add/update the definition with the new name and leave the target definition untouched. If this argument is False, and there's a rename conflict, the command results in an exception.

Return Value

A property scripting object (extended definition object) for the definition. (In the event of a failure, the command throws an exception and there will be no result.)

Python Syntax

UpdateDefFromBlockEx(<targetDefName>, <desiredDefName>,<defBlock>, <defFolderName>, <newTimeStamp>, <continueIfConflict>)

Python Example

# Note that the material block name will be ignored in this case

defBlock = "$begin 'unused_name' $begin 'AttachedData' $begin \

'MatAppearanceData' property_data='appearance_data' \

Red=255 Green=0 Blue=0 Transparency=0.19 $end \

'MatAppearanceData' $end 'AttachedData' \

simple('permittivity', 1.9) ModTime=1509090909 \

$end 'unused_name'"

try:

updated = oDefinitionManager.UpdateDefFromBlockEx("red_material",

"red_material",

defBlock,

"Materials",

"1609090909")

updatedName = updated.GetName().replace("Materials:", "")

AddInfoMessage("Result: " + updatedName)

except:

AddErrorMessage("Unexpected error in UpdateDefFromBlockEx")