Moonpearl

Depends on what you call "playable characters". If you mean like changing the character that appears on the map, it simply needs to be the first in the party, which you can achieve by removing all others from the party, then adding them again.

Wherever you like. That's the point of you leading your own learning course - before you get anything from your teacher you have to run into issues you can't solve beforehand, which gives you a chance to wonder about them and thus have your own insight (whether right or wrong, it doesn't matter) before getting the solution, instead of just being filled up with things you'd not even imagined yet. Besides, it ensures that you're interested in what you get to learn, which is important too. I can imagine there are tons of stuff you wish to ask and you don't know where to begin. You could start off with very basic questions, like "what does this statement do?" or "what is the difference between those two classes?", or on the contrary jump to sophisticated matters like "how do I program such a system?"... And don't worry, however complex the answer might be, I can always say "we would need to go through that other matter first" - which is, by the way, another reason why I don't feel like taking the initiative with what to study: I have no idea of your current level beforehand, so seeing what kind of questons you come up with will greatly help me determine it. Since you said you've already messed with RMXP base code, I'm sure there's stuff, however trivial, that you've always been wondering about.

This is the way I teach - I wait for students to come up with questions and then set up lessons and exercises adapted to answer them. So feel free.

Maybe not, but they know when there's something they don't understand, which the teacher can't possibly since he has to understand what he's supposed to teach. Also, the learner knows better what he doesn't know yet, so all in all I'd say he's in better position to know when to ask questions. Not necessarily. You know what you learned and in what order you did, but for one that's not necessarily the optimal course to follow, and second there's a possibility that the person you're trying to teach has a completely different learning style, in which case trying to impose your way of seeing things on them will be nothing but counterproductive. Also, when I mean the learner should lead their own course, it doesn't mean that the teacher is restricted from giving them advice (nor is the learner restricted to ask for some). What I'm saying is that it should be up to the learner what advice to follow and why choose this course over that. After all, they're not learning for your sake, but for theirs.

It's a little too empty to my taste. And the wrecked car feels out of place to me (in terms of graphic style).

One might run into problems I have yet to think of - but basically, the main issue I see is the fact that you can reprogram your game at will, but not the game-making software that helps you to design it. I mean basically you could very well make 3D games using RGSS, but this would not transform RPG Maker into a 3D world builder by magic.

Well, I might be a little old fashioned but that's the last thing I would advise to do. I believe the thing with scripting is not just to learn how to do things, but rather to learn how to think things. Well then, a tutorial is a pre-thought solution that might teach you a few things regarding Ruby and all, but it fails to teach you the most important step behind all this. Or at least that's my opinion. As far as I'm concerned, I've never used any scripting tutorials, I learned by myself just looking at RMXP's base code and trying to mess with it. Then I used Ruby documentation to try and determine how my ideas could be translated into code - but I had thought what I would program beforehand. That might sound trivial but I've received many requests from novice scripters who had come up with code that would technically work, but was so terribly badly designed that it would require rewriting it entirely for each single little add. Anyways, I would advise going through RMXP's base code before trying to do anything else, and then ask a teacher any questions that come to mind (I mean a person who explicitly agreed to take time and answer them) to help you get a better view of how things are done. I believe that a bottom-up approach works better than a top-down one (i.e. the training process is run by the learner, and only he decides when the teacher comes in, rather than the reverse).

Sorry, my bad. Replace @id with self.id and it should be fine.

Well, as far as I'm concerned, I'm all about teaching, but on the other hand I have the feeling that people who ask for help regarding scripts do not wish to learn anything - they just want stuff that works and they don't give a damn whether they've done it by themselves or not. Besides, scripting is probably the part of game-making which is the most difficult to get started with, so I believe it takes real commitment to actually take advantage of a scripting class, I mean you do not script casually, right?

We could use a tutorial on how to convert HTML into BBcode there. ;)

One way to do this is to change the Game_Actor's screen_x and screen_y methods. For example if you wish for all actors to read their initial coordinates from variable #1 and #2: class Game_Actor < Game_Battler def screen_x return $game_variables[1] end def screen_y return $game_variables[2] end end If you wish for each of them to read from a different set of variables (for example var #1 & #2 for actor #1, var #3 & #4 for actor #2...): class Game_Actor < Game_Battler def screen_x return $game_variables[1 + @id * 2] end def screen_y return $game_variables[2 + @id * 2] end end If you also want enemies to read from variables the same way, you should put the above in the Game_Battler class instead. And while you're at editing scripts, you can also save your variables for other uses and input constants directly in the screen_x and screen_y methods instead.

Using more than 4 frames for characters is possible, you just have to edit the part of the Sprite_Character class where it selects which block to select from the source picture. However, this will change the game's behavior, but not the RPG Maker software's - which means the events' graphics will appear scrambled on the map editor, since RPG Maker will keep thinking you're feeding it 4-frames characters, also you won't be able to select the 5th (or more) frame as the base graphic for events, for the very same reason. Stuff like that.

Restricted to 32x32. Nope, you have to make 96x128 blocks, lined up horizontally. For example for 2 frames you should have a 192x128 picture. Just look at the RTP's autotiles and see for yourself.

What you're looking for is in the Window_EquipItem class. What happened is that Guillaume777 rewrote all of the equip menu (which is pure heresy, but nevermind). So you might as well delete the entire Window_EquipItem base script, it won't change anything. What you have to do is find the line you were trying to change inside Gullaume777's scripts and modify it.

Thanks Dolarmak. Sadly, the Script Manager doesn't seem as easy to handle for everyone. I wish I had both the courage and the time to write that GUI, then there would be no possible mistake anymore. However, I agree with you: it's very likely that other scripts conflict with mine.

Not mine. They work on a manager which is able to load scripts from outside your projects. ElliotWyvern has likely run into a problem not following the installation instructions carefully enough... anyways there's little we can do for him without more information on his part.

Pretty much, yes. Even more so since the TMX format is distinct from the RXDATA format in which RPG Maker stores maps. What you're asking for is pretty much the same as asking whether it's possible to convert a music stream to a score without musical knowledge, in order to give it to someone who can only read guitar tabs.

That's not quite possible - unless you have a picture for each separate layer, which seems unlikely. I'm not exactly familiar with the TMX format, but as I understand it, it has nothing to do with a picture, it's more of a table stating which image should be put in each cell - while a PNG file is a mere picture with colored pixels. If you can recognize patterns and identify which cells use identical tiles using your human brain, a picture is just a stream of arbitrary colors to a computer. Theoretically, you could disassemble a rastered picture using a script that compares blocks of 32x32 (or any other size) pixels with each other to assess which cells use the same tile - however, there's a problem with layers, because pixels from top layers replace those from lower ones... which means that pixelwise comparison will fail to recognize that grass with a tree standing on it is still just grass. The computer has no way to assess which pixels originally belong to the ground and which belong to separate objects. And if there happens to be a fog of some sort on your map, it gets even worse because it will scramble all tiles, making it impossible to match any of them with each other.

Never EVER have the payer pick mushrooms in the nearby forest. If you've already made it, then unmake it.

Technically you can, but since capital letters are specific to constant names, it's best to avoid capitalizing method names, it would only confuse the interpreter.

Well I don't know what to tell you. It still sounds like the RPG Maker XP Base Engine bundle isn't installed properly, but I can't imagine a wrong way to do it which would result in the rest working, but not that part.

Uh, my best guess is that you're not loading the RPG Maker XP Base Engine prior to the MP Scene_Base bundle. Go to your project's Scripts folder and open the Script Manager.ini file, there should be a line stating "RPG Maker XP Base Engine" before the one saying "MP Scene_Base". If there already is, it must be that you have forgotten to download the RPG Maker XP Base Engine bundle.

Mine allows as many as you like. It's more of a file manager actually. http://moonpearl-gm.blogspot.fr/2012/03/miscellaneous-scripts.html