I am lost on this...

[Roguedeus]

I've been doing pretty good with my code issues until today. I've normally been able to track down and fix any error, without more than an hour or so of looking...

However, this particular issue has me completely stumped, because it simply makes no sense... I am left wondering if it might simply be a database bug?!?

This is the crux of the problem.

This method, in Kread-Ex Traits Namer (companion script for his Synthesis) sprintf call, with 3 arguments.

    #--------------------------------------------------------------------------
    # ? Generates effects name
    #--------------------------------------------------------------------------
    def self.effect_name(code, data_id, value1, value2)
      custom = CUSTOM_TRAITS[[1, code, data_id,
      self.convert_value(code, value1, false),
      self.convert_value(code, value2, false)]]
      return custom[0] unless custom.nil? || custom[0].nil?
      base_name = EFFECTS_CODENAMES[code]
      data_name = case code
        when 21, 22
          $data_states[data_id].name
        when 31, 32, 33, 34, 42
          Vocab.param(data_id)
        when 43
          $data_skills[data_id]
        end
      if data_name.nil?
        name = sprintf(base_name, value1, value2)  #<--- Here
      else
        name = sprintf(base_name, data_name, value1, value2)
      end
      name
    end

Somehow within the last 3 days of work, something changed so that it now errors out...

As you can see, its reporting that the string format method is called with too many arguments...

Here is the method caller. A simple reference to the items effect list object.

    #--------------------------------------------------------------------------
    # ? Points towards either feature name or effect name
    #--------------------------------------------------------------------------
    def self.trait_name(trait)
      if trait.is_a?(RPG::BaseItem::Feature)
        return self.feature_name(trait.code, trait.data_id, trait.value)
      end
      self.effect_name(trait.code, trait.data_id, trait.value1, trait.value2) #<--- Here
    end

However, when I load up my build from three days ago, it works fine. The object in question, is syth-able like normal.

When I load up today's build, that error occurs, and NOTHING on the database object (ID:2) has changed at all... However, removing the restore trait, (the data that's causing the error) prevents the error from occurring.

Now I have looked through every script I've edited in the last three days and NONE of them touch RPG::UsableItem::Effect as to cause the data that was working just fine three days ago, to suddenly start throwing an exception.

So, I am left wondering if the database is the problem? Or am I misunderstanding how sprintf works?

In his method, base_name references his default string formats... And in this particular case, the code is 11 HP Recovery.

    EFFECTS_CODENAMES = {

    11 => 'HP Recovery'                   , # HP Recovery
    12 => 'MP Recovery'                   , # MP Recovery
    13 => 'TP Recovery'                   , # TP Gain
    21 => 'Add %s'                        , # Add State
    22 => 'Cleanse %s'                    , # Remove State
    31 => '%s+'                           , # Add buff
    32 => '%s-'                           , # Add debuff
    33 => 'Dispel %s+'                    , # Remove buff
    34 => 'Cancel %s-'                    , # Remove debuff
    41 => 'Escape'                        , # Escape
    42 => '%s Bonus'                      , # Permanent stat growth
    43 => 'Learn %s'                      , # Permanent skill learning
    44 => 'Common Event'                  , # Common event

    }

As you can see, there are no %'s for sprintf to replace with value1.

The strings in question haven't changed. The data in question hasn't changed. Yet, suddenly, string format doesn't want to work.

If I hadn't shaved my head, I would be pulling my hair out by now.

[Roguedeus]

I don't expect you to divine the cause from what little I've provided... But if you could nudge me a little by throwing some places I can look, I may not be thinking of, I'd appreciate it.

[Roguedeus]

Also, item instances is not causing the problem. Removing the instance script (old and updated) has no effect on the result.

[Roguedeus]

WTF?!?!?

It is the $TEST variable being flagged true that's causing the problem.

How on earth is that possible?!?

[Roguedeus]

I just went through the dozen or so scripts that actually use $TEST as a facilitator for otherwise unperformed activity, and commented each one out to see if they effect the result and none of them do. Which leaves me wondering how in the hell flagging $TEST is causing the string format method to throw an exception?

[HimeWorks]

I don't know how the $TEST variable might be a problem but you should look at why

name = sprintf(base_name, value1, value2)

is being used when the method is being called by

self.effect_name(trait.code, trait.data_id, trait.value1, trait.value2)

It is pretty obvious that data_name is nil, but the only way that could happen is if the code doesn't match any of the cases.

[Roguedeus]

Im not sure what you are asking... I posted the effect_name method Kread-Ex uses to return the formatted string, to show that the sprintf method is the one with the error and that the data being sent to it is simply the RPG::UsableItem::Effect data through the trait_name method.

The screenshot error shows this is the Alchemical Synthesis script method that grabs the code from the Traits Namer script.

  #--------------------------------------------------------------------------
  # ? Displays the item's traits
  #--------------------------------------------------------------------------
  def draw_item_traits(item)
    max = KRX::SYNTH_MAX_TRAITS
    change_color(system_color)
    contents.draw_text(0, 0, width, line_height, KRX::VOCAB::TRAITS)
    change_color(normal_color)
    (1..max).each {|i| contents.draw_text(0, line_height * i, width, line_height,
    "#{i}.")}
    item.traits.each_index do |i|
      break if i == max
      name = KRX::TraitsNamer.trait_name(item.traits[i])  #<--- Here
      contents.draw_text(24, line_height * (i+1), width - 24, line_height, name)
    end
    draw_horz_line(line_height * 5)
  end

[Roguedeus]

Either I am missing something obvious, or there is some mystery interaction going on with $TEST and RGSS3 somewhere.

Unflagging the $TEST boolean stopped every single one of the sprintf issues with that script. I didn't mention that every single use of that method, only in that script, was causing the same error for having to many arguments... It is completely dumfounding to me.

[Roguedeus]

Ok, I just found this... So I think I might also need to mention that I had been manually flagging the $TEST variable at the beginning of my script collection. I thought it was necessary.

Apparently, its done automatically. However, oddly, I had to manually flag it in order to get Game_Interpreter to see it in my scripts... Which is now confusing me even more.

Of course, it was some time ago when I started doing that and I honestly can't remember why I did.

[Roguedeus]

I apologize if I am not offering you enough info for a clear picture. I'll close it to get it off the front page.

I have not found any more info than the contents page for anything regarding $TEST. Even if this was a script interaction issue, in spite of my not finding anything in code search related to $TEST that could possibly cause it, manually flagging the variable causes only that script to break, where at least a dozen others make similar use of the same ruby method, with no trouble at all.

By now the curiosity has got me unwilling to leave it be.

[HimeWorks]

What is the value of code in the effect_name method?

[Roguedeus]

It appears to be the feature ID. As its used to reference the EFFECTS_CODENAMES string, in the example above, for its name.

[HimeWorks]

What is the ID?

[Roguedeus]

Sorry, its 11. HP Recovery.

[Roguedeus]

Just so you know. Removing the effect from the item just moved the error to the effect of the next item... The error wasn't linked to the particular item type either. Equippable item features also caused errors.

The issue was the string format method, every time, saying too many arguments were present.

[Roguedeus]

Actually, don't worry about it. If it causes any more trouble, I'll take more time to make a demo so there is as little to back and forth as possible.

Thanks for the attention though.

[HimeWorks]

If the value of code is 11, then it is clear that it's going to fail.

   data_name = case code # <--- no case for 11, going to be nil
        when 21, 22
          $data_states[data_id].name
        when 31, 32, 33, 34, 42
          Vocab.param(data_id)
        when 43
          $data_skills[data_id]
        end
      if data_name.nil? # <--- true, from above
        name = sprintf(base_name, value1, value2)  #<--- Here
      else
        name = sprintf(base_name, data_name, value1, value2)
      end

[Roguedeus]

Hmmm. I'm gonna have to check that to make sure its 11.

[Roguedeus]

Well now that is strange...

It is 11 and yet, when $TEST is not manually flagged, it works fine.

Also, if data_name couldn't be nil, how was that the method that broke the script? boggle (I had not seen that as it never occurred to me that the original string could be blank as its clearly HP Recovery every other time)

[Roguedeus]

Sh*t... I can't believe I did this.

It wasn't $TEST I was flagging. It was $DEBUG

I had one of my dyslexic attacks yesterday and every time I looked at $DEBUG I saw $TEST in my head. I can't explain it. It is rarely that extreme, as normally its only a matter of not realizing very similar words apart, or which direction a letter faces... But sometimes, I literally replace entire words in my head.

You can imagine how frustrating it can be when doing something as touchy as programming.

It only ever happens with written/typed words. Nothing else. My brain has serious issues with symbol = sound and symbol = word pattern processing. Though I am a wizard at most manual tasks and abstract intuition.

[HimeWorks]

So how does $DEBUG make a difference?

data_name can be nil, but it should only be nil for features.

[Roguedeus]

I am not sure if it does. I just figured I'd mention it as I had been complaining that it was $TEST and I was wrong.

I've gone through my scripts and replaced all references to $DEBUG and changed it so I don't have to use it as the RGSS default.