Moonpearl

Of course not! Unless explicitly you set those events to "Through", they're impassable like any other events.

This all makes me think that rather than trying to rewrite everything from scratch, you'd better just treat your followers as events, so they would already process passability and stuff like that by themselves.

Then the guys who made that stuff clearly bungled. Where can I download their source code?

Does your Pokémon stuff work with Scene_Base alone?

As long as you use outside sources, no matter how little code you took from there, you have to credit them. You can call it your own only if you rewrite the whole system from scratch.

That's my point. The part of my Keywords system that raised the error you got is completely independant from RMXP's default engine, you could remove it completely and put anything in its place, it would make no difference. That's why I'm saying it can't possibly be a compatibility issue.

I think you're merely misusing my script, or didn't install it properly. The method which raised the error works only with variables which are exclusive to itself, there's no reason why using another script along with it would make it crash.

What's this Scene_PalletTown supposed to do?

You're welcome.

Well the, you're a luck guy, because i have exactly what you're asking for in store here. You still have only four choices, while prompted with keywords to ask for, you can cycle through them using L and R.

Technically speaking, it's possible, but how are you going to handle that in the project editor? When inserting a Show Choices command, the GUI does not allow for more than 4 choices, even if the script that processes those choices could handle more. And besides, what do you want this for?

Updated the script with a new feature - face display beside balloons. The following screenshot was obtained using only a Show Picture event command - the frame and the picture's position are entirely managed by the script.

Ever tried using a character maker? I have, and have found out that most makers have too few materials, or lack essential features, or can't be used with custom images, or use graphics which clash with RMXP's style, or which are otherwise ugly... and sometimes all of that. Making my own was an option I had been considering for a long time, so when JonBon asked whether someone would come up with a complete and handy maker, I felt it was the right moment for me to show off. That's how, within a few days, I'd completed this utility I'm pretty proud of. Purpose Make your own character sprites with a handy, complete maker. Main features Edit the hue, brightness and position of each feature individually, or edit all features at once Preview changes before applying them See your character animated while editing it Change the superposition order at will Render your characters as .PNG images or assign them to the player to test them live Save your characters as presets and reload them later to make new variations rather than start again from scratch Expand the libraries with your own custom graphics by simply adding files to the image folders, the program autodetects them Growing and collaborative materials database, updated regularily with new resources Known issues Few materials so far, and only for chubby sprites - but JonBon's working hard on this! Screenshots Download See my blog entry. Notes Thanks to Zeus81 for allowing the core feature of this utility to exist at all. Thanks to JonBon for working hard on the graphic materials.

Thanks for reporting the bug. Nothing too bad actually, just a stupid mistake. Look for the following (normally in Interpreter entry, line 9): def initialize(depth, main) ...and replace it with: def initialize(depth = 0, main = false) The upload was fixed as well.

You're welcome, it was a big personal challenge and I'm glad I was able to take it. You'll see it soon enough, in the next release for ACMS.

Oh, okay. Thanks bigace, I'll make sure to get some more good stuff done.

You forgot to edit the font settings. The version you have is set by default to use a font that is probably not installed on your system. You may re-download the demo if you can't figure how to do this, I uploaded a fixed version.

Sorry?

That's the point, Spriteset_Map objects are never referenced by global variables in RMXP's standard scripts, they are created by Scene_Map. So what you need to do is set :spriteset_map as an attr_reader in the Scene_Map class, and call: $game_map.spriteset_map

That'bad, but unless you're more specific, I cannot help you.

There. i hope this satisfies your request: http://www.rmxpunlimited.net/forums/topic/8377-balloon-messages/

While looking around for balloon messages sytemes, I noticed two things - first, the balloons are often ugly and second, they are often part of a broader custom messages system, which forces you to use that system. So I wondered if there was possible to make a balloon system that would be independant of any custom messages system, and how to make visually appealing graphics for balloons. And here's the result. Purpose Easily make dialogs using fully customizable balloons. Main features Fully emulates RMXP's standard messaging functions, including color change and actor name substitution, and possibly those of other custom messages systems. Fully customizable font type and size - see the balloon adapt dynamically around your constraints. Fully interfaced with RMXP's eventing system - no script call or any funny stuff like that ever. Customizable, full-color graphics for balloons using a unique Balloonskin module - which works pretty much like Windowskins. Three Balloonskins (normal, thinking, angry) featured by default. Multiple balloons may be displayed simultaneously. Theoretically compatible with other custom messages systems. Known issues Small latencies occur upon loading a Balloonskin for the first time, because they require prior processing before they can be used. To avoid this, all Balloonskins may be precompiled upon launching the game, thus making it longer to start (activated by default). Contrary to what one would think, this script should not clash with other custom messages systems because it does not rewrite the Window_Message class. It is not guaranteed that outsider functions will work absolutely properly, but at least they shouldn't make the game crash. Screenshots Download See my blog entry.

Errrrrrr... no. Dunno what you're trying to achieve with such a command but I hardly doubt it will accomplish anything. This is a Regexp (regular expression). I suggest you see some official Ruby documentation to fully understand its syntax, however what this one exactly means is: any expression featuring "\", then "cat_actor", then "[", then a number with any amount of digits (character between 0 and 9 with the symbol +), then "]". So what gsub does with this one is look whether the given string fits that description or not. For example "\cat_actor[01]" is a suitable candidate. As to the $1, it gets a little more tricky. You can see in the Regexp that the number is surrounded by brackets. This means that if the string fits the Regexp, gsub will capture the value between brackets (for instance the number), and put it into $1. This vaue is then assigned to the variable @caterpillar_actor. So, in short, this line is checking a String (wherever it might come from) against a pattern, and if the pattern is matched, it captures the number that was specified in said String for further use.

Well then you should've tried because you actually can. Don't forget brackets around [X,Y] though. @move_list.include?([X,Y])

That's not it. It's not compatible with my Scene_Base script, which I include in all of my scripts.This is pretty sad considering I gave my best to write it so that no compatibility error would show up, that's the first time I encounter one. I had a quick look at your code and it seems like it has a problem with you adding a parameter to Window_Message#initialize. What I don't understand, though, is why it crashes with my script and not without it. I mean, if you've correctly overriden the Scene_Map class so that it doesn't create a Window_Message in the old fashion anymore, this should not be a problem, with or without a Scene_Base modified Scene_Map.