ZUD Plugin [Essentials v19.1]

[Lucidious89]

Gen 8 1.1.2 and ZUD 1.1.4.
Or at least the ones at Reliccastle

Then this is probably Gen 8 related, and not ZUD. Since ZUD doesn't add any new battler sprites (except the G-Max ones of course), and doesn't have any code implemented that shrinks sprites, only enlarges.

What are the FRONT_BATTLER_SPRITE_SCALE and BACK_BATTLER_SPRITE_SCALE set to in your Settings?

 

[curryofthepast]

How would one go about defining different new types and abilities for G-Max forms? Basically an idea I'm toying around with for my project, take out all the Megas and roll some of their functionality and appearance into G-Max instead. Edits go in ZUD_dynamax PBS file sure, just wondering how much it supports functionality from pokemon.txt. Shouldn't be that hard since Protean/Libero and Color Change still work.

I tried digging around in the ZUD topics, but couldn't find any discussion on this.

 

[Lucidious89]

How would one go about defining different new types and abilities for G-Max forms? Basically an idea I'm toying around with for my project, take out all the Megas and roll some of their functionality and appearance into G-Max instead. Edits go in ZUD_dynamax PBS file sure, just wondering how much it supports functionality from pokemon.txt. Shouldn't be that hard since Protean/Libero and Color Change still work.

I tried digging around in the ZUD topics, but couldn't find any discussion on this.

You can't, really. The PBS file included with this plugin is for compiling the compatibility of G-Max moves so the game knows which species and type are required to "unlock" the specified G-Max Move. It doesnt actually add any new species data. Thats why G-Max Pokemon aren't considered "forms" in a traditional sense.

What you could do, however, is create new forms for these Pokemon with the types and abilities you desire, like you would for a new Mega or something. And then make it so that when you use Dynamax, the Pokemon is forced into the specified form. This is something youd have hardcode for each species with one of these forms. Similar to how Alcremie works (if you didnt know, Alcremie is forced into form 0 when Dynamaxed, and then its previous form is restored once Dynamax ends. This is why you dont need a _gmax sprite for all 62 Alcremie forms).

Then, you would just have to update the species in the ZUD PBS file to account for these new forms. For example, if you want to make Mega Venusaur take the place of Venusaur's G-Max form, then youd use VENUSAUR_1 instead of VENUSAUR.

If done correctly, Venusaur should change into form 1 when Dynamax is used, and that form will become G-Maxed, unlocking its exclusive G-Max move. Then once Dynamax ends, Venusaur will return to form 0.

 

[curryofthepast]

Thanks for the quick and detailed reply Lucidi. I'll take a look at what's done with Alcremie and post results if I figure out a good way to get the edits working.

Another thing I started wondering about is if the rb scripts in plugins need any editing, if I want to change a few types in the type-chart? The scripts seem to dynamically look at your Essentials script definitions and handle things for you. Couldn't find type references in the files I looked at. My case would be on the easier end since I'm basically just making all Rock types -> Ground types and then replacing Rock with a new type, mostly just making sure the right names are changed in a few locations and making the new graphics match. Basically just swapping and renaming old definitions. As long as I get Continental Crush e.g. to use the new type I think I know how to do the rest from there.

EDIT: Since I got on a text editor. In Battle Mechanics.rb I found the lines that force forms for G-max. Pretty self-explanatory, if you're using Gen 8 project, Alcremie and Cramorant are in your PBS/pokemon.txt.

# Alcremie reverts to form 0 only for the duration of Gigantamax.
battler.pokemon.form = 0 if battler.isSpecies?(:ALCREMIE) && battler.gmaxFactor?
battler.pokemon.form = 0 if battler.isSpecies?(:CRAMORANT)

Now in our PBS/pokemonforms.txt we already have a Mega with altered info I want to treat as a G-Max instead. We add a new line under the Cramorant logic.

battler.pokemon.form = 0 if battler.isSpecies?(:CRAMORANT)
battler.pokemon.form = 1 if battler.isSpecies?(:ALTARIA) && battler.gmaxFactor?

Since that's the logic I found relating to species, the other scripts should just handle the rest. Although it seems irrelevant, might want to remove the MegaStone requirement in the PBS. And of course make the stats, especially the HP the same as form 0 unless you want your G-Max forms even more busted. Please correct me if I missed/misunderstood something in the scripts.

Tweaking types and moves would take more work. A hacky solution I thought of would be using the old internal type word, while only changing the types.txt and renaming the altered type anywhere the game displays text or graphics.

 

[Loliberto]

Then this is probably Gen 8 related, and not ZUD. Since ZUD doesn't add any new battler sprites (except the G-Max ones of course), and doesn't have any code implemented that shrinks sprites, only enlarges.

What are the FRONT_BATTLER_SPRITE_SCALE and BACK_BATTLER_SPRITE_SCALE set to in your Settings?

(Sorry for answering now, I get caught by university)

It's:

FRONT_BATTLER_SPRITE_SCALE=2 BACK_BATTLER_SPRITE_SCALE = 3

 

[Lucidious89]

(Sorry for answering now, I get caught by university)

It's:

FRONT_BATTLER_SPRITE_SCALE=2 BACK_BATTLER_SPRITE_SCALE = 3

Weird. Are you using the battler sprites that came packaged with the Gen 8 Project? Well, in any case, try fiddling with those settings and see if it makes any difference.

 

[Lucidious89]

Thanks for the quick and detailed reply Lucidi. I'll take a look at what's done with Alcremie and post results if I figure out a good way to get the edits working.

Another thing I started wondering about is if the rb scripts in plugins need any editing, if I want to change a few types in the type-chart? The scripts seem to dynamically look at your Essentials script definitions and handle things for you. Couldn't find type references in the files I looked at. My case would be on the easier end since I'm basically just making all Rock types -> Ground types and then replacing Rock with a new type, mostly just making sure the right names are changed in a few locations and making the new graphics match. Basically just swapping and renaming old definitions. As long as I get Continental Crush e.g. to use the new type I think I know how to do the rest from there.

EDIT: Since I got on a text editor. In Battle Mechanics.rb I found the lines that force forms for G-max. Pretty self-explanatory, if you're using Gen 8 project, Alcremie and Cramorant are in your PBS/pokemon.txt.

# Alcremie reverts to form 0 only for the duration of Gigantamax.
battler.pokemon.form = 0 if battler.isSpecies?(:ALCREMIE) && battler.gmaxFactor?
battler.pokemon.form = 0 if battler.isSpecies?(:CRAMORANT)

Now in our PBS/pokemonforms.txt we already have a Mega with altered info I want to treat as a G-Max instead. We add a new line under the Cramorant logic.

battler.pokemon.form = 0 if battler.isSpecies?(:CRAMORANT)
battler.pokemon.form = 1 if battler.isSpecies?(:ALTARIA) && battler.gmaxFactor?

Since that's the logic I found relating to species, the other scripts should just handle the rest. Although it seems irrelevant, might want to remove the MegaStone requirement in the PBS. And of course make the stats, especially the HP the same as form 0 unless you want your G-Max forms even more busted. Please correct me if I missed/misunderstood something in the scripts.

Tweaking types and moves would take more work. A hacky solution I thought of would be using the old internal type word, while only changing the types.txt and renaming the altered type anywhere the game displays text or graphics.

Seems good to me. And yeah, id remove any traces that would mark the species as a "Mega", since I went out of my way to block Dynamax working with Megas, and I don't really know how thorough it would be in preventing the mechanic from working here. But if they're just regular forms, it should work fine. As far as Types go, I don't think there's anything in this Plugin that explicitly refers to specific types. Anything Type-related is handled in the ZUD PBS file where all Power Move compatibility is set, which will accept any Type that is defined in the types.txt file, regardless if it's an official type or a custom one.

 

[SpeedyAggron]

I bet this question has popped up several times, but I feel it would be faster to ask rather than to search even more. I always have wanted to include Z-Moves in my project, but I also added EBDX the moment it was released. I don't care for anything past the 3DS games and I could download the not supported ZUD script for V18.1. This means it will never be compatible with EBDX even if the V19 versions in the future might be. I mostly use EBDX for animated sprites and battle dialogue and those can be found in separate scripts for base Essentials. As long EBDX is fairy easy to remove and I look for modified battle UIs to spice it up, I could use ZUD instead.

 

[Lucidious89]

I bet this question has popped up several times, but I feel it would be faster to ask rather than to search even more. I always have wanted to include Z-Moves in my project, but I also added EBDX the moment it was released. I don't care for anything past the 3DS games and I could download the not supported ZUD script for V18.1. This means it will never be compatible with EBDX even if the V19 versions in the future might be. I mostly use EBDX for animated sprites and battle dialogue and those can be found in separate scripts for base Essentials. As long EBDX is fairy easy to remove and I look for modified battle UIs to spice it up, I could use ZUD instead.

So...what's your question that you're asking here?

 

[SpeedyAggron]

So...what's your question that you're asking here?

Yeah, maybe I wasn't clear about that and I guess I answered it myself since ZUD V18 is no longer supported. My other question was how to remove EBDX, but that seems to be deleting all the involved folders and the main script unless more is involved. It's all about listing the pros and the cons and weighing them for both scenarios to see which it most ideal and easiest to deal with.

 

[Lucidious89]

Yeah, maybe I wasn't clear about that and I guess I answered it myself since ZUD V18 is no longer supported. My other question was how to remove EBDX, but that seems to be deleting all the involved folders and the main script unless more is involved. It's all about listing the pros and the cons and weighing them for both scenarios to see which it most ideal and easiest to deal with.

I still don't really get what your issue even is. Are you simply asking how to make ZUD and EBDX work together? Because this version of the plugin is already compatible with EBDX, there's no reason to do anything special. Unless you're saying that you're still using Essentials v18.1? I don't really know what you're saying tbh lol.

 

[SpeedyAggron]

I still don't really get what your issue even is. Are you simply asking how to make ZUD and EBDX work together? Because this version of the plugin is already compatible with EBDX, there's no reason to do anything special. Unless you're saying that you're still using Essentials v18.1? I don't really know what you're saying tbh lol.

I'm still using V18.1 because I don't want to lose some of the scripts I'm using and I'm already pretty far in my project. Every time I checked on ZUD and EBDX compatibility, people were commenting on that was not the case even for V19 unless I was missing stuff. Like I said before, it's all about pros and cons and I'm considering switching EBDX for standalone scripts in V18.1.

 

[Lucidious89]

I'm still using V18.1 because I don't want to lose some of the scripts I'm using and I'm already pretty far in my project. Every time I checked on ZUD and EBDX compatibility, people were commenting on that was not the case even for V19 unless I was missing stuff. Like I said before, it's all about pros and cons and I'm considering switching EBDX for standalone scripts in V18.1.

Ok, you should have probably led with the fact that you're using v18.1 lol. I have no reason to assume that's what you're using if you're posting in a thread for v19.1.
This plugin has EBDX compatibility built-in already, and the main post states this several times. So updating you project to v19.1 would solve all of your issues, since you'd then be able to use the much improved versions of both EBDX and ZUD together.

But if you're dedicated to sticking with outdated scripts, you don't have any options and have to choose one or the other. I drop all support for older versions of plugins once a new version of Essentials come out, so I won't provide any help, support, or updates for ZUD v18.1. The same is true for this plugin once v20 comes out.

 

[SpeedyAggron]

I feel stupid that I didn't see that one line on the main post. I could make a list of all the scripts I have and see which ones have a V19 version or something similar. I have a lot of Gen 5 style ones for menus and the usual scripts such as following Pokémon and overworld encounters. If I see nothing crucial of my game is stuck on V18.1, I guess I can change to V19 now that I know this.

 

[mine4114]

After attempting to load the plugin, I get the following error:
[Pokémon Essentials version 19.1]
[v19.1 Hotfixes 1.0.7]

Exception: Errno::ENOENT
Message: File Data/ZUD_PowerMoves.dat not found.

Backtrace:
101:GameData:62:in `load_data'
101:GameData:62:in `load'
[ZUD Plugin] Compilers.rb:713:in `load_all'
031:StartGame:13:in `initialize'
372:Main:29:in `mainFunctionDebug'
372:Main:18:in `block in mainFunction'
014:Errors:70:in `pbCriticalCode'
372:Main:18:in `mainFunction'
372:Main:44:in `block in <main>'
372:Main:43:in `loop'

I have tried to compile the project, but this message stays there. Can I get some help?

 

[Lucidious89]

After attempting to load the plugin, I get the following error:
[Pokémon Essentials version 19.1]
[v19.1 Hotfixes 1.0.7]

Exception: Errno::ENOENT
Message: File Data/ZUD_PowerMoves.dat not found.

Backtrace:
101:GameData:62:in `load_data'
101:GameData:62:in `load'
[ZUD Plugin] Compilers.rb:713:in `load_all'
031:StartGame:13:in `initialize'
372:Main:29:in `mainFunctionDebug'
372:Main:18:in `block in mainFunction'
014:Errors:70:in `pbCriticalCode'
372:Main:18:in `mainFunction'
372:Main:44:in `block in <main>'
372:Main:43:in `loop'

I have tried to compile the project, but this message stays there. Can I get some help?

You didnt compile. Maybe you think you did, but you didnt.

 

[mine4114]

You didnt compile. Maybe you think you did, but you didnt.

After compiling, the error persists.

 

[mine4114]

Honestly, I might just uninstall the plugin.

 

[Lucidious89]

After compiling, the error persists.

You arent compiling. You cannot be getting this error if you were. The game console will literally say "starting full compile" if you do so correctly.

 

[YashPokeFan123]

After attempting to load the plugin, I get the following error:
[Pokémon Essentials version 19.1]
[v19.1 Hotfixes 1.0.7]

Exception: Errno::ENOENT
Message: File Data/ZUD_PowerMoves.dat not found.

Backtrace:
101:GameData:62:in `load_data'
101:GameData:62:in `load'
[ZUD Plugin] Compilers.rb:713:in `load_all'
031:StartGame:13:in `initialize'
372:Main:29:in `mainFunctionDebug'
372:Main:18:in `block in mainFunction'
014:Errors:70:in `pbCriticalCode'
372:Main:18:in `mainFunction'
372:Main:44:in `block in <main>'
372:Main:43:in `loop'

I have tried to compile the project, but this message stays there. Can I get some help?

I think you should delete your save file and make a new one . If it doesn't work then reinstall the plugin