Caethyril's Plugins

[Dehsalp]

Oh, that's strange. Before uploading, I tested it in a v1.6.2 project with three plugins active, in this order:

• HIME_HiddenChoiceConditions
• DreamX_ChoiceHelp
• CaeF_DreamX_ChoiceHelp

Just now I tested again to be super sure, and yes, when I disable choice #1, that choice disappears and the correct descriptions are shown for the remaining choices. I tried a few different combinations of disabled choices and they all seemed to produce the correct result. After that I added HIME_LargeChoices to the end of the Plugin Manager list and experimented with that; again, everything seemed to work out correctly.

I'm guessing your problem is due to a plugin conflict, though I'm not sure. Are you maybe using two plugins that affect choices, e.g. Yanfly's Extended Message Pack 1 and Hime's Hidden Choice Conditions? Perhaps list or screenshot all your plugins in your Plugin Manager. (Just a reminder: the order is generally important.)


I'm good! Glad you're still finding them useful~

Oh, I've arranged the HIME plugins in the order of the attached images to sort them all at once.

I saw above that I wrote DreamX choice help on top of HIME's large choice.

HIME's hidden choice
DreamX choice help
CaeF DreamX ChoiceHelp
HIME's large choice

Would you like to put it in between to sort it?

Should these plugins be placed below hidden choices, right above large choices?

+)
Secondly, it sorts by the attached image (named ffff), so it seems to work!

Thank you!

If there is another error or crash, i will check it and write it down in as much detail as possible.

 

[Solar_Flare]

Cae_EssentialActors

This one doesn't appear to be in the opening post, which makes me a little curious...

 

[caethyril]

This one doesn't appear to be in the opening post, which makes me a little curious...

Well spotted! Fixed. It was present in the drive folder, I'd just forgotten to add it to the opening post. ^_^

 

[caethyril]

...update summary since last November~

• Updated Cae_WindowHelpText to v1.2 (multi-line help text, param types were changed!)
• Updated Cae_MovingWindows to v1.2 (minor fix for this in evals)
• Released Cae_MapUpdateRate
• Updated Cae_CustomEscCodes to v1.3 (Yanfly wordwrap compatibility)
• Updated CaeF_DreamX_ChoiceHelpFix to v1.2 (Hime Hidden Choices compatibility)
• Released CaeX_FootstepTime
• Released Cae_SaveLoadSwitch and quickly updated to v1.1 (added save ID variables)
• Released Cae_DamageDisplayPos

Maybe a quarterly summary would be better in future... Note that if I don't post a summary you can always check the drive folder via the link in the opening post, click the "List view" button near the top-right, then sort by Date Modified. (I also have some small/niche stuff in the plugins > odds & ends sub-folder there in case anyone's interested.)

That's all for now, happy RPG Making!

 

[Chaos17]

OMG, THANK YOU for the move route fix!! My patrol event wasn't able to continue its original path after being stoped temporary! Now it CAN

 

[DadGuyDrawing]

These are great! Thanks for posting them.

 

[RK DracoRoy]

@caethyril I did want to request a plugin that's more of a fix to an unexpected behavior of a Yanfly plugin. I can explain it if that's okay with you.
--------
Update
--------
I got 2 plugins in total with glaring issues, one of which is from Yanfly.

 

[caethyril]

@RK DracoRoy: I can't promise a quick turnaround, but feel free to elaborate!

 

[RK DracoRoy]

@caethyril Here's Victor's Fog and Overlay plugin (requires his Basic Module): Fog and Overlay | Victor Engine (wordpress.com)

The only thing is that try the shake screen setting in the map and battle, the overlay is cropped by the screen instead of covering the whole area like off screen.

Spoiler: Code here

Map Notetag
--------------
<fog effect>
id: 1
name: '$MV_DarkCloudFog'
opacity: 180
hue: 0
move x: 10
move y: 10
blend: 1
</fog effect>

Fog overly picture (directory: img folder -> fogs folder)

Yanfly's Animated SV Enemies: Animated Sideview Enemies (YEP) - Yanfly.moe Wiki

About this one, to better exploit it will require action sequences. But here, you know how under 25% HP or any abnormal / sleep state, player actors stay in their updated stance when they either attack, get attacked, dodge an attack.

Example:
- First, player actor is in abnormal / sleep state.
- Second, player dodges an incoming attack / Player performs an attack.
- Third, player actor is back in abnormal / sleep motion afterwards. Works as expected.

When it comes to SV enemies during an action sequence:
- First, enemy actor is in abnormal / sleep state.
- Second, enemy dodges an incoming attack / Enemy performs an attack.
- Third, enemy somehow reverts to default idle motion but until the end of the remaining turn. **
- Fourth, after the enemies used up their turns and it's back to the player deciding things, the enemy goes back to abnormal / sleep state.

** - It's that part that really gets me. Like I'm attacking a sleeping enemy and they go to default idle motion for the remainder of the turns being passed but still have the sleep state.

An action sequence for example would be to attack and then have a wait value afterwards where you'd see the enemy revert to default idle motion, but SV enemies behave this way by also performing attack and dodging an attack.

 

[caethyril]

@RK DracoRoy: OK, I had a quick look, here are a couple of ideas:

• Screen shake causes the entire spriteset to wiggle, so in theory you could just cancel that out by having the overlays wiggle in counterphase. I haven't tested it but you can try loading this as a plugin, after Victor's:
  

  (function(alias) {
    Game_Fog.prototype.updateMove = function() {
      alias.apply(this, arguments);
      this._x -= Math.round($gameScreen.shake());  // cancel shake offset?
    };
  })(Game_Fog.prototype.updateMove);

  Might need to put that somewhere else...I'm uncertain whether updateMove reliably gets called every frame or not.
  
  
• I'm not sure about the Yanfly enemy motion thing, but if you're up to experiment, you can try commenting out these two lines (2644~2645 in my copy) in YEP_X_AnimatedSVEnemies:
  

        } else if (this._pattern >= 2) {
          this.startMotion(this._enemy.idleMotion());

  To be clear, "comment out" means "put // at the start of the line", i.e.
  

  //    } else if (this._pattern >= 2) {
  //      this.startMotion(this._enemy.idleMotion());

  I'm suggesting this because otherwise the refreshMotion line in there is unreachable.

Remember to save your project after making any changes in the Plugin Manager, else those changes will not be seen during test. Let me know if either of these suggestions actually work!

 

[RK DracoRoy]

@caethyril Thank you very much! The enemies now default to whatever stance they're set to when under certain conditions.

Unfortunately, the script for Fog overlay is acting the same when shaking the screen even if I did put it as a plugin. Both on map and battle.

 

[caethyril]

@RK DracoRoy:

• Yanfly fix: great!
  
  If it seems OK after a bit of testing, feel free to submit it as a bug-fix. It'd be awkward as a patch (need to replace that whole method) and it looks like a remnant from testing: "is pattern < 2? If not, is it >= 2? If not [how?], then refresh".
  
  
• Victor's overlays: on closer inspection the fog images are instances of TilingSprite, so I'm unsure why it's not tiling. It might be that child sprites are not rendered outside the parent container (spriteset), in which case the plugin would need rewriting so that the fog sprites are placed in a different container. It might depend on the fog display layer, too.
  
  Have you tried alternative overlay plugins, e.g. Galv's, to see if they have the same problem? Or is Victor's the only one you can find with the necessary features/compatibility?

 

[RK DracoRoy]

@caethyril Honestly, Victor's fog plugin is way easier for me to understand and implement in the project. It's strange, I used a similar plugin (GabeMZ_FogEffects) that didn't act like this in shake screen. I might have to give up on this otherwise.

 

[RK DracoRoy]

I do have one more thing and it may be in the editing category.

Yanfly's Turn Order Display is a really thought out plugin though it can get in the way of things like battle log so I have them on top of the battle status window.

Turn Order Display (YEP) - Yanfly.moe Wiki
Actor Party Switch (YEP) - Yanfly.moe Wiki

This one's the Switch. It's noticeable when opening it.


This is based on Yanfly's Libra skill but with a lot of different things.


It's these two I use that the Turn Order Display gets in the way. And the plugin is set to disable on certain windows.

 

[caethyril]

@RK DracoRoy: try loading this as a plugin after YEP_X_TurnOrderDisplay (untested):

(function(alias) {
  Window_TurnOrderIcon.prototype.isLargeWindowShowing = function() {
    const w = SceneManager._scene._actorPartySwitchWindow;
    if (w && (w.isOpen() || w.isOpening())) return true;
    return alias.apply(this, arguments);
  };
})(Window_TurnOrderIcon.prototype.isLargeWindowShowing);

 

[RK DracoRoy]

Thank you. And unfortunately not working, sadly.

 

[caethyril]

@RK DracoRoy: drat. I know you're experienced with using plugins, but just to check: you remembered to save your project before testing, right?

In that case I recommend asking over on the Plugin Support board, maybe someone there will happen to know of a solution.

 

[RK DracoRoy]

As always! And honestly since you brought that up, I tend to just copy and paste a backup sometimes when I save. This method which will help in case of a computer crash in the middle of progress.

 

[PLUEVNR]

Hello.
I just discovered this thread and it's golden. I'll use several of your plugins for sure.

The first one I need is your Cae_BattleMessages.
Is it possible to update it and let us choose the windowskin?

I'm using some functionnalities of YEP_MessageCore (+extensions) and GALV_MessageStyles. I have windowskins for menu, dialogue messages and pop but the battle messages (like merge and so on) only appear with the message windowskin and I don't wan't to.
Since your plugin is related to these messages, I was wondering if you could add this paramter or not.

Thanks anyway.
See you later!

 

[caethyril]

@PLUEVNR: I think Cae_BattleMessages only changes the text, not how that text is displayed.

If you just want the message window to use a different windowskin when in battle and your current plugins don't give that option, you could try saving this as a .js file (copy+paste into a text editor, Save As > File Type: All Files, Filename: whatever.js) then import it as a plugin:

(function(alias) {
  Window_Message.prototype.loadWindowskin = function() {
    if (SceneManager._scene instanceof Scene_Battle) {
      this.windowskin = ImageManager.loadSystem('WindowBattle');
    } else alias.apply(this, arguments);
  };
})(Window_Message.prototype.loadWindowskin);

Remember to save your project after making plugin changes, otherwise those changes will not be seen during test. I haven't tested but I think that will automatically use img/system/WindowBattle.png for the message window skin when in battle. Otherwise you could try asking over on the JS Plugin Requests board:

JS Plugin Requests

forums.rpgmakerweb.com