On 30 December 2010 05:47, James Paige <[email protected]> wrote: > On Wed, Dec 29, 2010 at 10:55:03PM +1300, Ralph Versteegen wrote: >> I looked down the HeartBug page wanting to tackle something, and more >> elements + the Plan for more flexible elementals seemed like a good >> task. However this plan is very sparse on details, and has never been >> discussed. >> >> http://hamsterrepublic.com/ohrrpgce/Plan_for_more_flexible_elementals.html >> >> I think that 64 elements would be enough that we wouldn't need to >> worry about allowing an unlimited number of elements, which would >> require switching to RELOAD instead of some simple binsize increases. >> But if I were to increase the number of elements to 64, wouldn't I >> want to convert the 8 enemy types into elements at the same time? And >> in that case, I'd want to convert strong/weak/absorb bitsets to >> percentage damage options, and so on. > > I had not worked any on this because I was always thinking of this as a > post-edit-edit feature, but increasing it now doesn't make a later > conversion to unlimited any harder, so I have no problem with it.
Practically every HotOHR request is a post-edit-edit feature if you take that approach... how did you hope to ever get any done?! >> So I've done some research to figure out everything that needs to be >> done if the plan is to be carried out. Some of the implications are a >> bit nasty, so I'm looking for other opinions. >> >> * Strong, weak, and absorb bits be merged into a single percentage >> damage value for each element, for each enemy and hero (for which I >> would use floating point rather than integers; especially when we >> support 32 bit integers for enemy stats you might well want 0.01% >> damage from fire): >> strong -> 12% >> absorb+strong -> -12% >> weak+strong -> 24% >> etc. > > Yes, converting to a combined percentage seems like exactly the right > thing to do. I hadn't thought about doing it with a float, but I like > that idea. > >> * Number of elements increased to 64, where 8 to 15 are mapped from >> enemy types; I would give them the default name "<enemy type>-killer". >> These new element names won't be visible anywhere in old games. >> >> * The 8 "bonus to <enemy type>" attack bits are changed to "does >> <enemy type>-killer damage" and the enemy type enemy bits are changed >> to "takes 180% damage from <enemy type>-killer". > > That sounds just right. > >> * Replace the Strong/Weak/Absorb lines in the status menu to new >> "Takes #% damage from <element>" messages for each element which is >> not at 100%. This is not ideal for non-English-language games, but in >> general we can't always avoid adding new in-game messages. > > Yeah, we have so much non-ideal for non-english already :) > > Of course, we could remap > 100% to the "Weak" message, < 100% to the > "strong" message, < 0% to the absorb message... but that is sooo much > less informative. > >> * The elemental absorb bit overrides cure and harmed by cure bits, so >> we have to emulate that when calculating attack damage. Not too bad. >> >> * The "Fail on <element> resistance" attack bit checks only a target's >> Strong Against bit. Luckily if both strong and weak are set, the >> damage is 24%, less than 100%, so we can switch the "Fail on >> resistance" bit to work by checking that the enemy takes damage >> between 100% and -100% (exclusive). It's weird that greater than 100% >> absorption shouldn't trigger a fail though. Perhaps we could switch >> over to a strictly less than 100% damage check with a general bitset. > > That is good. > And maybe as a /later/ update we can convert these fail on < 100% to > non-bitset data that says Fail if elemental is between x% and y% or > something like that? I like the sound of having the behaviour explicitly stated rather than relying on a general bitset, though I'm not sure what the utility of a range is, other than compatibility. >> * "Fail against <enemy type>" is equivalent to a "Fail on <enemy >> type>-killer weakness" on the attack (fail when damage is greater than >> 100% from the element). Which would mean adding 64 of these bits per >> attack. Well, I guess that it might have some use... > > This seems like it would be a nice compliment to the other fail bitset. > >> * Hero elemental bitsets are tricky, because they in-battle are >> determined by bitwise-OR of the "native" hero strong/weak/absorb bits >> (selected in the hero bits menu) and the bits for all the equipment >> they are wearing. This means that if you take 200% fire damage and >> wear an item set to -12% fire damage, then you absorb 24% fire damage, >> but if you put on another piece of equipment set to any amount of fire >> damage at all, then it makes no difference. >> So after converting the hero and equipment bits to percentage damage >> values, we have to use a nonsensical and complicated formula for >> combining the hero and equipment %damage values into the combined >> values which generalises to all %damage values (it's actually tricky >> to come up with one) yet still reproduces the results of the current >> system.. We should provide several alternative formulas (and we >> definitely want to allow scripts here eventually, as we could never >> hope to cover all the reasonable possibilities). > > Oh, yeah. The current setup here really is crazy. > > I feel like the way elemental equipment bits are combined here was just > me programming by random flailing, without taking the time to think > about the consequences, and how they would relate to what behavior the > user might reasonably expect. > >> I think that the best solution may be to restrict people from using >> any %damage values other than the 8 that you can get from some >> combination of the existing bitsets until you change the "equipment >> elemental damage combination formula" to something other than "Crappy >> bizarre old formula". There are probably no or almost no games which >> rely on its insane behaviour. However that's a bit of hassle to go to. >> >> * Hero bits are also saved in RSAV, so we'll just have to translate >> those back to percentage elemental damage values. Easy enough. >> >> * It's possible to read/write enemy elemental damage bits using the >> read/writenemydata commands, however we provide no wrappers or >> constants to do so, and I can't remember seeing any case of anyone >> doing it themselves. So I think that we can get away with breaking old >> games which do this, on the assumption that they don't exist. I could >> write a utility to scan games on the CP and SS gamelists for use of >> the read/writeenemydata commands, and write some ugly emulation code >> if we find any, but we can delay that. > > I knew those read/write enemy data commands were going to be a pain in > the ass in the future :( > > I wonder if DYWTBAH reads these? > >> * Luckily it's not possible to write/modify attack, item, or hero >> elemental bitsets from scripts. > > Yay! > >> * These days oobcure calls inflict (I wasn't even aware of that), so >> that's a bullet dodged. > > Yeah, I did that one a few months ago :) Excellent, that one terrified me :) But hang on, what's this comment in oobcure about? 'FIXME: populate elemental hits here herobattlebits is called to set the elemental bits on the target, and the attack of course has its elemental bits loaded, so is this comment just obsolete? >> * 64 bitsets is quite a lot, so I think I would move the "<element> >> damage", and "fail vs <element> weakness/resistance" bits out of the >> attack bits menu into a separate submenu. > > I agree. > >> I'm pretty sure that's everything (or at least, that I've considered >> everything but perhaps forgotten to mention it all in this email). All >> other features can be delayed. > > The only other elemental features I can think of are: > > * Elemental spawning > * Elemental counterattacks Ah yes. Spawning and counter attacks are easy because attacks will still only have a bit per element, as they do now. Did you eventually want to switch to percent elemental damage on attacks as well? We can worry about those then ;) > --- > James > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
