Moonpearl

Or alternatively, set it to Fixed and edit the move route like you would do with an event command.

Add the following to your script editor, in a new entry above Main: # Edit the following array with the IDs of actors to be removed automatically after battle ACTORID_REMOVE = [ 1, 2, 3, 4 ] class Scene_Battle alias old_battle_end battle_end def battle_end(result) for actor_id in ACTORID_REMOVE $game_party.actors.delete($game_party.actors[$game_actors[ACTOR_ID]]) end old_battle_end(result) end end This should work fine.

This seems all very complicated to me. The solution that comes to my mind is to make the core dead, I mean, technically dead. Thus you can't interact with it anymore. Then, when the armor is low on HP, you may respawn the core and kill the armor. You could use a variable to keep track of the core's HP while it's down to give it back when the armor wears out. Also, you could display a picture in place of the core, so that the player gets the impression it's still there and alive.

Theoretically speaking there's a very simple solution, it's to define the classes used by both systems as two separate sets (e.g. rename Scene_Battle to Scene_Another_Battle for one of the two scripts), so that the first system doesn't override the second one. Now, depending on the specific scripts it might not be as simple. For example, a side-view battle system may replace the classical battlers by spritesheets, so to toggle from one to the other you would also need to define references to another Graphics/ folder, and that's the kind of issue why I'm asking gyro2117 to elaborate his request.

Could you elaborate please...?

What error?

Oops, my bad. Replace Cache with RPG::Cache and it should work fine. You placed everything correctly except for the x and y change for the panorama, they should go in the update method (right before @command_window.update).

I think this should answer your questions: http://www.rmxpunlimited.net/forums/topic/8168-request-panorama-title-screen/ Juste replace panorama with fog.

Ah, that's too bad. Actually I'm trying my own hands at yet another theme for a hypothetical project of mine and I'm having a hard time putting together something better than Summer Breeze. Talk about a frustration.

Ah ah, thanks for your enthusiasm Forcebreaker. Yes, I did that everything with my lil' fingers (except of course the facesets and battlers).

I'm taken. But thanks nevertheless. :)

Aaaaand the video. http://www.youtube.com/watch?v=L4vjOUelRuU&feature=youtu.be

No need for an option. Just replace the face graphics with anything you like in the pictures folder.

You've been awaiting it for so long (or maybe not at all, on second though), and here it is! A new version of the Animated CMS has been born! So, to make things a little less dramatic, I've been busy trying my hands at designing a new theme of my own (since it's the script's initial purpose). I've spotted small flaws along the way, and fixed them while I was there. So the brand new theme comes along with a more powerful script. The two screens below were obtained using the exact same script, only the graphics were changed, and a few options adjusted. This gives you an idea of just how easy it can be to design your very own theme. See everything on my blog.

Thanks again kellessdee. Scriptwisely speaking, I could do some improvements though, but I was kinda eager to get things done and see the result, besides there was a request so I took pride in completing it in little time.

@CrimsonInferno: Thanks. No, no other compatibility issues since the rest of the script doesn't mess with any pre-existing elements. It's smoothly built to fit in the interface (for example choices with keywords are merely standard, event-called choices, only appointed to display variables with the keywords inside). So I guess this gives a little more work to the user than a full script where you just have to call a simple command and everything unfolds under your eyes, but on the other side it makes the use of keywords much more flexible and guarantees no compatibility problems.

I get your point. If your concern is about non-scripters, though, I believe that no matter what structure you may choose, there will always be people who find it obscure. So, if a script is meant to be modified by potentially non-scripter users, I think the scripter should rely on comments rather than any kind of seemingly clear syntax (which is what I personally do). Thus, why not write an efficient script with proper commenting, rather than sacrifice a good structure to transparent syntax? After all, since non-scripters cannot script by definition, they should be able to use scripts without requiring to read them in the first place.

I totally agree with that and that's exactly what I have in mind. I'm considering hashes because it seems to me like the best solution unless you go for an actual class. Your example is indeed difficult to read, but actually I would transpose it and rather do something like that: $bio = [ # Actor 0 { :name => "Aluxes", :gender => "male", :age => 18, }, # Actor 1 { :name => "Basil", :gender => "male", :age => 20, }, ] Then, calling for a particular actor's feature would be like $bio[actor_id][feature] Properly commented, it seems very clear to me. As for the syntax, if you're not a scripter, you just have to replicate lines and edit the text, like I used to do when i was new to Ruby. Besides, I do not agree that you still have to call features explicitly by their name, because using arrays and hashes, you can enumerate them. Thus, drawing a list of all the features would merely be like: $bio[actor_id].each { |feature, value| # Write feature name # Write value } And here you have a tiny portion of code able to process the hashes, whatever they may contain, which allows the script's user to add/remove features from them at will, with no need to tweak the code. You can also manipulate the display order by merely changing the declaration order of the features in the hashes. And you're not even forced to fill all features for each character. So, maybe because I'm a lazy guy, I do think it's THAT simpler for the scripter to do this way.

Is it not what I did? Need i quote the suggestions I gave and questions I asked? Guess I mixed two suggestions in one. The flexibility issue mainly lies in using fixed names, regardless of them being constants or not. If you ever wish to add new features, this means adding new names, then adding new portions of code to process those new names, then adding portions of code to call those new portions of code, and so on. If you use either arrays or hashes instead, you may expand them at will with no need to tweak the rest. Personally I would prefer using hashes because this way you can easily add new features to the bio with no need for a reference table to know which index refers to which feature. Arrays do have better performance rates but as far as a bio menu is concerned, this would just need a single call here and there, so you wouldn't gain much. As for the conceptually confusing aspect, I don't know, but I bet it would be clearer for me if I saw a table matching a feature name with its value directly, rather than a table of values plus a table of references.

Ow, sorry for trying and help you improve your scripting at all. I came here to give a hand, not to fight over who writes the better scripts. Anyways... That's the whole point. I'm actually making it sound like your script, the way it's written, can hardly be updated at all, unless you rewrite it in depth, that is. I'm not saying this is the final script, i'm saying you could gain much time in the future by working with a more flexible structure. Then again, if you want to spend hours rewriting code while it could just be a matter of minutes to add a new feature, suit yourself. Of course you're not going to explain to me what a module does, because 1 - I know what a module does, 2 - I use modules myself and 3 - that's not what I'm asking at all. Nevermind though, I'm not going to explain to a scripter what a question about scripts means, either.

Interesting. Too bad that your script lacks flexibility (what if I wish to display additional info like star sign or whatever?). All the same, using constants does not seem like a very wise choice to me (what if I want to modify bio info in-game, for example to unveil things progressively?), even though Ruby allows modifying constants, you should consider using hashes instead. Besides, what's that ACE module? And what does it bring at all?

After running around dozens of maps for hours and hours trying to find the place I was supposed to go to, and of which location the game designers assumed was completely obvious, I had enough and said to myself "Instead of giving those damned NPCs such lame, useless quotes, why couldn't they have them simply GIVE DIRECTIONS?". So I sat at my desk and a few hours later I'd done it (which proves how easy a feature it is to implement). And today I'm sharing it with you, so that I don't spend hours looking everywhere when playing your own projects. Purpose Allow the player to ask for directions with no other effort than copying the script to your project. Main features Just name the events connecting your maps as "Exit", and the script automatically searches for those connections. The pathfinder always returns the shortest way to go from one map to another. It is possible to ask for directions from a different map than the one you're in. Use along with the Keywords System to make asking for a destination even easier. Known issues None as far as I'm concerned. Screenshots Download See my blog entry.

I stumbled upon some external utility which did the trick a long time ago, but I can't remember the name. I know it's not much of a help but I just thought I'd let you know the solution exists.

Thanks rgangsta. It's not just about lookks, though, the colors and stuff are merely features of the original RMXP. I'm just using them to outline the keywords in the choice options.