Moonpearl

I couldn't agree more. Also, thanks for the compliment, it goes a long way. Programming the ACMS was anything but simple, though (even if it's basically just eye candy stuff).

Thanks guys, it's always nice to hear a kind word. :) Don't hesitate to feed me back with screens of my scripts in your project.

You need to change the make_filename method in the Scene_File class, and add a path to the filenames it creates. For example, say you'd want to put your savegames in C:\MyFolder, you'd write: def make_filename(file_index) return "C:/MyFolder/Save#{file_index + 1}.rxdata" end Now you're asking for something difficult, because the Application Data folders aren't constant, they change according to the username, as you noted, which forces you to ask Windows for their path. You can achieve that using environment variables: ENV['HOMEDRIVE'] #=> "C:" ENV['HOMEPATH'] #=> "/Documents and Settings/Moonpearl" Thus, the following should work: def make_filename(file_index) return "#{ENV['HOMEDRIVE']}#{ENV['HOMEPATH']}/Application Data/Aveyond II/Save#{file_index + 1}.rxdata" end

As far as I remember, yes, you can use RTP in commercial games, as long as they're made using RPG Maker - that is, you're not supposed to use them in games made from scratch. But I might be wrong.

You forgot a question mark. The corrected version is: p width > 32 ? 'width is good, no problem' : 'width is the problem' p @item_max > 0 ? '@item_max is good, no problem' : 'Uh, oh, @item_max is 0' self.contents = Bitmap.new(width - 32, @item_max * 32)

ForeverZer0's right. Also (this is just an hypothesis since I didn't take time to look at your scripts) it is possible that you try to make the contents bitmap before setting the window's position and size (using super in the initialize method), thus both width and height would still be zero at that time.

We'd need a link to said script, however it is likely that you're accidentally trying to create a new Bitmap object with null/negative width or height as parameters. Double-check your parameters' values right before the Bitmap.new statement.

Well, it seems to me that your code should work as is. You could maybe try a few tricks from this page and see if it works any better.

OMFG what a terribly poorly written script. Anyways what you're looking for is inside the " (**) Menu_System" entry, starting with line 4093 you have a series of: @<type>_window.x +/-= 16 Those parts are responsible for moving the windows when they're not either out of the screen or in place. Unfortunately for you, the scripter did not give a damn about object-oriented programming, so instead of changing the scrolling speed at a single place for all windows, you have to change it for each window. Anyways just replace 16 with a larger value. Stick to multiples of 16, however, because the script does not exactly check whether the window is at the right position, but rather if it's past some point. So with steps of 16 pixels the windows are supposed to fall right in place in the end. I suggest trying 32 hoping that the movement wasn't calibrated to last an odd number of frames. Otherwise take a look at my ACMS, it just takes modifying a single constant to change the windows' scrolling speed. :P

I agree with the return stuff which I also do, but on the contrary for the matter at hand it feels like a pretty awkward syntax, asking whether what looks like a condition but isn't really one equals nil or not. The =~ operator means "is there a match?", that's enough, no need to extend to "is there a response to is there a match?" in my opinion.

The '!= nil' part is useless, though correct. Just saying.

It's normal, however it tells you whether it's an syntax error or an error while running script, and this is important.

Don't forget to replace <actor_id> with the desired ID.

Even easier with a regexp. $game_party.actors[<actor_id>] =~ /gus/ This will return true if the chosen actor's name contains the string "gus", false if it doesn't. The strong point of Regexps is that you can test for very sophisticated conditions, like the special tags you may put in messages - they use regexps to see if there's any combination of backslash+any chosen letter+open bracket+any numbers+close bracket, and if so, capture the number for future use.

Well then, your event definitely doesn't trigger. I assume it must be because the system checks for events triggering at the beginning of each turn - and since the battle ends right when the last ghost is defeated, there's no new turn to check for it. Anyways it seems like a flaw in the core system so you should try something else. Maybe by triggering battles "manually", like with a parallel process randomly triggering battles at set intervals, and incrementing the variable in case of victory. Or even with ghosts showing as events on the map and triggering such battles whenever you come in contact with them.

If you're using a custom battle system, it is possible that it does not support in-battle events. Does the message "You killed a ghost" show properly?

Why did you set the second page to "Parallel Process"? It should be "Action Button" (or "Player Touch"). If this still doesn't work, I can only assume that the event supposed to increment your variable doesn't trigger properly. Use F9 to check if the variable does increment and if it has the correct expected value.

Well as you describe it it's supposed to work, so there must be some detail you overlooked but there's no way to tell what unless we can have a direct look at the project. Maybe screens of the event's two pages might help.

So in short the important feature is the arrangement of blocks? Or their orientation? Or both? And can red blocks be combined with blue ones? Oh, I do believe it alright. You can even make a vertical scrolling shooter or a FPS with RMXP. And I know how to compute matrices and to render 3D scenes using ray-tracing and stuff. I'm not asking if you have the technical possibility to do it, I'm asking how you wish to do it. Are you using RMXP's tilemap? Or are you building your own 3D rendering system? And most importantly, do you need help with the block stuff in a computational perspective only, or also with how to render them on-screen? My first question was not quite insignificant. Your request still seems a bit fuzzy to me, and I think some sort of diagram showing precisely how you see things as rendered in your actual game would help to outline exactly what your target script should include or not.

I don't understand your request. What do you call a "block system"? What part of the sample gameplay do you need help with? And how do you plan to render a 3D gameplay in RMXP (which is hopelessly 2D)?

Use a script. If you can't script, find a battle system/menu system/project with bars that appeal to you and search the scripts for Window_Base#draw_actor_hp and Window_Base#draw_actor_sp. class Window_Base ... alias ..._draw_actor_hp draw_actor_hp def draw_actor_hp(...) ... end alias ..._draw_actor_sp draw_actor_sp def draw_actor_sp(...) ... end end Copy both methods and put them in a new entry of your script edtior (including the alias statements if there are any), encased in a class Window_Base block, as shown above. Also, it is possible that the new draw_actor_hp and draw_actor_sp methods call on yet other methods. Once you've done all this and run your project, if you get errors like: Then search for said line number, there should be a call to another method (typically draw_bar or draw_text_shadowed or whatever) you also have to copy from the source script.

ForverZer0 made something like that with his MCI Player, he posted it on this site a few weeks ago, you should have no problem to find it.