This isn't the initial request for this sort of item... There are ice rod item scripts on the forums, but freezing water, and freezing enemies are global components that are usually game-specific. I don't recall any ice magic global functions/libraries that have been released for general use.
I know that Moosh has a brilliant global function for making ice combos, and one for melting ice into water, but I don't know if those are available for anyone to use.
Stunning/freezing enemies isn't really enough of an explanation for a request of this sort, as people can interpret this rather differently: Would you want the effect to be temporary (like stunning with a boomerang), and if so, what enemies would be immune?
(Any LWeapon with a 'Power' of '0' will stun enemies, and the ability of an enemy to block it is based on its 'Level'. Enemies with the flag 'Damaged by )0-Power weapons treat such weapons as if their 'Level' is their 'Power'.)
Else, is the stun duration permanent (as in Z3), or somewhere between these two?
Do you want the stunned enemy to appear frozen with visual effects?
Do you want frozen enemies to be destroyed by a hammer (e.g. shattered)?
Does fire return them to normal, or destroy them? Are fire enemies weak, or immune to ice?
Is hot terrain going to affect the frozen enemy effect?
---
I know that I'm considering all of that for my custom ice magic in LoE., but that's not complete, or in any way ready for release.
With regard to your question, you can use the combo ID in a for loop, to check for collision, unless I've gone totally mental. That's less efficient than using flags, but for a limited number of combos, you can use global functions to convert them without script flags.
Alternatively, you can set up any combo with both a frozen state, and melted state (e.g. water/ice, magma/rock) so that each combo has its frozen state one combo space after its melted state; then use one flag for combos that the player can freeze. That would simplify the global function to something like this:
//Presuming use of stdCombos.zh)
void ComboChange(int Cflag, int Ltype){
for ( int i = 0; i < 176; i++ ){
if ( Screen->ComboF[i] == Cflag ) {
if ( ComboCollision(i, Ltype) ) {
Screen->ComboD[i]++;
}
}
}
}
//Then, call in your main active loop, before Waitdraw():
ComboChange(CF_MELT,LW_ICE);
//The following function should work with any combo flag, or combo type, and LW type.
void ComboChange(int comboTF, int Ltype, bool flagCheck){
for ( int i = 0; i < 176; i++ ){
if ( flag == true && Screen->ComboF[i] == comboTF ) {
if ( ComboCollision(i, Ltype) ) {
Screen->ComboD[i]++;
}
}
if ( flag == false && Screen->ComboT[i] == comboTF ) {
if ( ComboCollision(i, Ltype) ) {
Screen->ComboD[i]++;
}
}
}
}
//Usage:
// For combo flags:
ComboChange(CF_MELT,LW_ICE,true);
//For combo types
ComboChange(CT_WATER,LW_ICE,false);
The following function would accept a specific number of tiles as an argument, and thus, youbcould set up combo pages with solid states, followed by melted states, at specific intervals.
void ComboChange(int Cflag, int Ltype, int numTiles){
for ( int i = 0; i < 176; i++ ){
if ( Screen->ComboF[i] == Cflag ) {
if ( ComboCollision(i, Ltype) ) {
Screen->ComboD[i] += numTiles;
}
}
}
}
You could also do this with tile pages, and use drawtile commands to establish something similar to LTMs for this kind of thing; so you might imagine that an assortment of library functions could be required to make this suitable, and indeed practical, for anyone to use it.
P.S. Untested, and not guaranteed. I would personally add some fancy effects, with FFCs called in the function, and a timer, to freeze ice, or magma, but the above should work on its own. It's what you'd want for combo changing, and you'd also need to add constants for CT_MELT, and LW_ICE.
I'll re-examine how I handled specific combo numbers in the past, when I'm not so terribly busy, and in so much pain. IIRC, Alucard was adding code for that to stdCombos.zh, so I'll need to read his latest version.
The basic method would be something like this:
const int CB_MAGMA_M = 1000; //Assign to values of magma combos.
const int CB_MAGMA_L = 1001;
const int CB_MAGMA_R = 1002;
const int CB_MAGMA_U = 1003;
const int CB_MAGMA_D = 1004;
const int CB_MAGMA_UR = 1005:
const int CB_MAGMA_UL = 1006;
const int CB_MAGMA_LR = 1007;
const int CB_MAGMA_LL = 1008;
//Solid rock combos should immediately follow these combos, in an identical order.
//Thus, the solid crock 'middle combo', if the magma middle combo is ID 1000, should be 1009.
void MagmaChange(int Ltype){
for ( int i = 0; i < 176; i++ ){
if ( Screen->ComboD[i] == CB_MAGMA_M ||
Screen->ComboD[i] == CB_MAGMA_L ||
Screen->ComboD[i] == CB_MAGMA_R ||
Screen->ComboD[i] == CB_MAGMA_U ||
Screen->ComboD[i] == CB_MAGMA_D ||
Screen->ComboD[i] == CB_MAGMA_UR ||
Screen->ComboD[i] == CB_MAGMA_UL ||
Screen->ComboD[i] == CB_MAGMA_LR ||
Screen->ComboD[i] == CB_MAGMA_LL ) {
if ( ComboCollision(i, Ltype) ) {
Screen->ComboD[i] += 9;
}
}
}
}
//Calling this in your main active loop, before Waitdraw():
MagmaChange(LW_ICE);
You can set up constants for the post-freeze combos, and convert the single inclusive or list,into single if/else if statements for each pair. Doing this avoids using CTs, and flags, but requires more set-up; plus, the need to keep combo numbers within numeric range of max int.
Note also that none of these would be permanent, or persistent changes. For that, you'd need to store the locations of changed combos in an array, or in Screen->D, and you'd either need functions t convert frozen combos by reading Screen->D, or array indices before Waitdraw(), or FFCs that work in a similar manner. Global functions that run before Waitdraw() are, naturally a prettier solution.
Screen->Secrets just isn't properly viable for this sort of thing, and making arrays for each screen of this sort is painful.
---
This could also be used for switches/gates, and other puzzles that may only need a single flag. If you only want to freeze water, you can substitute CFlag, with CType (CT_WATER), or something similar. (Custom CTs would be especially useful here.)
P.P.S. You have five script flags, and five script CTs. If you use them wisely, that gives you 25 basic combinations, that you can expand to 125 using dual-flags, and even further using layers. The problem here, becomes micro-management, which in turn, makes this sort of thing less user-friendly.
For a simple (application-specific) solution, you could use CT_MAGMA with CT_WATER (a default), and then use CF_ACTIVE and CF_INACTIVE as self-defined script flags, to set two states for each, and re-use those flags for other CTs, so that you needn't waste script flags.
If I present an ice system for general use, and that's likely going to become part of RPG.zh, as that header is intended to handle elemental magic, then it will need to be something that doesn't easily conflict with other headers, and scripts; and thus doesn't rely overmuch on singular flags.
P.P.P.S. These functions are free for anyone to use, modify, and distribute, per GPL2.
Edited by ZoriaRPG, 15 September 2014 - 11:04 AM.
