• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Which Pokémon Masters protagonist do you like most? Let us know by casting a vote in our Masters favorite protagonist poll here!
  • 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.

Curious about something relating to tm.txt

Derxwna Kapsyla

Derxwna "The Badman" Kapsyla
  • 437
    Posts
    13
    Years
    The project I'm working on, the Touhoumon Essentials Development Kit, requires a lot of new additions and changes to be added to the Essentials Engine. As such, TMs and HMs were new and changed. I won't lie and say I've been lazy about wanting to do it, but it's for a halfway-valid reason. I'm not overly fond of how one would work with the tm.txt file.

    My issue with the TM/HM Compatibility text file, and how it's done - with what I'm doing at least - means that I have to scour up and down YAPE and the text file repeatedly to get what goes into which category. Egg Moves, on the other hand, require you to just drop stuff in the Pokemon.txt as a simple line

    EggMoves=REFRESH18,HARDEN18,BODYSLAM18,WEATHERBALL18,FOCEPALM18,FORESIGHT18,MIST18,THUNDERWAVE18

    What's stopping TMs and HMs from being done like this, aside from the scripting required? Like, as an example, I did this to show how it could be done within Pokemon.txt

    TechedMoves=TM01,TM02,TM05,TM16,TM22,TM43,TM49,HM02,HM04

    As I understand, if the scripting was in place in RGSS, this could work. It would read the Internal name of the TM/HM from the Items.txt, where the TM/HM is actually defined.

    748,G18TM48,TM48,4,3000,Switches abilities with the foe on the turn this is used.,3,0,0,SKILLSWAP18

    (Ignore the G18TM48. It wouldn't allow me to start with 18, and TM48 is reserved)

    Pokemon.txt calls upon Items.txt for numerous situations. Evolutionary Items, Held Items, and I believe that's all. If it can call upon Items.txt for that situation, why can't it call upon it for TMs and HMs?

    Granted, right now I'm just ranting about this because it'll be annoying and painful for what I have to do, but it's also a valid complaint. Why does there need to be a separate file for TMs and HMs when it could be dropped into Pokemon.txt? Is it because tms.txt is an old fundamental file? If that's the reason, I suppose its hard to change old core things for new things, but I say that the option for another method to add them should be there.
    Don't mistake this for me demanding that it be done this way, I'm just a bit curious as to why this can't be done.
     
    It could indeed be done the way you describe. Information like a species' evolution paths are written in pokemon.txt and stored in a special file, and so could TM compatibility (listing moves rather than items, I think, to allow the inclusion of Move Tutor moves). I even think it used to be done like that.

    However, for whatever reason, tm.txt was created for this purpose instead. Perhaps it was for convenience - it sounds easier to work with a list of species that can learn move X rather than a list of moves that species Y can learn. It also means all the non-inherent moves (i.e. that can't be self-learned somehow) are in one place without any other clutter.

    I think the point of view is that move compatibility (in terms of TMs/HMs/Move Tutors) is a property of a move rather than a property of a species. Since you have to specially add in a way to learn a TM move (i.e. make a TM item), the species it can be taught to should be listed in a special place. It's just a way of thinking about it.

    Ultimately, it works the way it does because it's always been like that. Attempts to change it would require significant script changes; the vast majority of users would be unaffected, and at least an equal amount of users would complain about the change. It's not worth the effort. Allowing both methods would be a can of worms.
     
    Back
    Top