The terrain of a map is divided into many sections for use in various game modes. Sections of the terrain will have pre-placed units and doodads that contribute to loading time and max doodad/unit count. Each match, only one game mode is played, and thus only one section of the terrain is used while the others are completely unused for that match.
I am reaching max doodad and unit count for the map, but I would still like to make each section as detailed as possible. Is there a way through a combination of triggers and data to only render the units and doodads in specified regions at game initialization?
This issue is directed more toward doodads than units, since for units there's the "Don't load unit model" flag and "Load unit model" trigger. However, even when a unit's model isn't loaded, does it not still require resources to create the unit at initialization? If so, then what use is this flag?
Though time consuming, one option you could pursue would be to use points instead of units or doodads, then create units at runtime. The doodads would have to be units for this to work, so you would need to create a dummy unit type and apply the appropriate model and footprint at runtime. This would allow you to designate the position of units and doodads at initialization, then only create the ones you want at runtime.
If you plan on doing this, I would start with the units (since they are the easiest to deal with) then the easiest doodads, only replacing doodads with points as needed.
It has crossed my mind, and I believe people who've ran into this problem before have been suggested the same. However the quantity and placement precision of these doodads in question make it very impractical, in addition to script space required to mark the points and max unit limit conflicts.
I could very well just use less doodads if I can't figure this out. For units though, does the "Load unit model" trigger combination use less resources at map initialization?
I conducted a few tests with Load Unit Model flag and triggers in a map on B.net. As far as I can tell there was no difference in terms of loading time. I would still very much appreciate input regarding initializing doodads.
Anytime I've tried using that action, the doodads won't have pathing. Units will just be able to go right through them. That's probably why units were suggested.
Yes but there's no reason he couldn't use both. Using only an actor would be more efficient than a unit but it comes with limitations... it just depends on what the mapmaker needs in a given situation.
Use just actors for doodads that don't require footprints, and units for doodads that do require it. I suppose it depends on how badly you need to improve performance.
Has any recent patches changed the max doodad, unit, or actor limits? From past threads I recall the max actor limit being 16k, with 10k max doodads. It's unlikely this has changed but what are some workarounds developers have done for their projects?
For mine, the 'create actor at point' method isn't viable.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Gents.
The terrain of a map is divided into many sections for use in various game modes. Sections of the terrain will have pre-placed units and doodads that contribute to loading time and max doodad/unit count. Each match, only one game mode is played, and thus only one section of the terrain is used while the others are completely unused for that match.
I am reaching max doodad and unit count for the map, but I would still like to make each section as detailed as possible. Is there a way through a combination of triggers and data to only render the units and doodads in specified regions at game initialization?
This issue is directed more toward doodads than units, since for units there's the "Don't load unit model" flag and "Load unit model" trigger. However, even when a unit's model isn't loaded, does it not still require resources to create the unit at initialization? If so, then what use is this flag?
Thanks in advance.
Though time consuming, one option you could pursue would be to use points instead of units or doodads, then create units at runtime. The doodads would have to be units for this to work, so you would need to create a dummy unit type and apply the appropriate model and footprint at runtime. This would allow you to designate the position of units and doodads at initialization, then only create the ones you want at runtime.
If you plan on doing this, I would start with the units (since they are the easiest to deal with) then the easiest doodads, only replacing doodads with points as needed.
Just an idea.
It has crossed my mind, and I believe people who've ran into this problem before have been suggested the same. However the quantity and placement precision of these doodads in question make it very impractical, in addition to script space required to mark the points and max unit limit conflicts.
I could very well just use less doodads if I can't figure this out. For units though, does the "Load unit model" trigger combination use less resources at map initialization?
Bump.
I conducted a few tests with Load Unit Model flag and triggers in a map on B.net. As far as I can tell there was no difference in terms of loading time. I would still very much appreciate input regarding initializing doodads.
@BasharTeg: Go
I don't believe that the doodads would need to be units. Doodads are an actor, so you can "create actor at point" a doodad.
Highly impractical, though.
You can improve performance but not load times by using the "Remove Doodads In Region" trigger action.
@MasterWrath: Go
Anytime I've tried using that action, the doodads won't have pathing. Units will just be able to go right through them. That's probably why units were suggested.
@MaskedImposter: Go
Yes but there's no reason he couldn't use both. Using only an actor would be more efficient than a unit but it comes with limitations... it just depends on what the mapmaker needs in a given situation.
@BasharTeg: Go
Why would you use both?
@MaskedImposter: Go
Use just actors for doodads that don't require footprints, and units for doodads that do require it. I suppose it depends on how badly you need to improve performance.
Has any recent patches changed the max doodad, unit, or actor limits? From past threads I recall the max actor limit being 16k, with 10k max doodads. It's unlikely this has changed but what are some workarounds developers have done for their projects?
For mine, the 'create actor at point' method isn't viable.