Sorry for the pedantism, but this really bothers me. Can we stop using "compiler", "compiled", etc. to refer to the process of assembly being converted into machine code? It's a assembly, so it's assembled by an assembler. Compiling has come to refer to higher level languages such as C. FBI, please use the right terminology in the OP at least :(
Now to be helpful so I can't be deleted :x
Quote:
Originally Posted by azurile13
This thread is pretty amazing, especially the compiled versions for those of us who can't compile! Thanks to everyone who has contributed, in particular FBI Agent for obvious reasons.
I have two ideas for fire red that, although I know are longshots, would be very powerful features.
1) Dynamic trainer battle. In case I'm using that word incorrectly, what I mean is that instead of using the trainer table, there is one special slot in the game for which you can call an asm command that fills that slot with trainer information, you battle them like a normal battle, then that information clears out again. Maybe a variable for things like trainer class and AI. The biggest part, of course, would be six variables that the script uses to read off of a giant table of 80 byte each Pokemon. This single feature, along with semi random calls, would be a huge step in building a Battle Tower from the ground floor up. And even a Battle Factory/Battle Dome for anyone who cares.
2) This is even more of a long shot, but I'm curious. How many places does the game read nature, ability, and gender? Currently, all 3 are linked to personality value, making it tricky to alter one without possibly affecting the others. What if that weren't the case? Say we have a Pokemon with personality value [1234][5678].
What if instead of the current system, the game reads the 567 to determine nature. 16x16x16 = 4096. That isn't perfectly divisible by 25, but you could just make 4 of the 5 useless natures like Hardy/Quirky sliiightly less common and I don't think anyone would lose any sleep.
Gender value can range from 0 to 255, so just take two from the personality value and it works out fine.
Finally, abilities. With one or more of the remaining parts of the personality value, you could get rid of the current even/odd determiner, which would allow for third abilities.
Overall, wild and trainer Pokemon would still be just as random, so nothing would be needed to overhaul their random number calls, but it would be significantly easier to customize Pokemon for events and breeding changes.
There are obviously other features to personality value, ranging from things some people care about like shiny pokemon to things almost no one cares about like the dots on Spinda or Wurmple.
Sooo
1) Dynamic trainers
2) Completely reworking how the game reads personalities, gender, and abilities.
Or am I just in fantasy land? :)
|
1) shouldn't be so bad. You'd probably have to modify the trainerbattle command though
2) The "useless" natures round out the pairing. There is a nature for each combination of stats. The useless ones are basically the same stat being increased and decreased. I'm not so sure how changing that would affect balance. Currently, all places in the game that read these values are controlled by a single function call. Changing how it reads the personality value to calculate these things shouldn't be too complex, however, making it not read from the PID would be far more complicated. As for abilities, I did at one point make a hack that allowed a third ability. It just overrode the ability bit - I did meaning changing basically all the battle code however, so it conflicted with a large number of ability hacks.