In a dynamic terrain editor, to load a list of all the doodads, it cycles through all actors of the catalog and if its a doodad, it adds it to the list. This loop currently searches within 7710 catalog entry. But, since LotV the number of entry have raised and to get access to those doodads we have to increase the search. But the trigger to get the CatalogEntry is maxed at 8239. Above that it breaks.
Anyone can confirm that limit? And could suggest a solution?
This is our triggers. Note, forget about the fast load section, its about the whole loading with the 7710. If we set that number above 8239, it generates an error.
Based on the trigger posted it should never be reaching 8240 so I do not understand how you are getting that error. Or did you mean to post one with 7710 changed to "number above 8239"?
The way you are iterating is incorrect. You need to dynamically fetch the number of catalog entries and use that for the loop terminator since the number of entries may be subject to change over time with patches.
nativeintCatalogEntryCount(intcatalog);
If you still get this error despite being within the declared catalog entry count then there must be a bug with the CatalogEntryGet native which should be reported to Blizzard.
If in the trigger above it is changed to something bigger than 8239, it does the error.
It seems to be related to the dependency at some point. For example doing: Actor - Create actor (Game Link((String((Catalog Actors entry at index PutBigNumberHere))))) at point (Center of (Entire map))
With only Void (Mod) dependency result in: Max 5510
With Void (Mod) and Void (Campaign) dependencies result in: Max 12453
But when you look in the actor list it goes up to 13711. Why is it maxing out at that number? In my map, it goes up to 9006 actors, why does it block at 8239?
Because you are counting the same actor entry more than once. Mods can modify entries from their dependencies resulting in another entry in the data editor list but it is still just a single entry in game. This is why you should use the dynamic count lookup (which should be available in GUI) as that will return the number of actor catalog entries the game recognizes at run time.
Quote:
In my map, it goes up to 9006 actors, why does it block at 8239?
Because the number of actors you think you have is larger than the number you actually have? Use the dynamic entry count lookup to get the total number of entries. Entry numbers are only valid up to the value returned by that native and its equivalent GUI wrapper. Some of the actors you are counting must be entry modifications from dependant mods performed by mods.
This is why you should use the dynamic count lookup (which should be available in GUI) as that will return the number of actor catalog entries the game recognizes at run time.
Umk, and what is the dynamic count lookup? And if I just set the loop to 8239 exacly, wouldn't that search through all of them?
Where you call a function to get the number of actor catalog entries instead of hard coding some magic number.
In GUI the following would make a local integer variable with that number...
actorentryn=(CatalogActorsentrycount)<Integer>
The native which is called to do this is, as mentioned earlier, ...
nativeintCatalogEntryCount(intcatalog);
This returns the number of entries inside the catalog from the game's perspective. If more actor catalog entries were to be added or removed then it will still be correct as whenever it is called it will return the number of entries in the actor catalog which exist at the time of calling.
Quote:
And if I just set the loop to 8239 exacly, wouldn't that search through all of them?
It might for now, but if a patch adds or removes some actor catalog entries then it is just some arbitrary magic number unrelated to the number of actor entries in the map's catalog. The lookup function will always return the correct number of actor entries in the catalog, something not possible with a magic number constant.
The idea is you loop through all entries up until the entry number is reached. This loop is entirely dynamic, you do not care how many times it actually loops only that you want some actions performed on each entry.
Alright thanks. It seems like it's working... For sure the EntryCount makes sure I have everything, but I think i was also miss searching "void" where Void is just a Prefix for the editor and the real ID name of the actors do not countain "void" anywhere. To find stuff from Void Prologue for example, I'd have to search "Moebius" or "Slayn" etc.
I'm still kind of wondering why is the EntryCount of Actors not the same as the count of actors found in the Data editor?
Oh wait... In the Data, there are sometimes gap which is why it's not the same count... I guess?
I'm still kind of wondering why is the EntryCount of Actors not the same as the count of actors found in the Data editor?
It might be counting types as entries. Every entry has to extend a type with exception of the type itself which shows as a data entry in the data editor.
I would also speculate that it may or may not count entries that are default entries, which can not be instantiated in game. Easy to test, but your deduction is also correct, every type has an entry in Core, which serves as the default parent for any entity created of that type, basically an implicit parent id object.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
In a dynamic terrain editor, to load a list of all the doodads, it cycles through all actors of the catalog and if its a doodad, it adds it to the list. This loop currently searches within 7710 catalog entry. But, since LotV the number of entry have raised and to get access to those doodads we have to increase the search. But the trigger to get the CatalogEntry is maxed at 8239. Above that it breaks.
Anyone can confirm that limit? And could suggest a solution?
This is our triggers. Note, forget about the fast load section, its about the whole loading with the 7710. If we set that number above 8239, it generates an error.
Working on projects:
Could you post a screenshot of the error, too? Would be easier to work with, from that plain trigger I can't see/guess any errors.
@TheUltragon: Go
Here
Working on projects:
Based on the trigger posted it should never be reaching 8240 so I do not understand how you are getting that error. Or did you mean to post one with 7710 changed to "number above 8239"?
The way you are iterating is incorrect. You need to dynamically fetch the number of catalog entries and use that for the loop terminator since the number of entries may be subject to change over time with patches.
If you still get this error despite being within the declared catalog entry count then there must be a bug with the CatalogEntryGet native which should be reported to Blizzard.
@ImperialGood: Go
If in the trigger above it is changed to something bigger than 8239, it does the error.
It seems to be related to the dependency at some point. For example doing: Actor - Create actor (Game Link((String((Catalog Actors entry at index PutBigNumberHere))))) at point (Center of (Entire map))
With only Void (Mod) dependency result in: Max 5510
With Void (Mod) and Void (Campaign) dependencies result in: Max 12453
But when you look in the actor list it goes up to 13711. Why is it maxing out at that number? In my map, it goes up to 9006 actors, why does it block at 8239?
Working on projects:
Because you are counting the same actor entry more than once. Mods can modify entries from their dependencies resulting in another entry in the data editor list but it is still just a single entry in game. This is why you should use the dynamic count lookup (which should be available in GUI) as that will return the number of actor catalog entries the game recognizes at run time.
Because the number of actors you think you have is larger than the number you actually have? Use the dynamic entry count lookup to get the total number of entries. Entry numbers are only valid up to the value returned by that native and its equivalent GUI wrapper. Some of the actors you are counting must be entry modifications from dependant mods performed by mods.
Umk, and what is the dynamic count lookup? And if I just set the loop to 8239 exacly, wouldn't that search through all of them?
Working on projects:
Where you call a function to get the number of actor catalog entries instead of hard coding some magic number.
In GUI the following would make a local integer variable with that number...
The native which is called to do this is, as mentioned earlier, ...
This returns the number of entries inside the catalog from the game's perspective. If more actor catalog entries were to be added or removed then it will still be correct as whenever it is called it will return the number of entries in the actor catalog which exist at the time of calling.
It might for now, but if a patch adds or removes some actor catalog entries then it is just some arbitrary magic number unrelated to the number of actor entries in the map's catalog. The lookup function will always return the correct number of actor entries in the catalog, something not possible with a magic number constant.
The idea is you loop through all entries up until the entry number is reached. This loop is entirely dynamic, you do not care how many times it actually loops only that you want some actions performed on each entry.
@ImperialGood: Go
Alright thanks. It seems like it's working... For sure the EntryCount makes sure I have everything, but I think i was also miss searching "void" where Void is just a Prefix for the editor and the real ID name of the actors do not countain "void" anywhere. To find stuff from Void Prologue for example, I'd have to search "Moebius" or "Slayn" etc.
I'm still kind of wondering why is the EntryCount of Actors not the same as the count of actors found in the Data editor?
Oh wait... In the Data, there are sometimes gap which is why it's not the same count... I guess?
http://i.imgur.com/R2WKRXy.png
Working on projects:
It might be counting types as entries. Every entry has to extend a type with exception of the type itself which shows as a data entry in the data editor.
@ImperialGood: Go
I would also speculate that it may or may not count entries that are default entries, which can not be instantiated in game. Easy to test, but your deduction is also correct, every type has an entry in Core, which serves as the default parent for any entity created of that type, basically an implicit parent id object.