Perhaps you'd all benefit from pausing for a minute to consider not what reflect should do (programmatically), but rather what it should DO (e.g., why we have it.)
I've put some (boring) examples below; my point is that you should seperate reflect into its most BASIC components. For instance: 1. Elemental Immunity -> render damage from element (physical) to zero. 2. Damage Return -> Reverse spells, to a certain %. (Cure on user cures enemy, thunder->all on enemies hit all heroes.) 3. Bounce -> "bounce" a % of the spell back to the hero party (random target). If the hero targeted has "bounce" on him already: a) Strengthen the cast spell (e.g. Fire) b) Weaken the hero's "bounce" shield. c) Bounce to the enemy, repeat. This allows a "barrier" to, say, damage return 10% and bounce 90%. Now we've got something you've never seen in Final Fantasy! -->Seth PS: I used to be suspicious that the OHR was designed to be able to program FF IV (specifically, that is.) Just fun trivia. ;) Appendix A ==examples== For instance, if you want reflect to "compensate for a hero's weakness in one area" then a simple stat boost is fine. If you want reflect to "turn the enemy/hero's power against him" then FF-style reflecting works. If you want reflect to "protect your hero" then Earthbound-style barriers work. I.e., casting reflect on an _already_ reflected hero just strengthens the hero's barrier, which dissipates all (magical) damage. --- [EMAIL PROTECTED] wrote: > http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=441 > > ------- Comment #3 from [EMAIL PROTECTED] > 2007-08-23 14:04 ------- > I think this kind of uncertainty is why these status > effects were never > implemented in the first place. There are a lot of > cases for reflect: > > 1. No Reflect caster -> Reflect enemy > 2. Rf caster -> Rf enemy > 3. Rf caster -> self > 4. Rf caster -> Rf ally (with NR enemy) > 5. Rf caster -> Rf ally (with Rf enemy) > 6. Rf caster -> Rf ally (with no targetable enemy) > 7. NR caster -> Rf ally (with NR enemy) > 8. NR caster -> Rf ally (with Rf enemy) > 9. NR caster -> Rf ally (with no targetable enemy) > > I might be missing some still. That's a lot of > cases. What happens in each of > those cases? What's the UI if we're letting the user > decide? This is a > deceptively complicated feature :( > > > -- > Configure bugmail: > http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching > the assignee. > > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
