Open michaelrfraser opened 6 years ago
I thought somewhere there was a name substitution that was able to resolve other names to the same thing (so that it worked even if you gave it privilegeToDelete
). Should probably ensure that it resolves under a bunch of names.
Might also need to check the 1516 (2000) spec to make sure it wasn't hlaPrivilegeToDelete
in there, although I suspect not and that I just fat-fingered it.
@timpokorny there is name substitution, so privilegeToDelete and HLAprivilegeToDelete currently get mapped to the same handle. The vanilla 1516 prescribes HLAprivilegeToDeleteObject, so I looks like it was just a copy/paste error from the 1.3 code.
I have the fix all done for this issue, but unfortunately its on my machine at home. I'll try and get it uploaded tonight and put into a PR.
Hi Michael/Tim, am struggling with a persistent error related to this post i think. Any help?
The .xml fragment
`
Hooday! Problem solved with Michael's suggestion.
I copied
`
<dataType>HLAtoken</dataType>
<updateType>Static</updateType>
<updateCondition>NA</updateCondition>
<ownership>DivestAcquire</ownership>
<sharing>PublishSubscribe</sharing>
<transportation>HLAreliable</transportation>
<order>TimeStamp</order>
</attribute>`
From HLAstandardMIM.xml to my FOM, it works like a charm :)
Cheers
Problem Statement
The HLA1516e standard prescribes the HLAprivilegeToDeleteObject attribute at the HLAobjectRoot level object. This attribute must be held by a federate in order for it to delete the object
Within portico, the name of this attribute is HLAprivilegeToDelete, which looks to be a hang-over from the 1.3 spec (in which it is named privilegeToDelete).
As a result, federates that have been written against the IEEE standard won't work, as they will fail to resolve the correctly named attribute.
Acceptance Criteria
Once fixed, I will be able to