Jump to content

Photo

stdWeapons.zh

library beta

  • Please log in to reply
96 replies to this topic

#1 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 25 October 2015 - 02:23 PM

After a whole year of hiatus and RL issues, I finally finished first beta of stdWeapons.zh, the library for creating and manipulating "ghosted" lweapons, similar to ghost.zh with enemies.

 

stdWeapons.zh

Demo quest. Unpassworded.

 

The setup is similar to ghost.zh. Detailed instructions are inside Readme file packaged with header.

 


  • Demonlink and ywkls like this

#2 ywkls

ywkls

    Master

  • Members

Posted 25 October 2015 - 04:11 PM

I think you may have beat ZoriaRPG to the punch on this, since he was apparently working on something very similar. I don't know what the differences between your code and his are; but since this is available I'm certain that I (and others) will find uses for it, I'm inclined to go ahead and start experimenting with it.. Good job!



#3 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 25 October 2015 - 06:49 PM

I think you may have beat ZoriaRPG to the punch on this, since he was apparently working on something very similar. I don't know what the differences between your code and his are; but since this is available I'm certain that I (and others) will find uses for it, I'm inclined to go ahead and start experimenting with it.. Good job!

 

Not quite, and in fact, I fully support stdWeapons.zh.

 

Phantom.zh is about automation, ala AutoGhost, for weapons.

 

stdWeapons.zh has been a mandatory include with RPG.zh for a long while. It has also been a part of my signature for what... a year and a half? Use it, it's good stuff.

 

Here is a very basic, older example of what I'm doing with Phantom.zh, which is a big project, as I'm essentially recreating many ghost functions for it.

 

Spoiler

 

You may note how this uses item editor properties to set the automated functions. Phantom could be integrated into stdWeapons, or vice versa. It really is a method of automating ffc-based weapons, in the same way that AutoGhost automates ffc-based enemies.

 

The ffc script that it runs, is the item level, -10.


Edited by ZoriaRPG, 26 October 2015 - 03:22 AM.


#4 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 26 October 2015 - 02:10 PM

The ffc script that it runs, is the item level, -10.

I don`t think that item level good enough to serve as slot for script number. It may lead to huge troubles, if you use several items in the same class. I prefer D7 as script slot, as it`s used in stdWeapons.zh.



#5 isilmo

isilmo

    Recipient of Ways

  • Members

Posted 28 October 2015 - 10:18 PM

This is fantastic. Thank you for your hard work!



#6 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 30 October 2015 - 01:49 AM

I don`t think that item level good enough to serve as slot for script number. It may lead to huge troubles, if you use several items in the same class. I prefer D7 as script slot, as it`s used in stdWeapons.zh.

 

TBH, I didn't know that you added automation. That'll save me from working on that, for the most part, and I'll just submit some things for this package.

 

The thing is, with script type items, you have limited options, and you don't usually need to stack/replace them with the level field. I'd make it a setting, and opt for an additional option to use the item editor 'name' field to set the script, as Saffith recently did with Ghost.zh.



#7 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 30 October 2015 - 03:08 AM

The thing is, with script type items, you have limited options, and you don't usually need to stack/replace them with the level field. I'd make it a setting, and opt for an additional option to use the item editor 'name' field to set the script, as Saffith recently did with Ghost.zh.

LsiCV uses stack/replace items with the level field for whip upgrades.



#8 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 27 November 2015 - 04:42 AM

I've read the new materials, for the most part. I'd suggest including a set of melee weapons to replace the hardcoded ZC Link class objects (swords, hammers, hookshots) at some point, as these will be a very hot commodity.

 

I'm going to play with MeleeWeaponSlash180() and MeleeWeaponSlash360() to see what I can make with them, although having some default parameters for this sort of thing would be beneficial. In general, anything that demonstrates sprite set-up for radial motion, and the frames for animation, would be good. These will also be useful, for use on enemies, which you may want to consider as an additional plug-in to the package.

 

(Melee weapons, for enemies.)

 

I'm a bit perplexed by this function: MeleeWeaponEndStrike() '* Performs animation of Link putting weapon back into his pocket and terminates the script'

 

The...what? How precisely, is that animation defined?

 

I also suggested that Evan looks at this, as it might solve some of the issues he has with ZC hardcoded effects. A flag to keep weapons alive on the edge of screens, using OnScreenEdge() and some weapon flags would work well for a problem that he had recently, although I know that he found another way to solve it, involving increasing the hitbox of the lweapon.

void GetLweaponHitboxOffsets(lweapon l, int[] OFFSETS)
* Loads lweapon hitbox offsets into given array. Minimum size of input array is 4 units.

I think you mean:

void GetLweaponHitboxOffsets(lweapon l, int offsets[])
* Loads lweapon hitbox offsets into given array. Minimum size of input array is 4 units.

If SetLweaponHitboxOffsets() stores them in an array, it would be good to note that too. (That function is duplicated in the readme at lines 501, and 507. I'm pretty certain that the one at 501 is the erroneous copy.)

int NumScriptedLweapons (ffc f)
* Returns total number of ffc`s that run the same script as the given one, which is also counted.

I think this would be better suited to return the number of lweapons running any scripts with a misc index marked as running from stdWeapons.zh. Instead of this to return the number of weapons running a specific script, I'd suggest:

int NumScriptedLweapons()
* Returns the number of lweapons running a stdWeapons.zh script, as denoted by their l->Misc[INDEX}.
int NumScriptedLweaponsOf (int ffc_id)
* Returns total number of ffc`s that running a specific script.

The former would be good, to prevent overflowing the number of allowed FFCs. If you aren;t already doing it, storing a value in an index of each lweapon to denote that it is tied to an ffc from this header, would be prudent.

*  *LWF_CAN_PICKUP_ITEMS - If set, lweapon can drag around dropped items.
*
*  *LWF_CAN_INSTA_DELIVER_ITEMS - If set, any dropped item that touched this lweapon will be teleported to
*   Link`s position. Takes priority over LWF_CAN_PICKUP_ITEMS.

These could use some engine priorities, to determine what items the item can retrieve, from lists, or via some kind of item flags.

void Bounce (ffc ball, lweapon l, int sound)
* Makes FFC bounce off solid combos by changing FFC`s velocity depending on lweapon`s position relative
*  to solid combos. Don`t call it too often. Otherwise Lweapon can be stuck in a wall.

What precisely, is 'too often'?

void UseEnemyDefense(lweapon l, int npcid, int defense)

An extension of this, to use a custom set of stored script defs, would be a good addition.

 

[code=auto:0]

void KillRunScript( lweapon l, int d0, int d1, int d2, int d3, int d4,int d5, int d6, int d7, int scriptNum)
* Starts running another FFC script. Removes Lweapon if successful. Uses separate FFC.

[code=auto:0]

 

Did changing the f->Script attribute not work for this? Hmm...I'll need to toy with that. I presume that after launching the next ffc, the cleanup releases the first?


Edited by ZoriaRPG, 27 November 2015 - 04:59 AM.


#9 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 27 November 2015 - 03:42 PM

I'm a bit perplexed by this function: MeleeWeaponEndStrike() '* Performs animation of Link putting weapon back into his pocket and terminates the script'

 

The...what? How precisely, is that animation defined?

If you look closely at Link`s sword stabbing animation, you see Link putting back sword into his inventory at the end of stab. Same thing with wands. The animation uses the same sprite as all other melee weapon animations.

 

I also suggested that Evan looks at this, as it might solve some of the issues he has with ZC hardcoded effects. A flag to keep weapons alive on the edge of screens, using OnScreenEdge() and some weapon flags would work well for a problem that he had recently, although I know that he found another way to solve it, involving increasing the hitbox of the lweapon.

*LWF_MOVE_OFFSCREEN - If set, lweapon can move offscreen without disappearing on screen edges. This is done by altering Draw and Hit coordinate offsets, instead of X and Y values during LweaponWaitframe routine.

Lweapon flag allows this.

void GetLweaponHitboxOffsets(lweapon l, int[] OFFSETS)
* Loads lweapon hitbox offsets into given array. Minimum size of input array is 4 units.

I think you mean:void GetLweaponHitboxOffsets(lweapon l, int offsets[])

* Loads lweapon hitbox offsets into given array. Minimum size of input array is 4 units.

If SetLweaponHitboxOffsets() stores them in an array, it would be good to note that too. (That function is duplicated in the readme at lines 501, and 507. I'm pretty certain that the one at 501 is the erroneous copy.)

Thanks for report. Documentation fixed here in next beta. As for loading hitbox offsets, the function calculates them based on two values in lweapon->Misc array, HitWidth and HitHeight properties, as Hit*Offset vars can be used to control position as workaround for moving offscreen bug. 

 

 

int NumScriptedLweapons()
* Returns the number of lweapons running a stdWeapons.zh script, as denoted by their l->Misc[INDEX}.
int NumScriptedLweaponsOf (int ffc_id)
* Returns total number of ffc`s that running a specific script.
The former would be good, to prevent overflowing the number of allowed FFCs. If you aren;t already doing it, storing a value in an index of each lweapon to denote that it is tied to an ffc from this header, would be prudent.

Done in next beta.

 

 

*  *LWF_CAN_PICKUP_ITEMS - If set, lweapon can drag around dropped items.
*
*  *LWF_CAN_INSTA_DELIVER_ITEMS - If set, any dropped item that touched this lweapon will be teleported to
*   Link`s position. Takes priority over LWF_CAN_PICKUP_ITEMS.
These could use some engine priorities, to determine what items the item can retrieve, from lists, or via some kind of item flags.

By default, the function picks up only items dropped by enemies.

 

 

void Bounce (ffc ball, lweapon l, int sound)
* Makes FFC bounce off solid combos by changing FFC`s velocity depending on lweapon`s position relative
*  to solid combos. Don`t call it too often. Otherwise Lweapon can be stuck in a wall.
What precisely, is 'too often'?

Depends on FFC`s velocity, if used once every frame, lweapon will get stuck in the wall. The Ricocheting Diamond has given me full week of headaches by keeping getting stuck in a wall when it comes to debugging collisions at high speeds. In the current version of subweapons script it`s fixed by implementing "cooldown" between function calls.

 

 

void UseEnemyDefense(lweapon l, int npcid, int defense)
An extension of this, to use a custom set of stored script defs, would be a good addition.

I might consider that, but it needs an extra lweapon->Misc var to backup lweapon`s damage value in case of emulating damage modifier defenses. Same goes for custom defenses that require 512 Int`s array as argument.

 

 

[code=auto:0]
void KillRunScript( lweapon l, int d0, int d1, int d2, int d3, int d4,int d5, int d6, int d7, int scriptNum)
* Starts running another FFC script. Removes Lweapon if successful. Uses separate FFC.
[code=auto:0]

Did changing the f->Script attribute not work for this? Hmm...I'll need to toy with that. I presume that after launching the next ffc, the cleanup releases the first?

if just change script, lweapon will still remain flying, I maybe forgot to include current FFC pointer in function args, but this will be done in the next beta.

-----

Thanks for testing. New beta will be available soon (or not...).



#10 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 27 November 2015 - 06:38 PM

Depends on FFC`s velocity, if used once every frame, lweapon will get stuck in the wall. The Ricocheting Diamond has given me full week of headaches by keeping getting stuck in a wall when it comes to debugging collisions at high speeds. In the current version of subweapons script it`s fixed by implementing "cooldown" between function calls

 

Well, I believe that is because every frame, you are reversing its bounce direction, so it can't move. It probably jitters around one, or a few pixels, or something like that, so aye, you need a few frames of waiting time at least.

 

 


if just change script, lweapon will still remain flying, I maybe forgot to include current FFC pointer in function args, but this will be done in the next beta.

 

This is where storing an ID in the weapon's Misc[] indices to tie it to a script, or ffc ID would help. Once you know the FFC ID, you can search for an lweapon with that ID stored in its index, and kill it.

 

 

Do you think you'll be able to cram an assortment of melee weapons into the next beta too?

 

I was looking over it again, and I'm not sure if there is any specific way to emulate a hookshot with it, at present; although that one is more of as pain than any other type, if you want it to be accurate.


Edited by ZoriaRPG, 27 November 2015 - 06:44 PM.


#11 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 28 November 2015 - 02:21 AM

Well, I believe that is because every frame, you are reversing its bounce direction, so it can't move. It probably jitters around one, or a few pixels, or something like that, so aye, you need a few frames of waiting time at least.

Pretty much like this. 

 

This is where storing an ID in the weapon's Misc[] indices to tie it to a script, or ffc ID would help. Once you know the FFC ID, you can search for an lweapon with that ID stored in its index, and kill it.

Did just like you mentioned, stored FFC number inside lweapon`s parameters and rewritten functions for obtaining item ID and script ID from lweapon`s data.

 

Do you think you'll be able to cram an assortment of melee weapons into the next beta too?

Library download comes with example of custom melee weapons, like hammer, sword, wand and LttP-Styled bow & arrows (bomb arrows in the example). 

 

I was looking over it again, and I'm not sure if there is any specific way to emulate a hookshot with it, at present; although that one is more of as pain than any other type, if you want it to be accurate.

I am hoping, it will be fairly doable to re-script hookshot with stdWeapons.zh.



#12 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 28 November 2015 - 02:49 AM


Library download comes with example of custom melee weapons, like hammer, sword, wand and LttP-Styled bow & arrows (bomb arrows in the example). 

I am hoping, it will be fairly doable to re-script hookshot with stdWeapons.zh.

 

If you want to PM that newer melee / example library to me, I'll start testing it out. The one in the beta (that I downloaded) only has the following:

 

MeleeWeaponTest

LttPBow

BombArrow

LargeLweapon

FireRod

FireRodFlame

 

No hammers, or swords were in there, from what I saw. They are in the demo file, but the scripts for them aren't in the actual dist package...

 

Did you mean that you already updated it, with this new content?

 

Edit: Nevermind: I didn't pay enough attention to what the MeleeWeaponTest and the LargeLweapon ffcs were doing.

 

I'd suggest adding in a weapon speed argument in these functions, for controlling the animation speed (slash/pound). That would be very useful. The present 360-degree spin seems a bit off, in terms of animation speed, or number of frames of animation.

 

P.S. You should integrate the particles.z functions for collisions with weapons, and slash objects. I also noticed that the area of effect, for triggering slash, or pound combos is absolutely huge, so I hope there is a setting to constrain that. I think I rewrote some of your old routines, at some point, to keep the area of effect down to a reasonable size. I also made my own item and combo changing collision things as well, but that's probably not useful, as it would require adaptation.

 

Combo changes still need SFX too. At present, in your demo, they are silent.

 

 

[...]

I'm also going to suggest commands (flags) to add a sparkle trail to any weapon.


Edited by ZoriaRPG, 30 November 2015 - 01:22 AM.


#13 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 30 November 2015 - 02:52 PM

Beta #2!

http://www.mediafire...tdWeaponszh.zip

Changelog inside ReadMe file.



#14 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 01 December 2015 - 08:28 AM

I snagged the latest version, and read the update docs, so I'll try it out.

Did you see my edit above, regarding sparkle trails? They're normally an internal engine effect, and there's no basic method to create them for other scripted weapons, so it might be good to add a function to generate them, and include an ffc for that.

I'd advise including a decently large collection of weapon ffcs, and a demo quest with the Pure tileset, as that is what most people will use in the future. Something to use as a 'starter package', to get people using this.

Here's the main Phantom.zh function, if you want to integrate it (with LastItemUsed() set up, as you require for the header):
 

//Automates running an FFC script from any item, using its D7, or its Level.
void Phantom(){
	int it_scriptA;
	int itm = LastItemUsed();
	itemdata itA = GetEquipmentA();
	if ( ( itA->InitD[7] || itB->Level > 10 ) && Link->PressA ){ 
		int args[8] = {itA->InitD[0],itA->InitD[1],itA->InitD[2],itA->InitD[3],itA->InitD[4],itA->InitD[5],itA->InitD[6],itm};
		if ( itA->Level > 10 ) it_scriptA = itA->Level;
		else it_scriptA = itA->InitD[7];
		RunFFCScript(it_ScriptA,args);
	}
	int it_scriptB;
	itemdata itB = GetEquipmentB();
	if ( ( itB->->InitD[7] || itB->Level > 10 ) && && Link->PressB ){ 
		if ( itB->InitD[7] && Link->PressB ){ 
		int args[8] = {itB->InitD[0],itB->InitD[1],itB->InitD[2],itB->InitD[3],itB->InitD[4],itB->InitD[5],itB->InitD[6],itm};
		if ( itB->Level > 10 ) it_scriptB= itB->Level;
		e;se it_scriptB = itB->InitD[7];
		RunFFCScript(it_ScriptB,args);
	}
}

Edited by ZoriaRPG, 01 December 2015 - 11:55 AM.


#15 ywkls

ywkls

    Master

  • Members

Posted 01 December 2015 - 11:54 AM

After discussing this with ZoriaRPG, I'd like to request an explanation of how to set up lweapons that are blocked by certain combos and trigger certain combos. Or flags that can be set to them so that they handle it on their own. Demonstration scripts would be helpful.
 
I'm creating a scripted boomerang and while my script works, it doesn't seem to handle item pickup even with the example script included in stdWeapons. My script can be found here- Super Boomerang

 

I tried using stdWeapons whenever I first thought of it, but couldn't figure out how to get it to work. So I scripted this from scratch. It works like a normal boomerang, except for item pickup.

 

Discussing it with ZoriaRPG, I don't think either of us was quite certain to set up a similar item using stdWeapons. Any help you could give would be greatly appreciated.


  • Alucard648 likes this



Also tagged with one or more of these keywords: library, beta

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users