Moonpearl

Ah, now that's another story. I think I can do it but it would require much, much deeper rewrite. I'll give it a try and stay in touch.

I might have what you need. It actually simply displaces the message window so that it anchors to an event, so basically you just need to set a game variable before each Show Message event command. I could just replace the windowskin with bubble graphics. Also, you're asking to keep the default font, does that include size as well? Because it makes pretty large bubbles (although then you're absolutely sure that everything fits). Glad you like my CMS by the way.

Game_Party#actors contains Game_Actor objects, so you have to check for the presence of $game_actors[<id you want to check>]. $game_party.actors.include?($game_actors[<id you want to check>])

The Verbal Interaction System takes the Keywords System one stup further on my quest to cross modern RPGs with old-school point&click and text-based adventure games. You still have to use keywords to interact with your environment, but now actions are keywords as well - meaning you have to specify whether you want to examine, open, pick up objects, just like in good ol' Lucas Arts. This is perfect for puzzles because the player is forced to give a little thinking to what he does, clicking anywhere like crazy doesn't accomplish anything, unlike in your everyday RPG. Purpose To be able to interact with events using action names and inventory items. Main features Programming responses to actions with the eventing system is as easy as: if selected action is PICK UP, then change items ("Potion" +1) Cycle through known actions using the HUD Each object is assigned a default action with a specific button as shortcut You may also easily combine items from your inventory with objects Known issues Uses no less than 7 buttons. Better use a joypad if you have one, or at least redefine controls using F1 Controls C (keyboard ENTER or SPACE) - Use default action on object B (keyboard X or ESC) - Use selected action on object A (keyboard W) - Use item/Combine item with object L/R (keyboard A/Z) - Cycle through available actions L+R (keyboard A+Z) - Manually enter new action keyword Y/Z (keyboard S/D) - Cycle through items Screenshots Download See my blog entry.

Isn't there an "Ignore if can't move" option for this?

I'm not talking about the initialize method, but the update method. It's only natural that you would get an error calling Window_Base#initialize without the 4 parameters it requires (x, y, width, height).

Well, you should be getting one with this, wondering why not Okay... I'm still reading "@move" at lines 52 and 60 Neither, we're talking Ruby. I think it must be because you used uppercase characters in the alias (uppercase names are constants and unsuitable for method names)

I'm not saying you should use mine, only that the fact that I didn't use such methods is proof they're useless. Of course you're free to write code in whatever bizarre way you may think of, as long as you let me do likewise on my side. Notes: move_x and move_y are still unknown variables in your start method I'm wondering why you're declaring current_x and current_y as accessors since they don't appear in your script you wrote "move" in your update method instead of move_x/move_y you aliased the update method alright, but you still need to call the older version, you're not accomplishing anything by aliasing it otherwise

My script scans the folders for image files and allows to cycle through those files using left and right arrows. To keep things simple; what I could do is have, say a bunch of shirts named shirt00, shirt01, shirt02... along with coats named coat00, coat01, coat02... together as "outfit" variations, and be able to use a button which will automatically search for the first "coat" graphic when a shirt is being selected, and vice-versa. If materials are well-organized, you could then cycle through "kinds" of pieces, then look for the appropriate one using the standard arrows. This could keep the search relevant, while remaining easy and clean in a scriptwise perspective, since the script would just need to search for a file that doesn't match the naming pattern of the one being viewed. Regarding color change, I've already included the possibility to change each layer's hue. So what I suggest is have all basic graphics in a standard color (say red for hue = 0), that you could then change at will with no need to look for a different piece. Making all graphics into a standard color seems important to me since it will allow users to cycle through features while keeping the hue they've selected. Say you want a character with blue hair, you first adjust the hue of any piece of hair to blue, then if all hair pieces have the same basic color, they will all be displayed as blue when you cycle through them. However, I suggest including darker and/or lighter variations, at least for hair, because originally blond hair won't turn brown by adjusting hue, but orange instead. Other than what we're discussing right now, my script's all set and only awaits your materials to go.

I figured as much myself, the problem is that using only RGSS buttons you can't do anything but cycle through the different pictures. However the buttons may be held down to fast forward, and I can also include a "cycle by 10" feature. I'm awaiting some material to finish my script if you don't mind since i'm really too lazy to separate some characters' layers myself. That way I can also see for myself whether everyting's fit to the way your organized the different parts.

Replying to myself ('cause a little thinking doesn't hurt after all) I got it: you want a window that shows a preview before changing the selected parts, and another with a preview using the picture you're currently browsing, right?

Sometimes it's the simplest things we forget first. Take my students for instance, most of them can calculate a derivative and stuff like that, but cannot do additions anymore.

Okay, I get your point. I hadn't thought of that at all. How would you make a difference between both windows, though? I mean, my windows updates in real-time according to the parts that are being selected at the moment, so you would need to "lock" another view or something, right? I also had a "cycling" architecture in mind. However, I agree that it's not suitable for a large number of parts. How would you handle the selection? That, however, wouldn't happen. My program remembers which picture was selected for each part (wouldn't be able to display it otherwise).

Pretty lame for a program that's supposed to generate pictures.

Isn't it simple RGB addition/substraction? This seems to make sense to me since in Add mode, black is neutral, while white is neutral in Sub mode.

Well, the script I wrote does exactly what you need and as you can see, no move_win_x/move_win_y.

I have no idea what you mean. No, it only matters for a same and only window. The way your code is written, each window checks if it should move horizontally, and if so, it doesn't test whether it should move vertically, hence the impossiblity to move along both axes for a single window. It's no failsafe at all, it's a redundant... redundancy. The thing is, either you set the movement once and for all using a method (like in the script I wrote) and checking whether you should move serves no purpose at all, either you have the script check by itself if dest_x and/or dest_y were changed by a third party object, and thus if movement should occur - but in this case, there's no need to put those tests in separate methods, like you would if you were to call them from several places, just put their content directly into the update method.

Never used character maker XP. In what extent is it not efficient? Oh, my goodness, no, no raw code. Basically you'll have a menu in which you can select parts to edit, and for each, which picture to load. A window to the right will display the result, i.e. the parts layered in order to form the final picture which you can then export as an image file (and even test live since you're in RMXP). Possible features include hue changing for each part, pixelwise position adjustement, layers order changing, stuff like that.

In a single statement, no. However, you could do this: MNK_POSES_ENEMY = {} (1..9).each do |i| MNK_POSES_ENEMY[i] = 4 end Which is not very clean because constants aren't supposed to be modified, even though Ruby allows it. Another possibility is to keep MNK_POSES_ENEMY empty, but set its default return value to 4: MNK_POSES_ENEMY = Hash.new(4) You could bind some IDs to a different number afterwards, which once again is not very clean, but each ID which is not present in MNK_POSES_ENEMY will return 4.

This is not exactly what you're asking for, but i'm working on a RGSS charset maker. This acts as a RMXP script of which purpose is to generate image files from a combination of "parts", so of course you could include whatever "parts" you like by simply adding the image file to the Graphics/Pictures folder - thus this could be a collaborative project with a growing resources library. Let me know if you're interested.

The script takes a portion of the spritesheet by dividing its width and height by a certain number (for instance, 4 and 11 respectively). So the only constraint regarding the spacing is that each frame must fit in a AxB cell, A being the forth of the total width and B the eleventh of the total height. So basically if you wish to optimize the spacing you need to find out the maximum width among all of your frames and the maximum height, so you're certain that all will fit. This said, you may as well have 192x192 cells with lots of unused space, it doesn't make any difference to the script, only to the picture file's size.

Your custom battlers most likely don't have the right number of rows. Since the script has no way to detect how many rows were drawn, it has to trust the user blindly, so if you happen to give it spritesheets with a different number of rows, it will split them incorrectly.

The : is the marker for symbols. Symbols are sort of hybrids between integers and strings: they are commonly used to designate something internal with a name rather than a number (typically variables or methods), but they're not meant to be displayed. You see them used with attr_reader and attr_accessor statements, to designate the instance variable with the same name. In the case of method aliasing, you can write method name either as is or as symbols, so both those syntaxes work: alias old_method method alias :old_method :method

You can't. They aren't coded in Ruby but in C. All such RGSS classes are featured in the dlls. However you can alter them like regular classes, only you'll have to figure out by yourself what the actual code should be like.

Well, make a single common event which tests each evolvable actor for the required conditions in turn.