02-18-2023, 01:52 PM
(This post was last modified: 02-18-2023, 02:08 PM by Kain Nobel.)
The first issue I see is Sprite_Character < Sprite_Character.
Were you intending to do something like Sprite_Equipment < Sprite_Character ? I suggest studying the topic of Ruby class inheritance.
I would suggest studying how alias or alias_method is used to add new code to pre-existing methods. By calling an alias, you're making a call to the original method definition, and you can add new code above and below the alias call. This allows you to extend an existing class without editing the original source code.
Here is how I would refactor the script...
Sprite_Character
Sprite_Equipment
Now that I've provided you some slightly better structure hopefully you'll have an easier time with your script. This is by no means a finished work, just a starter example, so you'll still have to do some work in regards to refactoring your existing code for the new format.
I've already provided a little bit of code in the Sprite_Equipment#update method which should keep your Z value synchronized with the Sprite_Character. If you start adding more than one piece of equipment, you may need to re-prioritize the Z stack. You'll have to ask yourself "do the boots go above the pants, or below? Is this a hard-defined rule, or is it situational and flexible?" That's beyond the scope of this help topic, you'll have to figure that out on your own.
Please note that I'm using Sprite_Character's viewport as Sprite_Equipment's viewport; if the accessory is larger than Sprite_Character's graphic, you may have to create a new Viewport object with modified dimensions. It would need to retrieve the width and height properties from the equipment's bitmap.rect. You might also need to modify the X and Y of the Viewport (synchronize them with the Character's X and Y, but modified.) I did not address this issue in the sample code, I only focused on synchronizing the Z value, so you'll have to implement your own solution.
What JayRay linked above would probably be the best thing to look at (or use) because I don't know how to explain it any better than that system would. Maybe it has exactly what you need already.
Hopefully I didn't overload you with too much information. There is a lot of different aspects to think about when making a visual equipment system. I'm not discouraging you from writing your own, but I would definitely suggest checking out existing visual equipment systems and getting more study time in with the Ruby language. Figure out what you like VS what you don't like and go from there.
Best of luck and take care!
Were you intending to do something like Sprite_Equipment < Sprite_Character ? I suggest studying the topic of Ruby class inheritance.
I would suggest studying how alias or alias_method is used to add new code to pre-existing methods. By calling an alias, you're making a call to the original method definition, and you can add new code above and below the alias call. This allows you to extend an existing class without editing the original source code.
Here is how I would refactor the script...
Sprite_Character
Code:
class Sprite_Character
alias_method :visualequip_spcharacter_initialize, :initialize
alias_method :visualequip_spcharacter_update, :update
alias_method :visualequip_spcharacter_dispose, :dispose
def initialize(viewport)
# Call alias method
visualequip_spcharacter_initialize(viewport)
# Create equipment sprites
create_equipment
end
def create_equipment
# Create an array for equipment layers
@equipment_sprites = []
# (Finish the method definition...)
end
def dispose
# Call alias method
visualequip_spcharacter_dispose
# Dispose of equipment sprites
@equipment_sprites.each {|sprite| sprite.dispose}
end
def update
# Call original method
visualequip_spcharacter_update
# Update equipment sprites
@equipment_sprites.each {|sprite| sprite.update}
end
end
Sprite_Equipment
Code:
class Sprite_Equipment < Sprite_Character
def initialize(sprite)
# Get character sprite
@sprite = sprite
# Parent method (Set viewport)
super(@sprite.viewport)
# Set Z value on top of character
self.z = (@sprite.z + 1)
# Refresh equipment graphic
refresh
end
def refresh
# (Your code goes here)
end
def update
# (Your code goes here)
# Set Z value on top of character
self.z = (@sprite.z + 1)
end
def dispose
unless (self.bitmap.nil? || self.bitmap.disposed?)
self.bitmap.dispose
self.bitmap = nil
end
end
end
Now that I've provided you some slightly better structure hopefully you'll have an easier time with your script. This is by no means a finished work, just a starter example, so you'll still have to do some work in regards to refactoring your existing code for the new format.
I've already provided a little bit of code in the Sprite_Equipment#update method which should keep your Z value synchronized with the Sprite_Character. If you start adding more than one piece of equipment, you may need to re-prioritize the Z stack. You'll have to ask yourself "do the boots go above the pants, or below? Is this a hard-defined rule, or is it situational and flexible?" That's beyond the scope of this help topic, you'll have to figure that out on your own.
Please note that I'm using Sprite_Character's viewport as Sprite_Equipment's viewport; if the accessory is larger than Sprite_Character's graphic, you may have to create a new Viewport object with modified dimensions. It would need to retrieve the width and height properties from the equipment's bitmap.rect. You might also need to modify the X and Y of the Viewport (synchronize them with the Character's X and Y, but modified.) I did not address this issue in the sample code, I only focused on synchronizing the Z value, so you'll have to implement your own solution.
What JayRay linked above would probably be the best thing to look at (or use) because I don't know how to explain it any better than that system would. Maybe it has exactly what you need already.
Hopefully I didn't overload you with too much information. There is a lot of different aspects to think about when making a visual equipment system. I'm not discouraging you from writing your own, but I would definitely suggest checking out existing visual equipment systems and getting more study time in with the Ruby language. Figure out what you like VS what you don't like and go from there.
Best of luck and take care!