øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&topic=2219.75e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index3b59-2.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&board=8.80e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index3b59-2.html.zx %h^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ ,/Æ]OKtext/htmlISO-8859-1gzip8:ÖÆ]ÿÿÿÿÿÿÿÿTue, 10 Mar 2020 23:55:16 GMT0ó°° ®0®P®€§²ð® %h^ÿÿÿÿÿÿÿÿŸ9Æ] WIP Patch: Permanent Morph bugfix

« previous next »
Pages: « 1 2 3 4 5 6 7 »

Author Topic: WIP Patch: Permanent Morph bugfix  (Read 8421 times)

Imzogelmo

  • Ogopogo Aficianado
  • *
  • Posts: 241
  • Gender: Male
  • Ask me about my other job.
    • View Profile
    • NEPROMR
Re: WIP Patch: Permanent Morph bugfix
« Reply #75 on: May 12, 2016, 09:49:49 AM »
Now you see why I made that patch allocation document so many years ago. And I love seeing all the philosophical debate going on in this topic. I tend to agree, though, that it would be helpful to have a massive, open, assembly of all the C2 bank at least.

Is there any kind of assembler that can handle the following:

"A kind of meta-data tag, that can optionally include/exclude a block of code, settable in one, easy-to-find location"?

Essentially some kind of flag that toggles blocks of code, but the flag itself does not appear in the final output one way or another.  And it should be possible to have as many such flags as desired (one for each patch or variation of a patch, ideally).

Moving the (upper) C2 bank to another place is relatively easy. There aren't many entry points to the bank, so you just have to be careful to either not move those (placing JMPs as necessary), or modify them on the caller's end.
Logged
5/31/16 - I have an assembly of the battle portion of C2, relocated to the F0 bank, which has both vanilla and patch code in my dropbox. I'll be updating it with additional patches as I have time. I will *not* be releasing it publicly, but ask me for the link and I'll share.

magitek

  • Antlion
  • *
  • Posts: 67
  • Gender: Male
  • Juggler
    • View Profile
Re: WIP Patch: Permanent Morph bugfix
« Reply #76 on: May 12, 2016, 09:50:47 AM »
Quote from: assassin on May 12, 2016, 07:17:12 AM
magitek: are you still considering the C2/4BB2 relaxation version?  iirc, we agreed it was:
- stronger in terms of minimizing the chance of a Morph user with no "fuel" left continuing to receive the status' benefits (e.g. higher Defense).
- weaker in terms of a certain-timed Stop/whatever spell.  (i'm foggy, so see a few of our prior posts for specifics.)

it's understandable if you've put it off, as juggling both at once would be a bitch to code, and make for confusing discussions.  if you've nixed it, also understandable, though i'm curious as to the reason, given i tended to see the approaches as on roughly equal footing.

Yes, I intend to include it as an alternate version. I've just put that on hold because I was under the impression that there were no outstanding issues with it, animation modifications notwithstanding. Actually, I think it's a bit weird to have Revert be able to push through time freezes, unconsciousness, and full-body rigidity due to cryogenics, so I consider it the lesser version (sorry!). :P


Quote from: assassin on May 12, 2016, 06:54:48 AM
so the call is not a problem in the game but rather in a very specific reworking thereof.

Ok, agreed. Just making sure I didn't miss anything.


Quote from: assassin
my follow-up issue regarding the Haste/Slow recalculation requires either:
- adding a "BEQ 0B2C_equivalent" before the "JSR $4792" in C2/0B01, and having a nonzero fallback decrementor.  (initially, i said the 2048 cap, but the $3F30 zeroing means even 1 would suffice here.)
- dropping the C2/0B36 call.

It's not fresh in my mind right now, but I'll look into it when I have more time.

Quote from: assassin
huh?  i was actually challenging my own viewpoint there, by saying: if depleting a whopping 65035 points off the Morph timer isn't meaningful enough (by Square's standards) to update the supply, why should depleting the last mere 500 points -- admittedly a special case -- be enough?

While I intended no offense, calling it a strawman might have been overly aggressive. I just meant that the argument is more of a philosophical nature than a technical one. I understand your point.


Quote from: assassin
i don't always want to wait to see the concrete, instead assuming some might be lurking around the corner, or ready to fall from the sky. ;)

I say we squash that bug when it bites us! :)
Logged
Don't feed the trolls. Use proper grammar, spelling, and punctuation. Eat your vegetables.

assassin

  • Bane of Retards
  • *
  • Posts: 1,033
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: WIP Patch: Permanent Morph bugfix
« Reply #77 on: May 12, 2016, 10:23:37 AM »
Quote
Yes, I intend to include it as an alternate version. I've just put that on hold because I was under the impression that there were no outstanding issues with it, animation modifications notwithstanding. Actually, I think it's a bit weird to have Revert be able to push through time freezes, unconsciousness, and full-body rigidity due to cryogenics, so I consider it the lesser version (sorry!). :P

if an asleep entity can have their Morph timer tick down and thus lose fuel, why is it so weird for their Morph state to also change?  see, i suspect you're thinking of Revert as more of an overt act on the character's part -- perhaps due to its upright, twirly animation -- whereas i see it as just as much a recognition or consequence of simply having no fuel left.  why should the cessation of Morph's benefits be contingent on the character giving their consent in the form of the little Revert jig?  either they have the energy to sustain those benefits, or they don't; it's not their damn call.  Revert as selected from the menu is surely consensual, but the auto-Revert isn't the same beast in concept.

you seemed amenable to my reasoning at one point:
Quote from: magitek
However, you're close to winning me over to your case, Assassin, with the point that, mechanically, it shouldn't be possible to artificially prolong the Morph duration with Sleep or Freeze to reap its protection.

alas, what has happened?  :sad:

in some regards, the flouting from Sleep/Freeze reminds me of a little kid playing peek-a-boo; as long as their eyes are covered, the other person isn't there.  if they can deny reality, they don't have to pay the friggin' piper.  well, babies of the world, newsflash: The Piper calls on all of us, and we must be ready with a toll.  it's an inevitability of life.  rooted in conservation of mass and energy, i believe.

i likely agree with you on the time freeze (i.e. Stop, and other-Quick, if the latter's possible) loophole, but that is kept small by having a check for those two in C2/1211, as you planned.

anyway, glad you're still planning it as an alternate patch.  and yes, the animation change(s) is/are important for the passive (e.g. dozing) Revert.  a shame i probably won't be helpful on those, though i can research with Everything's doc and the C1 disassembly if need be.
« Last Edit: May 12, 2016, 10:34:48 AM by assassin »
Logged

magitek

  • Antlion
  • *
  • Posts: 67
  • Gender: Male
  • Juggler
    • View Profile
Re: WIP Patch: Permanent Morph bugfix
« Reply #78 on: May 12, 2016, 10:29:38 AM »
Quote from: Imzogelmo on May 12, 2016, 09:49:49 AM
Is there any kind of assembler that can handle the following:

"A kind of meta-data tag, that can optionally include/exclude a block of code, settable in one, easy-to-find location"?

Essentially some kind of flag that toggles blocks of code, but the flag itself does not appear in the final output one way or another.  And it should be possible to have as many such flags as desired (one for each patch or variation of a patch, ideally).

I think this might be possible by abusing the xkas define system, not sure. Defines can include other defines, and even whole functions.
Logged
Don't feed the trolls. Use proper grammar, spelling, and punctuation. Eat your vegetables.

magitek

  • Antlion
  • *
  • Posts: 67
  • Gender: Male
  • Juggler
    • View Profile
Re: WIP Patch: Permanent Morph bugfix
« Reply #79 on: May 12, 2016, 11:17:49 AM »
Quote from: assassin on May 12, 2016, 10:23:37 AM
if an asleep entity can have their Morph timer tick down and thus lose fuel, why is it so weird for their Morph state to also change?  see, i suspect you're thinking of Revert as more of an overt act on the character's part -- perhaps due to its upright, twirly animation -- whereas i see it as just as much a recognition or consequence of simply having no fuel left.  why should the cessation of Morph's benefits be contingent on the character giving their consent in the form of the little Revert jig?  either they have the energy to sustain those benefits, or they don't; it's not their damn call.  Revert as selected from the menu is surely consensual, but the auto-Revert isn't the same beast in concept.

Yes, we're thinking about it differently. Similar to breathing, I consider the toggle of Terra's magically-maintained esper state to straddle the line between autonomous and conscious action. It's not that she holds her transformed state until she's literally unable to maintain it (similar to holding one's breath until one passes out), it's that she feels that she will be unable to maintain the state much longer and thus initiates her little Sailor Moon-esque transformation sequence. I think the short duration of a mid-battle nap would fit within the "buffer" she allows herself.

Now, as regards to Freeze, it's a bit unclear as to what the state actually is: is it a Petrify-esque cryogenic deep freeze? Or more of a stun due to being in a hypothermic state (seeing as you can still receive damage and healing)? My rationale is that, whether hypothermic or frozen solid, it slows down (or stops) the body's processes and thus slows (or stops) the consumption of Morph juice, too.

You could argue that the "juice" is magical and not physical. Do you really want to get into a discussion on the mind-body problem as it pertains to the mechanics of a video game...? Because I'd be totally up for that. :P

Game mechanics-wise, it is of small concern that she reaps undue benefits. I don't feel it trumps the line of thinking above. However, again, contested topic, thus necessitating the alt-version. There are also the immense compatibility benefits of this tiny change rather than messing with, as you've pointed out, the otherwise pretty solid Morph system.

Quote
i likely agree with you on the time freeze (i.e. Stop, and other-Quick, if the latter's possible) loophole, but that is kept small by having a check for those two in C2/1211, as you planned.

anyway, glad you're still planning it as an alternate patch.  and yes, the animation change(s) is/are important for the passive (e.g. dozing) Revert.  a shame i probably won't be helpful on those, though i can research with Everything's doc and the C1 disassembly if need be.

At some point very soon (it's summer and the weather is fine), I'm going to run out of interest in this topic, so I should compile what we have and release it. I still have to actually make and test the changes to battle endings, so I'm afraid that a possible fix for the avoiding-time freezes issue with the alt-version, and the animation issue, won't make the cut this time around. It's possible I'll make a future revision of this patch in winter. Meanwhile, should you wish to improve on the alt-version, I'll of course accept the contribution and update the patch.

Regarding the more robust way of preventing multiple Reverts being queued, I don't think we should commandeer that bit for this tiny improvement; it seems too useful for other purposes. I have a periodical-MP-regen thing underway that might enjoy the robustness, for example.
« Last Edit: May 12, 2016, 11:23:00 AM by magitek »
Logged
Don't feed the trolls. Use proper grammar, spelling, and punctuation. Eat your vegetables.

assassin

  • Bane of Retards
  • *
  • Posts: 1,033
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: WIP Patch: Permanent Morph bugfix
« Reply #80 on: May 12, 2016, 11:56:05 AM »
Quote from: magitek on May 12, 2016, 11:17:49 AM
Yes, we're thinking about it differently. Similar to breathing, I consider the toggle of Terra's magically-maintained esper state to straddle the line between autonomous and conscious action. It's not that she holds her transformed state until she's literally unable to maintain it (similar to holding one's breath until one passes out), it's that she feels that she will be unable to maintain the state much longer and thus initiates her little Sailor Moon-esque transformation sequence. I think the short duration of a mid-battle nap would fit within the "buffer" she allows herself.

while i can see her awake auto-Revert as akin to opening her mouth and exhaling/inhaling, i also see it as much recognition of the inevitable as it is a choice.  not being willing or able to do that big breath voluntarily doesn't get rid of the inevitable aspect.  and a sleeping person would just take the damned breath without a thought, so i must question your analogy here. ;P

as for the "buffer", it can actually be quite large if Sleep is given late in the Morph countdown.  Sleep auto-expires after 38 seconds per the Algorithms FAQ, and a full supply, post-Phunbaba Morph timer lasts for 64 seconds per your code notes.  so the sometimes "short" buffer can be over half of the oxygen/fuel/pomegranate supply!

now, the exact quantity of seconds doesn't matter much in a more conceptual debate, though it helps to show a sense of the proportions involved in the put-off Reversion.

Quote
Now, as regards to Freeze, it's a bit unclear as to what the state actually is: is it a Petrify-esque cryogenic deep freeze? Or more of a stun due to being in a hypothermic state (seeing as you can still receive damage and healing)? My rationale is that, whether hypothermic or frozen solid, it slows down (or stops) the body's processes and thus slows (or stops) the consumption of Morph juice, too.

i'll agree Freeze is weirder, but will punt on analyzing it for now.  (as you're doing with a possible supplement patch.)  and viewing it as a status that shouldn't lower the Morph juice/timer isn't specifically at odds with the C2/4BB2 relaxation approach, since added C2/1211 checks would make the latter abide -- brief loophole aside -- by Freeze now being under the Stop/other-Quick umbrella.

Quote
You could argue that the "juice" is magical and not physical. Do you really want to get into a discussion on the mind-body problem as it pertains to the mechanics of a video game...? Because I'd be totally up for that. :P

haha.. good punchline there. :)  now we need at least one large, metaphysical post each.  i'll hold off until at least earlier in my day tomorrow, when i have more energy.  been on the computer too long now.

Quote
Game mechanics-wise, it is of small concern that she reaps undue benefits.

i also see it as reasonably small.  as i do the aforementioned time-freeze loophole.  which is why i've put the two approaches on similar footing for most of this thread (not including the first few posts, where i was slow).

Quote
At some point very soon (it's summer and the weather is fine), I'm going to run out of interest in this topic, so I should compile what we have and release it. I still have to actually make and test the changes to battle endings, so I'm afraid that a possible fix for the avoiding-time freezes issue with the alt-version, and the animation issue, won't make the cut this time around. It's possible I'll make a future revision of this patch in winter. Meanwhile, should you wish to improve on the alt-version, I'll of course accept the contribution and update the patch.

our mid-Spring is lapsing into Autumn.  i truly think we might skip Summer entirely.  but still, i hear ya.

simply having a status check in the Revert command code for the alt-patch and using a null animation would be reasonable (imho, at least a little better than sleepwalking), until something more refined can be decided upon and implemented.
« Last Edit: May 12, 2016, 12:01:56 PM by assassin »
Logged

magitek

  • Antlion
  • *
  • Posts: 67
  • Gender: Male
  • Juggler
    • View Profile
Re: WIP Patch: Permanent Morph bugfix
« Reply #81 on: May 12, 2016, 01:46:43 PM »
Quote from: assassin on May 12, 2016, 11:56:05 AM
simply having a status check in the Revert command code for the alt-patch and using a null animation would be reasonable (imho, at least a little better than sleepwalking), until something more refined can be decided upon and implemented.

Thwarting Revert via a check for Stop/other-Quick would mean we'd have to combine the two approaches of relaxation and requeuing, right?
Logged
Don't feed the trolls. Use proper grammar, spelling, and punctuation. Eat your vegetables.

assassin

  • Bane of Retards
  • *
  • Posts: 1,033
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: WIP Patch: Permanent Morph bugfix
« Reply #82 on: May 12, 2016, 02:19:19 PM »
^ i just meant to have Revert use a null animation instead of the usual one if Sleep or Freeze was detected.
Logged

magitek

  • Antlion
  • *
  • Posts: 67
  • Gender: Male
  • Juggler
    • View Profile
Re: WIP Patch: Permanent Morph bugfix
« Reply #83 on: May 13, 2016, 11:43:20 AM »
I didn't notice until now, but it seems that, a week ago, while we were sidetracked by the nuances of the "Haste/Slow affecting the Morph timer" addon, Leet Sketcher pulled the trigger and released a patch, using a modified Revert re-queueing method. It does not include the alternative method of allowing Revert to ignore disabling statuses.

This puts a bit of a damper on my motivation to finish up what we've been working on since and releasing a patch of my own, since it's unnecessary to have competing patches with nearly the same function. However, working on this has consumed me for the past two weeks and it would be quite disappointing to not see this project through to a release of my own. :/

Even so, I've still learnt a lot from this project, and thoroughly enjoyed the discussions we've had in this thread. And there's still the Haste/Slow addon.

All that aside, I've tested his patch and it neatly addresses all the issues raised up until then but two:

1) It doesn't include the fix to stop the Morph gauge from running down if you linger during the end-of-battle messages, although that may have been intentionally left out.

2) It also does not include the fix to update the Morph supply at non-standard battle endings (e.g. Gau Leaping), though I suppose that could be seen as a separate issue since it causes other bugs (i.e. losing items) as well.

Furthermore, while testing, I discovered that being removed from battle via Sneeze or BabaBreath (not running way) now zeroes the Morph supply, which doesn't happen in vanilla.
« Last Edit: May 13, 2016, 03:28:30 PM by magitek »
Logged
Don't feed the trolls. Use proper grammar, spelling, and punctuation. Eat your vegetables.

assassin

  • Bane of Retards
  • *
  • Posts: 1,033
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: WIP Patch: Permanent Morph bugfix
« Reply #84 on: May 13, 2016, 12:26:51 PM »
ah, i actually noticed a handful of days ago, and wrongly assumed you knew.  apologies.

i still think there's merit in making your own patch(es), whether they be standalone, or addendums to his.

Quote
Furthermore, while testing, I discovered that being removed from battle via Sneeze or BabaBreath (not running way) now zeroes the Morph supply, which doesn't happen in vanilla.

this hardly seems intentional.  are you sure it's the supply, and not just the gauge?

i suspect his $3AA0,X test in the start of C2/1211 is intended as a follow-up to running, and might not have Sneeze or BabaBreath in mind, as he doesn't clear $3EE2.  that said, i don't grasp from looking at the code why this would cause the issue you described.  the $3AA0,X test ought to prevent the entity's Morph timer from decreasing on future calls.

did you by any chance (try to) run in this battle as well?
Logged

assassin

  • Bane of Retards
  • *
  • Posts: 1,033
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: WIP Patch: Permanent Morph bugfix
« Reply #85 on: May 13, 2016, 01:14:54 PM »
okay..  because $3EE2 isn't cleared, the end-battle C2/0B36 call from C2/4903 will update the supply again.  so there'll be an extra pro-ration of the supply in there, e.g. if my Morph timer was at 32768 before being Baba'd/Sneezed, i'll wind up with a supply of 1/4 the starting value, instead of 1/2.  but that's not exactly a zeroing.

the above paragraph is untested, and could be wrong.
Logged

magitek

  • Antlion
  • *
  • Posts: 67
  • Gender: Male
  • Juggler
    • View Profile
Re: WIP Patch: Permanent Morph bugfix
« Reply #86 on: May 13, 2016, 02:31:38 PM »
Quote from: assassin on May 13, 2016, 01:14:54 PM
okay..  because $3EE2 isn't cleared, the end-battle C2/0B36 call from C2/4903 will update the supply again.  so there'll be an extra pro-ration of the supply in there, e.g. if my Morph timer was at 32768 before being Baba'd/Sneezed, i'll wind up with a supply of 1/4 the starting value, instead of 1/2.  but that's not exactly a zeroing.

the above paragraph is untested, and could be wrong.


Nope, no running. This issue happened even if Gau ended the battle by Leaping, which suggests it's not caused by the battle ending call to $0B36 C2/0B36.
Also, I didn't actually look at the value in RAM when testing, I just noticed that Morph was unavailable the next battle, indicating that the supply was at least below 16. Now that I trace what's getting written to 7E1CF6 when something Sneezes Terra while Morphed, I see that it gets written to every frame until the end of battle, first a string of garbage values, followed by zeroes.

This issue presents itself with my collated .asm file as well, including when running, but I haven't pinpointed its cause yet.
« Last Edit: May 17, 2016, 08:22:20 AM by magitek »
Logged
Don't feed the trolls. Use proper grammar, spelling, and punctuation. Eat your vegetables.

assassin

  • Bane of Retards
  • *
  • Posts: 1,033
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: WIP Patch: Permanent Morph bugfix
« Reply #87 on: May 13, 2016, 04:05:20 PM »
very strange.. i think because the game waits until after the Sneeze/Baba animation to remove the character from the battlefield, C2/1211 will continue to run and count down during the animation.  but i can't see a problem with that unless the timer happens to run out then, which:
- i'm assuming didn't happen in your tests
- is likely harmless anyway

to be sure: did you start from a clean ROM?
Logged

magitek

  • Antlion
  • *
  • Posts: 67
  • Gender: Male
  • Juggler
    • View Profile
Re: WIP Patch: Permanent Morph bugfix
« Reply #88 on: May 13, 2016, 04:52:23 PM »
Quote from: assassin on May 13, 2016, 04:05:20 PM
very strange.. i think because the game waits until after the Sneeze/Baba animation to remove the character from the battlefield, C2/1211 will continue to run and count down during the animation.  but i can't see a problem with that unless the timer happens to run out then, which:
- i'm assuming didn't happen in your tests
- is likely harmless anyway

to be sure: did you start from a clean ROM?

I'm going to call it for tonight, but yes, definitely a clean ROM. Also, I MAY have spoke too soon on the garbage values, it does look like they are being continually reduced until 0 (at least with my own patch). I edited out all the calls (to update supply) one by one from my patch, starting with the C2/1211 one, but it seems the culprit is the one I make when bit 1 of 3AA0,index is clear, i.e. when Terra has been removed from battle.

To clarify (I also posted the code earlier), my fix calls a routine if the check for battle presence at C2/1143 indicates that Terra is no longer present. This routine clears $3EE2, updates the supply, and skips calling C2/1211, which is perhaps why my patch affects running as well.

I haven't looked closely at Leet's code, but I think he has that presence check duplicated (or moved?) inside C2/1211 instead, but C2/1211 doesn't clear $3EE2, nor does being removed from battle (I think?), causing C2/1211 to keep running until Terra is actually removed. It seems that the culprit in his case is the call to update the supply inside C2/1211. I didn't look closely at his code, but I think he handles zeroing the timer differently in there. Perhaps the cause is that the low byte of the timer isn't cleared and so it empties over and over again, re-updating the supply each time?

Yep, I removed the pre-C2/1211 call (to update supply) from my patch, re-added it into C2/1211 and now Sneeze or running mid-Morph no longer affects the supply. The culprit is the call to update the timer if removed from battle.(edit: wait, what?) Remove it, and let the battle ending code handle updating the supply.

I mean, maybe getting sneezed should update the supply (once, before zeroing the timer), but it no longer "updates" it into oblivion.

NOTE: I'm drunk and have one foot out the door from this project, so any or all of the above may be partially or fully wrong. :P
« Last Edit: May 13, 2016, 04:58:42 PM by magitek »
Logged
Don't feed the trolls. Use proper grammar, spelling, and punctuation. Eat your vegetables.

assassin

  • Bane of Retards
  • *
  • Posts: 1,033
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: WIP Patch: Permanent Morph bugfix
« Reply #89 on: May 13, 2016, 06:38:05 PM »
ah, gotcha..  yeah, every extra call to C2/0B36 reduces the supply by some fraction.  my 5/13/2016 01:14:54 PM CDT post got into this, but i thought there was only one additional call: the end-battle one.  as it turns out, i was too slow to realize the call will happen *every* time C2/1211 branches due to an absent character.  even if the timer was mostly full, e.g. 95%, a mere 10 calls will reduce the supply down to 60% of its original.  and because C2/1211 is called so often, there'll likely be well more than 10 of them.

agreed that clearing $3EE2 upon the character leaving battle would solve the problem, as it'd stop C2/1211 from pointlessly running (and further calling C2/0B36), and the end-battle C2/0B36 execution would harmlessly exit.

running code that updates the supply, zeroes the timer and gauge, and clears $3EE2 makes sense to me.  it could be reached via what's currently "BCC update_and_remove", and should only trigger once.  but space constraints might make any addition to C2/1211 tricky.  maybe a "JSR $0AE7" at the end of Function C2/3966?  i'd need to hear Leet Sketcher's reasoning for currently handling it inside C2/1211 with the "BCC update_and_remove".

man, i'm stone-cold sober, and stared at his code for eons.  so it's weird i missed the repetitive reductions.  that'll teach me just to read, rather than actually APPLY and test the patch. :P
Logged
Pages: « 1 2 3 4 5 6 7 »
« previous next »