Changing how Shadow Pokémon work, and creating Light counterparts

[SinfulGuroRose]

So, uh, can I get some help with a few things?
First, I'd like to ask how to get an additional set of graphics to display properly. They are sprites for Light Pokémon, which, if you haven't checked out my project thread, are essentially Shadow Pokémon in everything except for lore.

Second, I'd like to ask something about scripting specifically. What I'd like to do is a few things: I'd like to be able to enable EXP gain, leveling, and evolution in Shadow/Light Pokémon.
I'd also like to edit the Snag Ball so that it captures both Shadow and Light Pokémon; however, when I attempt to do this, I come across several problems. One is that, upon my first attempt at editing it, the entire battle system crashed. (It's fixed now.) I also realized that I do not know how to implement some bits of coding.... like, let me give you an example.
At the section where it says:

if pbIsSnagBall?(ball)&& @opponent
            pokemon.pbUpdateShadowMoves rescue nil
            @snaggedpokemon.push(pokemon)
                else
            pbStorePokemon(pokemon)
          end

I'd like to add additional criteria for snagging Pokémon. However, I don't know how to add that criteria without it interfering with pbIsSnagBall? (In case you're wondering, it would be two sets of criteria: IsShadow? in the first if and IsLight? in another.) Would someone please help me?

 

[Nickalooose]

What you mean about the graphics? As long as you've added graphics to the right files and within the type within types.txt, etc. It should be fine.

                if thispoke.respond_to?("isShadow?") && thispoke.isShadow?
                  thispoke.exp+=exp
                else

This part within def pbGainExp, is where it controls Shadow Pokémon differently, maybe comment that part out, just remember, every if state has an end state, comment out the end too... Since Light types aren't in Essentials, you have no problem with that type gaining EXP anyway.

Maruno once said.

 

[SinfulGuroRose]

For the graphics, you know how shadow Pokémon can have a different set of graphics? You know, as long as they're named with "_shadow", they show up only on Shadow Pokémon? Well, even though I named the Light graphics with "_light", they won't show up because that's not programmed in. And I don't know where to go to do that. U wU

And I'm curious, does the EXP bar move? After following your suggestion, it now gives a notification that the Shadow Pokémon has gained EXP, but the bar doesn't move, and there's no way for me to check to see if that EXP was in fact gained.

Also, thank you for your help! :>

 

[dexter1o6]

Yes the exp bar moves. You can check the amount experience of a pokemon using the debug mode (probably). Just check the debug menu from the pokemon window.

 

[Nickalooose]

Shadow Pokémon work completely different to normal Pokémon that's why, they have heart gauges and don't gain all their EXP until they become purified, for Shadow types to work exactly like normal Pokémon, I suggest creating a new type and call it SHADOW2, but internal name as Shadow.

For adding the _light thing, in PokemonUtilities, there is numerous things you will need to add, now I'm not familiar with this script section, so it's a wild guess.
Search:

    tshadow=((i/8)%2==0) ? params[5] : false

And add below it:

    tlight=((i/8)%2==0) ? params[5] : false

Then search:

       tshadow ? "_shadow" : "") rescue nil

And add below it:

       tlight ? "_light" : "") rescue nil

Well anything with a "_shadow" or tshadow, copy below but change shadow to light.
As I said though, it's a wild guess, it looks legit.

 

[Maruno]

Something like that, yes. I believe I put every graphic- and audio-loading method relating to Pokémon and species in the same place, so just look around and come up with modifications. Light and Shadow should be mutually exclusive, which should help. Go for something like this instead of the latter part of what Nickalooose said:

tshadow ? "_shadow" : tlight ? "_light" : ""

As for your more general "how do I remove nearly all the special features of Shadow Pokémon?", those should all be in the script section PokemonShadowPokemon. Have a poke around in there and remove bits and pieces.

Why you think removing these features is a good idea is another matter. What exactly is the point of Shadow Pokémon if you're making them behave just like normal Pokémon? The only things left that I can see are being able to steal certain opponents' Pokémon, which has nothing to do with Shadowness, and having access to Shadow moves (which will not only be a headache to make them work alongside learning moves via level-up, but is also not a huge Shadowness thing since they're just custom moves). Hyper Mode is just a side-effect of the Shadow moves, like outraging is to Outrage.

 

[SinfulGuroRose]

Thank you both very much for the answers! > w< Though it seems like your suggestion should work, it doesn't. I'm not quite sure why, but I get the feeling it has something to do with the fact that there are a few instances where the light Pokémon differ from the shadow in ways that I didn't implement. I get the feeling that I'm simply going to have to intensively study and learn RGSS and completely go through the scripts myself to get everything the way I want it.

And also, Maruno, as for the 'why', it's actually because there's a... well, how do I explain it? Those features are ones I'm going to implement into only certain Pokémon, special ones. Legendaries, that kind of thing. Sorry if that doesn't make sense. U wU It really has to do with the lore of the game.

 

[Nickalooose]

So is light just an appearance and move-set changing thing? Because if you're having trouble this way, try using forms instead.
Or is it a completely new type? Because you can achieve this through forms too.
If it has something special, I.E. The heart gauge... You could probably make a new script section by copying PokemonShadowPokemon, and change every "shadow" line to light... I'm not totally sure what's going on here, so I'm just taking shots and hoping for the best I get another answer you're looking for.

 

[SinfulGuroRose]

And I appreciate your efforts. :> And I'd thought of that, but I'm not quite sure how to go through with it.
And yes, that's what I did to create the light Pokémon. Light Pokémon are already effectively in the game now, I'm just having various strange little bugs like their battler sprite not showing up. U wU

 

[Nickalooose]

If you've already added "light" types, then that's easy...
For example, if you changed Bulbasaur to a light type you could have it look like:

MultipleForms.register(:BULBASAUR,{
"getForm"=>proc{|pokemon|
   next 3
}
})

And it will search for 001_3 in the battlers... That's all you need right?

 

[Maruno]

That's not going to work, Nickalooose, because it'll make all Bulbasaurs use form 3 and the light sprites.

SinfulGuroRose, you're welcome to post the code you're having problems with. I for one am not going to guess at what you've been doing and make suggestions.

 

[SinfulGuroRose]

Well, I do have a question, if you don't mind? You said that the previous example Nickaloose posted would cause all Bulbasaurs to have that specific graphic. It did what you said it would do, Maruno, but upon viewing the Pokémon's summary and initiating a battle, I receive the following error:

Exception: TypeError
Message: cannot convert nil into String
PokemonUtilities:1234:in `+'
PokemonUtilities:1234:in `pbResolveAudioSE'
PokemonUtilities:1291:in `pbCryFile'
PokemonUtilities:1274:in `pbPlayCry'
PokemonSummary:921:in `pbScene'
PokemonSummary:1006:in `pbStartScreen'
PokemonParty:883:in `pbSummary'
PokemonParty:2013:in `pbPokemonScreen'
PokemonParty:1922:in `loop'
PokemonParty:2048:in `pbPokemonScreen'

I think what I'm going to do is, if I can fix... whatever I messed up this time, I'll just go through the long process of inserting a form code for every light Pokémon. What I can't figure out, however, is if it is even possible to add additional criteria to that? I don't think if pokemon.isLight? word work, since there's already Multipleforms.register there, right?

 

[Maruno]

Only you know which version of Essentials you're using. I changed a few things about playing cries recently, but I'm pretty sure I tested them for once.

If I was doing this, I'd stick to using the scripts which already exist that do what you want (i.e. the Shadow Pokémon scripts). If you tried making forms out of them, it would not only be tedious but would also involve reinventing some parts of what the Shadow Pokémon scripts already do.

If you've copied the Shadow Pokémon scripts and renamed pretty much all the "shadow" to "light", then pokemon.isLight? will work and things should be relatively straightforward. Again, you've not mentioned what you've actually been doing in this regard. I would've started with a direct copy, made sure Light Pokémon work like Shadow Pokémon all over the place, and then fiddled with how they work (e.g. letting them gain Exp).

A Pokémon being a Shadow Pokémon is entirely separate from that Pokémon's form. You can have a Shadow Unown F if you want. Every Pokémon has the ability to be a Shadow Pokémon, but no Pokémon will ever naturally be a Shadow Pokémon - it's something you have to force yourself as part of how you make your game. Traditionally this forcing is done by defining an enemy trainer's Pokémon as a Shadow Pokémon, with this being the only way to obtain/encounter Shadow Pokémon.

 

[SinfulGuroRose]

Goodness, I'm not doing a very good job of explaining this, am I? Sorry. U wU I'm using 12.2.
See, therein lies the problem; although Shadow Pokémon work perfectly (except, for some reason, when debugging and trying to lower the heart gauge, which is already at stage 0 despite having a heart level at max), I copied the PokemonShadowPokemon script and made a new script section for light Pokémon, changed anything with 'shadow/Shadow' to 'light/Light', and did nothing else besides change the weather move to its light counterpart. Yet, still, there are deviations between Shadow and Light Pokémon that I didn't implement that continue to mess things like this up. :/ I've not actually gone into the editing of their basic functions, like EXP gain, because I'm still trying to get the light graphics to work properly.

I'm curious then, would it even be possible to have wild shadow Pokémon? I'd thought I might be able to edit it so that they have a certain ratio of appearing, but from what you say, it sounds like Shadow Pokémon have been implemented with only the features from Colosseum/XD. So there are no further effects than what is in those games?

 

[Maruno]

I'm assuming here that you took the obvious step of turning a Pokémon into a Light Pokémon before you tried mucking around with it (and that you created a way with mucking around with the Lightness aspects of it). The heart gauge is empty (and the heart stage is 0) for any Pokémon which isn't a Shadow/Light Pokémon. For convenience, you should also rename references to heart to lightHeart or something (and maybe also hypermode if you want Light Pokémon to have that), to make sure they don't overlap with Shadow Pokémon.

For your graphics problems, first look in def pbLoadPokemonBitmapSpecies and add the red bit:

    bitmapFileName=pbCheckPokemonBitmapFiles([species,back,
                                              (pokemon.gender==1),
                                              pokemon.isShiny?,
                                              (pokemon.form rescue 0),
                                              (pokemon.isShadow? rescue false)[COLOR=Red],
                                              (pokemon.isLight? rescue false)[/COLOR]])

Then add the red bits:

def pbCheckPokemonBitmapFiles(params)
  species=params[0]
  back=params[1]
  for i in 0...2**(params.length-2)
    tgender=(i%2==0) ? params[2] : false
    tshiny=((i/2)%2==0) ? params[3] : false
    tform=((i/4)%2==0) ? params[4].to_s : ""
    tshadow=((i/8)%2==0) ? params[5] : false
    [COLOR=Red]tlight=((i/16)%2==0) ? params[6] ? params[6] : false : false[/COLOR]
    bitmapFileName=sprintf("Graphics/Battlers/%s%s%s%s%s%s",
       getConstantName(PBSpecies,species),
       tgender ? "f" : "",
       tshiny ? "s" : "",
       back ? "b" : "",
       (tform!="" ? "_"+tform : ""),
       tshadow ? "_shadow" : [COLOR=Red]tlight ? "_light" :[/COLOR] "") rescue nil
    bitmapFileName=sprintf("Graphics/Battlers/%03d%s%s%s%s%s",
       species,
       tgender ? "f" : "",
       tshiny ? "s" : "",
       back ? "b" : "",
       (tform!="" ? "_"+tform : ""),
       tshadow ? "_shadow" : [COLOR=Red]tlight ? "_light" :[/COLOR] "") if !pbResolveBitmap(bitmapFileName)
    return pbResolveBitmap(bitmapFileName) if pbResolveBitmap(bitmapFileName)
  end
  return nil
end

Do the same below that code for def pbPokemonIconFile, and that should be it.

It's certainly possible to have wild Shadow Pokémon, just as it's possible to have wild shiny Pokémon. Code which allows this goes in PokemonEncounterModifiers.

I can't see any reason for Essentials to give Shadow Pokémon any features other than the features we know they have. Therefore Shadow Pokémon behave, as best as possible, just like how they behave in the games which feature them. However, like anything in Essentials, Shadow Pokémon can be fiddled with to behave differently than how their games use them (some fiddles require more extensive work than others).

 

[SinfulGuroRose]

Goodness, Maruno, you are wonderful. <3 The graphics display properly now, and there are no errors. Thanks so much for all your help!

If you don't mind my asking, in which ways do you think they would overlap? I haven't had issues with it so far, but then again, I haven't had the opportunity to extenively playtest it.

 

[Maruno]

You said that you'd replaced shadow with light. However, methods like def heartgauge don't include shadow, which means you probably didn't rename them. Some such methods (like def heartStage) reference @shadow and so forth, which you would have renamed.

The problem is that, if the method itself isn't renamed, then you've got the same method in two different places, with one overriding the other. Since (some of) those methods specifically reference either shadow or light, and one of the methods is going to be overridden by the other, you're going to end up with incomplete scripts that will, at the least, not function properly.

This may be the cause of your "can't lower heart gauge in debug even though it's supposed to be full" - the copied def adjustHeart(value) references @light (which is false for a Shadow Pokémon) and overrides the original version, so it can't do its thing for Shadow Pokémon. The same applies for any time the heart gauge of a Shadow Pokémon needs changing. I haven't looked for any other examples of problems, but they'll be there.

The simplest way around these problems is to rename everything you've copied. Most of this renaming is indeed done by replacing shadow with light, but there are some cases which wouldn't be and need to be. The Shadow Pokémon scripts are a bit of a tangle, and in fact there are some methods you don't need to copy at all, but that takes some programming sense and knowledge of what those methods do. "Rename it all" is the dumbed-down answer, and will definitely work, although it's more to do.

Note that it's not impossible to have a Pokémon which is both Shadow and Light at the same time. That's fine, that's acceptable; you just need to design your game to make sure such a scenario can never occur.

 

[Nickalooose]

As far as I was aware it was just the graphic and it also stated that certain Pokemon will be light types... As I said in a post before, I was guessing until the right answer came... And the answer is the original post I made about copying things (almost) but at least the problem is sorted now :D

 

[SinfulGuroRose]

You've both been a great help. Thanks a ton! <3 I'm currently working on the script sections I didn't rename, and so far, things are starting to work properly.