So as the title says, this topic is for discussing your ideas on how to optimize the games in a way that these ideas could be readily utilized ROM hacks. This could be anything that doesn't really require a massive overhaul or balance change... For example, making it so summon HP% damage values are easier to change is an example of an optimization, but adding a psynergy/magic power stat or increasing the number of characters in the game is not.
Oh, and I guess this topic could also be used for brainstorming possible solutions as well. I may even be able to make a patch or two if it wouldn't take me a long time to do something, but no promises on that.
Idea making Reflect actually work.
Effect can b e like any attack or spell is reflected to enemy.
For 2 turns and big cost of pp of curse.
Adding party member portraits to deeper slot so we can add them to antagonists.
Are the values for the revive formula editable?
If not we might want that. Some Djinni's became useless as it is now.
Can Djinni's be edited? We could make some more balanced Djinni's right?
Quote from: Luna_blade on 02, August, 2014, 02:05:20 AM
Are the values for the revive formula editable?
If not we might want that. Some Djinni's became useless as it is now.
Can Djinni's be edited? We could make some more balanced Djinni's right?
well that's simple in atrius editor there is djinn editor and you can give them abilities sarch for ability and edit it.
If I recall there is something like revive rate change it from 25% to ... don't remember. cheek the editor that's all.
Code optimizations? Perhaps make it so Ability Effect Chances are done via a table rather than a Select Case/switch code statement. (Yes, that's what in-code pointer lists are, from my research.)
Reflect: Funny you should mention that, but that is something I would like to do in the future. The basic idea I have is that it would work a lot like Reflux, but with some formula applied to make the damage reflects a fix fraction of what was dealt to the target. The original plan was to make it so it would still damage the target at full damage before buffs, but now I'm still working out ideas... might be more of a balance thing, really.
Portraits: Yeah, I'm not really sure why they did it that way. I would imagine it to be an easy fix, but I don't know for sure.
Revive: Now this is a rather unique one. I think there are four Revives, not counting enemy-specific abilities and such; 50%, 60%, 80%, and the normal Revive. This latter one just copies your max HP and overwrites your current HP (which has to be 0 first) with it, but the others calculate their amounts differently... The 50% one is especially weird, since it basically erases what it calculates before grabbing your max HP again and dividing it by 2. Well anyway, you can change these values if you can change their formulas, but they only work if your HP is 0 and the healing formula(s) only work if your HP is > 0. Basically, my goal for Disco Sun is to do the following:
Quote- Modify Revive abilities; 50%, 60%, 80%, 100% chance of revival, but the amount of HP they restore will be based on the ability's power/ formula values + 1.
- Requires some modifications to healing formulas code/structure. Life check
will have to come after calculation, but before text. Additionally, another
"write difference to RAM" segment will be required for both formulas.
- Also requires a field effect for the HP% formula.
- Might also make the Revive spell restore 50% HP with a 100% success rate.
Also touches a bit on balance, but it's a copy+pasted excerpt from the notes/readme document.
Although you can alter their success rates quite easily. (http://forum.goldensunhacking.net/index.php?topic=2067.msg41674#msg41674) The base rates are 100% for the normal Revive, and +10% of what the other three heal. So like, the 60% one has a 70% chance of working, 80% has 90%, and 50% has 60%. Still not optimal, but one could easily change these if they want by; that's more of a balance thing though.
Effect Chance Table: You know, it is pretty weird how they did that. Kind of like the summon thing, except that doing it this way actually takes up more space than it did for summons... I might just do it later. Probably not for recovery because those are dependent on character/enemy data in RAM, but I could do success rates. The only thing is that I will also have to account for flat success rates that are not based on luck, and I'll probably remove the option to have >150% luck rates for that. I'm thinking, 0-150 for normal, and 151-251 for flat rates (so for a flat rate of 50%, the calculation would be 201 - 151 and so on).
Edit: Well that took a tiny bit longer than I thought it would, but it's done. The code itself was done after about five minutes, but I had to manually reenter all of the values; that took me about 30. I'll post it in the downloads section shortly.
I'd argue to make revival a full on ability type, with the power being the percentile of HP recovered. For effects, we could have instead, say "10% chance for full revive, 30% chance for revive to 10%". The way I want to do revival djinn is kind of like that:
Take the base revive power for the djinn (for this example, we'll use revive to 40%). Subtract from 100 - so that's a 60% chance to revive a party member to 40% health. These djinn always have a 10% chance to revive to full, and are they only way to get a full revive, period. This leaves us with the remainder - 30%. That's what's left for "revive to 10% health". That way, even when revival djinn miss, they still get the adept up on their feet, and now they have a chance to critically succeed.
Having the ability to manually enter the revive amount also lets us have tiered revives. It'd let us give access to revival early (say, at Knight), and then upgrade to a stronger version later (say, at Lord). With that, we could have this:
Squire -
Knight - Vivify (revive to 35%)
Gallant - Vivify (revive to 35%)
Lord - Revive (revive to 70%)
Slayer - Revive (revive to 70%)
I'd have revival items be rarer and a bit more costly, and have them revive to 50%.
Effect chances I'd love to be able to manipulate, because it'd let us have different magintues of chance. For example, casing an ailment-only spell would have a high chance to succeed, djinn or summon induced ailments and attacks from cursed weapons would have a moderate chance, and ailments from basic unleashes and spells like Toxic Flow would have a low chance to succeed. It'd make things more of a risk vs reward kind of thing.
Also, the ability to better manipulate agility. The original games really didn't utilize that stat well - monsters need to be faster, and agility buffs and debuffs need to be worthwhile.
Quote from: Rolina on 02, August, 2014, 10:38:59 PM
I'd argue to make revival a full on ability type, with the power being the percentile of HP recovered. For effects, we could have instead, say "10% chance for full revive, 30% chance for revive to 10%". The way I want to do revival djinn is kind of like that: (quote shortened)
Sounds like a good plan.
Haha, um, a couple of those points have a tad more to do with game balance than optimization. I'll see what I can explain though;
Revive: Ability type as in formula? If you do that, then you can't apply success rates to reviving unless you also have revival ability effects... One would probably be further ahead to just add "ability effect revives" checks along with the "must be alive" one. Probably:
If HP > 0, heal ("is alive?");
If Revive effect #1 and effect succeeds, heal;
... Etc.
Not sure how to go about checking for effect successes in RAM just yet, but it would certainly be more flexible for hackers to be able to define both healing amounts and revival success rates than just one or the other. Might even be easier to see if there's a RAM check for "target is revived" and try using that.
Effect chances: The patch I just made yesterday lets you edit them pretty easily (with a short guide on how the system works on the download's page), but the easiest way to do that would be to have multiple ability effects that do the same thing (since success rates are tied to the effect IDs, and not to the actual effects themselves in most cases). Kind of like how there are two Seals, really. All you really need to do is play around with pointers to figure out what you want, although some effects have multiple bits of code attached to them (like the HP/PP drains or delude all enemies effects). Might not be the most optimal, but it's definitely easy enough to do if you know how to do it.
Agility: That has very little to do with optimizing the game and much more to do with balance. Plus, that's also assembly editing and should be pretty similar to the other buff effects.
I'd argue that revival should never fail. After all, would you ever use the djinn to revive someone, when an item or spell always succeeds? I certainly never did, unless I was just spending it to summon on the next turn. Revival djinn were generally seen as useless, because they had a chance to fail.
What I did was make a formula that still allows revival on failure - rather than just not reviving, it's just a minimal one. Plus, as they'd have a chance of reviving to full, unlike any spell or item in my system, it'd be a matter of risk vs reward - guarantee a healthy revival, or chance for a perfect one at risk of a minimal instead.
Also, I'd like to suggest variable effect strengths. In vanilla, things like stun and seal have a set base percentage chance. I think it'd be nice if we could have multiple instances of an effect, and either manually put in a base chance, or to be able to set a "Low", "Med", and "Hi" version of the ailments/effects. Personally, I want to raise overall infliction rates and severity, so as to make them not only more of a threat, but more of an option for the player to use in combat. Another example I like is reducing Death Curse from a 7 turn kill to a 3 turn kill. That'd make it a legitimate threat, and worth actually using.
The ability to modify/change what effects do, as well as add new ones, would be nice as well. I'd love to implement Sap/Blight as a PP version of poison, and I'd love to make Delusion a flat 30% reduction to the success of all actions that target foes, not just normal attacks. Things that would give more of a threat to the more useless ailments (Ex: Psy seal seals unleashes too), and thus making the cure of such things something players actually consider for once. As it stands, the only things worth bothering with are Poison, Sleep, and Stun.
Also also, I'd like to suggest a new damage argument - piercing. Most abilities would have this as a 0, meaning no defense is pierced. However, with this argument, we no longer have to rely on the chancy "may pierce xyz" effect, and can make spell families that use defense piercing a their primary schtick.
For example:
Attack +0, pierces 30% defense
Attack +26, pierces 35% defense
Attack +90, pierces 40% defense
This, of course, is just a set of numbers I pulled out of my butt. They shouldn't be used as a guideline for balance, but rather just as an example.
@Agility: Eh, the biggest thing I'd do with agility is to give monsters more of it so that they're an actual threat. I don't think we'd need to tweak it much at all, just apply it well. I could, however, see skills like Sonic Smash being given bonus damage based on agility (Say, Attack +(10% of agility) with a multiplier chance?). Generally, anything with a theme of speed to it could get a bonus, but it shouldn't be too great, especially since the added effects of such skills are typically multipliers and such.
By the way, does anyone know if giving priority status to an unleash will cause the character to move first when it's triggered? I haven't tested that particular thing yet. I could see attacks like Vorpal Slash being priority moves, if possible.
Agility buffs/debuffs need to work properly. That is, if I get hit with a 50% agility nerf, I shouldn't be able to use an Agility buff to immediately bring myself up to 200% of my normal Agility stat. I should end up at 100% Agility instead.
I'd also like if the "Ignores Defense" effect worked with 100% effectiveness on any foe, instead of always working versus some types of enemies and never working versus other types. What decides whether it works on a given foe or not, anyway? I don't think it's the Luck stat, nor does it seem to just be about whether they have a vulnerability set for it or not.
Warning: Long post ahead. Would love it if you give it a full read though, as it took me a while to type.
Revival: Only if it's multi-target, but I may also want to have the odd item that can fail or have some sort of summon/weapon unleash that can also fail. That or a "full revival" spell/item/djinni that can fail while weaker variants always succeed. Either way, I wouldn't necessarily call it an optimization if it's a fundamental change in how the effect works rather than altering it for ease of use and/or better code.
Effects: Totally possible now actually. For example, there are two delusion effects (one of which can work on all enemies) that can be assigned different success rates; this is exactly what they did with Bind vs. Luff. It barely even requires any assembly editing to add more, as all you have to do is change a couple pointers and then change their base rates (which is even easier if you're using the patch for it).
The only problem with this is that, again, the amount of effects you have is limited and you may have to add more if you want to keep all of the old ones. While it would be pretty easy to expand the amount of available effects, there is only a limited amount of room for these in player/unit battle RAM. Multiple of the same ailment would be no problem at all, but you may have to be a bit conservative about adding entirely new ailments to the game.Completely changing or adding new utilities definitely requires some assembly editing, but the amount of editing one would have to do is dependent on what they want to do. For example, tweaking the poison/venom or regenerate formulas would be pretty easy, but some of the other ailments are more complicated than that. To list a few examples;
- I think delusion is specific to one or two action types if I recall correctly, and only to the ones that can miss their target. You may either have to add an accuracy variable to all action types or settle for making it more potent for the ones that already have an accuracy variable.
- Seal only applies to any ability with > 0 PP, with the sole exception being Psy Drain. You could probably get around this by either bumping up the PP counts of more abilities or by adding more exceptions to the base code. I can't say if it would work for unleashes, but it might.
- Sleep/stun prevent all units from acting if they have these ailments, while PCs also can't act with confusion/charm. Enemy actions (and the inability to act) are done along with their AI (including whether their selected moves can target allies or enemies), while for PCs they are... um, can't find it. I know we recorded it at some point, but whatever. Probably the "start round" code or something.
Well anyway. It depends on what you want to do and whether you have the space in unit RAM to do it (keep in mind that there isn't a lot of space). Something like your "sap/siphon" idea probably wouldn't be hard to implement. Poison/venom both share a single byte in unit RAM, and do a basic calculation to deduct a % from HP. You would have to modify the battle formula and field effect, but you could probably change it so it's binary (x0 = clear, x1 = poison, x2 = venom, x4 = sap, x8 = siphon). The graphic might be a bit harder, but I'll talk about that some other time.
I sort of agree on a balance level about changing base success rates themselves, although I took a different approach for Disco Sun and just changed the formulas to make luck have a lesser influence, allowing base rates to stay the same as a result. Definitely more of a balance issue though.
Piercing: I guess. Why not just add a couple "ignore defence" effects with 100% or so success rates? This doesn't really have much to do with optimizing the game or making something easier to do in a hack though, just adding a new feature.
Priority: No idea, but I might look into it sometime.
Agility:
Role: Hard to say. I personally think that most enemies are already pretty decent (aside from their AI maybe), but also that the player characters are poorly balanced. You could probably achieve the agility-based multipliers through ability effects at any rate.
Jamie: Oh yeah, I forgot about that! I think the game might simply write the values to RAM rather than do them in tiers like the other buffs; I guess I can make a patch for that someday now that I think about it.
Ignores defence: Yeah, I think the "ignores 50% of defence" effect also has a 50% success rate. How the vanilla success rate code works is that it grabs effect ID and subtracts by 8. This means that every ability effect that is not between 8-85 will be excluded from the success table and is assumed to have a flat 100% rate (the patch I made recently changes this), but certain effects have different success rates regardless. There is also the following though:
Quote080B06A8 = Return 1 if enemy found in table 080C6B18, else 0. (For Ignore Defense)
080B06C8 = Return 1 if enemy found in table 080C6B76, else 0. (For Trident)
Quote080B075C = Calculate_Ailment_Success(attacker,defender,element,effect,percentMod)
Quote080C6B18 = Enemy list (080B0782:5A; Ignore defense 100%)
080C6B76 = Enemy list (080B0796:5B; Trident 100%)
So these snippets. Every enemy within each list will always be hit by those effects because the effects have a flat 100% in the aforementioned success table, but I assume they will always fail if the enemy is not listed in them because of this alternate calculation code. I can see how these lists would be immensely useful if they were used differently, like a "poison always fails against enemies in this list" sort of deal for bosses and/or unique enemies, but nope. If you really want to disable this and just make it a flat 100%, then it looks like all you would have to do is open the game up in a hex editor and change a single byte or two. Changing 080B0782:5A (address:byte) to 080B0782:00 should do it for the 100% defence one and 080B0796:00 for trident, although you could also change the bytes to correspond to certain ailments, like poison or instant death, and then change the enemies in the lists (keeping in mind that PCs and enemies actually use the same ID system, so you'll have to add 8 to what you see in the editor and convert it to hex notation). Maybe even add a couple new lists... Your call.
Thank you for telling me how to fix the Ignore Defence effect!
Why was it coded that way to begin with? What enemies specifically are supposed to be extra vulnerable to the Cloud Brand's unleash? I presume it, like the Trident, is based on some mythology thing?
Happy to help!
Yep, it's all mythology. If going by editor IDs, we get the following:
Ignore defence;
80-92 (Aqua Hydra line, Serpent, and Avimander line)
135-137 (Wyvern Chick line)
141-143 (Dino line)
168-170 (Sea Dragon line)
177-179 (Wyvern line)
183-185 (Blue Dragon line)
291-293 (Salamander line)
315-317 (Chimera line)
349 (Fusion Dragon)
361-369 (Doom Dragon)
The Cloud Brand is basically a Wyrmslayer.
Trident;
76-82 (Cuttle line, Aqua Jelly line, Aqua Hydra line)
93-95 (Poseidon)
159-173 (Urchin Beast line, Conch Shell line, Merman line, Sea Dragon line, Seabird line)
322-324 (Lizard Man line)
340 (Kraken)
And this is a Merslayer. I can't remember if the Trident effect actually does anything beyond disabling Poseidon's protection, but still.
So yeah. I'm thinking that one could probably modify the code to make certain enemies immune to effects like poison or curse, and remove/alter the 40+ luck requirement for immunity.
@Lord Squirtle: We shouldn't be arguing balance here. The reasoning for my suggestion as Revival as its own type is to allow for the greatest user freedom with making it. If you want it to be Single Target, Multi Target, or have chance to fail, you should be able to customize it the way you want to do it. That's the angle I'm going at here - I've been suggesting things not based on how I'd balance it, but rather what'd be the most useful tool.
If we can increase the number of formula types, that'd be great (ex: Change it from the way it works now, to a two byte check - one byte for the formula type, the other byte for the modifiers and stuff. IIRC, the way it works now is that half of the bite refers to the damage type, the other half to the damage values). This again would give people more freedom to create and use the formulas they want to use, essentially lending much more usability to the tools. Of course, I could be misunderstanding how the formulas work now, it's been a couple years since I last asked about this after all.
@Removing 40+ luck on bosses: THIS. SO MUCH FREAKING THIS. Being able to do that would be a freaking godsend - something I personally want to do is upgrade the hell out of ailments and the like, basically make them worth using. That'll be a huge boon to me, and many others I'd imagine. Combine that with the ability to make new ailments and tweak the ones we've got now (Ex: reducing Death Curse to 3 turn KO instead of 7 turn), and we'd be able to do so much more with how we balance the game.
Hell, I'd love to have abilities with the effects: "Absolute Priority" and "Barrier Reflux" - absolute priority would be able to go off before barriers go up, and barrier reflux will actually invert the barrier for the attack and break it (ex: If the barrier reduces damage by 60%, if hit by this attack it becomes a 60% multiplier, and the barrier is dispelled). This could encourage using certain weapons over others, as well as give us the ability to have some tricky enemy setups that require the player to think about how to overcome them.
Also... the idea of having effects that specifically affect certain enemy types? Freaking. Genius. If we can make it more clear as to how to pull that off, that'll be awesome.
Edit: Thought of something that I really want to have happen. To hell with the text compression! A patch to get rid of that!
To deal with that luck thing:
Change 080B08CA:27 to any other value to pick the highest luck stat one can have before a character gains that immunity. x27 = 39, and the code checks for a luck value higher than that before granting immunity. If you just want to remove the immunity altogether, then you may want to wipe out "27 2B 00 D8" (same address) in a hex editor. The way the code works is that, after checking for luck, it checks every ability effect from 18-82 and grants the immunity for only a few of them. 18/19/26/27/28/34/80/82 if going by editor IDs... Keep in mind that this will apply to the PCs as well.
This should be pretty easy to optimize actually. One could make it so it grabs a value for every effect and compares it to the target's luck, allowing different stages of effect immunity rather than having a flat rate for certain effects. Might do that later.
Revive: Yeah, I think we're confusing each other here. It kind of looked like you were saying that revival effects should not have a chance to fail or something. Would you mind explaining your formula a bit more so I can see what you mean?
Formula total: The positive side is that you can have up to 15 formulas right now, but adding any more would require a bit of an overhaul unfortunately. You would either have to expand the data that makes up each ability or change it so formulas are read elsewhere.
Priority: Not sure how to go about doing that, but it shouldn't be too hard.
Reflux: No idea how to do that honestly. I would imagine a bunch of formulas would have to be changed to allow for that though.
Enemy-specific immunity: Should be easy enough; it could be done the same way as the Cloud Brand/Trident effects, but inverted for "success = 0%" rather than guaranteed to hit.
Text: Well, that depends. Text compression is great for saving space, but there would be little harm in having certain lines be uncompressed. Isn't there already a tool for that floating around somewhere?
This is hardly an "optimization", but...
I'd love to have a patch that makes the "User may drain HP from target" and "User may drain PP from target" effects no longer use the ailment rate formula (with Luck and elemental levels and all that) and just have a flat percentage-based success rate.
That's actually super easy to do either way. Rather than make a patch for it, I'll just tell you what has to be done in order to do this.
Unpatched:
The way the game normally assigns these values is that it follows a pointer for every ability effect between 8-85. It then assigns a value and branches to another area of code; it will decide whether or not to use the formula depending on where the branch goes. To change them without the patch, you'll need to change the following pointers (32-bit):
At #080B0584, "080B067C" (reverse the bytes if reading in 8-bit) should be "080B069C." You need to do the same at #080B0588 for PP drain.
Patched (http://forum.goldensunhacking.net/index.php?action=downloads;sa=view;down=60):
If you're using this patch, then you can assign success rates to virtually any effect (with some unique exceptions here and there that I won't bother talking about right now). Each one is a byte, and depending on the value you use you can use pretty much any rate you want. For normal rates that follow the formula, you can go as high as a base of 150%; for flat rates, you can go up to 100%. To assign a flat success rate to an effect, you have to add 151 to whatever value you want to use and type it in hex. Example:
10/x0A = 10% formula.
100/x64 = 100% formula.
151/x97 = 0% flat.
201/xC9 = 50% flat.
251/xFB = 100% flat.
The way I coded it is that it will use values that are less than 151 in the formula, and subtract that amount from whatever values are read if they are equal to or greater than 151. To change a success rate, you need to convert the effect's editor ID to hex notation and add it to #080B0528 to find the rate you want to change. For HP/PP drain, you have to change the bytes at #080B0547 and #080B0548 to xFB.
Any advice on finding a hex editor that can deal with the ROM's compression? The Editor's Data Browser doesn't seem to support actually saving the changes.
Edit: Never mind. Turns out the April Fool's Day version of the editor is good for something! Thanks a lot for the help!
Edit the second: Is there a table somewhere showing where each of the ability effects is located in the function that assigns effect rates? You know, so I can easily just punch in the address in the "goto" field and then just change the effect rates up. I'd like to mess around with some of 'em.
Edit the third: Also, it would be really cool to have a patch that makes the PP Drain effect cooperate properly with Added Damage and Multiplier attacks. As it is now, if you try to assign one of those effects to a physical attack and the effect triggers, it deals 0 PP damage instead of dealing physical damage to the foe's PP.
Basically, my idea was a flat "Revive to [power]% health". Vanilla would have a power of 100, and djinn effects would be "Has an X% chance to fail". My personal way of doing it? It'd be to 35% tops for first tier, 75% tops for second tier. Djinn would have a 10% chance for full revive, but also a percent chance to revive to only 10% health. Another person may choose instead to do the Dragon Quest thing, where you have a revive to 50% with the effect (50% fail chance), and a larger, more expensive version that's just a flat out revive to full.
But the formula should be easy peasy.
Revive target to [power]% of HP.
@Formula Tool: I'm in favor of the data expansion idea, honestly. Hell, while we're at it the ideas of overhaul patches, throw in more stats. I'd love to have Casting and Warding implemented.
Jamie: That or something like Hex Editor Neo would work, yeah.
Second edit: Sort of. In an unpatched version of the game, each pointer corresponds to an ability effect from 8-85. It's basically "base location + (ID x 4) = pointer" for every effect in that range. Using the patch, every byte from a certain address on corresponds to an ability effect. The table in both cases is at #080B0528!
Third: Huh, that's interesting. Does it work fine for base damage, or does it fail for all HP-damaging formulas? If it's the latter, then the effect could be set up to only account for damage to PP rather than HP; you could benefit from a "restores PP based on HP damage" effect in this case.
Role:
Revive: I guess, but I'd think it would be more worthwhile to just make the amount revival effects heal dependent on what an existing healing formula heals, and then add additional ability effects for whatever else is desired by the hack owner. That way, you don't have to add what is basically a duplicate formula with the distinction of also being an ability effect.
Formula Overhaul: Well... None of this has a lot to do with pure optimization, but I can bite. Expanding abilities like that would require rewriting some of the existing code and relocating the ability data (or reducing the amount of abilities in the game), while not doing that can afford you about four more ability formulas overall; six if you scrap two of the clone values and leave out the HP% or PP% formulas (summon is the same as base damage if I'm not mistaken, and you could probably figure out another way to assign priority and get rid of the other effect only formula).
Stats: Yeah, that's basically one of the examples of what doesn't qualify as optimization in the first post; reason being that it's a major overhaul and it has little to do with streamlining parts of the game for ease of use. I'm sure it could be done with enough work, but something like that could take forever when the game doesn't account for them already. Plus there are already the eStats that seem to do the same thing...
What I meant is "has anyone ever recorded, somewhere on these forums, what ability effect is at what offset to make my life easier if I want to change the effect rates around?"
What the "User may drain PP from target" effect does if used with the Base Damage formula is that, if the effect triggers, the target's PP is damaged instead of their HP, and the user recovers PP equal to the damage dealt. I would really, really like it if it worked the same way for Added Damage or Multiplier formulas.
On the subject of formulas, what I'd like is simply a basic modification to the Editor that makes the four empty formula slots selectable when editing abilities, so they can be used with patches that add formulas. Also, Summon Damage is not the same as Base Damage. The two formulas have differing damage diffusion. Summon Damage effects deal less damage to secondary targets than Base Damage effects do.
As in actual, fully recorded locations? Well, for success rates, it's basically "#080B0528 is effect 8's rate, 080B052C is effect 9's rate, #080B0530 is effect 10's rate, etc." if you're not using the patch. Every pointer in that list corresponds to an effect in numerical order from 8-85. If you are using it, then it's "#080B0528 is effect 0's rate, #080B0529 is effect 1's rate..." and so forth, where every effect is a byte in numerical order.
PP: Huh, that's interesting. It actually seems like a pretty useful ability; I'm afraid that it might be coded into the damage formula, but I can't say for sure. I'll probably look into it later, although I'm working on something else at the moment. Something grand and magical, and partially finished but also partially a pain in the butt. :happy: And also Skyrim.
Formulas: Yeah, I'd love that too. I was actually working on making tiny changes like that at some point, but I'm using a cracked version of the tool and it stopped working with me for some reason. The plan was to do that for formulas, ability types, and ability effects.
Summon: Oh wait, really? Um, is it the same as base damage - diminishing at least?
Oh, here's an idea. Remove the three diffusion types from formulas - Base, Summon, and Diminishing - and instead have those be togglable option. For example, let's say you have an AoE physical attack, but you want it to be more of a "hit with some shrapnel effecting an area". You'd use the physical damage type, a range of 3, with the Diminishing AoE Magnitude.
I think being able to designate magnitudes like you do the AoE size would be great. If we can do that, we'd also free up space for more formulas, and allow for physical attacks to have diminishing AoEs.
@Summons: Summons work just like Base Damage and Diminishing - it's base power, with a stronger center. It's about halfway between Base and Diminishing in magnitude. The only reason it's "more powerful" is because of the HP Percentile damage associated with the specific ability slots. Check the Battle Mechanics FAQ on TLA's Gamefaqs page for more info.
Might be a bit tricky or time consuming if it's applied to all formulas, but I'm sure it could be done at some point. Probably more of an overhaul though. I probably won't be able to do it because my summer break is really short this year and I'm working on another couple patches... One or two of which I'm keeping to myself until after I release Disco Sun's balance update! :happy:
Summons: Yeah, I know. I just forgot that its diminishing rate was different.
Honestly, though, I think the best possible update for the editor right now isn't a patch for the game - rather, we desperately need some better keyboard support. Taking an hour to do one class line is ridiculous, and is arguably what's holding most people back. I'd say fixing that first might be the best course of action right now, since it'd make updating/modifying hacks significantly faster.
Well maybe, but that's optimizing the editor rather than the game. What you're asking for is actually really easy with a hex editor anyway, you just need to know how to use one first; pretty simple to learn if you're willing. Takes me about 10-20 minutes at most for a group of 5-6 classes (make the first, copy+paste until the same class fills each of the line's slots in a hex editor, tweak the rest of the new classes in the editor). Even then though, I never find that it takes me an hour to make a full set of classes...
Okay, so recent ideas for optimization include universal PP damage for PP drain, tiered luck-base immunity for ailments (instead of a flat 40 cap for certain ailments, which would also allow for disabling it by putting each minimum luck requirement at 100+), Revival stuff, Agility buff fix... Are there any others that wouldn't require a major overhaul or anything? The plan is to keep tabs on these and maybe make patches for them in the future if they are simpler fixes.
Right, I happen to have a PP% formula that works a lot like the HP% one; I'll see if I can isolate it from Disco Sun and upload it when I also upload a DS patch, but it will have the same problems as the HP% one (being no editor support and no field use).
For those whom use the editor as it was presented, without going to the more advanced things like Hex Editing, that's about how long it takes to set everything up - and even then, there's no clear way to handle how you want ailment resistances to work.
Hm, simple fixes, huh? Do we have abilities that cost HP yet? I know that was a popular idea.
HP costing abilities, sounds like fun.
I don't know if this existed already, but what about People joining your party?
They're always the same level (example Mia always starts at level 10) as far as I know.
Would it be something if people that join your party are about as high as your average party?
Yeah, having a patch that allows the starting XP for characters be the party average is a great idea. I was so focused on mechanical stuff I forgot about that one. That's another popularly wanted idea.
Make spell like "farewell"
it takes all pp no mater is it 153 pp points or 1 pp...
spell takes all pp and fully revives all allies or fully heals them and user after that dies.
I think that'd need a new formula - one that uses a percentile of current PP rather than a flat value. These would be "manaburn" style spells that scale with the amount of fuel you have to give them. I don't think it's optimization so much as a new option - but a good idea nonetheless.
Hello guys and girls, i'm new to this forum even though i've been following it for a very long time, but this is something i really want to give my 2 cents to. IMHO what we really need is psynergy that becomes stronger as characters level up, and that is stronger for mage-like characters and less for warriors. I think a bonus dependant on max MP would suffice, something like "multiplier=1+(MAXMP/1000)" to all the base damage spells, which are the ones that suffer the most late-game. Also, rising the elemental power power/resist cap to 255 would help, as well as making the 2 draining psynergies useable (not dependant on enemy luck).
Quote from: Caledor on 28, August, 2014, 11:38:44 AM
Hello guys and girls, i'm new to this forum even though i've been following it for a very long time, but this is something i really want to give my 2 cents to. IMHO what we really need is psynergy that becomes stronger as characters level up, and that is stronger for mage-like characters and less for warriors. I think a bonus dependant on max MP would suffice, something like "multiplier=1+(MAXMP/1000)" to all the base damage spells, which are the ones that suffer the most late-game. Also, rising the elemental power power/resist cap to 255 would help, as well as making the 2 draining psynergies useable (not dependant on enemy luck).
Welcome! I like your idea.
Yeah, that's an idea we've had before. I don't remember who first suggested it, though. That would fall under formula editing, which would be a new feature we'd need to implement. I might also suggest having max PP factor into psynergy defense as well, but at half the weight as offense.
There is still someone willing to work at this game that knows this stuff? By myself I only managed to rise the elemental cap to 255 among many other things I implemented in my roms, mostly from ideas found here, like your eight character class system Rolina. ;)
While it doesn't have much to do with optimizing the game, I could offer a tiny suggestion for this PP cost stuff. If you can find the code that handles PP cost deduction (a breakpoint on PP when casting a spell should do it), you could probably code an exception for a certain selection of abilities and use different deduction code; for example, you could pick abilities 300-320 and have them follow a formula that basically goes Cost / 1000 * PP, where "Cost" is a value from 0-1000. The same could be done with HP if one wanted (either with formula or with plain subtraction). I'm a tad tired, but I think that would work. Either that or a list for every ability that decides how the deduction will work. Something like "0 = PP subtraction, 1 = HP subtraction, 2 = PP formula, 3 = HP formula" maybe.
As for this "formula editing feature," what you would probably want to do is download a compiler somewhere and learn how assembly works. It's basically the same as saying "we need a C++ editor" or a "we need a Java editor" and it's not really practical for a basic editor beyond more minor functions. Regardless, adding the "1+(PP/1000)" portion would definitely require you change whichever formulas you want to use max PP for damage calculations.
Also, welcome and enjoy your stay and stuff!
Party Exp average: It depends on how you want to do it, but I imagine a simpler fix would be to change the code from "join at so-and-so level" to "grab so-and-so level and recalculate with party Exp average + current character Exp." If you don't want the base level at all, then you may be able to just average the party experience values and calculate the character level from there... Oh, and you would need some way to check how many characters your party currently has. Going by flags could work; check for existing characters, add their experience values together, and divide by the amount of existing characters you have.
Or you could take a simpler route and just tweak the averaging formula for each character, but this requires that you plan ahead so you know exactly when each character will be acquired and may also take up a little more space. GS1 would basically work like "when Ivan joins, add Isaac + Garet, divide by 2, and calculate level; when Mia joins, add Isaac, Garet, and Ivan, divide by 3, and calculate level." Same deal with GS2, just with slightly different calculations.
Quote from: Lord Squirtle on 29, August, 2014, 09:10:44 PM
As for this "formula editing feature," what you would probably want to do is download a compiler somewhere and learn how assembly works. It's basically the same as saying "we need a C++ editor" or a "we need a Java editor" and it's not really practical for a basic editor beyond more minor functions.
I don't think there is any compiler for ARM/THUMB assembly, would be glad to be proved wrong about that though.
Agree that formula editing would be impractical to do beyond the most basic things, but just being able to change the non-dynamic values used in the current formulas would probably be enough for a lot of people.
I know for sure that there are a few (http://patater.com/gbaguy/gba/ch2.htm) if you're willing to pick one and learn how to use it, but I think there are also a couple floating around on the Pokemon Community somewhere... They are rather hard to find if you don't know what to search for though.
It definitely depends on what one wants to do with a formula, but being able to make some minor changes wouldn't be terribly hard to do depending on what you want it to do. For example, the healing formula (not explained perfectly in the image, but this was a while ago):
(http://i.imgur.com/spF0I0i.png)
It's actually pretty short. If you know;
a) Where unit data is stored,
b) What some of these instructions mean, and
c) How branching works;
Then you could easily figure out what this function does without a guide or any really advanced tools and tweak it to do whatever you want it to do.
It's kind of hard to say how useful this sort of feature would actually be if added to the editor though, especially when certain features (like the class/party separation patch) are awful and you have to rework your hack just to avoid having them screw you over constantly. It winds up being utterly useless if someone changes the formula and the editor reads the wrong instructions; even worse if the editor saves any default info (like that bloody class/party separation patch) and makes using the tool a bigger pain than it's worth after manually changing the ROM yourself. The editor would probably have to be able to understand assembly for the feature to not be broken on some level, although not having it save default information would be a huge step in the right direction (looking at you, class/party separation patch). Definitely more of an editor optimization and may not be suited for this topic, but I can see the appeal for it.
this is very good news. I know basic assembly so i think i can manage to write down the multiplier i mentioned in thumb and i can find where the base damage formula is thanks to teawater's gs2codedatalist; what actually worries me is the space... where can we put the whole thing in the rom?
Probably, yeah. The actual multiplier itself would be fairly short, so I would expect that you could just do an LDR/BX branch to another area of the code and place the multiplier there. As for where to put it, that would depend on whether you want to use anything else for your hack(s) or upload it for public use. If either of these are the case, then I would suggest at least looking at some of the more popular and/or major patches and avoiding the areas that they add code to. Or maybe patching all of those onto a clean ROM and then trying to find space from that point. I might also suggest avoiding the area around #08FB0400 for about x1000 bytes or so, as I'm currently using that for another minor project that I plan on releasing for general use sometime soon (I'd say it is about 50-60% finished right now). Your call though.