Jump to content
kal

Ruby/RGSS3 questions that don't deserve their own thread

Recommended Posts

@FenixFyreX made a script called In-Depth Maps.

It's essentially for making passable ceilings with A4 tiles, but I've never gotten it to work for me.

I think I may know what the deal is, but whether or not this is the culprit depends on if the setting [Default_Ground_Tile] is something that needs adjusting, and that leads me to the point of my inquiry. What in the loving mother of Mercy does tile ID 2816 point to? That appears to be the default setting of the script but I have not one damned clue as to which tile that is. Pretty sure @Kayzee knows...

Share this post


Link to post
Share on other sites

2816 is actually autotile 16, or the first tile in the third row in the editor's tile picker which is grass in the default rtp tilesets.

 

Why? The thing about tile ids is they are all scrambled up compared to the editor, largely because of how autotiles work. Tile 0 is actually the first tile of the B tiles. Autotiles start at 2048 and each autotile is really 48 different normal tiles. The formula for getting an autotile number from a tile number is (tile - 2048) / 48. So (2816 - 2048) / 48 = 16.

 

FYI: I am pretty sure the A1-A4 tiles are all autotiles. Can't remember off the top of my head what the IDs for the A5 tiles are.

Edited by Kayzee

Share this post


Link to post
Share on other sites

Huh. There's a script by Tsukihime called Mapshot (takes a picture of the map or of the screen) that depicts a bunch of tile ID values, but it's too complicated for me to figure out on a tired brain, lolz

Anyway, it's likely that some other script was not playing nice with it (this is from a different project but from time to time it makes me think-especially since someone else actually reminded me of the script not too long ago), or I've got something set up wrong or, whatever, but it seems to not be an issue with the default tile ID.

Share this post


Link to post
Share on other sites

OK, so, I'm having another syntax issue, with VE - Passive States (found here)

 

So, I have a passive state on a piece of gear, let's say it's an accessory.

 

<passive state: 50>
true;
</passive state>

^ That is the note tag applied and it works just fine. 

 

Now, I have ANOTHER piece of gear, let's say it's also an accessory. This one has this tag:

 

<passive state: 51>
state?(50);
</passive state>

This should mean that the actor would have both of these passive states when both of these items are equipped at the same time, due to the first time applying state 50 at all times when equipped, and the second item applying state 51 when the actor also has state 50 applied. That second note tag there, does not work. Here, in the script instructions...

 

# Useful script calls:
#   Here some useful script calls that can be used:
#
#   state?(x)
#    checks if the battler is under state ID x

So, either this was written in the instructions in error, or it was poorly explained on what syntax exactly, to use. That's what I need help with. I have tried a million different ways to do this. Just to assist a little more, here is the code in question that handles custom evaluation in the conditions for a passive state.

 

  #--------------------------------------------------------------------------
  # * New method: passive_state_custom?
  #--------------------------------------------------------------------------
  def passive_state_custom?(notes)
    eval("#{notes.gsub(/\r\n/i, ";")}") rescue false
  end

 

Thanks for any help!

Share this post


Link to post
Share on other sites

Maybe because it's checking the equipment with the condition before the one that actually sets state 50. Not even sure 'state?' even works with passive states... Ether way, check for the equipment not the state it's self.

Edited by Kayzee

Share this post


Link to post
Share on other sites

Gaining the new passive state (51) that I am aiming for is not dependent on the equipment specifically, it is dependent on the actor having another state (50). That state can be added by other equipment or abilities in battles, etc. The only condition I want for having state 51 is by first having state 50. Surely, there has to be some expression I can put in that eval to check the actor's current states.

 

I should point out that the character I tested with already had state 50 applied before even trying to equip ANYTHING (just for testing) and it still would not give them state 51. The script is versatile, I've used it to do some pretty wild things with equipment, but checking for a state should be a simple thing in the grand scheme of things. It's super weird that it doesn't have support for that up front, but there has to syntax that exists to check for it.

Share this post


Link to post
Share on other sites

But did you apply state 50 as a normal state or a passive state when you tested? Because every time passive states are refreshed they are removed first, then rechecked one by one. Thus using 'state?' as a condition is unreliable at best when it comes to other a passive states. If you applied state 50 as a normal state and it still didn't work... I donno!

 

Or what I think happning is:

 

Object one:

  • Sets passive state 50

Object two:

  • Applies passive state 51 if state?(50)

When the game refreshes passive states:

  • Clears old passive states
  • Checks Object Two first for whatever reason
  • state 50 is unset so never applies state 51
  • Checks Object One after
  • applies state 50

 

Note: The script checks objects in this order: Actor, Class, States, Equips, Skills. States, and skills are ordered by id, Equips are ordered by slot. I think.

 

 

 

 

Edited by Kayzee

Share this post


Link to post
Share on other sites

Alright, so I should note that the items in question that I am testing are both accessories (Yanfly Equip to be able to equip multiple).

 

Equipping object 1 in the example (state 50) in the first accessory slot and then equipping the second object (state 51 relying on state 50) in the other accessory slot, and then switching both with each other, both return the same issue.

 

I then changed the first object to an entirely different armor piece (a hat) and an accessory, same thing.

 

If it is checking equips by slot ID and doing so in ascending order, the hat comes before the accessories in ID number, and thus should have worked (assuming I even have the right syntax).

 

So I put the passive state on an item that comes AFTER the accessories, and guess what? Works fine. So I guess it checks them in descending order (from the bottom slot ID to the top)

 

Now this presents a huge problem either way, because the order in which it checks is causing certain passives not to work when they rely on another state. Doesn't seem to affect any other calls I made in the passive state tags so far for anything.

 

So, is there any way I could potentially fix this, or am I just boned here?

Share this post


Link to post
Share on other sites

Well... I found a really slow crappy way to fix it:

class Game_BattlerBase

  alias_method :add_passive_states_base, :add_passive_states
  def add_passive_states
    s = 0
    loop do
      add_passive_states_base
      break unless s < @passive_states.size
      s = @passive_states.size
    end
  end
  
end

Mostly slow because of how the passive states script works. I could try rewriting parts of it in a more optimized way sometime I guess. But it's kinda a pain...

Edited by Kayzee

Share this post


Link to post
Share on other sites
3 hours ago, Kayzee said:

I could try rewriting parts of it in a more optimized way sometime I guess.

 

Thank you for the fix, even if it isn't the most optimized. Can always figure that out later AND that is something I wouldn't be against paying for. Just sayin'. :D

Share this post


Link to post
Share on other sites

Problem is a big chunk of the script would need to be re-written. Pretty sure it's mostly slow because it rereads the notes every time, rather then remembering the results. Also lots of eval calls. Oh well.

 

And honestly even if you were to pay me, I don't think I have a way to receive money online. XD

 

Edit: Uuuuughh... Seriously even if you paid me this is turning out to be way too much work to optimize. At this point it would be easier to write my own passive state script. :/

Edited by Kayzee

Share this post


Link to post
Share on other sites
14 hours ago, Kayzee said:

At this point it would be easier to write my own passive state script. :/

As long as it allowed custom conditions I'd be all over that lol

Share this post


Link to post
Share on other sites
23 hours ago, PhoenixSoul said:

Permanent States

 

Doesn't seem like it offers conditions to be evaluated on whether or not a state should be applied or removed. I would need that.

Share this post


Link to post
Share on other sites

It doesn't, but states would not be removed when tagged, therefore removing the following issue:

 

On 10/16/2020 at 8:19 PM, Kayzee said:

When the game refreshes passive states:

  • Clears old passive states
  • Checks Object Two first for whatever reason
  • state 50 is unset so never applies state 51
  • Checks Object One after
  • applies state 50

 

Share this post


Link to post
Share on other sites

It wouldn't let me only apply those states under certain conditions, such as only when wearing a hat, or only when above level 50, etc.

 

Without that functionality, I am stuck with the VE script unless Kayzee is inspired to make one. :P

Share this post


Link to post
Share on other sites
On 10/18/2020 at 2:07 PM, PhoenixSoul said:

Just saying. I use the two scripts in tandem a lot. No conflicts.

 

USE BOTH IN TANDEM NOT ONE OR THE OTHER.

Share this post


Link to post
Share on other sites

I found out today I was using an old version of VE Passive States, so it might not be as slow as I thought anymore...

 

4 hours ago, PhoenixSoul said:

 

USE BOTH IN TANDEM NOT ONE OR THE OTHER.

 

But how would that help in this situation?

Share this post


Link to post
Share on other sites
20 hours ago, Kayzee said:

But how would that help in this situation?


It removes the following issues:

 

On 10/16/2020 at 8:19 PM, Kayzee said:

When the game refreshes passive states:

  • Clears old passive states (NOPE NOT WITH PERMASTATES)
  • Checks Object Two first for whatever reason
  • state 50 is unset so never applies state 51 (STATE NOW APPLIED)
  • Checks Object One after
  • applies state 50


PROFIT

Share this post


Link to post
Share on other sites

We want state 50 active if and only if it's actually set as a passive state though. Permanent States might prevent state 50 from being removed... but it also would prevent state 50 from being removed. Maybe... Would it work if state 50 was a permastate and set to expire in one round? Or would it be prevented from being removed like that too?

Edited by Kayzee

Share this post


Link to post
Share on other sites

I see now; what we're looking for involves states being actively set. Permastates won't help with that unless being set and unset with common events.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×