645 replies to this topic

[Alucard648]

Sorry for necro-posting this thread, but I found a bug involving cleaning up FFC`s after killing ghosted enemies. The cleaning here is done by just setting FFC`s Data to combo #0. But IMHO, it`s far from enough, if FFC will be reused by other scripts (like summoned ghosted enemies). This may result in graphical glitches or wrong script behaviour, depending on how that script uses FFC. Here is a proper FFC cleanup function:

//Clears FFC and prepares it for being reused. Works best right before calling "Quit()"
void CleanFFC(ffc f){
	f->X=0;
	f->Y=0;
	f->Data=0;
	f->Ax=0;
	f->Ay=0;
	f->TileHeight=1;
	f->TileWidth=1;
	f->EffectHeight=16;
	f->EffectWidth=16;
	f->Vx=0;
	f->Vy=0;
	f->Delay=0;
	f->CSet=0;
	for(int i=0; i<=15; i++){
		f->Misc[i]=0;
	}
}

Edited by Alucard648, 01 August 2014 - 07:53 PM.

[SpacemanDan]

I swear I've asked this before but have been unable to find my post on the matter and can't remember the answer so here we go.

When an eweapon is spawned in with ghost and all its fancy attributes, which eweapon->Misc element(s) are safe to use? From what I've been able to gather with a quick look in ghost.zh, it looks like 0, 1 and 2 are okay but I want to make sure before I do anything with it.

[Saffith]

Yeah, that's right. Assuming the default values of the indices,
non-ghost.zh weapons: 0-14
standard ghost.zh weapons: 0-2
dummy weapons: 0-1

[SpacemanDan]

Awesome, thank you! This'll make things easier. :3

[Timelord]

Out of curiosity, for precisely what are index elements 03, to 24 reserved? Further, is this value different for autoghosst vs, ghost enemies?

 

I'd assume that it's possible to change their use, for customisation of ghost.zh?

 

I haven't yet run into that need, but if  eweapon init functions use these, and you know that you won't need one of these, or will need a special operation in place of one that exists, you could alter it.

 

I also assume that you can create 'ffc weapons' with unique properties, in place of eweapons, should that prove necessary, which may be  in my case. I already know that I'm doing to need to set defence properties on types of armour/protection, that differentiate by ew type, and set up some of this with ffcs that behave/act like eweapons.

 

I thought it'd be brilliant to work out some form of sword melee system, that does more than use enemy shields, by blocking damage with some kind of custom AI, for parrying, and so forth. As my swords are now ffcs, if I design an enemy that uses a similar ffc sword, then i can script ffc/ffc collision for parrying blows.

[Saffith]

Out of curiosity, for precisely what are index elements 03, to 24 reserved?

They've got a lot of stuff to keep track of. Movement, lifespan, and death effect types, arguments to each of those, flags, and counters and position data for some movement types. Dummies need a bit more on top of that.
 

Further, is this value different for autoghosst vs, ghost enemies?

No.
 

I'd assume that it's possible to change their use, for customisation of ghost.zh?

Yep.
 

I haven't yet run into that need, but if  eweapon init functions use these, and you know that you won't need one of these, or will need a special operation in place of one that exists, you could alter it.

Yeah, you could reuse a few of them if you really needed to. You can use the lifespan argument slot if no lifespan is set, say.
 

I thought it'd be brilliant to work out some form of sword melee system, that does more than use enemy shields, by blocking damage with some kind of custom AI, for parrying, and so forth. As my swords are now ffcs, if I design an enemy that uses a similar ffc sword, then i can script ffc/ffc collision for parrying blows.

Possibly. I was thinking of adding some way of making persistent weapons, but it wouldn't involve FFCs. There aren't many available, so I don't want to use more than I have to.
Honestly, I've felt lately that the weapon functions should be in another header entirely, and I'm wondering if I can create it without causing problems. Might be more trouble than it's worth.

[Mero]

I know your pretty much a solo act. but If you ever need assistance with this hit me up in a PM kay man.

[Saffith]

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

[Timelord]

...thiinking of adding some way of making persistent weapons, but it wouldn't involve FFCs. There aren't many available, so I don't want to use more than I have to.
Honestly, I've felt lately that the weapon functions should be in another header entirely, and I'm wondering if I can create it without causing problems. Might be more trouble than it's worth.

 

If not ffcs, how would that work?

 

You  may want to consider combining any such work with the stdWeapons.zh project, to prevent two headers with similar uses.

 

As to not causing problems, anything that we do always pushes ZC to lean on the edge of a knife. In a way, there is a sick, artistic beauty to this sort of thing, as we break ZC into submission.

[coolgamer012345]

I have a question, Has Ghost.zh been updated recently?

[Jamian]

Yesterday, it seems.

[Alucard648]

I can`t wait for ghost.zh to have proper support for ghosting segmented enemies, like Moldorms and Lanmolas. I had a few ideas regarding SkeleDragons for my LsiCV quest series. But had to drop them after reading out, that Ghost.zh does not have segmented enemies support.

[Saffith]

It can be done, it just takes a bit more work. For a skeleton dragon, you'd do something like this:
 

void run(int enemyID)
{
    npc head=Ghost_InitAutoGhost(this, enemyID);
    npc neck[8];
    
    for(int i=0; i<8; i++)
    {
        neck[i]=Screen->CreateNPC(enemyID);
        Ghost_MarkAsInUse(neck[i]);
        neck->OriginalTile=NECK_TILE;
        Ghost_SetAllDefenses(neck[i], NPCDT_IGNORE);
    }
    
    // ...
}

void SDWaitframe(ffc this, npc head, npc neck)
{
    if(!Ghost_Waitframe(this, head, true, false))
    {
        // Dead
        for(int i=0; i<8; i++)
            neck[i]->HP=-1000;
        Quit();
    }
    
    // Flash
    for(int i=0; i<8; i++)
        neck[i]->CSet=this->CSet;
}

[Lejes]

The hard part is getting the segments to move properly in relation to each other. I made a script where the segments follow the next one in line, Moldorm style, but something different like a neck or a whip tail would need a very different approach.

[Timelord]

The hard part is getting the segments to move properly in relation to each other. I made a script where the segments follow the next one in line, Moldorm style, but something different like a neck or a whip tail would need a very different approach.

 

That's essentially what I've told anyone who wants an enemy that has component parts, that are to move in concert, while also having their own movement patterns. The choreographic design becomes exponentially more difficult to initiate, and less apt to prediction, with each such component that you add.

 

Segmented enemies, whether the 'segments' are joined, or simply separate components, usually devolve into a chaotic mess. Even the in-built lanmola-type enemies do thus, due to (what I suspect to be) latency problems, if they have a high segment count, and those segments have a rather straightforward movement. A true lanmola has segments that can move in a variety of patterns, must detect solidity to determine viable directions, and following segments must each respond in kind, in relation to all of the components of the enemy.