Improving the way Item graphics are handled?

[Mr909]

So, I'll be a bit blunt here, despite Pokemon Essentials system being so complete, having so much flexibility and so much to offer, it is not without it's faults.
I have an idea to completely straighten out how moves are addressed, but I don't think I need it bad enough to implement it.
What I do, however, wish to implement, for sake of ease of access and because it'll just help so much with all the items I need to take out, thus reducing my overhead:

So, instead of being jumbled together into Graphics/Icons with all the little Pokemon graphics (I'm using G6 for Essentials so I'm having to deal with those too) I'm thinking about having all the items being addressed at Graphics/Icons/Items. In addition to this, instead of having them addressed by number, I was thinking about having them attach to files based on the lowercase version of their internal name (:POTION would be potion.png). I was also thinking about having them auto-assign id numbers based on line number in the file (having line breaks automatically increment a counter). I'm aware this would create a system where save files would not be retrievable if I moved stuff around, but that's a price I'm willing to pay.

I know I just described, in detail, how I would do it, but I'm doing this instead of just asking this as a question because I think it's a good idea for the theory of the implementation as a whole. Isn't this a more robust way to do it? Doesn't it help instead of traditional indexing, and is roughly as easy to implement? Doesn't this keep it simple?

Okay, my real question: Where is the thing that compiles all the item files into such neat little internal objects, and how foolish am I for wanting to mess with it? I can't seem to find it, I'm really not good with how all these scripts are organized.

 

[Maruno]

You can already name the icon files itemPOTION.png or whatever (using the internal name of the item, which is uppercase).

I see no reason why you would want to have the game decide on the ID numbers of items for you. It's no trouble at all to pick the numbers yourself - it's just a number. As you say, it'd be far easier to cause problems with saves if you did it your way, and even if that's only theoretical hassle, it's still more than you already have, so there's no point in bothering. Having the ID numbers defined in the PBS file also makes debugging a little easier, as you can immediately tell which item is which from the number, rather than having to count lines.

You can have gaps between item ID numbers, as far as I remember. You can simply delete the lines in items.txt for whichever items you want to get rid of, and delete the icons for them, and everything will still work. You don't need to renumber all the other item IDs.

Changing which directory the game looks in for item icons is easy. Search for def pbItemIconFile - this method does all the item icon-loading for all cases where item icons appear (Bag, PC item storage, Marts, Mystery Gift, etc.). You'd only need to change that one method accordingly.

 

[Mr909]

Well yeah, I just didn't want gaps for compactness's sake, and then I was being stupid. I didn't know the method already picked up on Internals, now I just have to rename all my items so I can juggle them around how I want and get the numbers in an order that will keep me happy. I'm taking Gen 6 for essentials and taking Megas back out and juggling around A LOT of TMs, and the paperwork frustrated me.

Since I have your attention, I do have a less stupid idea to present to you, why can't moves use a form more like Pokemon, with sort of a slotted system for effects? If you treat it with arguments like you did for evolution methods, you could really, REALLY cut down on the bulk of that space. I know a lot of moves have unique functions, but a large bulk of them don't, and having something like a slotted system would probably allow for a lot more flexibility.

Here's a sample of what I'm talking about in theory:

[1]
Name=Thunder Fang
InternalName=THUNDERFANG
Type=ELECTRIC
Category=Physical
PP=15
Power=65
Accuracy=95
Effects=FLINCHCHANCE,10,PARALYZECHANCE,10
[2]
Name=Fire Fang
InternalName=FIREFANG
Type=ELECTRIC
Category=Physical
PP=15
Power=65
Accuracy=95
Effects=FLINCHCHANCE,10,BURNCHANCE,10

By having effects stated separately and implemented in a fashion like this, you can really cut down the bulk of the redundancy in the way the effects section is coded. Both of these move effects would no longer occupy their own function slot like they do currently, as every move with flinch and another effect could just have flinch and it's other effect. This would cause some new naming problems, as you'd have to give internal names to move effects now, but it's well worth it for the boost in clarity and ease of implementation. For some reason, stat decreases are all separate from each other, and their code, as well as the messages and whatnot, is placed separately every single time a stat needs to be lowered, when to my knowledge the process of decreasing a stat by a number of stages is pretty much always the same. I think you would need to change a few critical things about how move events are called, because steps would need to be implemented to get things all working and all working in order, but it really could help a lot of projects. Also certain internals that changed the move's type, or did things somewhere else in the move's effect than just the damage step would need to be made compatible with slots and whatnot... I know it's a lot of work, but I think it could pay off.

Eh, I should stop right now, I don't have plans to implement it myself because it would take me too long to learn the necessary Ruby. I code in Python and plan to stay that way. XD

 

[Maruno]

There are two main reasons why I've not done this:

1) It was already like the way it is when I took over. I've never felt the need to change it, because of...

2) It works just fine the way it is. Changing it would cause all sorts of problems, as not only would each effect have to work on its own, they would ALSO have to work if paired with ANY OTHER effect. And given some effects need to be intertwined (e.g. Tickle lowers two stats, but is successful even if only one of them is lowered) while others aren't (i.e. ones that fail if any part of them is unable to be done, even if other parts can be), making the necessary checks for all that would be awful. You severely overestimate the benefits of such an overhaul too, both in terms of code efficiency (which would actually be less in your system due to the extra cross-checks of compatibilities between effects) and in terms of benefit to the user (it'd be that much harder for them to create a new effect and to comprehend the battle scripts in general). And it's not as though there's a huge amount of effects this would apply to anyway; this would be a major overhaul of the whole system just to MAYBE SLIGHTLY benefit a handful of effects, which is definitely not worth it.

One move, one effect. It works very well, thank you. Sure, some parts of some effects may look the same as some parts of other effects, but the whole of one move's effect can be found in just one place (or rather, associated with just one function code), so it's easier to look at and manage. It's unlikely anyone will want to tinker with the existing effects in any meaningful way, and if they do, it's already easy for them. Plus it's how the official games do it., and if it's good enough for them...

I think the system that exists is just fine for what it needs to be. In fact, I'd be hard pressed to find any advantages of your system that would make it worthwhile, even ignoring all the effort required to implement it.

 

[Mr909]

Okay, I can see where you're coming from a little better now. I just thing the section as it is runs into a lot of redundancy issues in it's current state, and a number of those could probably be cleaned up if we had a system that handled it. With an effect like Tickle, all you'd need to do is have an event that checks and lowers the first stat, and an event that checks and lowers the second stat. Treating the effects separately would IMPLICITLY cause the failure of one not to effect the failure or success of the other. The stat stage reduction code is eight lines, and it appears in a LARGE block of function codes, doing, from what I can see, exactly the same thing every time.
From a cursory glance at Veekun, there are 101 moves that cause non-damage affliction, damage and affliction, etc. There are 121 that cause stat increase or stat decrease, which is only 12 slots in my hypothetical system. Accounting for some degree of overlap, and identical moves that already work right in this system, it could pare down 80+function codes easily.
The counterpoint you made to my point still holds, though, that certain effects that are a bit more intertwined would probably process differently. Like Future Sight would cause a whole host of problems. Stockpile still needs to be treated separately. I can see that. I can see that my system is much harder to implement successfully, and maybe the benefits aren't so great. I was just curious as to what went into the decision to write it how it was written.

 

[Maruno]

We don't have a shortage of function codes. I'm not saying you couldn't make some efficiencies, but it's not really practical.

The decision wasn't mine, so I can't say for certain, but it was probably on the lines of "this is how Game Freak does it". We've long had the move definitions ripped from various Pokémon games, and they show the use of function codes.

 

[Mr909]

Okay, I see a little. I think really my biggest gripe is I don't like the way stat increase/decrease is so spread out over incredibly redundant lines, and I sort of overshot it in terms of what would constitute a reasonable fix. I don't know Ruby well enough to implement even that though, I'm struggling with stuff that's a cinch in Python. XD