20 replies to this topic

[Timelord]

That's pretty brilliant: mate You went from not being able to handle ZScript to working with complex functions in a remarkably short time.

 

You should really post what you have done, to date, on this header, as an Alpha, so that others can start using it; or contributing to it. If you want real filespace, I can make a server account for you. (The RapidShare thing is always such a pain.)

 

I should be able to integrate some of the functions that I did finish at some point, once I see how you set the rest of it up.

 

I'm curious: Did you use floats, and division, to handle the problem with FFC weapons applying damage per frame, or did you find another solution that I handn't considered?

 

Have you done anything that involves reading all the enemies on a screen, and assigning a value to them by (the enemy editor) enemy number, rather than the screen NPC number? One of the things that I was trying before I stopped working on it, was to read the NPCs, determine their enemy editor numbers, and assign those numbers to the slots; then affect them with LWeapons based on their enemy ID. This would simplify special enemy effects, without needing to script custom enemies.

 

For example, all Moblins on a screen, may be especially vulnerable to LW_ARROW, but take 1/2 damage from LW_MAGIC; Gibdo enemies could take damage * 2 from fire; special weapons could instantly destroy enemies of a certain type, on contact, using the different LW_SCRIPT entries, as the enemy editor only has a generic script defence type, instead of a script defence for each LW_SCRIPT number.

 

Having this would also give you half of what you need to create special defence items for Link, against those enemies; or other enemy-specific effects. I am hoping to eventually integrate Lore skills in my game, which for enemies, would give combat advantages (offence and defence) if the player has the correct Lore skills (e.g. Lore: Undead).

Edited by ZoriaRPG, 28 March 2014 - 10:41 PM.

[Alucard648]

That's pretty brilliant: mate You went from not being able to handle ZScript to working with complex functions in a remarkably short time.

Credit goes to BobbyLight. Without his Zscript IDE even otherwise basic compile errors would be a nightmare to track down.

You should really post what you have done, to date, on this header, as an Alpha, so that others can start using it; or contributing to it. If you want real filespace, I can make a server account for you. (The RapidShare thing is always such a pain.)

I should be able to integrate some of the functions that I did finish at some point, once I see how you set the rest of it up.

I would like to have an account on your server if you want. As for updates I will upload header alpha when I got all 6 planned subweapons working properly. Also I need to add comments (document) all functions in header.

I'm curious: Did you use floats, and division, to handle the problem with FFC weapons applying damage per frame, or did you find another solution that I handn't considered?

Have you done anything that involves reading all the enemies on a screen, and assigning a value to them by (the enemy editor) enemy number, rather than the screen NPC number? One of the things that I was trying before I stopped working on it, was to read the NPCs, determine their enemy editor numbers, and assign those numbers to the slots; then affect them with LWeapons based on their enemy ID. This would simplify special enemy effects, without needing to script custom enemies.

It`s simple:
1.Item script takes an unused FFC and launches script with passed in args.
2.After some initialization procedures (including handling ammo counter) the FFC creates Lweapon at his position and assign basic parametres (damage, sprite, etc.).
3.FFC moves according to script commands.
4.Then it calls LweaponUpdate functions to update position, direction, and sprite flipping, if needed. This is implemented as 3 separate functions.
5.If pointer to Lweapon is rendered invalid FFC can refresh pointer by creating another Lweapon with the (usually) same stats.
6.Lweapon itself handles collision detection with enemies and other stuff (like solid combos). PenetratorUpdate function prevents Lweapon from disappearing by hitting enemies.

For example, all Moblins on a screen, may be especially vulnerable to LW_ARROW, but take 1/2 damage from LW_MAGIC; Gibdo enemies could take damage * 2 from fire; special weapons could instantly destroy enemies of a certain type, on contact, using the different LW_SCRIPT entries, as the enemy editor only has a generic script defence type, instead of a script defence for each LW_SCRIPT number.

Special enemy interaction will probably implemented in far future version of stdWeapons header.

Having this would also give you half of what you need to create special defence items for Link, against those enemies; or other enemy-specific effects. I am hoping to eventually integrate Lore skills in my game, which for enemies, would give combat advantages (offence and defence) if the player has the correct Lore skills (e.g. Lore: Undead).

You mean large variety of rings that reduce damage from certain things (eweapons, enemies, hazards...) from Oracle games? It`s a matter of whether the script can catch collision between Link and practicular object before ZC engine resolves outcome (damage, knockback, etc.) if it`s true, the script could give Link a dummy Ring that reduces damage and removing otherwise. If not, it`s impossible .

EDIT:
Holy Bible!

Ricocheting Diamonds!


First alpha version of stdWeapons.zh. Should require only Std.zh and ffcscript.zh.
https://www.mediafir...lpkr8c837c066b6

Updated test quest:
https://www.mediafir...lpkr8c837c066b6

Edited by Alucard648, 29 March 2014 - 06:37 PM.

[Timelord]

I created your account.

[Saffith]

Detecting when a weapon is going off the edge of the screen is difficult if it's actually doing so, but perhaps you could fake it by using hit and draw offsets.
 

// Get movement since the last frame
int dx=wpn->X-32;
int dy=wpn->Y-32;

// Update offsets
wpn->HitXOffset+=dx;
wpn->HitYOffset+=dy;
wpn->DrawXOffset+=dx;
wpn->DrawYOffset+=dy;

// And reset the position
wpn->X=32;
wpn->Y=32;

You'd also have to check for weapon blocking combos manually, but that's not too hard. More importantly, you'd have to make sure there wasn't a blocking combo at the weapon's actual location. Combo cycling and secrets make it practically impossible to guarantee that can't happen, but it can probably be done well enough for realistic purposes.
 

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.

It varies. Numbers you declare yourself are stored as ints 10000 times greater than their apparent values. Built-in floats actually use Allegro's fix type, which is similar. Built-in ints are ints internally, so when npc->HP is 10, the enemy really does have just 10 HP.

[Alucard648]

Detecting when a weapon is going off the edge of the screen is difficult if it's actually doing so, but perhaps you could fake it by using hit and draw offsets.

While debugging CV Cross Boomerang weapon script I have discovered the fact that Lweapons and Eweapons disappear even when thay are 4-6 pixels away from the edge of the screen. Hence therefore nothing would probably make Lweapon appearing on screen edge. The only exception is falling off bottom of the screen in sidevew areas where lweapon itself can actually trigger "OnScreenEdge" function.

You'd also have to check for weapon blocking combos manually, but that's not too hard. More importantly, you'd have to make sure there wasn't a blocking combo at the weapon's actual location. Combo cycling and secrets make it practically impossible to guarantee that can't happen, but it can probably be done well enough for realistic purposes.

Yes. It`s already planned in future versions. But the only slution I am thinking about is to iterate trough all combos on screen  by checking first combo type/flag then collision detection between Lweapon and combo. And all that every frame. This can lead to perfomance issues especially with other heavy global and FFC scripts. But this guarantees proper working even with crazy combo cycling patterns.

[Timelord]

Alucard, were you able to add the server account with the instructions that I sent to you?

 

If so, please upload the files to date, so that I have an easy way to make a collaboration page for it.

 

If you need help using the server, please let me know. I hope that my instructions were easy to follow.