Resource Fame Checker [v19/v20] 2.1.1

[domx9200]

domx9200 submitted a new resource:

Fame Checker [v19/v20] - Adds an easy to use Fame Checker to allow for more lore for characters

It does all the things the original Fame Checker did in FRLG but also has an additional feature. you can have as many pips of information as you want per character, be-it 1, or 200. this code should be able to support it (though it'll be tough to keep track of 200 bits of info). And it will also allow for as many people as you want as well. I'm going to be doing a complete re-write of the code soon-ish, which will include a few more features, such as animated sprites for the info pips and a...

Read more about this resource...

 

[neoncityrain]

Very much a fan of this! I enjoy adding a bunch of characters, lore, exploration, and more, so this fame checker scratches a particular itch of mine!
The only things I've had come up is the rather odd sprite size for icons and wanting the sprites to be in its specific files (thus making duplicate images if all the characters are fightable trainers). This plugin seems to be a bit picky with the size of sprites- nothing too difficult to fix myself, though! It works well and does exactly what I want it to :>

 

[domx9200]

The only things I've had come up is the rather odd sprite size for icons and wanting the sprites to be in its specific files (thus making duplicate images if all the characters are fightable trainers). This plugin seems to be a bit picky with the size of sprites- nothing too difficult to fix myself, though! It works well and does exactly what I want it to :>

Hey, First off, Thanks for using my plugin, I put a lot of effort into making it as user friendly as possible while adding new features to it. Second, you don't even know how much it means to me that you are enjoying using the plugin. Finally, I do understand the issues with sprite sizing, When I was developing the original version I only had access to official gen 3 sprites I ripped from my Fire Red rom so I built everything off of that. I'd love to try to get it touch on discord so that I can look at possibly adding different size options, as that was something that I planned for the re-write anyways. I'm still generally new to the community, so I don't know the general standard in terms of sprite sizing. My discord is domx9200#4020 if you want to send me a message, just make sure to mention who you are, I'm often weary of messages from accounts I don't know well. Also, I'm in the reliccastle discord so If you want to find me that way there shouldn't be a problem.

 

[AenaonDogsky]

This looks amazing, props for your work.

I was looking for a fame checker-style script, but due to mobile and older hardware compatibility, I'm still on v18.1. I haven't tried retrofitting it yet, since you intend on rewriting it, so I'll wait for that first, but I assume the v19 version will be mostly compatible. Also thanks for FameChecker.create(), because I can see users wanting to include the vs-seeker as a PokeGear function/app, rather than an item (it's a bit more convenient that way, and access to it can be controlled via switch anyway). Is there a way to check for completed info profile, or should FameChecker.hasFoundInfo() be used (but I assume that checks for a specific bit of info, not a "stage" of info gotten, right?)

I would suggest the possibility of passing certain information to a global variable accessible via eventing, but seeing as you can already check for - and in the next version, toggle specific parts, that won't be necessary, I think.

Kudos for supporting deprecated versions going forward too, that is rarely the case.

I should also mention that Trainer Battle Sprite size, would be around 80x80 or less in gen4 style, and 80x80 or higher for gen5 style. I use 82x82 for gen5 sprites.

 

[domx9200]

This looks amazing, props for your work.

I was looking for a fame checker-style script, but due to mobile and older hardware compatibility, I'm still on v18.1. I haven't tried retrofitting it yet, since you intend on rewriting it, so I'll wait for that first, but I assume the v19 version will be mostly compatible. Also thanks for FameChecker.create(), because I can see users wanting to include the vs-seeker as a PokeGear function/app, rather than an item (it's a bit more convenient that way, and access to it can be controlled via switch anyway). Is there a way to check for completed info profile, or should FameChecker.hasFoundInfo() be used (but I assume that checks for a specific bit of info, not a "stage" of info gotten, right?)

I would suggest the possibility of passing certain information to a global variable accessible via eventing, but seeing as you can already check for - and in the next version, toggle specific parts, that won't be necessary, I think.

Kudos for supporting deprecated versions going forward too, that is rarely the case.

I should also mention that Trainer Battle Sprite size, would be around 80x80 or less in gen4 style, and 80x80 or higher for gen5 style. I use 82x82 for gen5 sprites.

Thanks for taking a look, It means a lot to me that people are using this tool I spent a while working on. So, to talk to the points of your post,
The FameChecker.create() function was less of a deliberate way to use the program outside of the item, but rather a side-effect of how I developed it, I do plan on renaming this function to something that is easier to understand, such as showScreen or startMenu for the end user.

As of the current version I don't have any easy way to track completion values, this is something I can implement without too much issue, I'll probably set it up as a percentage vs a Boolean value. Though doing so would probably break previous save files, so I'll need to add some code to make conversions.

As for the global variable thing, I don't exactly know how they work, I would have to figure that out if I were to implement it.

As for supporting previous versions, I know that people usually take a few years to develop their games, so I wanted to let people continue using their current versions while continuing to add new features and bug fixes.

Thanks for the Heads up on the battle sprite sizing, I'll look into changing the textures to fit the gen 5 style sprites. Do you happen to know the rough difference between the gen 4 styled overworld sprites and the gen 5 styled overworld sprites?

 

[AenaonDogsky]

Thanks for taking a look, It means a lot to me that people are using this tool I spent a while working on. So, to talk to the points of your post,
The FameChecker.create() function was less of a deliberate way to use the program outside of the item, but rather a side-effect of how I developed it, I do plan on renaming this function to something that is easier to understand, such as showScreen or startMenu for the end user.

As of the current version I don't have any easy way to track completion values, this is something I can implement without too much issue, I'll probably set it up as a percentage vs a Boolean value. Though doing so would probably break previous save files, so I'll need to add some code to make conversions.

As for the global variable thing, I don't exactly know how they work, I would have to figure that out if I were to implement it.

As for supporting previous versions, I know that people usually take a few years to develop their games, so I wanted to let people continue using their current versions while continuing to add new features and bug fixes.

Thanks for the Heads up on the battle sprite sizing, I'll look into changing the textures to fit the gen 5 style sprites. Do you happen to know the rough difference between the gen 4 styled overworld sprites and the gen 5 styled overworld sprites?

Thanks for your time.

Just a quick reply:
Global variables are usually checked for, and set in this form
:

$game_variables[variable number] = value

For instance,

$game_variables[105]=4

However I have seen functions (at least in scripts event commands used within events) such as

pbSet(variablenumber, value)

and

 pbGet(var)

I do think the engine changes usage of $game_variable (at least inside events) to pbSet or pbGet automatically, but I don't remember what's it like in the scripts themselves.

Generally, people might already be using global variables even in the very high numbers, so the script should mention which ones are used, and that the dev should change them for unreserved ones. Also, if the script loads before a savegame is loaded (hence, before global variables are initialized) it will most likely lead to a crash.

I think I saw a couple of scripts (must have been quests system scripts?) that had encountered similar save-compatibility problems in the past, and can work fine with older saves now, so perhaps give them a look?

As for sprite sizes, at least on the dev's side, both gen 4 and gen 5 sprites should fit into a 128x128 texture divided by sixteen 32x32 individual frames. Some devs use slightly different sizes for taller gen 5 OWs (that shouldn't be necessary, though I remember someone saying gen 5 OWs looked better that way) so I would give it some space of around 4-6 pixels just to be sure. Some Pokemon OW sprites are bigger though.

 

[domx9200]

Thanks for your time.

Just a quick reply:
Global variables are usually checked for, and set in this form
:

$game_variables[variable number] = value

For instance,

$game_variables[105]=4

However I have seen functions (at least in scripts event commands used within events) such as

pbSet(variablenumber, value)

and

 pbGet(var)

I do think the engine changes usage of $game_variable (at least inside events) to pbSet or pbGet automatically, but I don't remember what's it like in the scripts themselves.

Generally, people might already be using global variables even in the very high numbers, so the script should mention which ones are used, and that the dev should change them for unreserved ones. Also, if the script loads before a savegame is loaded (hence, before global variables are initiated) it will most likely lead to a crash.

I think I saw a couple of scripts (must have been quests system scripts?) that had encountered similar save-compatibility problems in the past, and can work fine with older saves now, so perhaps give them a look?

As for sprite sizes, at least on the dev's side, both gen 4 and gen 5 sprites should fit into a 256x256 texture divided by sixteen 32x32 individual frames. Some devs use slightly different sizes for taller gen 5 OWs (that shouldn't be necessary, though I remember someone saying gen 5 OWs looked better that way) so I would give it some space of around 4-6 pixels just to be sure. Some Pokemon OW sprites are bigger though.

I see. I'm going to assume this global variables can hold anything, and If so, then I can add it without too much issue I think. I don't know how well it would work with using maps here though. I feel like if I did do it, it would be something kind of annoying to use, something like

$game_variables[variable number][famousPersonName][infoNum]["seen"] = true

Which I attempted to abstract away with FameChecker.hasFoundInfo(). having the data stored in any other way would result in one game variable per famous person being used which would either have to be decided by the game maker, or dynamically assigned upon first load. But hey, I can implement it if people really want it.

I'm not concerned about fixing compatibility, the way I store the data should make it easy to fix. I just have to make sure it works under every scenario.

Good to know about the sprites, the sprites I was using to test with were this really odd 28x36 size, I'll change them to be 32x32 to ensure general compatibility. I'm not sure if I'll expressly support pokemon OW sprites because it would be... interesting to ensure the selection box fits every situation. But I'll throw it into the backlog of improvements to make later on.

 

[AenaonDogsky]

I see. I'm going to assume this global variables can hold anything, and If so, then I can add it without too much issue I think. I don't know how well it would work with using maps here though. I feel like if I did do it, it would be something kind of annoying to use, something like

$game_variables[variable number][famousPersonName][infoNum]["seen"] = true

Which I attempted to abstract away with FameChecker.hasFoundInfo(). having the data stored in any other way would result in one game variable per famous person being used which would either have to be decided by the game maker, or dynamically assigned upon first load. But hey, I can implement it if people really want it.

I'm not concerned about fixing compatibility, the way I store the data should make it easy to fix. I just have to make sure it works under every scenario.

Good to know about the sprites, the sprites I was using to test with were this really odd 28x36 size, I'll change them to be 32x32 to ensure general compatibility. I'm not sure if I'll expressly support pokemon OW sprites because it would be... interesting to ensure the selection box fits every situation. But I'll throw it into the backlog of improvements to make later on.

I do believe arrays can be stored in global vars, but I have no idea about the specifics. If you ask around about it, you'll get some help for sure.

On the other hand, I guess most people would only have to check for whether all the hints have been found, in which case, a boolean in the form of global switches $game_switches[switchnumber] would suffice, but I think it'll be easy to do even without them?
Also, a global switch per character isn't anything fancy, how many famous people would someone need, more than, like 30?

Ah, I forgot to mention that the entire frame is 64x64 upscaled from its base 32x32, that's because we actually have to upscale the graphics for Essentials. So the 256x256x texture is divided into sixteen 64x64, it's the original 128x128 that is divided to sixteen 32x32.

In the example below, RMXP reads the frame as shown in the blue square.

As far as mons are concerned, I don't think it's really necessary, since Fame Checker is about people, and the vast majority of mons will fit into the 64x64 frame, assuming someone might want to do have a... famous mon?

 

[domx9200]

I do believe arrays can be stored in global vars, but I have no idea about the specifics. If you ask around about it, you'll get some help for sure.

On the other hand, I guess most people would only have to check for whether all the hints have been found, in which case, a boolean in the form of global switches $game_switches[switchnumber] would suffice, but I think it'll be easy to do even without them?
Also, a global switch per character isn't anything fancy, how many famous people would someone need, more than, like 30?

Ah, I forgot to mention that the entire frame is 64x64 upscaled from its base 32x32, that's because we actually have to upscale the graphics for Essentials. So the 256x256x texture is divided into sixteen 64x64, it's the original 128x128 that is divided to sixteen 32x32.

In the example below, RMXP reads the frame as shown in the blue square.

As far as mons are concerned, I don't think it's really necessary, since Fame Checker is about people, and the vast majority of mons will fit into the 64x64 frame, assuming someone might want to do have a... famous mon?

Honestly, just having a switch for determining completion would probably make more sense than having the complete objects.

Interesting hearing that the actual size of the sprites are 64x64. It makes some amount of sense though seeing as the 512x386 screen size is double that of a Nintendo DS, and seeing how the DS sprites were 32x32 (at least in gen 4) that would double as well. Good to know, I'll remake the backgrounds and stuff to fit that standard.

The main thing I was thinking in relation to people using pokemon would be as a bit of information, such as representing a trainer's favorite pokemon, not necessarily as a famous pokemon itself, though I could see that being an interesting idea. Honestly, this helped solidify my ideas on improving my sprite sizing, I'm gonna make some mockups to see how it looks.

 

[domx9200]

Hey people, I now that most of the rewrite work is done I wanted to show what it looks like now! There have been a number of small changes to how everything looks as well as a sneak peek at a new feature, animated sprites in the info section. If you want to see how the code on the back end looks now, just head over to my Github. anyways here's a video showing off the end user experience.

 

[domx9200]

domx9200 updated Fame Checker [v19/v20] with a new update entry:

Fame Checker v2.0.0, the Rewrite update

oh boy, that was a surprising amount of work. Well either way, the major update v2.0.0 is done and ready to be downloaded on my GitHub. Lots of things changed, from changing the entire code base, to adding new features. This update in total took up a good chunk of time. Anyways, lets get onto the Updates.

• I updated how the info sprites are loaded, they can now be animated, and can grab files from anywhere,
• Also updated the...

Read the rest of this update entry...

 

[AenaonDogsky]

domx9200 updated Fame Checker [v19/v20] with a new update entry:

Fame Checker v2.0.0, the Rewrite update



Read the rest of this update entry...

Looks amazing, thank you for your hard work, I'll take a look as soon as I can.
I will try it for v18 too, which is what I'm working with.

 

[domx9200]

Looks amazing, thank you for your hard work, I'll take a look as soon as I can.
I will try it for v18 too, which is what I'm working with.

I'm glad that you were watching the progress, I implemented the game switch that you were asking about.
As for porting it to v18, it shouldn't be that hard, the main thing is making sure the y padding on the text is properly aligned. That being said, if you have any issues shoot me a message, I'll try to help.

 

[domx9200]

domx9200 updated Fame Checker [v19/v20] with a new update entry:

Old Save Compatability Fix

I am just a bit of an idiot, I forgot to ensure that $PokemonGlobal.FamousPeople actually existed before trying to manipulate it. I feel like a small bit of an idiot. To be fair, because of the way I was testing conversion from old to new, I'm pretty sure my save file already had $PokemonGlobal.FamousPeople initialized, I will have to be more careful with that in the future.

Read the rest of this update entry...

 

[domx9200]

domx9200 updated Fame Checker [v19/v20] with a new update entry:

Fame Checker v2.0.2, Save Parity Fix

I can't believe I left so many small bugs in the code. I had thought that I had made sure there were no bugs, but... apparently not. This time it was one that is really important to fix. as it turns out, I had it do the save parity update only when the PBS file was compiled, an end user would never be able to do this save parity update if so, I really should have tested the code in the game.exe variation as well... At least I found this one before anybody brought it to me.

Read the rest of this update entry...

 

[AenaonDogsky]

I'm glad that you were watching the progress, I implemented the game switch that you were asking about.
As for porting it to v18, it shouldn't be that hard, the main thing is making sure the y padding on the text is properly aligned. That being said, if you have any issues shoot me a message, I'll try to help.

Thanks a lot! Yeah, I read the changelog and saw the game switch update. I'll give it a go as soon as I can.

 

[domx9200]

domx9200 updated Fame Checker [v19/v20] with a new update entry:

Fame Checker 2.0.3, PBS Location Config and compiler fixes

This release is a small update that most people probably won't need, however a user expressed that they want to be able to modify where the PBS files are located, so I made it possible. In addition I got rid of the annoying error message that happens on first launch, it shouldn't affect anything if you have already been using Version 2.0.2.

Read the rest of this update entry...

 

[Richard PT]

I'm having an anoying issue:

1- I've posted your graphics in its correspondent places.
2- Plugins in plugins folder.
3- PBS/FameChecker.
4- When i'm trying to add a famous person or a piece of info into the fame checker, by calling this in an event, like this:
FameChecker.setFameSeen("OAK",true)
FameChecker.setFameInfoSeen("OAK","EXPERIMENT",true)

The "black window" always says that the file fame_.... etc, couldn't be find in the DATA folder. The only thing that i've changed was the switch number, so I can test it first before editing it in the PBS file.

I don't know if i'm missing something. Cus everything seems to be in its place just to test it.

 

[domx9200]

Oh, I see your issue, the name of the famous person and piece of info must be Symbols, so
FameChecker.setFameSeen(:OAK, true) and
FameChecker.setFameInfoSeen(:OAK, :EXPERIEMENT, true)
alternatively, for setting info, if you know the exact position you can type in FameChecker.setFameInfoSeen(:OAK, pos of info, true),
and you don't even need to have the last variable true, because it defaults to it. though it is clearer if you include it.
The goal with my implementation of the PBS files were to replicate the input style of Pokemon essentials v20.1, which translates everything into Symbols, I can probably add a check in the code to change the input into Symbols if that'd help you out.

That being said, please do reach out to me if you have any issues.

 

[domx9200]

I'm having an anoying issue:

1- I've posted your graphics in its correspondent places.
2- Plugins in plugins folder.
3- PBS/FameChecker.
4- When i'm trying to add a famous person or a piece of info into the fame checker, by calling this in an event, like this:
FameChecker.setFameSeen("OAK",true)
FameChecker.setFameInfoSeen("OAK","EXPERIMENT",true)

The "black window" always says that the file fame_.... etc, couldn't be find in the DATA folder. The only thing that i've changed was the switch number, so I can test it first before editing it in the PBS file.

I don't know if i'm missing something. Cus everything seems to be in its place just to test it.

oh and, i'm interested in that error message, because that means something is very wrong with your copy if it says what I think it does, because it shouldn't ever report that type of message when calling setFameSeen or setFameInfoSeen, as they don't have those guards on them. the most likely error message it reports is probably something along the lines of "OAK does not exist"