Closed Roguedeus closed 10 years ago
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.
Also, item instances is not causing the problem. Removing the instance script (old and updated) has no effect on the result.
WTF?!?!?
It is the $TEST
variable being flagged true that's causing the problem.
How on earth is that possible?!?
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?
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.
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
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.
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.
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.
What is the value of code
in the effect_name
method?
It appears to be the feature ID. As its used to reference the EFFECTS_CODENAMES
string, in the example above, for its name.
What is the ID?
Sorry, its 11. HP Recovery.
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.
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.
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
Hmmm. I'm gonna have to check that to make sure its 11.
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)
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.
So how does $DEBUG
make a difference?
data_name
can be nil, but it should only be nil for features.
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.
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.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.
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 is11
HP Recovery.As you can see, there are no %'s for
sprintf
to replace withvalue1
.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.