645 replies to this topic

[Evan20000]

I've noticed that the 360_ROTATE weapon function is incompatible with 2x2 or bigger weapons. Bug?

[David]

Another update, finally. Just some bug fixes.
- AutoGhost() now avoids using changers
- Fixed issues with diagonal movement in 8-way walking functions
- Corrected flashing CSets and timing
- The exploding and flashing death animation works correctly now
- SuspendGhostZHScripts() affects legacy Waitframe functions

Will this update break any saves or scripts or anything like that?

[Mero]

Also the weapons are draw during Link's death animation.

[Saffith]

Will this update break any saves or scripts or anything like that?

It shouldn't break any scripts. Old saves are still valid if the quest previously used 2.7.1 or 2.7.0.

[David]

It shouldn't break any scripts. Old saves are still valid if the quest previously used 2.7.1 or 2.7.0.

Okay, good, thanks for letting me know!

[Lejes]

Two questions. The first is about autoghosted enemies and ghost-created eweapons. I'd like to know why this works:

void run(int enemyID)
	{
		npc ghost = Ghost_InitAutoGhost(this, enemyID);

It's nice to not have to specify exactly which enemy ID you're using, but I'm not really sure how it's pulling the correct number. I thought the initial values of run()'s arguments were set in ZQuest? Is this something ghost.zh is handling behind the scenes? Similar to that, I'm not sure how the eweapon death effect EWD_RUN_SCRIPT works.

 

eweapon GetAssociatedEWeapon(int weaponID)

 * Finds an eweapon using an internal ID number. This should be used by scripts

 * launched by EWD_RUN_SCRIPT, and the weaponID argument should be the number

 * passed to the script as D0. If the requested weapon is not found, an

 * uninitialized pointer will be returned.

 

I'm not sure what "weaponID" is, exactly, but maybe I don't need to?

void run(int weaponID)
	{
		eweapon example = GetAssociatedEWeapon(weaponID);

If I ran a script from the eweapon death effect that started out like that, would it work? Not that I know what the pointer returned by GetAssociatedEWeapon should be used for.

 

Also, is there a way (via ghost.zh functions or otherwise) to keep an eweapon alive even after it hits the edge of the screen?

[Saffith]

It's nice to not have to specify exactly which enemy ID you're using, but I'm not really sure how it's pulling the correct number. I thought the initial values of run()'s arguments were set in ZQuest? Is this something ghost.zh is handling behind the scenes?

You can also set a script's arguments with ffc->InitD[].
 

If I ran a script from the eweapon death effect that started out like that, would it work? Not that I know what the pointer returned by GetAssociatedEWeapon should be used for.

Yep, that's how you do it. The ID number is just an arbitrary, unique number. It's determined and assigned internally, and it's not really useful for other purposes.
The pointer returned by GetAssociatedEWeapon() is the weapon that the script was spawned from. You can delete it or move it around or whatever else you like. You should check that's it's valid first, since it's possible for it to be deleted before the script runs.
 

Also, is there a way (via ghost.zh functions or otherwise) to keep an eweapon alive even after it hits the edge of the screen?

You can't exactly do that, but you can fake it. Don't let the weapon move at all; keep it in a fixed location on the screen and adjust its hit and draw offsets. That can get tricky if there are blocking combos involved, since they don't respect hit offsets.

[Mero]

So you fixed scripted weapons not being disposed of when they go offscreen. This is good news.

[Jamian]

I have a bug report, just in case you haven't caught it in the thread I posted a few days ago: when you use EWD_AIM_AT_LINK, the weapon actually aims to the left of Link.

[Mero]

Yeah he knows, I pmed him about it.

[Lejes]

Another eweapon issue. It's only possible to have one dummy/prototype eweapon? I tried to declare two different ones, but the first just took on the properties of the second, like it had been overwritten.

[Saffith]

It should be possible to use more than one. It might be broken; I'll check that out.

[Lejes]

After some searching through ghost.zh's header files trying to fix my dummy eweapon problem, I came across this in eweapon.zh.

    // Give the weapon a unique ID number so it can be found later
    for(int i=Screen->NumEWeapons(); i>0; i--)
    {
        checkWpn=Screen->LoadEWeapon(i);
        if((checkWpn->Misc[__EWI_FLAGS]&__EWFI_DUMMY_CHECK)

==__EWFI_DUMMY_CHECK)
            continue;
        minID=Min(minID, checkWpn->Misc[__EWI_ID]);
    }

The check for whether the weapon is a dummy (and thus the subsequent assignment of a unique ID number) looked off to me, so I changed it to this:

    // Give the weapon a unique ID number so it can be found later
    for(int i=Screen->NumEWeapons(); i>0; i--)
    {
        checkWpn=Screen->LoadEWeapon(i);
        if((checkWpn->Misc[__EWI_FLAGS]&__EWFI_DUMMY_CHECK)!

=__EWFI_DUMMY_CHECK)
            continue;
        minID=Min(minID, checkWpn->Misc[__EWI_ID]);
    }

It seems to have fixed the problem. The two dummy eweapons I have set as death effects now use their own properties, instead of the first being overwritten by the second. I still don't have a clear idea of how ID numbers are assigned, or how the __CopyEWeapon function works, so maybe Saffith or someone else with a better understanding of this header can confirm if this is a bug or not?

[Mero]

you shouldn't edit the header files unless you absolutely are certain you've found the problem.

[Saffith]

Yeah, you got it right. It shouldn't be skipping dummies.