20 replies to this topic

[Timelord]

Being unsure if this belongs in Scripting Discussion, or in Script requests, as it as it is both, I have filed it here for the present. If a mod believes it belongs in Scripting Discussion, then please, by all means, move it to the appropriate board.

 

History

II have spent some time trying to make a few very odd (for ZC) weapons, such as replicating the holy water from Castlevania. In the end, i realised that a header that handles all of the requisite functions would be mandatory, as would a few functions to ru  in the main, active while(true) loop.

             I've given some thought, and made some progress with custom weapons, and in the end, I realised that the best way to manage this is via a complete header. What I am seeing is help, ranging from basic hep to full collaborators on a project that I call stdWeapons.zh.

             In simplest terms, this should be for LWeapons, but I think it could also be expanded to cover EWeapons in future models.

 

Premise

stdWeapons.zh is a header designed rto augment the in-built LW functions, adding an array of features, such a movement types, to any normal weapon via scripts that power the weapon/item. it relies on some FFC scripts that I will bundle into it, and stdArguments.zh to allow for the many parameters that this kind of header will require. The goal is to add weapons of any kind, such as weapons that travel in an arc, or penetrating BRang-type weapons to ZC.

 

My Goals for stdWeapons.zh:

Notes in (parenthesis) denote my level of progress and success on a given segment of this project.

 

1. Detect edge of screen; detect Link Direction, and set 'screenEdge' variable in a while active loop based on this every frame. (No real progress, and may slow game down.)

 

2. Custom weapon movement, including arc, circle, and spline. (Lots of work to do here; many problems)

 

3. Custom weapon range:

3(a). Weapon expires at a specified range. (Theory, although I have done some work on it and seen some examples that do something similar.)

3(b). Weapon returns at a specified range.  (No work on this, as yet.)

 

4. Special, custom, new LW_Type set, defined in header. (I believe this should be possible, to set up some basic parameters, such as arcing weapons with the type LW_ARC.)

 

5. Weapon LType changes based on durations in frames. (No progress yet.)

 

6. Custom weapon penetration. (Some work done.)

 

7. Weapon can trigger secrets specific to that weapon. (Done, via FFC scripts.)

 

8. Enemy-based weapon vulnerabilities and defences. (Theory only.)

 

9. Multi-tile weapons: Weapons longer than one-tile, or of larger sizs. (Mostly done; needs debugging.)

 

10. Selective item pick-up; weapon can 'retrieve' items, such as rupees, hearts, keys, etc., and should be based on both the weapon, and items that it can grab (in sets).. (Partially done.)

 

11. Animated weapons. (Ideas thus far have not worked.)

 

12. Secondary item or weapon required in inventory to use a custom weapon. (Partially done)

 

13. Secondary weapon or item loaded into Slot A or Slot B to use custom weapon. (Minor work done.)

 

14. Additional effect for weapon if an item exists in inventory. (Pretty easy, based on my existing scripts.)

 

15. Additional effect tor a weapon if an item is loaded in Slot A or Slot B. (Not done yet, but should be possible with my existing libraries.)

 

16. Ammo Loads: Manual and Automatic (Mostly done: I have auto-loading and manual loading ammo in a demo game, each specific to a single weapon)

 

17. Make ammo only on active subscreen, to save passive subscreen space. (Some work done; should be easy.)

 

18. Weapon Damage Multiplier and Divider.

18(a). Requires a specific inventory item to be true.

18(b). Requires another item loaded on Slot-A or Slot-B.

 

19. Fractional (decimal / float) damage.

 

20. Integrate with stdArguments.zh for options. (Easy)

 

21. Make a set of weapons using the header. (Easy, when the header is done.)

 

22. Make a manual for using everything. (Easy.)

 

23. Make demos to show how to use it all (Easy.)

 

Do I have any takers that would be willing and interested in helping me make this a reality? I will admit that my C knowledge is limited, so I need some talented help, but I think that in the end, this will be a very useful extension for ZC.

 

Please let me know if you are willing and able to contribute in any way. Many thanks!

Edited by ZoriaRPG, 18 December 2013 - 08:23 AM.

[Mero]

This really isn't needed. We already have ghost.zh and simply rewriting the functions to use lweapons and adding ffcScript makes it a lot easier.

[Timelord]

To be honest, that doesn't cover enough ground for what I am trying to do. It does have EW functions, but not LW functions, and even so, it doesn't do much in the way of generalised control of EW types.

 

I hate to be rude, but if you aren't interested, please don't roadblock this, simply because you aren't sure of what I want to do.

 

Rewriting ghost.zh still won;t make LW with arcs, or do a lot of what I intend this to do, and would still be a custom header with a great deal of changes. I have no objection to using components from there, but this is a project that, if people are to be able to easily make specialised games, will be quite handy.

 

Bundling a lot of this into a framework will take a lot of pain out of custom LW creation.

[Mero]

Have you actually read the eweapon header files. Most of what you said can be done easily by changing the eweapon pointers to lweapon pointers. Also It's not that I'm not interested. But rather that it'll cripple frame rates. LWeapons and EWeapons are exactly the same. I've actually consulted Saffith on the matter of why scripted weapons have the same ID. That's cause internally they're the same, only the vector there stored in is different. So your better off using ghost.zh weapon functions as a base. Hell I could help you get some of these things working if you wish. Just let me know. ^_^

 

Oh and It's not at all that it's not needed; I sort of struggle with communication, what I meant to say that I reuse a lot of my code from script to script to make shit easier on my end so I have a lot of stuff already. The future is global functions.

 

19. Fractional (decimal / float) damage.

npc->HP is an int. Not sure if it gets truncated or not though, I can check when I get home.

Edited by Palpaleos, 18 December 2013 - 10:44 AM.

[Timelord]

I do appreciate it, and will take this one step at a time. As I said, I have no qualms about recycling modified code.

 

For the record, as I understand things, everything in ZC is handles as an Int. There are no true floats. An enemy with 10.25 HP really has 1,025HP, and an enemy with 10HP has 1,000HP. FLoats are convrted into ints, which is why my stdArguments,.zh header hekps if you want larger values, as the highest value that you can set in any script attribures is truncated because ZC converts the value into a float with four trailing zeros.

 

I found this out when I tried to set a combo for an FFC effect instead of a tile. Look at the docs on how ZC handles ints and floats and you will see what I mean.

 

I'll be honest, at present my own time is limited, so this is going to take a while. My first goals are to create :LW that move in arvs (defined), splines (defined) and circles (radius defined).

 

The next important thing is for weapons to have a secondary effect when them impact an enemy or object/combo based on four main criteria:

isSolid

isCombo

isSolidCombo

isFlag

 

That is, if a weapon is set to explode with a bomb blast when it hits anything solid, it would act as a bombarrow.

 

Another example is the 'holy water' item from CV: When it hits the ground (isSolidCombo) it breaks and causes an eruption of fire.

 

You could also set it by flag, so that if an item hits a combo with a specific flag, it triggers an event from a predefined list. i can already do that in part with an FFV script, but I think there may be ways to expand on it.

 

Detecting screen edges is beyond me, but very important. My main example for its use is this:

 

A weapon that when fired toward the edge of a screen, on touching the edge, bounces, and returns along its original path. For example, if Link is facing left and fires it, it flies to the left edge of the screen, then bounces, and reverses course to the right edge of the screen, ignoring Link;s current position. (It does not home on him.)

Edited by ZoriaRPG, 19 December 2013 - 02:04 PM.

[Alucard648]

I'll be honest, at present my own time is limited, so this is going to take a while. My first goals are to create :LW that move in arvs (defined), splines (defined) and circles (radius defined).

Bonus points for spiral movement for Lweapons (Holy Bible subweapon in Rondo of Blood). 

[Mero]

For the record, as I understand things, everything in ZC is handles as an Int. There are no true floats. An enemy with 10.25 HP really has 1,025HP, and an enemy with 10HP has 1,000HP. FLoats are convrted into ints, which is why my stdArguments,.zh header hekps if you want larger values, as the highest value that you can set in any script attribures is truncated because ZC converts the value into a float with four trailing zeros.

 

Yeah, the reason for this as you might of guessed Is that floats and integers are not compatible with the other type without type casting which is a pain IMO.

Edited by Palpaleos, 19 December 2013 - 10:24 PM.

[Timelord]

I do know about casting any value type to another, although the term has additional meanings in other languages. TBH, I have only minor C experience, and was at one time used to COBOL, FORTRAN and PASCAL. That is why it takes me a long time to do much of note in ZC, as I am learning a language at the same time as creating ideas that require it, all on a limited temporal budget.

 

@Alucard: I did consider spirals, but the drawing commands aren't really intuitive in this department, and my idea was an orb or something that slowly spiralled outward until it struck isSolid, or hit edgeOfScreenAny, assuming I can figure out how to set those vars.

[Alucard648]

Coming Soon...

[bigjoe]

I think a header for weapon scripting would be very useful. Trying to wing it yourself is no fun, I have so many incomplete things that would have been so much easier to make if I had simple functions in place of grueling calculations.

 

 

Coming Soon...

 

Is that made using stdWeapons.zh? How does it relate?

[Alucard648]

Is that made using stdWeapons.zh? How does it relate?

It`s a weapon created for testing during making that header. The principle is simple: 

 1. Item script runs FFC script with arguments passed in (7 arguments and one for FFC script).

 2. FFC creates lweapon (usually LW_SCRIPT#) and controls it`s movement. 

 3. Lweapon itself handles collision with enemies while FFC handles other effects (like collision with solid combos).

[Timelord]

Nice. Looks a lot like what I was doing, before I had to take a break to avoid going entirely insane.

 

I was trying to make a much more exaggerated arc, to match the CV axe, and I think that the problem that I was having is that if the FFC left the screen, that it would not obey gravity, and return.

 

stdWeapons isn't something I am ready to jump back into making, but I will eventually get around to it. At present, i'm trying to make a Tango extension for menu systems. Not fun. :/

 

Two of the main problems in creating stdWeapons were methods for detecting screen edges, and as no-one with the appropriate experience, or knowledge, wanted to contribute, I let it pass. Without those functions, much of what I wanted to do would't work. Changing LW type mid-stream needs some kind of interaction, and in order to make a weapon that behaves similarly to a boomerang, but not identical to LW_BRANG, you need to detect IsSolid and OnEdge.

 

I still think that a collected weapons header is a fine idea, but the dependency on others is keeping it from happening. The only think that I had thought of doing was to flag all of the screen edges, or to plaster all edges with FFCs, for every screen: Neither would be acceptable in practice. There must be a way to determine if the weapon is on the edge of a screen, and to handle weapon damage globally, in a way that an increase to an attribute adds more damage to specific LW types, or multiplies, or divides, or lessens damage, based on other variables.

 

I could probably put together a basic header in a few days, but it would not have all of the features that I want to see in this project. I do appreciate the reminder though.

Edited by ZoriaRPG, 26 March 2014 - 09:30 AM.

[Alucard648]

I was trying to make a much more exaggerated arc, to match the CV axe, and I think that the problem that I was having is that if the FFC left the screen, that it would not obey gravity, and return.

Lweapons and Eweapons are instantly removed as soon as they touch the edge of the screen.

Two of the main problems in creating stdWeapons were methods for detecting screen edges, and as no-one with the appropriate experience, or knowledge, wanted to contribute, I let it pass. Without those functions, much of what I wanted to do would't work. Changing LW type mid-stream needs some kind of interaction, and in order to make a weapon that behaves similarly to a boomerang, but not identical to LW_BRANG, you need to detect IsSolid and OnEdge.

1. Edges of screen. I have yet to know if going off screen can cause FFC`s script to terminate prematurely. But I have some ideas how to make Lweapon return from offscreen...

2. Wall collisions. Althogh it`s impossible to detect walls preciesly, for small Lweapons (like 16*16 pixels) it maybe feasible to define collision points (8 points: 4 at corners and 4 at center of hitbox edges) and return true if any of the points yield true for Screen->isSolid check.

I still think that a collected weapons header is a fine idea, but the dependency on others is keeping it from happening. The only think that I had thought of doing was to flag all of the screen edges, or to plaster all edges with FFCs, for every screen: Neither would be acceptable in practice. There must be a way to determine if the weapon is on the edge of a screen, and to handle weapon damage globally, in a way that an increase to an attribute adds more damage to specific LW types, or multiplies, or divides, or lessens damage, based on other variables.

Mine problems are:

1. Dynamically updating Lweapon->Dir for proper interaction with shielded enemies like Darknuts. So the Axe can hit Darknut`s head and cause damage to the knightie.

2. Detect what cause Lweapon`s DeadState (usually to WDS_DEAD). Aside flying off screen this may caused by hitting enemy. Is it possible to detect if Lweapon collision actually caused damage to enemy?

I could probably put together a basic header in a few days, but it would not have all of the features that I want to see in this project. I do appreciate the reminder though.

I am also making the header. But I am also making some example weapons for testing it. As soon as I get all examples working properly...  Here is the liat.

 1.Axe (V);

 2.Knife (V);

 3.CrossBoomerang (V);

 4.Holy Water/Molotov Cocktail (V);

 5.Spiraling Holy Book ( );

 6.Ricocheting Diamind ( ).

Edited by Alucard648, 28 March 2014 - 07:45 PM.

[Timelord]

That's pretty much the problem that I was having.... LWeapons ceasing to exist on leaving the screen.

At least you now know why it was taking so bloody long to do this.

I mucked about with deadstates to a decent degree. I found that a boomerang class weapon, that is kept alive, will continue to animate, and make sounds after it leave a screen, but will not be present on other screens. The object itself ceases, but its animation sound continues, and the game still sees it as being 'in use'.

Updating the direction: You will need to check LWeapon direction every frame, and set up a routine to predict the frame number at which it changes direction, and set its direction again; keeping the direction as an int inside your while() loop for the FFC. (With an FFC, that runs in a loop, you will have to set up a routine to change its direction on an inbound journey.) This is a problem, because you can;t exactly predict within the script, how many frames it will take to complete its arc, but you can probably tie this into the X-distance and Y-distance of the FFC, making a pointer to its X/Y point of origin.

That is, when the FFC is generated, set its initial X/Y position as an int, and try to predict at what point in this arc that it will make a return journey, to obey gravity. This will vary, based on gravity settings, so you'd probably need to create an equation with the gravity constants included, if you want to truly automate this.

I would have expected that any weapon, touching a shielded enemy on a non-shielded area would do damage, without concern for the initial direction of the weapon; that it would be based on the hitbox collision areas of the weapon (or FFC) and the enemy, at the instant of collision.

There were too many unanswered questions, regarding use of deadstates, and detection of collisions, for me to do what I wanted to do: You are pretty much running into the same problems that I faced, and I couldn't get any answers on the subjects. I ended up scrapping a lot of it, because it was broken in so many ways, due to not having the information on how the engine works.

One important thing to note, is that if you script the enemies, that you can set up these kinds of collision checks, but for standard enemies and objects, I simply do not know what is, and what is not possible.
I know that you can read Screen->NPCs, and their HP every frame; I do not know how to track if a specific LWeapon hit a specific enemy, unless that enemy is also scripted, and even then, if you have multiple LWeapons on-screen with the same LW_Type, I do not know how to isolate them from one-another.

[Alucard648]

 

Updating the direction: You will need to check LWeapon direction every frame, and set up a routine to predict the frame number at which it changes direction, and set its direction again; keeping the direction as an int inside your while() loop for the FFC. (With an FFC, that runs in a loop, you will have to set up a routine to change its direction on an inbound journey.) This is a problem, because you can;t exactly predict within the script, how many frames it will take to complete its arc, but you can probably tie this into the X-distance and Y-distance of the FFC, making a pointer to its X/Y point of origin.

That is, when the FFC is generated, set its initial X/Y position as an int, and try to predict at what point in this arc that it will make a return journey, to obey gravity. This will vary, based on gravity settings, so you'd probably need to create an equation with the gravity constants included, if you want to truly automate this.

Actually it was even simplier:

// Updates Lweapon direction depending on FFC`s X and Y velocity.
void LweaponDirUpdate( ffc f, lweapon l){
	if ((f->Vx==0)&&(f->Vy==0)) return;
	else l->Dir=RadianAngleDir8(ArcTan(f->Vx, f->Vy));
}

And you can make FFC control Lweapon movements:

// Puts Lweapon at FFC`s position
void LweaponPosUpdate( ffc f, lweapon l){
	l->X= f->X;
	l->Y= f->Y;
}

or even update it`s sprite dynamically;

//Changes Lweapon`s sprite and flip settings depending on it`s direction.
void LweaponSpriteUpdate (lweapon l, int sprite, int altsprite){
	if (l->Dir<4) l->UseSprite(sprite);
	else l->UseSprite(altsprite);
        if (l->Dir==DIR_LEFT) l->Flip=1;
	else if (l->Dir==DIR_RIGHT) l->Flip=0;
	else if (l->Dir==DIR_UP) l->Flip=7;
	else if (l->Dir==DIR_DOWN) l->Flip=4;
	else if (l->Dir==DIR_LEFT) l->Flip=1;
	else if (l->Dir==DIR_RIGHT) l->Flip=0;
	else if (l->Dir==DIR_RIGHTUP)	l->Flip=0;
	else if (l->Dir==DIR_LEFTUP) l->Flip=1;
	else if (l->Dir==DIR_LEFTDOWN) l->Flip=3;
	else if (l->Dir==DIR_RIGHTDOWN) l->Flip=2;
}

And forgot to mention: if you use FFC`s to control Lweapon`s movements, make sure to call this functon right before Quit();

// Clears FFC and prepares it for reusage.
void ClearFFC( 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;
}

Even though lweapons disappear on touching edge of the screen... FFC`s can fly off screen completely.

// Checks if FFC is still within screen boundaries
bool InsideScreen (ffc f){
	if ((!(f->X>=0-f->EffectWidth))||(!(f->Y<=256))) return false;
	if ((!(f->Y>=0-f->EffectHeight))||(!(f->Y<=176))) return false;
	return true;
}

//Returns true if FFC`s hitbox intersects with edge of the screen.
bool OnScreenEdge(ffc f){
	if ((f->X>=0-f->EffectWidth)&&(f->X<=0)){
		if (InsideScreen(f)) return true;
	}
	if ((f->Y>=0-f->EffectHeight)&&(f->Y<=0)){
		if (InsideScreen(f)) return true;
		}
	if ((f->X>=256-f->EffectWidth)&&(f->Y<=256)){
		if (InsideScreen(f)) return true;
		}
	if ((f->Y>=176-f->EffectHeight)&&(f->Y<=176)){
		if (InsideScreen(f)) return true;
		}
	return false;
}

P.S. Currently working on death effects for Lweapons (like explosions or Molotov-styled fire bursts)...

 

EDIT: A new weapon has been invented:

Yes! it`s possible to configure fire splasing radius!

Edited by Alucard648, 28 March 2014 - 07:47 PM.