• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

[Scripting Question] Compiler is deleting data from Pokemon.txt

61
Posts
4
Years
  • Age 27
  • Ohio
  • Seen Apr 22, 2024
Hi all! I'm having trouble getting the compiler to work with a new feature I added. I added a new property in Pokemon.txt called ShadowHeartValue (determines how long it takes to purify a Shadow Pokemon). However, when I compile data, the compiler deletes ShadowHeartValue from all Pokemon in the PBS file.

It is defined in the compiler as an optional type.
Code:
"ShadowHeartValue" => [59,"w"]

I have the property defined in the compiler, using bytes 59 and 60 and the "w" code. Before I added it in, there were already 2 bytes being allocated to "w". Since ShadowHeartGauge takes up 2 more bytes, I allocated 4 bytes to "w" like so:

Code:
when "w" #each property for w uses up 2 bytes
       value = csvPosInt!(secvalue,key)
       bytes = 4 #added 2 more bytes for ShadowHeartValue

Here's the code (created by the awesome Vendily!) in Pokemon_ShadowPokemon that references the compiler.

Code:
 def vibecheck # Checks the heart gauge values assigned in pokemon.txt
    dexdata=pbOpenDexData
    pbDexDataOffset(dexdata,self.species,59)
    shadowheart=dexdata.fgetw
    dexdata.close
    return shadowheart
  end

I thought this would be enough to do it, but I guess I'm still missing something. Do I need to create a new DAT file? Is it necessary to also include this is Editor_Screens or Editor_SaveData? Thanks!
 
1,681
Posts
8
Years
  • Age 24
  • Seen yesterday
Hold on. Why would you change the amount of bytes saved? That could throw off the whole count.
I mean, quickly playing around, I'm not seeing any issues, but still, I'd personally rather not edit the stuff already there because I don't understand it enough yet.

Plus, 2 bytes is a lot already, holding a max of 65536, or maybe 65535 (I can never remember with these things). Whatever, it's big on its own.
If you wanted something bigger, you could define a new letter code, like "d" or something, set that to 4 bytes, and use that instead of "w". Then, in the vibecheck, use fgetdw which pulls 4 bytes instead of 2. (That's like 4 billion though, do you really need a shadow value that big?)

Any way, back to the question, it's getting erased because def pbSavePokemonData hasn't been updated. I never use the in-game editor, so I didn't realize this was a thing for my custom properties. Good to know for the future.

Anyway, I'm tired, and still have things to finish up, so one last thing. new return
Code:
return shadowheart>0 ? shadowheart : HEARTGAUGESIZE
makes it so it uses the default value if none is defined. That way, no crashes.
 
61
Posts
4
Years
  • Age 27
  • Ohio
  • Seen Apr 22, 2024
Hold on. Why would you change the amount of bytes saved? That could throw off the whole count.
I mean, quickly playing around, I'm not seeing any issues, but still, I'd personally rather not edit the stuff already there because I don't understand it enough yet.
*snip*
Any way, back to the question, it's getting erased because def pbSavePokemonData hasn't been updated. I never use the in-game editor, so I didn't realize this was a thing for my custom properties. Good to know for the future.
*snip*
Thanks again so much! You've been such a big help. I wasn't understanding exactly how the bytes worked, but you cleared that up for me. I kept it at 2 bytes--definitely don't need 4. And I appreciate your wisdom about the editor because I never would have thought that mattered.

Unfortunately, the compiler is still messing with things. At the point I'm at now, every Pokemon in Pokemon.txt was given a ShadowHeartValue of 0, and if I try to change them, it just resets them back to 0 with the next compile. I've spent hours trying different tweaks to the code, but can't figure out exactly how it likes it. Here's what I've done:

I still have ShadowHeartValue saved as a type "w" property in the compiler. Since this is similar to StepsToHatch, I mirrored it with ShadowHeartValue in Editor_SaveData and Editor_Screens. I put ShadowHeartValue directly underneath StepsToHatch. I noticed there were different DexDataOffsets for different properties, so maybe ShadowHeartValue wouldn't have the same offset as StepsToHatch.

In Editor_Screens, I listed ShadowHeartValue as the last property, #39.
Code:
data.push(shadowheartvalue)        # 39

Then it refers to property 39 a little further down with allocating the bytes:
Code:
savedata[59] = data[39]&0xFF   # ShadowHeartValue - lower byte
            savedata[60] = (data[39]>>8)&0xFF   # ShadowHeartValue - upper byte

My only other idea is maybe listing ShadowHeartValue as a type "f" property, which is for nonzero numbers like height/weight. Type "w" allows for 0, which is maybe why it's defaulting it to 0? Seems like a stretch to me, but it's the only thing I can think of at this point. I'd be super grateful if you had any more ideas! Thanks again!! :)
 
Back
Top