Changeset View
Standalone View
binaries/data/mods/public/simulation/templates/special/filter/mirage.xml
| <?xml version="1.0" encoding="utf-8"?> | <?xml version="1.0" encoding="utf-8"?> | ||||
| <Entity filtered=""> | <Entity filtered=""> | ||||
| <Footprint merge=""/> | <Footprint merge=""/> | ||||
| <Identity filtered=""> | <Identity filtered=""> | ||||
| <Civ merge=""/> | <Civ merge=""/> | ||||
| <GenericName merge=""/> | <GenericName merge=""/> | ||||
| <SpecificName merge=""/> | <SpecificName merge=""/> | ||||
| <Tooltip merge=""/> | <Tooltip merge=""/> | ||||
| <History merge=""/> | <History merge=""/> | ||||
| <Classes merge=""/> | |||||
elexis: If I understand the matter correctly, this will cause a copy of classes to be written to the… | |||||
templeAuthorUnsubmitted Not Done Inline ActionsThis doesn't do anything to the Mirage component, instead the miraged entity will have this.classesList in its Identity component (and nothing is serialized there). (Currently, the miraged entity has a Mirage component with this.classesList which is copied from the original entity (in Fogging, as you said), but it also has an Identity component that's filled out with the things that are merged here, like Civ and GenericName. Doing QueryMiragedInterface will get the Mirage component while Engine.QueryInterface will get the Identity (or whatever) component. (For non-mirage entities, QueryMiragedInterface is the same as Engine.QueryInterface. Added in rP16607.) It's a bit weird that Identity is split this way when the other miraged components like Health aren't. So maybe that's an argument for this patch.) temple: This doesn't do anything to the Mirage component, instead the miraged entity will have `this. | |||||
elexisUnsubmitted Not Done Inline ActionsSorry I meant mirage entity, not mirage component. Yes I liked that the patch at the other revision proposal unified Identity, but we certainly have enough complexity to review already in this iteration IMO elexis: Sorry I meant mirage entity, not mirage component.
But the mirage entity is serialized and the… | |||||
elexisUnsubmitted Not Done Inline Actions
In the non-clone / special filter variant iteration of the patch the classeslist of the mirage entity is part of the template and templates are not serialized. It's a new object (which is what I meant with deepcopy), hence indeed no OOS. elexis: > But the mirage entity is serialized and the mirage still serializes this classes list, but… | |||||
| <Icon merge=""/> | <Icon merge=""/> | ||||
| <Undeletable merge=""/> | <Undeletable merge=""/> | ||||
| </Identity> | </Identity> | ||||
| <Minimap merge=""/> | <Minimap merge=""/> | ||||
| <Mirage replace=""/> | <Mirage replace=""/> | ||||
| <Obstruction merge=""> | <Obstruction merge=""> | ||||
| <BlockMovement>false</BlockMovement> | <BlockMovement>false</BlockMovement> | ||||
| <BlockPathfinding>false</BlockPathfinding> | <BlockPathfinding>false</BlockPathfinding> | ||||
| Show All 11 Lines | |||||
If I understand the matter correctly, this will cause a copy of classes to be written to the Mirage component. So the Identity classes list is not serialized, while the Mirage classes list is. This still solves the OOS because the AddEntity call in Fogging.prototype.LoadMirage yields a deepcopy, whereas now we only copy over a reference.