Blizz-ABS-Can Enemies Animate Like Actors?

[Untitled]

After a painful search, I was surprised nobody's tried this (or maybe they have but with more success than me)

5.1 (Sprite Reference), among other places, of the manual says that a lot of animations are Actor-only. Is it possible to make enemies have the same type of jumping, guarding, etc. animations, preferably with variably visual weapons?

And of course the better question is, if so, how?

May as well specify that this is 2.84 of the Blizz-ABSystem for XP.

Oh, and a general question about RPG Maker XP: can character animations be longer than 4 frames?

[ForeverZer0]

Not sure about the BABS question, but animations can, and usually are already longer than 4 frames.

[Untitled]

"usually"? Character animations or action animations? I've never seen a character with any number of frames but 4 ._."

[ForeverZer0]

I thought you meant animations, not characters.
There are scripts that do it in more than four frames, though.

[winkio]

Yes, enemies animate very similar to actors in Blizz-ABS.  Try reading section 2.

[Untitled]

Oh, awesome, thanks. But can enemies jump?

Also, can scripts be flat out modified mid-game?

EDIT: Also, can weapons have more than one animation? E.G. for a sword, one for swinging up and one for swinging down? And then one for stabbing? Or is that best done, like, through combos? *doesn't know how combos work anyway*

[ForeverZer0]

You can modify script mid-game, actually a couple of ways. All the scripts are stored in a global variable: $RGSS_SCRIPTS
This variable is an array of arrays. Each element of the outer array is a script. Index[1] is the title, while Index[3] is the actual text of the script. The variable is created when the game is loaded by un-Marshaling the Scripts.rxdata file and storing it here. You could re-save new text into the proper script, and then re-dump it back to Scripts.rxdata. You need to use the proper way of storing it though, since RMXP uses the Zlib library to compress the data when saving. This will only solve half of your problem though. It will use the new script next time the game is loaded, but not at that very moment. To do that you have to "require" the script to load it into memory. That's pretty simple though. Save your script with an .rb extension, and then in a script use this line:

require 'PATH AND FILENAME OF RB_FILE'

[Blizzard]

@F0: That doesn't work so well in RMXP, it has to be done in a different way.

Also, can scripts be flat out modified mid-game?

If you mean change the scripts while the game is running, then no. If you mean save and exit the game, add a new script and then load the save game, it works only with scripts that don't add any additional save data and most scripts do add additional save data.

[ForeverZer0]

You can so add scripts during runtime. I have actually created code to built a class with methods while running that didn't exist when the game started running, and I'm not talking about "requiring" anything, but using "module_eval", "class_eval", "send", and blocks of code. Ruby is one hell of a dynamic language.

I'm saying "yes", you can. What does this do then?

YOUR_OBJECT.class.send( :define_method, :YOUR METHOD_NAME ) { BLOCK }

[Blizzard]

I know that you can add stuff anytime, I am saying that inserting completely new functionality that alters already existing functionality is complicated as hell. How would you go about rewriting the method that is loading the modified code? Or about adding a new method and new variables to a scene? You would have to make either a new instance of the object (and therefore exit the current scene for a moment, even if it's just for restarting the changes) or you would have to add everything during runtime and making sure the already created instance of the object has the stuff added as well (because if you change a class, the already created instances are not altered). Why do you think I require people to re-instantiate BlizzABS::Controller once new methods have been added or methods have been aliased? Because they are not added to the instances in runtime. And adding code that would allow that is so much of a hassle that, if this is the way somebody would go about implementing some functionality, I would consider that somebody doing it wrong.

Also, he asked whether the already loaded scripts can be changed. They cannot. Already loaded scripts cannot be changed. You can add stuff, but you cannot change already loaded stuff.

[ForeverZer0]

Not to be argumentative, Blizz, but you are wrong. You can add instance variables to existing instances without re-initializing a new one.



EDIT:

You can also simply do something like this.

class MyObject
  # Empty class
end

obj = MyObject.new
meta = class << obj; self; end
meta.send(:attr_accessor, :var1, :var2)

obj.var1 = "Look at me, I'm a new"
obj.var2 = "instance variable in the instance obj"
puts obj.var1, obj.var2

A am not saying this is wise to do by any means, and I too consider bad practice. Just wanted to say that. I see no reason why you would ever need to do it this way.

[Untitled]

Um, yeah, I doubt I'll be doing any of that any time soon 

As for animations in general, can animations be specified to play when a character receives damage?

Also about animations, can spell/attack animations shake the screen? (Like for an Earth-based spell)

[Blizzard]

@F0: I was talking about methods and aliasing, not about variables. Adding variables is not a problem.

[Ryex]

could you do a sudo alias / emulate the functionality? simply define the new method name and set to to the old method object. at the point the methods will have two names. then over write the old method


I would get complicated as hell but it can be done. why you would want to do this or what practical purpose it would serve is a completely different story though.

[ForeverZer0]

There are multiple ways, but all our ugly.
The "send" function basically lets do whatever you want, since it allows invoking all the private functions Ruby uses to construct objects, that wouldn't normally be available.

Like you said, though, all this is really nothing more than interesting. It serves no real practical purpose to someone who actually wants to make a script that is not a complete pile of unplanned bullshit.