Moonpearl

You got it, ForeverZer0, thank you so much.

As I understand it the sprite's lower portion opacity when using bush flags is not processed by RMXP's scripts (as can be read in the script editor), but is a RGSS core feature (from the RGSS####.DLL file). It's a property of the Sprite class, which has no Ruby script to define it, just like you can't find a Ruby script for Bitmaps or Tilemaps. So I'm afraid you have to go with wht you currently have, or ask for someone to write a custom script which would substitute for RMXP's featured bush flag.

What you said made me think of something, Kellessdee. Actually I don't use RMXP's script editor anymore since I do everything using the Script Manager system. I tried to input strings containing special characters in the script editor and it works fine. So, actually, the issue is that those characters aren't recognized when loaded from a file, certainly because it is read byte-to-byte as you suggested. I guess it is a matter of file encoding because scripts from RMXP's script editor are compressed using Zlib::deflate before being written ro Scripts.rxdata. So my issue is half-solved, even though it kinda pains me to be forced to resort to the script editor (I would like to use the script in both projects with multiple languages and a language editor, and the Script Manager stuff sounds just perfect for this). I'll manage with that for now: however, if you have further insight regarding how to use special characters in external Ruby scripts, I'm still interested.

You're obviously using a custom script, and there's not much we can do without it.

Definitely not a. As I explained in my first answer, the scene creates an Window_Item object and stores it reference into its @item_window variable (could be any other name, it doesn't matter the least bit to Ruby). As long as you have the reference to an instance of Window_Item, which is the case here, you can call its item method by writing: <reference>.item You could also write the following: Window_Item.new.item What we have here is indeed a reference to an instance of Window_Item, so we can call its item method. The reason why we don't do this is because it creates a window "on-the-fly", and since the reference to the window is not stored in a variable, then the window is destroyed right away - it feels pretty dumb to create an object we don't intend to keep just to get one of its properties.

Hi guys, Here's a quite technical question, but I'm having trouble using special characters in RMXP scripts. What I want to do is a script to allow different languages for a project. Since I'm planning to use it on my own project to translate it to French, namely, I'd need characters such as accented vowels (é, è, à...). I know RMXP can handle them because it is possible to input some via the Show Message event command, and they display properly in-game. The thing is, no matter what I try, I can't get such characters to display properly with the source string encoded inside a script. The best I get is a blank character, like the string was empty. What I tried: Character as is between quotes: issues a syntax error "è" 'è' ​ Escaped character: returns an empty string with double quotes and only a backslash with simple quotes "\è" '\è' ​ Character hex code: returns an empty string with double quotes and the code itself with simple quotes "\xC3" "\303" Conversion from an integer: returns an empty string 0xC3.chr 195.chr Packing array into a string: returns an empty string [0xC3].pack('C') [195].pack('C') Any of the above using the print, puts, and inspect methods (in case some miracle would happen): returns the exact same contents Using a Win32API which reads characters directly from keyboard input: pressing the 'è' key returns a blank string (whereas all non-special characters work perfectly fine, of course) So I think I've done it all. I really wonder how I can't get these characters to show, especially since when I ask a Show Message command how its 'è' is encoded, it returns "\xC3" (one of the encodings I tried with no luck). So, if any of you has got some sort of solution or even a clue, I'm all ears.

I don't understand that part. Also, based on what I understood of the rest, I can't see how your spirit would heal the player automatically since its event page is set to "Action button". Anyways I would have done things differently, maybe this can help. Program for event #1 (check if spirit appears): Program for event #2 (make spirit appear) And no program for the spirit event, everything is managed by the first two. Replace #AAA by any free switch slot number

Actually, there are two parts in the answer. First, you're wondering about how a scene can access its windows' parameters. It's pretty easy actually. Each object can have some of its variables accessible by other objects using the attr_reader and attr_accessor tags (specifically, they automatically create a method which returns the desired variable, so it may be called like any other methods). The difference is that attr_accessor additionally creates a method to assign values to said variable, which makes it possible for other objects to change the variable's content. Thus, to call for those variables, you just need to have the object's reference - well then, since a scene creates all windows on its own, it just has to keep track of them by holding their reference in a variable. That's the reason why the Window_Xxxxxx.new statements are assigned to variables, so that the scene can still work with them later. Second, you asked how two windows from a same scene may access each other's parameters. That's a little trickier, but obvious if you understand how a scene accesses its windows. In the equip scene, the help window displays details about the currently selected item. Since neither window know of the other's reference, you could use the scene, which know both, to update info in the help window according to the item window's contents. This would sound like: Get item window's selected weapon Get weapon's description Send weapon's description to the help window However that's not how it's done in RMXP, because the help window's contents needs not be updated each frame, only when the item window's index changes. Thus, we would like the item window to control the help window's contents. To do this, we have no choice, we must tell the item window the reference to the help window. And the object which does that must know both references, that's why we'll have the scene do it: If you search the Scene_Equip's code, you shall find something like: @item_window.help_window = @help_window Which in turn allows Window_EquipItem objects to use: @help_window.set_text(<weapon's description>) Well, it's just initializing the window's index, as could the window itself using: def initialize self.index = 0 ... end Then the window manages its index on its own (using code from their Window_Selectable superclass, which mostly deals with changing index when arrow keys are pressed), and when the scene accesses that index again, it gets its current state. Hope this all makes sense.

You can still give it a try. It doesn't matter if your answers are wrong, just give it your best.

Oh, that's so unexpected. I mean, I've done virtually nothing this month, since I was busy with my own stuff. Thanks anyways, guess I've got to live up to my reputation and post a ground-breaking demo. Still no one to help me, by the way?

Do all four characters of yours have the same stats? If so, it might be that you just forgot to change the text's position according to the ID of the actor and they all display at the same place (which does not show since the same text is drawn over again and again).

Hi everyone, So, my upcoming project is seriously ripening by now, and since it's technically an investigation game, I wish to test whether the courses I designed to solve it are not too obscure for players to see through them. Anyone can participate, the more the merrier - and it should take very little of your time, although I expect you to serioudly think about the problem I shall present you with, just like your final success after hours of play was at stake. The only drawback is that it will spoil the game's solution when you get to play it - however, since there are several routes, it's possible for me to spoil you only one of them, which leaves the others for you to explore as a blind player (I'm planning on about 5 routes so far). Also, since I wish to test all routes, participants wlll not necessarily be given the same spoilers. If you wish to participate, please complete this preliminary test first, and PM me your answers. I don't mind you discussing various issues in this topic, but please don't write any answers here, and keep information you get regarding the game to yourself. Thank you for your time!

OXYD! (the person in the back of the room who just said I'm a grandpa is prompted to leave at once)

Even better to make people realize how absurd the argument is - ask them what about games that are a combo between FPS and RPG?

FPS and RPG ARE better than sports game, though.

Setting a comparison between the two in terms of quality is quite pointless since both genre have nothing to do with each other. People who're fond of FPS clearly do not seek the same kind of pleasure in video gaming than do those who're fond of RPG, and vice-versa. That's all there is - you can't argue that a game with no FPS elements is better or worse than a FPS, and same goes for RPGs. Those flaming about that fool no one but themselves.

I know there's a version of Minkoff's animated battlers which does just that, leaving the rest of the battle system untouched. Thus it is theoretically compatible with any battle systems, though you often run into stupid issues. Also, I know there's a version for use with Cogwheel's RTAB too.

I did not actually run tests on this but in my opinion, it's not really about variables, but rather about objects. I've read an interesting article about that, which said the following. Suppose you wish to read lines from a text file and then write them again (supposedly after some processing). The obvious way is to make a huge string which concatenates each line read from the file. Alternatively, you could put each line into an array and then write each string from the array in sequence. Both solutions require the same number of objects, that is, a String object for each line which is read, plus an additional String object in the first case, or an Array object in the second. The difference, though, is that the former case takes up much more memory, because the huge string contains a duplicate of each line contents, while the latter case's array just features references to those strings. Of course the strings read from the file shouldn't be kept in memory after they've been copied to the huge string since they're not useful anymore, but you cannot explicitly destroy objects, thus leaving them there until the Garbage Collector gets rid of them. So, even if it does not address your issue directly, my best guess is that you should think in an object-wise perspective. For example, I saw you using strings as keys in a hash - well then you'd better use symbols (:top instead of 'top'), because whenever you write a string in your code (whether to write the 'top' key or to access it), a new String object is created, thus leaving you with multiple instances of 'top' in memory, while :top always calls for the same unique Symbol object.

Like I always say, French is a good reflect of its people's way of thinking - it was made specifically to repel foreigners.

Thanks CrimsonInferno, but English grammar is childplay next to French one. ;)

To be honest, I get wordreference.com to back me up from time to time. I don't always have the exact phrasing to fully render the original version up my sleeve. Sometimes there are expressions I don't know, sometimes there are some I'd forgotten.

I like to think so!

Même pas mage! (Not Even a Mage!*) This song tells the story of a guy who became the ruler of the world unwillingly. This time I couldn't find a video with the nice strips by Marion Poinsot, I don't know if she even illustrated that one. http://www.youtube.com/watch?v=KbxWBRDVX68&feature=related