Reported by @Dimentio , and verified.
While eweapon->Behind works, lweapon->Behind does nothing.
Test File
Printable View
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:
This does not separately load the sprite.Code:case ewSBomb:
LOADGFX(ewSBOMB);
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
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./Quote:
Originally Posted by Tamamo
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.
You sir, must switch to atom or sublime immediately.
Hell I use both.
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().
Quote:
Originally Posted by Saffith
maps.cpp. Grumble, gurgle, choke... Probably should move this into a drawing.cpp in the future.
Thanks, and it should be fixed now.
The patch is now in ZC Main.