User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 19

Thread: Increasing the alias count

  1. #1
    Gel
    Join Date
    Sep 2015
    Posts
    18
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    400
    Level
    7
    vBActivity - Bars
    Lv. Percent
    26.03%

    Increasing the alias count

    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.)

  2. #2
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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.

  3. #3
    Gel
    Join Date
    Sep 2015
    Posts
    18
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    400
    Level
    7
    vBActivity - Bars
    Lv. Percent
    26.03%
    Quote Originally Posted by Tamamo View Post
    You mean redoubled.
    ...ok.

    Quote Originally Posted by Tamamo View Post
    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.

  4. #4
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    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?

  5. #5
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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.

  6. #6
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    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?
    Last edited by Gleeok; 01-15-2017 at 09:48 PM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  7. #7
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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 )

  8. #8
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Lüt View Post
    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.

  9. #9
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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.

  10. #10
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Tamamo View Post
    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social