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! :P
* 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! :P
* 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. :(

[SUCCESSOR]

I remember I made a joke about combo aliases once -- something about trees. I imagine it was hilarious. :)


I remember this! Someone asked if they could be increased and Gleeok, IIRC, asked why anyone would need more. The person stated that they had used a bunch for different colored trees. I found the "Pro Tip: Don't use them all for trees! " comment hilarious.



..Do people actually use all of them?

I don't see how. Those things are annoying to set up and use. I prefer drawing layer by layer myself. I guess if you don't use layers much they may be a little more user friendly.

[Gleeok]

I remember this! Someone asked if they could be increased and Gleeok, IIRC, asked why anyone would need more. The person stated that they had used a bunch for different colored trees. I found the "Pro Tip: Don't use them all for trees! " comment hilarious.



I don't see how. Those things are annoying to set up and use. I prefer drawing layer by layer myself. I guess if you don't use layers much they may be a little more user friendly.


Maybe we should ask Lüt what's in the burgers. :P

[SUCCESSOR]

I have a disturbing curiosity what one would need over 2000 combo aliases for. I probably wouldn't be the same afterwards, though.

[Lüt]

Wow, this really took off.


..Do people actually use all of them?
If you consider me a "person," I suppose so.

If you consider me something Confucius say you must drop on your head, then probably not.


What is your application for combo aliases, that you have expended them all?
Forming large structural components and assembling other big objects so they can be placed with a single click rather than 4 or 40, and so people don't have to endlessly jump around the combo list in the process.

To which extent... OK, well first off, honest confession: I do have a batch of trees at the beginning of the list.

BUT! The majority of it is spent on dungeon architecture. I've been throwing together an absurdly expanded classic-based tileset for far too long, which has considerable overworld expansions, but has a primary focus on expanding the dungeon tile collection with the purpose of eliminating square rooms in favor of freeform layouts with diagonals and multiple levels/tiers. Making these all fit, particularly when spanning diagonals across varying heights, can occasionally get overwhelming even for me who made them. Building them into pre-made wall segments, corner segments, etc. for each of the heights saves much scouring through the combo list, and the overall intent is to make advanced dungeon design accessible for beginners (or probably intermediates by this point). It also has the further capability of indirectly "explaining" how all these new combos are used.

I mean, if people really need to know, I could throw together a picture post showing exactly what I'm doing. It would probably take all day to make though.


but a new class of objects, grouped combos, might be better, aye.
Isn't that exactly what they are though? All I do with aliases is group combos together.

Unless you're suggesting that they somehow remain a single unit even after being placed on the screen?


Quite frankly, I would think that users more easily run out of tiles, than anything else.
If you're referring to the 252-page limit, well, I'm closer to filling that out than the combo list, for certain. Kind of surprising, given they're both a little over 65,000 entries, but enemy sprites take up a large chunk of space, and in default classic you lose about 10,000 entries for those 39 pages. It's also a matter of organization, rather than simply filling in every blank space.


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 was anticipating an answer along these lines (though one can always hope). Would we be looking at years for an official "new" release, or is this a thing you're considering for 2.54?


I would be in favour of increasing all the system counts, if they do not gravely, adversely affect file size.
Actually, to that extent... hey Gleeok, do you remember how much the first increase from 1024 to 2048 aliases affected the file size? I'd imagine it's a safe bet to expect double that for the next increase.

(I just talk like it's actually going to happen.)


Such as the combo alias editor being fucking awful.
There's also this.

I managed to crack it and can use it fairly easily now, but I do agree it needs a near-complete overhaul. Mass amounts of I+Enter and Shift+I+Enter takes long enough in the combo list - having to manually enter a number each time you want a new alias inserted, or removed, has taken more than a few hours of my time.


i would much rather use check boxes or something to select which csets are not changeable and which ones are.
I like that. +/- still changes CSets as easily as ever (so I don't know why the default quest has the same aliases in 4 different CSets heh), but in the event of, say, changing the CSet of leaves without also changing the trunk, I was considering doing something along the lines of keeping the standard 4-bit leaf tiles that can cycle through CSets but using 8-bit trunks instead, so you could change leaf colors all you want without screwing up the trunk colors as well and having to make 3x or 4x the amount of aliases to compensate. Yours is the preferable option though.

[ZoriaRPG]

Wow, this really took off.


If you consider me a "person," I suppose so.

If you consider me something Confucius say you must drop on your head, then probably not.


Forming large structural components and assembling other big objects so they can be placed with a single click rather than 4 or 40, and so people don't have to endlessly jump around the combo list in the process.

To which extent... OK, well first off, honest confession: I do have a batch of trees at the beginning of the list.



Are you using more than two or three layers in these quests? If you want to post some screenshots, that would work. I wouldn't mind expanding the dungeon carving and relational stuff, or just adding some kind of new, user-defined set of linked combos. All of that seems better than mucking with this.



BUT! The majority of it is spent on dungeon architecture. I've been throwing together an absurdly expanded classic-based tileset for far too long, which has considerable overworld expansions, but has a primary focus on expanding the dungeon tile collection with the purpose of eliminating square rooms in favor of freeform layouts with diagonals and multiple levels/tiers. Making these all fit, particularly when spanning diagonals across varying heights, can occasionally get overwhelming even for me who made them. Building them into pre-made wall segments, corner segments, etc. for each of the heights saves much scouring through the combo list, and the overall intent is to make advanced dungeon design accessible for beginners (or probably intermediates by this point). It also has the further capability of indirectly "explaining" how all these new combos are used.

I mean, if people really need to know, I could throw together a picture post showing exactly what I'm doing. It would probably take all day to make though.


Isn't that exactly what they are though? All I do with aliases is group combos together.

Unless you're suggesting that they somehow remain a single unit even after being placed on the screen?


If you're referring to the 252-page limit, well, I'm closer to filling that out than the combo list, for certain. Kind of surprising, given they're both a little over 65,000 entries, but enemy sprites take up a large chunk of space, and in default classic you lose about 10,000 entries for those 39 pages. It's also a matter of organization, rather than simply filling in every blank space.



I've run out of tiles, several times. Character portraits, structures, enemies, walking npcs, dialogue boxes, visual effects, you name it. I had planned to do a sort of 'area vista' thing for a quest, where the user could look at the surrounding area in landscape mode, and this ran me out of tiles in a few dozen views, with the animations involved. Most of this stuff is for DrawTile() and scripted drawing though, and that's why I would think that the tile editor might be able to handle this kind of expansion. Tiles are just bitmap patters, and only use space when added because they are compressed with zlib; whereas combos probably are like most of our other struct objects, and each space uses a memory footprint, based on its internal variables, at all times. :(

I'll have a look and see how hard it would be top change the combo table size.



I was anticipating an answer along these lines (though one can always hope). Would we be looking at years for an official "new" release, or is this a thing you're considering for 2.54?


I'd consider it for 2.54, which I hope that we might be able to release by the Summer, even if that means cutting some features. (I would ideally like to see it available when all the younger crowd have their summer break.)

There's no way to know how long a new official release will take. I'm hoping that we can at least get something out this year, in that regard, but it's in such a state of flux, that I just don't know.



Actually, to that extent... hey Gleeok, do you remember how much the first increase from 1024 to 2048 aliases affected the file size? I'd imagine it's a safe bet to expect double that for the next increase.

(I just talk like it's actually going to happen.)


It's extremely negligible, a few KB, at worst. I could check if you want, but the memory footprint might be a bigger issue. It will come out to ( ( total number of bits in the combo alias struct ) * ( number of aliases ) ). Then again, that is a ZQuest memory thing, not a ZC memory thing, so it's far less catastrophic if it uses a few hundred more KB to run.



There's also this.

I managed to crack it and can use it fairly easily now, but I do agree it needs a near-complete overhaul. Mass amounts of I+Enter and Shift+I+Enter takes long enough in the combo list - having to manually enter a number each time you want a new alias inserted, or removed, has taken more than a few hours of my time.


I like that. +/- still changes CSets as easily as ever (so I don't know why the default quest has the same aliases in 4 different CSets heh), but in the event of, say, changing the CSet of leaves without also changing the trunk, I was considering doing something along the lines of keeping the standard 4-bit leaf tiles that can cycle through CSets but using 8-bit trunks instead, so you could change leaf colors all you want without screwing up the trunk colors as well and having to make 3x or 4x the amount of aliases to compensate. Yours is the preferable option though.

[/quote]

If you have suggestions on how to improve it, as a user that...uses it...please list them.

[Lüt]

Sorry, busy week.


Are you using more than two or three layers in these quests?
Rarely. The way things are set up, it would be unusual to need more than one ground and one overhead layer in dungeons. The only instance I would imagine needing layer 5/6 for is overlays, i.e. dungeon leaf overhangs, outdoor rain/snow, etc.


If you want to post some screenshots, that would work.
OK, yeah I'll finish that (hopefully) in a few days. I started, then realized I had more pressing issues, so I'm just writing a normal reply for now.


I wouldn't mind expanding the dungeon carving and relational stuff, or just adding some kind of new, user-defined set of linked combos. All of that seems better than mucking with this.
How exactly do you mean to expand dungeon carving and relational stuff? Are you talking about adding more combo sets that are configured for those modes, or are you talking about changing the programming/functionality of the modes?

Because I've also been doing a lot of relational setups as well, and they're quite functional and do exactly what I (and I would imagine most people) need them to do.


I've run out of tiles, several times. Character portraits, structures, enemies, walking npcs, dialogue boxes, visual effects, you name it.
Ah yes, I remember some of your full-screen images...


I had planned to do a sort of 'area vista' thing for a quest, where the user could look at the surrounding area in landscape mode, and this ran me out of tiles in a few dozen views, with the animations involved....though this is news to me, and I can see why you're running out of tiles so quickly.

Which reminds me, the other thing I can't believe I forgot that was eating tile space was subscreen/map/item/sprite graphics on p63-110 and 120-134, which eats another 16,000+ tiles. Though, honestly, deleting a lot of the unused tiles and consolidating the remaining ones could free up a load of space. I just don't know enough about things like offsets/modifications/subscreen config/etc. to feel comfortable deleting/rearranging those just yet.


I'm hoping that we can at least get something out this year, in that regard, but it's in such a state of flux, that I just don't know.
Oh, yeah I understand, I was just wondering if people were thinking months or years.


It's extremely negligible, a few KB, at worst. I could check if you want, but the memory footprint might be a bigger issue. It will come out to ( ( total number of bits in the combo alias struct ) * ( number of aliases ) ). Then again, that is a ZQuest memory thing, not a ZC memory thing, so it's far less catastrophic if it uses a few hundred more KB to run.
Well that's good to hear. I tend to think of aliases as little 2x2 to 4x4 things, maybe x6 or similar, but I suppose you have to consider that each one could be up to 16x11 in size and use all 7 layers, which would mean each one has the possibility of containing over 1,200 combos. Is this a situation where every alias has that amount of space assigned by default, or is it more like the tiles in that they remain empty spaces on a list if they're not being used?


If you have suggestions on how to improve it, as a user that...uses it...please list them.
That'll take some planning to lay out. Things like that, almost always turn into sub-projects for me, as I'm really not the best at explaining things like that over text, as opposed to in person, where I'd be pointing all over the screen, going hardcore Italian with the hand motions, pulling out the pen+paper, etc. Though basically, a fair chunk of it boils down to establishing consistency between the combo menu/page/editor and the alias menu/editor, thus borrowing a few already-established layouts/organization options from the existing combos setup.

[Tamamo]

well lets all just accept and hopefully agree that this isn't happening again.
There's no reason to increase it beyond what it is now.

[Lüt]

That's an impressive brand of willful ignorance. Do you genuinely think the thread came about because nobody had any reason for increase? Or do you simply think the fact that people will actually use a feature doesn't count as a reason?

And what could possibly be your intent in hoping that it won't happen, other than to undermine the increased ease of design and potential for productivity that it would bring? Are you the official spokesperson for the devs? I asked if it was possible, not if any random person wanted it, so let the devs give an actual reason for an answer of yes or no. If it's "no" for whatever reason, coding hassle or resource/memory management or otherwise, then fine. I had a curiosity, not an intent to argue with them until I finally got what I wanted.

[SUCCESSOR]

That's an impressive brand of willful ignorance. Do you genuinely think the thread came about because nobody had any reason for increase? Or do you simply think the fact that people will actually use a feature doesn't count as a reason?

And what could possibly be your intent in hoping that it won't happen, other than to undermine the increased ease of design and potential for productivity that it would bring? Are you the official spokesperson for the devs? I asked if it was possible, not if any random person wanted it, so let the devs give an actual reason for an answer of yes or no. If it's "no" for whatever reason, coding hassle or resource/memory management or otherwise, then fine. I had a curiosity, not an intent to argue with them until I finally got what I wanted.

Don't be afraid to ask about new features or make suggestions, even if you get a few silly or petty replies. To answer your question in a constructive way, ZC is more moving in the direction of reworking things in a better way instead of just increasing hardcoded values of how many of a thing you can have. Maybe someday aliases will be reworked to provide as many as you may need. Or maybe someone will increase the the number of aliases available sometime in the short future if it is possible. I think it is pretty rare for a quest maker to use all the aliases we have already though.