Opened 8 years ago
Last modified 4 years ago
#4066 new enhancement
In some cases AddEntity tries to use already occupied Entity IDs — at Version 2
Reported by: | AlThePhoenix | Owned by: | |
---|---|---|---|
Priority: | If Time Permits | Milestone: | Backlog |
Component: | Maps | Keywords: | |
Cc: | Patch: |
Description (last modified by )
Attached is an addition to the GarrisonHolder component which makes it possible to make entities come with a starting garrison once they are created.
Basically, AddEntity() seems to be unable to check what the last used EntityID on a map is. For example: If a carrier (this is the definition we're going to use for the unit with the StartingGarrison) is placed as the 5th entity on the map and its garrison consists of 4 units, the garrisoned units will use IDs from 6 to 9. This causes a crash if more entities were placed on the map after placing the carrier (place the carrier at ID 5, place something else at ID 6, a house for example -> conflict).
What should happen: Instead, AddEntity() should be able to check what the highest EntityID is on the map that is being loaded and use IDs after that or there should be an alternate function that does this.
Change History (3)
by , 8 years ago
Attachment: | GarrisonHolder_Mod.js added |
---|
follow-up: 2 comment:1 by , 8 years ago
I'm not entirely sure I get the issue. Are you trying to say this happens when loading a scenario/skirmish map?
There is no bug in the code itself, you should rather wait for the start message and spawn the units then. Maps expect and ID and it indeed fails weirdly if you spawn new entities in the meantime.
We might change maps to not expect an ID at all but I'm not sure if that is desirable.
comment:2 by , 4 years ago
Component: | Core engine → Maps |
---|---|
Description: | modified (diff) |
Priority: | Should Have → If Time Permits |
Type: | defect → enhancement |
Replying to wraitii:
We might change maps to not expect an ID at all but I'm not sure if that is desirable.
Setting priority and type according to the above message.
(See also Phab:D1958 for a fix for this specific usecase.)
Tested with Alpha 20