User Tag List

Page 4 of 4 FirstFirst ... 2 3 4
Results 31 to 39 of 39

Thread: 2.x vs 3.x

  1. #31
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    Quote Originally Posted by ZoriaRPG View Post
    @Gleeok : I mean to reference an npc via its UID with something akin to LoadNPC(). At present, we can only affect an npc, by using its screen index, which changes. I also need to add typecasting so that a user can read an npc pointer as an int, unless you want to do that. I'm not sure if npcdata will need UIDs, ut I know of no way to write to, or read from any npc data without using the screen index ID.

    Being able to do something like uid->X without needing to load the npc from its screen index into a pointer would be wicked useful.

    Did you review the files?
    Oh. Well, npc is already the uid, not the pointer. So for example; npc->isValid() is exactly the same as calling guys->isValidUID(*(long*)&npc_as_seen_by_script);

    refInfo are just ids:

    Code:
    class refInfo
    {
    public:
        dword pc; //current command offset
        
        long d[8]; //d registers
        long a[2]; //a regsisters (reference to another ffc on screen)
        byte sp; //stack pointer for current script
        dword scriptflag; //stores whether various operations were true/false etc.
        
        byte ffcref, idata; //current object pointers
        dword itemref, guyref, lwpn, ewpn;
        
        
        refInfo();
        void Clear();
    };
    Also, I have no idea why the refs stuff are not a union. As a general rule never ask me such things.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  2. #32
    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%
    Here's Plan A why Plan A didn't come before Plan B i have no Idea.

    1. Add a reasonable amount of comments to the weapons file to make it easier to read.
    2. qr_WPNANIMFIX: This allows animated weapons to be offset correctly. It was never implemented)
    3. ewFLAME2TRAIL: Current issue is that this weapon is like ewFLAME2 it does not die after a set amount frames.
    4. ewICE: Link knockback should be disabled when link is frozen.

    This stuff is low priority right now however.
    Last edited by Tamamo; 07-13-2016 at 10:40 AM.

  3. #33
    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%
    @Gleeok
    sprite_list::swap isn't broken, It just isn't implemented. :p
    Not going to bother commiting this @Saffith since it's most likely wrong. But I tried to fix it.

    Code:
    bool sprite_list::swap(int a,int b)
    {
        // Re-added for now, but stil unimplemented.
        return false;
    	
        sprite *c = sprites[a];
        sprites[a] = sprites[b];
        sprites[b] = c;
        uids[a] = sprites[a]->getUID();
        uids[b] = sprites[b]->getUID();
    // checkConsistency();
        return true;
    }
    Last edited by Tamamo; 07-13-2016 at 05:01 PM.

  4. #34
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    That would only work if you changed lookups to be O(n), which kind of defeats the purpose. The reason swap even exists is because some enemies try to change the draw order of thiings, so it's actually pretty trivial. I just haven't looked at the exact behavior of this to confirm that children uids are always greater than the parent (which I would assume). If that's the case swap would simply be:

    Code:
    void sprite_list::swap(int a, int b)
    {
        swap(sprites[a], sprites[b]);
        swap(sprites[a]->uid, sprites[b]->uid);
    }
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  5. #35
    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%
    Quote Originally Posted by Gleeok View Post
    That would only work if you changed lookups to be O(n), which kind of defeats the purpose. The reason swap even exists is because some enemies try to change the draw order of thiings, so it's actually pretty trivial.
    You're mistaken my dear It has less to do with drawing order and more with keeping the sprite list organized the dead arms of manhandla are pushed to the end for example that way their are no gaps.

  6. #36
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    Which is even more silly - swapping around dead enemies instead of removing them when sprtie->animate will end up just deleting them. Anyway, it's not that it's difficult to put in swap, I'd just rather get rid of it altogether which is why I haven't fixed it yet.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  7. #37
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,451
    Level
    24
    vBActivity - Bars
    Lv. Percent
    73.19%
    Best I can tell at the moment, they do it because the dying segments hang around for several frames, and that's how they avoid counting them repeatedly. That should be very easy to fix.

  8. #38
    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%
    Quote Originally Posted by Gleeok View Post
    Which is even more silly - swapping around dead enemies instead of removing them when sprtie->animate will end up just deleting them. Anyway, it's not that it's difficult to put in swap, I'd just rather get rid of it altogether which is why I haven't fixed it yet.
    It's sillier then you think. Patras and Manhandlas are broken solely because this is missing. Fucking enemy code. Once I get to rewriting it, we shouldn't need it anymore. How do you like them apples.

  9. #39
    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,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by Tamamo View Post
    It's sillier then you think. Patras and Manhandlas are broken solely because this is missing. Fucking enemy code. Once I get to rewriting it, we shouldn't need it anymore. How do you like them apples.
    I certainly do. Please remember to ensure that you have a specific flag or something for an enemy 'core' for manhandlas, gleeoks and such. The core needs to be an npc with all the normal attributes and properties, so it's possible to get its x/y and apply things to it.

    Gleeok bodies with a flipping hitbox would be nice.
    @Gleeok How big is your hitbox?

Thread Information

Users Browsing this Thread

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

Tags for this Thread

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