User Tag List

Results 1 to 8 of 8

Thread: LWeapon->Behind does nothing.

  1. #1
    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%

    Dead Bug LWeapon->Behind does nothing.

    Reported by @Dimentio , and verified.

    While eweapon->Behind works, lweapon->Behind does nothing.

    Test File

  2. #2
    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%
    Some notes, as I try to debug this:

    Somewhere there is a call in the drawing order to determine if a sprite should appear behind other sprites that is not being replicated on the lweapons front.

    Behind is a property of sprites i.e. Weapons/Misc Sprites), BUT THIS his may be in addition to weapons

    I'm wondering if the issue is that link;s weapons load their sprite like this:

    [code]
    if(itemid >-1)
    defaultw = itemsbuf[itemid].wpn;
    else
    defaultw = wBRANG;

    LOADGFX(defaultw);
    [/code[

    this reading the SPRITE properties, which are /not changed/ by this variable.


    ...while enemy weapons do this:

    Code:
     case ewSBomb:
            LOADGFX(ewSBOMB);
    This does not separately load the sprite.

    I do not know what file handles drawing the sprites, and drawing order. @DarkDragon , and @Gleeok , do you know which file has this?

    I think that I could add an additional property to the weapons and do:
    behind = (wpnsbuf[wid].misc&WF_BEHIND | scriptbehind )!=0; //This is not working for lweapons. -Z
    but if this is not the cause, then it is somewhere int he drawing sequence

  3. #3
    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%
    shouldn't have anything to do with it. lweapons and eweapons are the same thing, only thing different is the vector they're stored in.

  4. #4
    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
    shouldn't have anything to do with it. lweapons and eweapons are the same thing, only thing different is the vector they're stored in.
    I would not immediately suspect how the sprite is read, but there is so little other difference, that is one of the few notable things, and I am somewhat convinced that it is the culprit./

    Let me explain:

    The lweapons may always be reading the 'behind' bit from the sprites struct, while eweapons do not.

    I will probably throw in a substitute call for LOADGFX() in the arrow lweapon, without reading wpn.misc1., just to see what happens. If that does fix it, then I will know to fix it by adding an extra call to read the script behind attribute, which may also fix it anyway. Not ideal, but it's something. I flipping made a diagonal hookshot flag that works from the editor or by script, and I added a Range attribute to scripted weapons that handles the internal item editor Range/Distance value, so I do know that script vars can be overridden by other ZQuest editor properties.

    In that adventure, I had to fix the range value for boomerangs, arrows, and the hookshot in different manners to ensure that (1) the editor property was forwarded to ZScript, and that if the user overrode it in ZScript, that their change had precedence, but if the value in zscript was unchanged (default initialised to -1), that the editor value had precedence. ....so, I am not just throwing a wild idea out there that LOADGFX being fed values for lweapons from their misc1 that these values may be overriding the user script setting for them. It happened before.

    The only other thing I can conceive of causing this is some weird drawing order issue, and I am unsure where that would occur at present. I will pop out a build that tests a few things to see if anything affects this issue. You are of course, welcome to try to find the problem if you want, but I'm pretty sure that will never happen.

    Do you know offhand where the calls are to draw on-screen eweapons and lweapons? I don't remember at present, and I won't be able to go through the whole bastard for a few days.

  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%
    You sir, must switch to atom or sublime immediately.
    Hell I use both.

  6. #6
    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,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    It's draw_screen() in maps.cpp. There are separate loops for drawing eweapons with or without Behind, but lweapons are handled by a single call to Lwpns.draw().

  7. #7
    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 Saffith View Post
    It's draw_screen() in maps.cpp. There are separate loops for drawing eweapons with or without Behind, but lweapons are handled by a single call to Lwpns.draw().


    maps.cpp. Grumble, gurgle, choke... Probably should move this into a drawing.cpp in the future.

    Thanks, and it should be fixed now.

  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%
    The patch is now in ZC Main.

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