Forum Replies Created
-
Posts
-
Atma–
All tactics capable generals already learn their own list… it should not be difficult to have the game pull from each officer's own list during battle. However…
As TP remaining is only stored in one place in memory, it would be difficult to implement each officer pulling from their own TP pool.
Having each officer use their own tactics seems to be a better idea, especially when we implement a minimum Int value for using tactics, instead of the stock DoaE's condition of Int > Str. If I get a spare moment tonight, I'll see how easy it would be to implement separate tactic users. The only hitch I foresee is how the game will accept officers who are too dumb to use tactics.
When all else fails... manipulate the source code.
Hey Sonic,
Sorry about that, should have been more specific. "—-" is just a placeholder. (In the example above, it corresponds to code you shouldn't change at 0x3a1d0.) Don't edit anything there; it was just to make things easier to visualize on the site, to let 2-byte-wide columns of hex code to line up a bit more easy to read.
When all else fails... manipulate the source code.
Quote:Now just need to get it to work for enemies… A scary thought…True… You'll need to allow enemies to even select that tactic, since enemies are restricted from receiving Tui Lu/Gui Huan as picks for their tactics. (In stock DoaE, enemies got to receive Yi Xin, even though by level they could learn one of the other two).
When all else fails... manipulate the source code.
It's totally skipping the name display; it's not reading from that portion of the Status Screen display string. I think a pointer is wonky somewhere.
Found it! The problem is with my reading. I changed the pointer in 0x3edf0… not 0x3ee00, as the guide stated. Boy, hex editing is picky work :roll:
When all else fails... manipulate the source code.
MiDKnighT-
For some reason, when I applied the 8 tactics to my ROM, the general's name disappeared from the status screen, and the list of tactics in the status screen only allows 6 tactics. Could you help me find out what happened?
EDIT: Found the value necessary for making the list 8 tactics long:
0x3b74b: "05" -> "07"
Still searching for how/where the name is getting placed…
When all else fails... manipulate the source code.
You can use an .IPS do patch a 256K rom to a 512K ROM… my thoughts would be to simply create an .IPS using the original DoaE as the source, and then we wouldn't have to worry about overwriting anything (at least, not above 0x40010). Then, any portrait banks that are not wanted could be overwritten with custom stuff.
Oh, and if you create the .IPS this way, I can convert it to a .EXE patch. It would run by clicking the .EXE, and I would set it up to take the original DoaE ROM as source.
Quote:Black out the peach garden oath pic on startup? That pic wouldn't make sense unless you were starting with the usual 3 guys.I'm sorta partial to that pic… but my mod doesn't meaningfully change the storyline, either.
When all else fails... manipulate the source code.
I voted…
And it is possible to allow the 8 extra chapters, if you apply the edits in this order:
1. Agility based extra attacks
2. DoaE2-like Damage
Here's the magic… apply #2 like this:
@ 0x397f2… to 0x3982d (0x3b bytes)
"B9D0 6085 04B9 D160 8503 A8C0 00F0 1F30
08C0 0830 12C0 2030 07A2 27A0 0A4C 1498
A20F A008 4C14 98A2 07A0 074C 1498 A201
A005 8600 4CC7 A1EA 205B C1"
Or, if you'd already applied it, just edit
0x39826: "4cc7a1"
Then, the offending code goes here:
0x3a1d7: "4603 6604 88C0 00D0 F7A5 0418 6500 8515 4C17 98"
3. Then, put 8 extra chapters, since the code in 0x3bff0-0x3c003 is freed up.
Why does it work? Because I moved just enough code with the Agility-based attacks to another code bank in order to make it possible! Not that I was planning to do that, mind you…
When all else fails... manipulate the source code.
Could we include Portrait/Sprite code/and some of your better portrait work in the patch?
When all else fails... manipulate the source code.
Quote:Wonder why he got a 2x attack then unless it doesnt do that for enemies for agility.I do not know. When I used Negate, there were no Agility values to reset…
Quote:What about the castle tactic? I was never even sure it did anything although it was supposed to raise AC somehow?Again, I don't know, but that would be a fun thing to test. Now, from what I remember from Meteorstrike's research into the Castle tactic, it doesn't actually modify AC, but it modifies a separate value… the enemy's defensive fortification value. This is only actually set in gate/fort/castle battles… all but one- when you attack Nan Yang from the west (that gate is supposed to be under construction, according to intelligence gathered :wink: ). When the enemy uses Castle, it increases the fortification value, and if an ally uses it, it decreases the fortification value. I do not know if the enemy can fortify itself if it happens to use the tactic in the field.
Quote:One other thing I was thinking about. Maybe for some more complicated fixes like the 8 tactics stuff or agility fix we should do an ips patch. Or maybe combine a bunch of enhancements into one ips patch bundle.That's a great idea, MiDKnighT! On the subject of the patch bundle… maybe a new post with a poll where people can vote for one/all of their favorite rules modifications?
When all else fails... manipulate the source code.
Quote:So I think I'm officially off that project lol… We'll have to made do with what we have.Totally understand, and agree. That space might still be useful for display purposes (portraits)… or maybe extra strings that we might want to place… or anything that can be calculated straight from temporary memory ($0000-$1fff).
It might be instructional if we were to figure out memory locations within $0000-$1fff that were not used during the game (or used very rarely), because it may be possible to store more permanent data that we need in temporary memory, go to an extended page and play, and then return and store the results from temporary memory back where they should go.
Okay, that might be grasping at straws. Just trying to look at the issue from every angle (or as many as my feeble brain can at 7:30 in the morning :scratch: ) Anyways, I don't think the situation is a total loss.
When all else fails... manipulate the source code.
Thanks! I'm still tweaking it but I'll be done by tonight.
EDIT: Got it! Finally… the successive penalties add up as they should and I'm 99% sure I don't have any outstanding show-stopping branching bugs from moving code around. Yay!
When all else fails... manipulate the source code.
Agility based multi-attacks:
Edits:
@ 0x3a1d2-0x3a1f9:
—- a91c 2082 c400 0000 0000 0000 0000
0000 0000 0000 0000 0000 d006 208d ab4c
5aa1 0000 0000 0000 a678 …..
@ 0x721d0-0x721f9:
0000 0000 0000 004c fbb1 0000 0000 0000
0000 0000 00a9 0e20 82c4 0000 0000 0000
0000 00a9 0e20 82c4 0000
@ 0x73200-0x7320f:
0000 0000 0000 0000 0000 00a9 0b20 82c4
@ 0x73300-0x7330f:
0000 0000 004c e3a1 0000 0000 004c d5a1
@ 0x2f210-0x2f30f (0x100, or 256 bytes)
bdd0 61d0 2aa9 409d d061 980a 0a0a a8b9
0061 c9c7 f010 eaea eaea eaea eaea eaea
eaea c9cb d003 4c9d b2c8 9829 07d0 e0a4
4ab9 b461 8510 a900 8511 bdd0 61a8 c040
f017 8884 12a9 00a0 3cc6 1088 c510 f02d
c000 d0f5 a412 4c3e b2a9 0085 12a5 ad65
ae65 10ea 85ad 290f a8b9 e0b2 8515 205b
c138 a44b b9b4 614c 8ab2 eaea ea4c d7b2
a44a fed0 61a9 004c f8b2 a8a9 00c6 1188
c511 f0e9 c000 d0f5 4c80 b200 00a5 ad65
ae65 1085 ad4c f8b2 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 00ea eaa9 00a4 4a4c f0b2
1926 3340 4c59 6673 8099 a6b3 c0cc e6ff
a91c 2082 c400 0000 a91c 2082 c400 0000
What it does:
1. Keeps the Bow/Crossbow bonus hit… applies this first. This is only valid for allies, as only allies have item packs.
2. After that, Agility is modified by a random percentage from a table @ 0x2f2f0. This is achieved by multiplying by a chosen value, then dividing by 256.
1926 3340 4c59 6673 8099 a6b3 c0cc e6ff
These values correspond to these percentages:
10%, 15%, 20%, 25%, 30%, 35%, 40%, 45%, 50%, 60%, 65%, 70%, 75%, 80%, 90%, 100-%
3. Then, that modified value is compared with the defender's agility.
4. If the defender's Agility is greater, then the turn ends. If not, a new attack is performed…. and the check is done again.
5. Each successive hit renders a cumulative 60 Agility penalty to all checks against the enemy's agility. Therefore, the chance to make another attack becomes nil very quickly… only the very fastest officers ever get a legitimate chance for three hits… and only on slow generals.
6. The Agility-based check is valid for allies as well as enemies hitting you… if you plan on using this modification, Agility will be a very important stat and thought will need to be spent on how you balance out officer's Agility throughout the game.
7. One interesting thing about this implementation… bonus attacks are not always awarded. A 255 Agility officer could hit a 160 Agility officer up to three times (255 – 120 penalty = 135… which would automatically fail that check against 160 Agility. However, because of the random table, it is *much* more likely that they would strike once, or twice.
Possible customization to the algorithm:
1. There are twelve "EA" NOPs in 0x2f226-0x2f231. These are intentionally left in, because that space is perfect for placing up to 3 extra item checks. This is what an item check looks like:
0x2f222 – 0B:B212:
Code:C9 C7– CMP #$C7(Is it an equipped Bow?)
0x2f224 – 0B:B214:
Code:F0 10– BEQ $B226*
*$B226 = $B214 + $#0010 (from statement) + $#0002 (trust me). To create a valid branch, you'll need to take whatever address to which you want to branch (always $B226 here), subtract the address of your branch statement (in this case, that's $B214), and subtract also the length of your branch statement (in 6502 assembly, I believe this value is always 2). That's how I arrived at the "10" at 0x2f225.
2. Obviously, the table for percentages (0x2f2f0-0x2f2ff) is editable.
3. To remove the Random Agility check, and use this edit simply for expanded item checking:
Change 0x2f23f-0x2f241 to "4cd7b2"
0x2f23f – 0B:B22F:
Code:4C D7 B2– JMP $B2D7(what that statement says)
4. To cap the number of extra hits from Agility at one, do this:
Change 0x2f252-0x2f254 to "4cd7b2"
0x2f252 – 0B:B242:
Code:4C D7 B2– JMP $B2D75. To edit the cumulative Agility penalty on successive hits, edit this:
Change 0x2f258 to whatever you want.
0x2f257 – 0B:B247:
Code:A0 3C– LDY $#3c(Default penalty is 60)
Let's review.
1. Any bonus attack for equipment/item possession is applied first. There is a maximum of one item-based attack bonus. After that's out of the way…
2. Attacker Agility is first penalized based on the number of attacks made.
3. Then, it is multiplied by a random value from the table.
4. Then, the result is divided by 256.
5. Finally, this value is compared against the defender's agility.
6. If, after all that, the defender's agility is lower, a new attack is made… and after that attack is completed (and there's still an enemy standing), we'll do this check all over again.
7. With my default setup, it's rarer than it sounds to make extra attacks… unless the defender's Agility is abysmal.
Happy serendipities
In stock DoaE, if you get two attacks (for example, via equipped Crossbow), and manage a critical hit on strike #1, strike #2 is an automatic critical. This has been corrected, at least within successive hits based on Agility. I believe the auto-critical is also corrected if you make a critical on strike #1 with an equipped bow, though this has not been explicitly tested.
Errata
I noticed that after I had used a successful Negate tactic, Pang Tong got a second hit. That was not expected, but not bad. I wonder if this modification will suffer from the same difficulty that the Ambush tactic does… if an officer successfully uses Ambush and uses a Healing tactic the next round, often times he will strike his ally. More testing may be necessary to track this and fix it. However, I have used healing tactics successfully without extra attacks being applied to allies, so I don't think this is too much of a worry.
Also… Jiang Wei just hit that absolute maximum number of non-bow attacks… struck a group of chapter 2 Brigands 5 additional times. (He was repelled once). Of course, he has 255 Agility, and the poor Brigands only had an Agility of 12… poor poor Brigands.
When all else fails... manipulate the source code.
Thanks for looking into it, MiDKnighT. I was afraid it was going to be a brutal difficulty. At the very least, we can use those extra pages as transitory pages, branching into the extra space that may be lurking in pages 00 through 0E… I've done that with the Agility augmentation code that I'm basically ready to post. It's coming… real soon.
When all else fails... manipulate the source code.
As an aside, MiDKnight… are you aware of anything that might be affected by putting code in the space 0x2f210 to 0x2f30f? This is where I'm putting the heavy-lifting for my Agility-based multi-striking code.
I have it written (at least, a first stab), but can't modify my ROM until I get home… I'm at work and all that :wink:
When all else fails... manipulate the source code.
Alternately… why is it storing the Accumulator in $FFF9 between shifts? It seems majorly over-redundant-muchly. Could we commandeer three of those bytes, and Shift as many times as we need (NOP'ing the rest)? That would seem to be the path of least resistance… if it works.
When all else fails... manipulate the source code.
