Increasing the alias count

[Lüt]

Currently, there's a limit of 2048 entries for aliases.

Would it be possible to expand this?

Most expansions I've seen have been doubles (i.e. 256 to 512 enemies), so how about 4096 aliases?

I mean, for my own purposes, 3072 would be comfortable, but I have no idea what numbers would be easiest to work with on the programming side of things, so maybe most expansions have been doubles for a reason... (?)

(And, as per the sticky topic, the suggestion is for the next "maintenance release" (2.50.3?), in case that wasn't the default assumption.)

[Tamamo]

You mean redoubled. And i'm against this change, and it's probably not gonna happen. Since gleeok was against it the first time. (I swear if you cave this time because of trees, I'm gonna punch you in the dick @Gleeok ) Just kidding necky.

[Lüt]

You mean redoubled.

...ok.

And i'm against this change, and it's probably not gonna happen.

Something to do with restructuring the file format or data storage system? I was worried if a thing like that might be an issue. I figured, if it was as simple as entering a max number, that would've been done already. Well, if that's the case, then there's probably no point going to such a huge inconvenience for only a minor convenience. It was more for people who were/might have been considering using my stuff than it was for me.

[DarkDragon]

Can you please link me to the previous discussions, particularly those that include
- rationale for the need for more than 2048 combo aliases;
- Gleeok's decision and reasoning for turning down the request?

[Tamamo]

Did you misread the thread @DarkDragon .
I specifically said it was already doubled, @Gleeok was the one who did that. And he said firmly that it won't happen again.
Let's leave it at that shall we less he fills the need to chime in.

[Gleeok]

I changed enemies to 512 because people were running out of custom enemy slots and I remember I made a joke about combo aliases once -- something about trees. I imagine it was hilarious. :)


[edit] (I also misread this thread.)

* Increased the maximum usable combo aliases to 2048. Pro Tip: Don't use them all for trees!
* Added Import and Export Combo Aliases functionality in the File->Import/Export Menu. ( Gleeok, 2012-06-11 01:06:28 )

..Do people actually use all of them?

[Tamamo]

Yes, for the third time. From shardstorm.
Build 1550 - linux , macosx-Leopard , windows
* Increased the maximum usable combo aliases to 2048. Pro Tip: Don't use them all for trees!
* Added Import and Export Combo Aliases functionality in the File->Import/Export Menu. ( Gleeok, 2012-06-11 01:06:28 )

[ZoriaRPG]

Currently, there's a limit of 2048 entries for aliases.

Would it be possible to expand this?

Most expansions I've seen have been doubles (i.e. 256 to 512 enemies), so how about 4096 aliases?

I mean, for my own purposes, 3072 would be comfortable, but I have no idea what numbers would be easiest to work with on the programming side of things, so maybe most expansions have been doubles for a reason... (?)

(And, as per the sticky topic, the suggestion is for the next "maintenance release" (2.50.3?), in case that wasn't the default assumption.)

There is no specific reason that expansion shave been a PO2 doubling, other than standard programming logic to think in powers of two. What is your application for combo aliases, that you have expended them all?

If increased, I would try to set this sort of thing up as a standard value, along with the other combo placement modes. Quite frankly, I would think that users more easily run out of tiles, than anything else. I know that I, and a few others have certainly done that, because we use an unsigned short for them. Given the data width of a tile, I see the sense in limiting them for quest packaging, but because we compress that data, and unused space should be 0, I also see the 'nonsense' in it.

Combo aliases are the same sort of deal. I'd rather hear the rationale both for, and against a change here.

I'm not against this change, despite that I rarely use the things, mostly because I'm senile and forget to use them. We may as well get all out filepack revisions done in one pass; but it will not be in a maintenance release (e.g. 2.50.3), as this would pose compatibility concerns within a series of releases that should be avoided.

I'd like to add some extra padding into the filepack to support changes within a series, in the future. I would be in favour of increasing all the system counts, if they do not gravely, adversely affect file size.

[Tamamo]

Fun fact, it's not just about system counts. Such as the combo alias editor being fucking awful.
We need it so you dont need different combo alias for different csets on different layers etc.
i would much rather use check boxes or something to select which csets are not changeable and which ones are.
You could cut combo alias tree usuage by 1/2 to 1/4 alone doing that depending on tileset.

[ZoriaRPG]

Fun fact, it's not just about system counts. Such as the combo alias editor being fucking awful.
We need it so you dont need different combo alias for different csets on different layers etc.
i would much rather use check boxes or something to select which csets are not changeable and which ones are.
You could cut combo alias tree usuage by 1/2 to 1/4 alone doing that depending on tileset.

Certainly, the editor itself has issues. Drawing the things to layers, and their general clunky handling, is why I don't bother with them. I can comprehend why someone thought that setting a default layer pattern for them would be good, but a new class of objects, grouped combos, might be better, aye. Hell, look at the editor. It doesn't even appear visually finished. Radio buttons and pulldowns with no context; huzzah.

I mostly favour upping counts so that future exansion is easier; and adding some generic var arrays to classes, for the same reason. At least the combo class has expansion[6], which I believe is wholly unused. I was thinking of using one of those indices to define Expanded combo types, but some of the base types that I feel it would be good to define will need some additional properties, which means changing the class itself to accommodate them.