Moonpearl

You're welcome.

Why don't you try this: class Arrow_Base alias mirror_arrow_initialize initialize def initialize(viewport) mirror_arrow_initialize(viewport) self.oy = 0 self.angle = 180 end end Adjust oy to move the arrow up or down if needed.

Ooooo, I see several problems here. Your start method does not take any parameters. This means that when you call start, the four local variables move_x, move_y, dest_x and dest_y are undefined, and thus the instance variables will be set to nil. You're overriding Window_Base's update method, so any previously set behaviour is now erased. You should use an alias there. In the last few lines, you're not testing for equality, but rather assigning a value to @move_x and @move_y. Use == instead. Your window cannot move both horizontally and vertically because of the elsif statement. That's fine if it was intended that way, but I doubt it. Your window cannot move up or left because you only increase x and y's value. Once again, fine if that's what you wanted to do. The way your code is written, the win_move_x and win_move_y methods do not serve any purpose. Since you set the @move_x and @move_y flags in the start method, I don't see why you would want to specifically call two methods just to update them. Better remove the flags at all and test if the destination values were reached directly All in all, I would do things that way: class Window_Base < Window alias old_initialize initialize def initialize old_initialize # Set the @dest_x and @dest_y values to avoid NoNameErrors @dest_x = self.x @dest_y = self.y end def start_movement(dest_x, dest_y) @dest_x = dest_x @dest_y = dest_y end alias old_update update def update old_update if @dest_x < self.x self.x -= 1 end if @dest_x > self.x self.x += 1 end if @dest_y < self.y self.y -= 1 end if @dest_y > self.y self.y += 1 end end end And this should do it. Also, if you want to be able to test whether a window is moving or not, use something like: def moving_x? return @dest_x != self.x end def moving_y? return @dest_y != self.y end

Well, the thing is, I don't know what you are doing. That's why I don't know what example to give you. Basically, the main process creates a Scene object and calls its main method, which loops until the scene is exited (either replaced by another scene or not, in which case the game stops). The scene in turn creates windows and sprites and stuff, and for each, calls their update method. Since the scene loops over one update call, then a frame refresh, each object is updated once per frame. So, whatever you are trying to do, there's no other way to update your objects than referencing them in the appropriate scene and have it call their update method. I don't know if this is of any help, since this is what one could infer from reading RMXP's default scripts.

An example of what eaxctly?

This is not possible. If you want a process to self update without hanging, you need to put a Graphics.update command that will advance frames. But if you do that, you're overriding the main porcess's Graphics.update, so the rest of the game won't run anymore. You have to include whatever portion of code you'd like to add in the class's update method, then call it from the main process (or from an object called from the main process).

Fixed. Added a new vid as well, while I was at it.

Hi guys, I messed around with my sweet ACMS and came up with a third theme which I called Data Vortex. As usual, you can find it in the gallery on my blog. Cheers!

It's fairly easy actually, but sticking to MIDI has its good side. For example, you can't loop a PCM or MP3 properly, and of course the files are much bigger. The best solution actually would be to write an alternate MIDI synth for RMXP, which is a project that crossed my mind, but I need to give some thought to, so it's not for now yet.

Thanks Vinderex. Of course, I wouldn't share it otherwise, let alone advertise it on forums.

As specified in the instructions, changing a picture is as easy as replacing the file in the Graphics/Pictures folder. So, yeah, do develop your own theme, it's the script's very purpose after all. The two themes I've made so far are merely a demonstration of how much the apperance may be customized by changing picture files, with little to no changes in the script itself (switching from Standard to Summer Breeze requires editing exactly 6 lines from the script for instance). Regarding the HP and SP bars, the script automatically replaces them wherever they may appear in the game, including battle scenes. But once again, their apperance is completely customizable, so you could simply make graphics that suit both the menu and the battle scene - as for their placement in the battle's windows, I can also have a look at your CBS script and tweak it accordingly if needed. If you really need to keep menu bars separate from battle bars, I guess I'll have to add that to the list of new features in the next version. Have fun in the meantime.

I would naturally recommend my own: http://moonpearl-gm.blogspot.com/2011/06/animated-cms.html :D

I've already seen such a script somewhere, though I can't remember where. Sorry I can't be more helpful, but I thought I'd let you know it does exist.

Isn't it as simple as to give the actors and enemies very small stats? I remember doing that once in order to get damage as small as 10 or so.

You can't lock the camera onto an event as such, but what you can do is to give the event a Scroll Map command along with the Set Move Route command, set to move one step in the same direction, and using the same speed as the moving event's.

You're welcome. I didn't think the viewport thing would be an issue since it was already set to 640x480 when I looked at my RMXP's default scripts. Maybe we have a slightly different version.

Well, I don't quite know what to say. Is it possible to have a look at your code?

Odd. You're using a custom battle system, aren't you? If so, look for the same line inside your CBS script, which replaces the original scripts and thus makes modifying them useless.

Search the Spriteset_Battle script entry for this line: @battleback_sprite.src_rect.set(0, 0, 640, 320) The 640x320 cutoff you're talking about is set right there. Just change the 320 to something else. If you further want the program not to perform any resizings at all, just comment this line (adding # at the beginning).

Is it possible to have a look at what you've written so far?

Yes, beside you can actually enter only a single command (move right) and have it repeat.

You should input an Erase Event command at the end of your autorun event. Technically, while there are autorun events on the map, the interpreter will run them, regardless of whether it has already done so or not. To further disable an autorun event forever (for example a cinematic which should happn only once in the whole game), set a selfswitch to ON and create a new, blank page under the condition that this selfswitch is ON. This will turn the autorun event into a useless triggerable event, and thus disable its autorun commands for good.

Well, I suppose it depends on how the city is laid out. As far as I'm concerned, I never actually draw an entire city into a single map, but rather several small maps with the city's points of interest connected with each other. In that case, it's easy to have one event simply go from the left to the screen to the right, and then disappear. Also, I don't see anything wrong with the player noticing the pattern, as long as there are enough citizens walking in different directions, and at different speeds. On the contrary, I think random movement is much more unnatural, you never see people take a step, then stop, then take another step in the opposite direction right after in real life - not to mention that if you want to draw a modern city with roads and cars, citizens with random movements get to get run over quite often. Anyways, that's just some insight, I still agree random movement remains an easy, though rough way to give NPCs some life.