Crystal hack: Pokémon Polished Crystal (update 2.2.0)

[FIQ]

That's why I buffed some of the HM moves. Cut is a 60 power Steel attack, Flash and Fly are 100% accurate, Strength is 90 power (matching Surf), and Rock Smash is 75 power (eventually I plan to give it Brick Break's screen-breaking effect). Surf and Waterfall were already good. Whirlpool... still sucks, but you only need it for the Whirl Islands sidequest.

I also decided that I like the idea of making Cut/Whirlpool/Rock Smash permanent, although this will have to wait for 3.0.



Cool, thanks. :) 2.1 will have new areas to explore: I posted a preview of Johto's western sea earlier, and have some ideas for Kanto too.

Why permanently smashed rocks? They don't block anything and making it permanent rids you of encounters (and if you want to backport HGSS features, items)

EDIT: I see that you made some in the upcoming cave. Unless this was for another reason than to prevent allowing access to Ercuteak without dealing with the Sudowoodo, you don't need to bother since you need Surf anyway.

Also, I saw this in your TODO: "Give female trainers better DVs, and use the new unique DVs feature to make certain Pokémon female"
Now you've entertained my curiousity. What unique DVs, HP/SpD? Did you make other changes to the pokémon structure as well?

 

[Rangi]

Why permanently smashed rocks? They don't block anything and making it permanent rids you of encounters (and if you want to backport HGSS features, items)

Basically for consistency. I wasn't planning to add HG/SS's items; it would be a source of more fossils, but I'd rather add more of those as a reward for exploring an expanded Mt. Moon.

Also, I saw this in your TODO: "Give female trainers better DVs, and use the new unique DVs feature to make certain Pokémon female"
Now you've entertained my curiousity. What unique DVs, HP/SpD? Did you make other changes to the pokémon structure as well?

Normally DVs are assigned based on trainer class. I added a table for targeting individual Pokémon, so they can be shiny, or have typed Hidden Power, or so on. Gender is based on DVs in GSC, with female Pokémon having lower Attack, and female trainers were given female DVs. I want to make some of them more competitive, like giving Jasmine's Steelix or Clair's Gyarados better Attack, without just making all NPCs have male Pokémon.

 

[Splash]

Why permanently smashed rocks? They don't block anything and making it permanent rids you of encounters (and if you want to backport HGSS features, items)

It was pointed more on those that block the path

 

[ChrisTheWhiteWolf]

Mr.Rangi
I just started playing your hack and I've gotta say its a blast.
Your touches have certainly changed the game to its best condition.
And this is coming from a guy who has completed the game more times than I could count.

I have just one quest.
Will the upcoming updates(meaning 2. blah blah until patch 3.) break the saves?
Cause it will definetely suck if you are mid game and you have to start all over.

THX again

 

[Deokishisu]

Whirlpool... still sucks, but you only need it for the Whirl Islands sidequest.

I also decided that I like the idea of making Cut/Whirlpool/Rock Smash permanent, although this will have to wait for 3.0.

Whirlpool is also required to get the eighth badge in the Dragon's Den (which was super annoying). I guess Game Freak needed to justify it being a HM for just Whirl Islands/that one item on Route 27.

I second the permanently cut trees/smashed rocks/dispersed whirlpools. I can't tell you how often I needed to pull out a HM slave or overwrite a TM move on my main team to handle Cut or Strength. Strength is nice, but I'll take Body Slam over it anyday.

 

[Rangi]

Will the upcoming updates(meaning 2. blah blah until patch 3.) break the saves?

Possible next releases:

• 2.0.2 would be a minor update, mostly to get bugfixes out. Save-compatible.
• 2.1 would include some open ocean maps and trainers. Save-compatible.
• 3.0 would have new features—probably permanent HMs, a fourth stat screen page, and other stuff—and would not be save-compatible. That would also let me add more new trainers than I otherwise could, since each one takes up an event, and I only set aside so many unused ones.

 

[bynine]

it's only a suggestion, but in a hack i did a while ago i replaced whirlpool with a more generic move called "Still" (as in, cause stillness), a psychic move that raised special attack. because of the nature of the move i was able to give it to a variety of pokemon besides just water types, as well as having it be more of a justifiable moveslot. maybe you could do something similar?

 

[oscariothetrainer]

Just wondering about one thing after you defeat your rival in rocktunnel is that The last time or what?😊

 

[FIQ]

Possible next releases:

• 2.0.2 would be a minor update, mostly to get bugfixes out. Save-compatible.
• 2.1 would include some open ocean maps and trainers. Save-compatible.
• 3.0 would have new features—probably permanent HMs, a fourth stat screen page, and other stuff—and would not be save-compatible. That would also let me add more new trainers than I otherwise could, since each one takes up an event, and I only set aside so many unused ones.

Regarding 4th status screen, I went ahead and added that on a personal polished crystal build ported from TPP:AC and while I managed to get it working fine functionality-wise, I got some pallet issues: http://home.fiq.se/fail.png
Is what I did wrong obvious, or do I simply just suck? : p

Speaking of personal changes, I always disliked how you couldn't see Accuracy in the move description menus, so I did this a few days ago: http://home.fiq.se/clutter.png
Wasn't completely happy with how it looked since it ended up being a bit cluttered, but never figured out a way to make it look better... I tried http://home.fiq.se/lessclutter.png but ended up preferring the cluttered version. Would be nice to show though, so I'd appreciate it if you added a similar feature.
(The numbers are a bit silly, I intended to port the 3gen accuracy mechanics with percentages, I just didn't bother as of yet)

 

[Rangi]

Regarding 4th status screen, I went ahead and added that on a personal polished crystal build ported from TPP:AC and while I managed to get it working fine functionality-wise, I got some pallet issues: http://home.fiq.se/fail.png
Is what I did wrong obvious, or do I simply just suck? : p

Speaking of personal changes, I always disliked how you couldn't see Accuracy in the move description menus, so I did this a few days ago: http://home.fiq.se/clutter.png
Wasn't completely happy with how it looked since it ended up being a bit cluttered, but never figured out a way to make it look better... I tried http://home.fiq.se/lessclutter.png but ended up preferring the cluttered version. Would be nice to show though, so I'd appreciate it if you added a similar feature.
(The numbers are a bit silly, I intended to port the 3gen accuracy mechanics with percentages, I just didn't bother as of yet)

Oh, thank you! The cause of the palette error is not immediately occurring to me. Is your code on GitHub? Maybe try deleting all the code for the actual status info, just have a blank page, if only to narrow down the possible issues.

I wanted to include Accuracy in the stats too, but couldn't think of a good interface either. Maybe one of these?

The possibilities all involve some combination of crowdedness, new terse symbols, and/or abbreviating things.

 

[FIQ]

I think the pallet issue is that the code I added simply wasn't pallet related in any way. I was reading the StatsScreen part of main.asm in tppcrystal251 (it is in its own file in later pokecrystal revisions, and Polished Crystal was forked off at a point where this was the case) and diffed towards the revision of pokecrystal that TPP was forked off to figure out what changes it did to it. Since TPP:AC's github repository lack any kind of history and I have to rely on diffs, it isn't apparent to me where the actual pallet code is -- it certainly doesn't seem to be in StatsScreen.

The commit for the 4th status screen I added is here: https://github.com/FredrIQ/pokecrystal/commit/55c56ed73ef8a56c87e8e3c770b8c0784c2e02e9

-----

For the moves screen, I'm not sure if increasing the size of the PSS text is neccessary -- Physical still wont fit (and Physica looks a bit silly IMO). For the P/A display, IMO it looks better the way you did over my "lessclutter.png" version, but I'm still slightly torn on it compared to "clutter.png" since it isn't obvious that it is related to Power and Accuracy.

What are your opinion on how to fix the numbers, btw? There is basically 2 options: specifically add code to the accuracy display to "convert" the number into a percentage, or make move accuracy be percentage-based and change the hit checks. Changing the accuracy logic simply to fix a display might sound ridiculous, but I honestly think the work is about equal, and the latter would also make it more equal to how it works in later generations.

EDIT: You posted more screenshots after I made this post. I personally think the left one looks the best out of those 3, but I still think it might be a bit too vague.

EDIT2: Maybe restructure the entire move screen interface, get rid of the PP display for all moves, make a 5-line (literally -- similar to the battle move menu) move selector with Cancel as the 5th menu option, heighten the move description window and show PP for single moves. That way, everything should be able to fit just fine without issues, clutter or similar. As a bonus, you could possibly make learning new moves take you to this interface directly, replacing Cancel with the 5th move pending learning, similar to how it works in 3gen.

 

[Rangi]

I think the pallet issue is that the code I added simply wasn't pallet related in any way. I was reading the StatsScreen part of main.asm in tppcrystal251 (it is in its own file in later pokecrystal revisions, and Polished Crystal was forked off at a point where this was the case) and diffed towards the revision of pokecrystal that TPP was forked off to figure out what changes it did to it. Since TPP:AC's github repository lack any kind of history and I have to rely on diffs, it isn't apparent to me where the actual pallet code is -- it certainly doesn't seem to be in StatsScreen.

The commit for the 4th status screen I added is here: https://github.com/FredrIQ/pokecrystal/commit/55c56ed73ef8a56c87e8e3c770b8c0784c2e02e9

-----

For the moves screen, I'm not sure if increasing the size of the PSS text is neccessary -- Physical still wont fit (and Physica looks a bit silly IMO). For the P/A display, IMO it looks better the way you did over my "lessclutter.png" version, but I'm still slightly torn on it compared to "clutter.png" since it isn't obvious that it is related to Power and Accuracy.

What are your opinion on how to fix the numbers, btw? There is basically 2 options: specifically add code to the accuracy display to "convert" the number into a percentage, or make move accuracy be percentage-based and change the hit checks. Changing the accuracy logic simply to fix a display might sound ridiculous, but I honestly think the work is about equal, and the latter would also make it more equal to how it works in later generations.

Oh right, "Physical" is even longer than "Special". Yeah, "Phys/Spcl/Stat" is fine then.

I think the palette issue is related to engine/color.asm;LoadStatsScreenPals. Just needs a fourth entry in predef/cgb.asm;StatsScreenPals and support for loading said entry.

To find code in TPP:AC you can grep for addresses. So given "StatsScreenInit: ; 4dc8a" in polishedcrystal, find "4dc8a". Some code differences are the TPP devs' changes, others are due to refactoring the pokecrystal code, like hiding more stuff inside macros. Glancing at it I see that TPP has separate StatsScreenMain and StatsScreenBattle routines, and it looks like an original change. Do you know why that's the case? Was there an issue with displaying the fourth screen in battle?

I'm pretty sure that converting 0–255 to 0–100 for display is less likely to add bugs than changing how accuracy is stored and calculated throughout the battle code. And would it really be much more work than doing ×100/255 before calling Print? (Okay, so you'd have to store it in two bytes and use the special Multiply and Divide routines. Or use a lookup table, though I don't think that would actually have an advantage.)

Edit:

Maybe restructure the entire move screen interface, get rid of the PP display for all moves, make a 5-line (literally -- similar to the battle move menu) move selector with Cancel as the 5th menu option, heighten the move description window and show PP for single moves. That way, everything should be able to fit just fine without issues, clutter or similar. As a bonus, you could possibly make learning new moves take you to this interface directly, replacing Cancel with the 5th move pending learning, similar to how it works in 3gen.

This is probably the best long-term plan. I'd really like to see moves' properties before overwriting one.

Edit 2:

Lots of possibilities for a full move screen. Here are some mockups:

It would be somewhat complicated to implement. Pressing A normally selects a move to swap it with another, but when learning a move confirms that it should be replaced. And the left/right function to switch Pokémon would be disabled for that too.

 

[FIQ]

Oh right, "Physical" is even longer than "Special". Yeah, "Phys/Spcl/Stat" is fine then.

I think the palette issue is related to engine/color.asm;LoadStatsScreenPals. Just needs a fourth entry in predef/cgb.asm;StatsScreenPals and support for loading said entry.

To find code in TPP:AC you can grep for addresses. So given "StatsScreenInit: ; 4dc8a" in polishedcrystal, find "4dc8a". Some code differences are the TPP devs' changes, others are due to refactoring the pokecrystal code, like hiding more stuff inside macros. Glancing at it I see that TPP has separate StatsScreenMain and StatsScreenBattle routines, and it looks like an original change. Do you know why that's the case? Was there an issue with displaying the fourth screen in battle?

I'm pretty sure that converting 0–255 to 0–100 for display is less likely to add bugs than changing how accuracy is stored and calculated throughout the battle code. And would it really be much more work than doing ×100/255 before calling Print? (Okay, so you'd have to store it in two bytes and use the special Multiply and Divide routines. Or use a lookup table, though I don't think that would actually have an advantage.)

The main issue I see would be potential rounding issues (Things like showing "94" accuracy for when "95" is intended, the worst probably being showing "99" instead of "100". However, I suppose that as long as accuracies are consistently stored so that they round the same way, it would be fine to just add 1 to the result if needed. You'd need to apply minor changes like changing 228-accuracy moves to 227, but I guess it is fine.
The main reason I disliked this approach is that it is inaccurate from what it displays, and figured that it wouldn't really be all that hard to change the hit check algo (Wouldn't it just be a matter of, call BattleRandom until you have a number 0-199, shift right, compare with internal move accuracy? The reason for the shifting is simply to reduce the risk of minor lag from BattleRandom re-rolls, you could just skip this step if the GBC is fast enough to handle 50+ re-rolls at worst without lag).

I honestly didn't understand why TPP:AC had 2 status screens, but I honestly doubt it would be related to the 4th status screen. Possibly to handle some other change(s) they did. Actually, let me test if the 4th status screen works properly in battle...

EDIT: It works just as fine in battle as outside it. Now let's see if I can look into the pallet thing.

 

[Rangi]

The main issue I see would be potential rounding issues (Things like showing "94" accuracy for when "95" is intended, the worst probably being showing "99" instead of "100". However, I suppose that as long as accuracies are consistently stored so that they round the same way, it would be fine to just add 1 to the result if needed. You'd need to apply minor changes like changing 228-accuracy moves to 227, but I guess it is fine.
The main reason I disliked this approach is that it is inaccurate from what it displays, and figured that it wouldn't really be all that hard to change the hit check algo (Wouldn't it just be a matter of, call BattleRandom until you have a number 0-199, shift right, compare with internal move accuracy? The reason for the shifting is simply to reduce the risk of minor lag from BattleRandom re-rolls, you could just skip this step if the GBC is fast enough to handle 50+ re-rolls at worst without lag).

I honestly didn't understand why TPP:AC had 2 status screens, but I honestly doubt it would be related to the 4th status screen. Possibly to handle some other change(s) they did. Actually, let me test if the 4th status screen works properly in battle...

EDIT: It works just as fine in battle as outside it. Now let's see if I can look into the pallet thing.

I'm getting 89 for converting 227, 228, and 229 (which I believe is the internal value used, since the "90 percent" macro expands to "90 * $ff / 100", and Python 90*0xff//100==229), and 90 for 230*100/0xff. Maybe a lookup table would be simpler.

My concern with changing accuracy internally is that it could be used in more than one place in the code, and even if all occurrences of MOVE_ACC get edited, maybe it's being accessed elsewhere without the convenient constant (like by loading MOVE_TYPE and later incrementing hl; that issue is why I stored the Phys/Spcl/Stat category at the end of the data structure, because when I put it right after type I was getting bugs and was too unfamiliar with Z80 to fix them).

 

[FIQ]

OK, so I messed with the pallet code. I got it working properly in a way -- however, this required me to mess with a function I didn't quite understand.
I properly managed to load pallets and fix the cursor fine. However, the page loading colors were still wrong. Due to an accidental typo I had made when I was working on it before (before I committed stuff), I knew a fix -- the issue was that I didn't know why (because, as said, it was accidental) and it was a change TPP:AC never did.
Basically, when I originally introduced the 4th status screen in my personal version of polished crystal, I misread the diff and ended up adding an "inc a" in LoadPals. Curiously, this made the page colors offset properly, but I am fairly sure the only reason it works is a fluke with it cancelling out a bug/typo somewhere...
I committed the changes regardless but added a comment referencing this in LoadPals, would be cool if you or someone could look into it.
Commit: https://github.com/FredrIQ/pokecrystal/commit/d855e39e501eaf75dc1a7f332ff33ae05a403e1f

I'm getting 89 for converting 227, 228, and 229 (which I believe is the internal value used, since the "90 percent" macro expands to "90 * $ff / 100", and Python 90*0xff//100==229), and 90 for 230*100/0xff. Maybe a lookup table would be simpler.

Take the original (internal) accuracy, multiply by 100, add 255, divide by 256.
Should give the proper result in every single case unless GF did some serious rounding errors in their internal representation somewhere.

My concern with changing accuracy internally is that it could be used in more than one place in the code, and even if all occurrences of MOVE_ACC get edited, maybe it's being accessed elsewhere without the convenient constant (like by loading MOVE_TYPE and later incrementing hl; that issue is why I stored the Phys/Spcl/Stat category at the end of the data structure, because when I put it right after type I was getting bugs and was too unfamiliar with Z80 to fix them).

I understand this concern in general. Not sure if it would apply to move accuracy specifically (considering that the game would only ever need to call it in like, 3 places, at most), but fair enough anyway.

 

[ndeliberto]

Rangi,

Can you receive a dratini from the wonder trade portal? I've received four larvitars as well as numerous chanseys and jynxs but not one dratini. Is the pokemon you receive based on the rarity of the pokemon you offer to trade? i.e. offer a rare, get a rare kind of deal?

 

[Rangi]

Rangi,

Can you receive a dratini from the wonder trade portal? I've received four larvitars as well as numerous chanseys and jynxs but not one dratini. Is the pokemon you receive based on the rarity of the pokemon you offer to trade? i.e. offer a rare, get a rare kind of deal?

It's random within a set of valid-level Pokémon, so anything you trade between level 20 and 29 can be for a Dratini.

 

[FIQ]

Pff, wonder trade should work just like 6gen with 95% trash, the occasional breedject and the rare really good thing and your own trade having no impact on the wonder trade whatsoever :P

(joking)

 

[FlameShot]

Where can I get Whirlpool? I already defeated the rockets in Mahogany but I still can't get it. Is it changed in this hack?

 

[ndeliberto]

Rangi,

Thank you for your quick response earlier.

That being said, I am once again stumped: I cannot find Misty in Cerulean. Every time I go to the cape she isn't there. Furthermore, Zapdos keeps reappearing at the power plant, even though I've captured it and knocked it out twice. Does her non-appearance have anything to do with Zapdos not going away? I solved the power plant mystery and returned the part, but never battled the rocket. Just ran into him at the gym.

A little help would be much appreciated.

Best,

Nick