Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit)

Glad the project has been useful to somebody! ^__^

For #1, the easiest option would be to have the stone type matchup affect catch rate directly. In init_items, change the argument for all monster stones to an array with two elements: catch rate, and a new type affinity parameter. Then in itemuse_catch, change line 13 from "argument1" to "argument1[0]" (reading the catch rate from the array) and add a new parameter for the catch rate as a multiplier for the final catch rate. For instance maybe you could write a function that, given an AMP ID and a type, returns either 1.00 if the monster has that type, or 0.05 (or even zero) if it doesn't, and then have the type parameter just be the elemental type that stone works on. (Or the factor could be based on something else entirely...)

Blocking the player from using the stone entirely if the monster doesn't have the type gets a slight bit more complicated, I think the easiest incision point would be in mev_battle_item_select. After you get the list of valid targets "targets" at line 6, go through the list and remove all targets whose type the stone doesn't work on, using whatever logic you are planning: hardcoded whitelists, type checks, level checks etc. (The selected item is in "my_item" at this point so you can access its data). Keep in mind, the list is an array and not a ds_list.

For #2, the GGUI code is so deeply ingrained in the menu functionality that it's probably going to be pretty difficult to replace it entirely. What exactly are you planning to do? It's made to be as generic as possible (with elements like frames and sprites that can use any assets you want) so it should be possible to script more or less anything with it. You can also add new element types by editing ggui_draw.