You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Important note to anyone spawning units into an area for modifying encounters and such... your units need to be registered into a "summonpool" (whatever you want, usually) if you want the game to handle loading/unloading/etc... the units, along with making sure you are spawning units into the game instance's main state. If you don't do this, you will need to manually handle loading/unloading units based on area the player is in. If you don't do this, you will end up with huge overhead loaded on every area load, which is especially easy to feel when you load a large map like Drezen/midnight fane.
Similar to the inventory lag when you have lots of items (think we currently have an extremely inefficient array handling process being used, though I haven't evaluated it in depth yet), adding/removing units when the currently "awake"/"active" units list is large becomes extreme (~4+ minutes to load the map)
I have no idea why they decided to use "summonPool" for literally all of the area unit handling.. but I guess they just extended it and didn't bother refactoring, which makes sense
It's a bit interesting to look in the summon pools blueprint folder and see hundreds of pools, for basically every encounter in the game though
Easy way to see exactly what encounters exist though, I guess... :slight_smile:
Example of the handling i'm talking about:
publicvoidHandleUnitDeath(UnitEntityDataentityData){foreach(SummonPool item in m_Pools.Values.ToTempList()){if(!item.Blueprint.DoNotRemoveDeadUnits){
item.Unregister(entityData);}}}```
swizzlewizzle — Today at 4:51 AM
Manual destruction can be done via value.MarkForDestroy();orsimilar.. you will also want to set the unit entity data's IsInGame to false
The text was updated successfully, but these errors were encountered:
This issue will be closed because it is older then a year. The here mentioned Bug/Feature might already fixed or implemented. If the bug still persists/the Feature is still requested please reopen the issue or create a new one.
Important note to anyone spawning units into an area for modifying encounters and such... your units need to be registered into a "summonpool" (whatever you want, usually) if you want the game to handle loading/unloading/etc... the units, along with making sure you are spawning units into the game instance's main state. If you don't do this, you will need to manually handle loading/unloading units based on area the player is in. If you don't do this, you will end up with huge overhead loaded on every area load, which is especially easy to feel when you load a large map like Drezen/midnight fane.
Similar to the inventory lag when you have lots of items (think we currently have an extremely inefficient array handling process being used, though I haven't evaluated it in depth yet), adding/removing units when the currently "awake"/"active" units list is large becomes extreme (~4+ minutes to load the map)
I have no idea why they decided to use "summonPool" for literally all of the area unit handling.. but I guess they just extended it and didn't bother refactoring, which makes sense
It's a bit interesting to look in the summon pools blueprint folder and see hundreds of pools, for basically every encounter in the game though
Easy way to see exactly what encounters exist though, I guess... :slight_smile:
Example of the handling i'm talking about:
The text was updated successfully, but these errors were encountered: