Quote:
Originally Posted by
Lüt
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.
Quote:
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. :(
Quote:
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.
Quote:
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]