All right, I'm making an edited Vampyr SBABS, mainly for higher compatibility, and it seems to be coming along fine. The only problems are:
1) When I add an actor to my party, I get the following error, and nothing I do has any effect:
Script 'Vampyr SBABS' line 2326: NoMethodError occurred.
undefined method 'piece=' for nil:NilClass
What is being overwritten to cause such an error?
2) In addition, I'm wondering about how the animations are handled. When I use a skill, that skill's animation is played. But if it's set to Same As Normal Attack, no animation plays at all. What I'm trying to do, is cause it to default to a normal SBABS attack, or at least play the animation that is actually the same as a normal attack. The only problem with that, is that I don't know the values for the animation when set to anything not an actual animation, and not none.
3) Finally, it seems to modify Scene_Item unfavorably. What I don't understand, is why an alias would remove an overwrite that is already ABOVE the alias. It's as if the alias is deciding it wants to overwrite and redefine instead of aliasing the method as it should. As an added note, the same thing is done with Scene_Skill, only Scene_Skill functions as it should. It might be worth mentioning that the overwriting method is from DRIACS.
4) Everything else works, including enabling of Tankentai. Honestly, it's just a re-enabling of the default encountering system. (Would something in Tankentai be causing my only error message?)
Edit:
#1 & #3 resolved.
Full Version: Vampyr SBABS - Extra Compatibility Questions
>.> I think we need to see your code before we can answer..
Anyway
This is my way of doing things
Anyway
This is my way of doing things
CODE
# For methods that need something important and something nil might come along
def something(object = nil)
return if object.nil?
end
# For Loops
for object in a_whole_lot_of_stuff
next if object.nil?
end
def something(object = nil)
return if object.nil?
end
# For Loops
for object in a_whole_lot_of_stuff
next if object.nil?
end
For #4, try removing tankentai and see if that fixes #1.
#2, have you tried adding an animation to the weapons, not only the skills as well?
#2, have you tried adding an animation to the weapons, not only the skills as well?
QUOTE (IceDragon @ Nov 12 2010, 05:50 PM) 
>.> I think we need to see your code before we can answer..
Yes, we do, but...
QUOTE (IceDragon @ Nov 12 2010, 05:50 PM)
Anyway
This is my way of doing things
This is my way of doing things
CODE
# For methods that need something important and something nil might come along
def something(object = nil)
return if object.nil?
end
def something(object = nil)
return if object.nil?
end
This is actually the opposite of what you should be doing (also, what is the point of a default argument value of nil if you are just returning? The purpose of a default argument is that you can actually do something useful with the default value, not create an error condition). All that you are accomplishing is hiding an error instead of fixing it. Crashing is preferable to a silent failure 100% of the time. At least when a program crashes you know where to start looking. When something doesn't work right but doesn't completely fail either you spend a lot more time tracking down the root cause.
If something should never be nil than my program better damn well tell me when it is instead of ignoring it. This is sometimes referred to as a "code contract", i.e., something that should be guaranteed to never happen. A dead program normally does a lot less damage than a crippled one, so crash early and often. This is coming from years of software engineering experience.
Here is the relevant excerpt from that link:
QUOTE
Crash Early
Bill Venners: In your book you suggest we try to detect problems as early as possible, so we can make the program crash before it does damage. I have often felt the need for a ShouldNeverHappenException in Java. I'm programming along, and I get to a case that I'm confident will really never happen. But just in case it ever happens, I want to throw an exception there, but what exception? I usually end up throwing a RuntimeException and putting in a comment that "This should never happen." But it takes time to add that throw statement, as does any way of crashing early. Checking every pointer in a C program for null before it's used, for instance, would take a lot of time. Where do you draw the line? How do you decide the investment is worth it?
Dave Thomas: That's interesting, because quite often you don't have to do anything special to crash early. For example, as long as you're sure a nullpointer is going to cause an error immediately, then I don't see much difference in throwing a random RuntimeException or throwing a NullPointerException. The bad thing is to propagate an error.
The reason you crash early is to stop errors from propagating far away from the cause. Because once you have an error that's a million instructions away from the cause, finding the cause is a pain in the butt. Quite often, the check is done for you by the compiler. What we're trying to say is when the checks are not put in by the compiler, that's when you start needing to put the checks in yourself.
Andy Hunt: It's more an issue of localization, keeping the crash near the cause.
Bill Venners: You write in your book, "When the system does fail, will it fail gracefully?" And in a footnote, you write, "Our editors wanted us to change this sentence to, 'If the system does fail...' We resisted." Why?
Andy Hunt: We actually quite deliberately put in "When." I think we had this argument in a draft of the book. Somebody else reading the draft made the same comment, that we should say, " If the system fails..." No, that's wrong. It should be, "When the system fails..." Every system fails. There is no such thing as perfect software. So part of phrasing that sentence that way is to encourage people to get over this in-bred arrogance that the system can't fail. Of course it can. Every system can fail. The question should not be, "Can the system fail?" It should be, "When the system fails, how are you going to handle it?"
Bill Venners: In your book you suggest we try to detect problems as early as possible, so we can make the program crash before it does damage. I have often felt the need for a ShouldNeverHappenException in Java. I'm programming along, and I get to a case that I'm confident will really never happen. But just in case it ever happens, I want to throw an exception there, but what exception? I usually end up throwing a RuntimeException and putting in a comment that "This should never happen." But it takes time to add that throw statement, as does any way of crashing early. Checking every pointer in a C program for null before it's used, for instance, would take a lot of time. Where do you draw the line? How do you decide the investment is worth it?
Dave Thomas: That's interesting, because quite often you don't have to do anything special to crash early. For example, as long as you're sure a nullpointer is going to cause an error immediately, then I don't see much difference in throwing a random RuntimeException or throwing a NullPointerException. The bad thing is to propagate an error.
The reason you crash early is to stop errors from propagating far away from the cause. Because once you have an error that's a million instructions away from the cause, finding the cause is a pain in the butt. Quite often, the check is done for you by the compiler. What we're trying to say is when the checks are not put in by the compiler, that's when you start needing to put the checks in yourself.
Andy Hunt: It's more an issue of localization, keeping the crash near the cause.
Bill Venners: You write in your book, "When the system does fail, will it fail gracefully?" And in a footnote, you write, "Our editors wanted us to change this sentence to, 'If the system does fail...' We resisted." Why?
Andy Hunt: We actually quite deliberately put in "When." I think we had this argument in a draft of the book. Somebody else reading the draft made the same comment, that we should say, " If the system fails..." No, that's wrong. It should be, "When the system fails..." Every system fails. There is no such thing as perfect software. So part of phrasing that sentence that way is to encourage people to get over this in-bred arrogance that the system can't fail. Of course it can. Every system can fail. The question should not be, "Can the system fail?" It should be, "When the system fails, how are you going to handle it?"
>.> The times I use that, is when the object is allowed to be nil, but would cause an error if it continued.
O.< Currently I have no examples on me though..
But as I said we need to see the code before I can make a valid fix.
O.< Currently I have no examples on me though..
But as I said we need to see the code before I can make a valid fix.
QUOTE
#2, have you tried adding an animation to the weapons, not only the skills as well?
All of my weapons have animations set to them. I simply want to be able to set a default animation to be played for skills if they don't have an actual animation with an id set.
QUOTE
All that you are accomplishing is hiding an error instead of fixing it. Crashing is preferable to a silent failure 100% of the time. At least when a program crashes you know where to start looking.
That is very true. It took me a while to figure out my "patches" for the map screen were causing the HUD to appear under the map... It took even longer to figure out that KGC_TilesetExtension was messing with the passability for the SBABS's enemies. I simply removed the passability portions from that script, to retain only the terrain tags feature.
QUOTE
But as I said we need to see the code before I can make a valid fix.
No need... #1 was because of KGC_LargeParty... Seems as though that's where I'll need to start looking. I feel like a noob.
Offtopic - There's actually 5 scripts that are currently conflicting, though they shouldn't be too hard to fix...
QUOTE
3) Finally, it seems to modify Scene_Item unfavorably. What I don't understand, is why an alias would remove an overwrite that is already ABOVE the alias. It's as if the alias is deciding it wants to overwrite and redefine instead of aliasing the method as it should. As an added note, the same thing is done with Scene_Skill, only Scene_Skill functions as it should. It might be worth mentioning that the overwriting method is from DRIACS.
I was aliasing the wrong method. How incredibly noobish of me.
QUOTE (IceDragon @ Nov 13 2010, 04:20 PM)
>.> The times I use that, is when the object is allowed to be nil, but would cause an error if it continued.
Well, I would call that a poor design, but I was responding to your suggestion in this specific case where these objects obviously should not be nil.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.