Intocabille

The player is the antagonist sometimes. :-)

I can spare few minutes with reading about the game, then if I like what I read I might give it a try even if it is full RTP. Reasons? They might not be artsy type. Same way I am not, but they might have an interesting story to tell. Same as books, you don't go for them for pretty pictures (use French accent and draw face of Teemo for previous sentence). And while you might say they should pay for it... sometimes that is just not an option. They can use a free art, true, but that might then not mesh together well.

You could have the item call common event that flips s witch called "calling ship" and have the "ship event" have wo event pages. Page 1: classical event on activate, like boarding the ship or something Page 2: condition the "calling ship" switch ON, autononmous movement type approach, speed 4, freq. 5, Trigger: Event touch and the Content being flipping the switch OFF. This way when you use the item and flip the calling switch ON the airship will start moving on its own to your location and when it touches you, it will stop moving. There are few problems with it though to sum it up A] It cant go through unpassable terrain, unless you set it as Through, in which case it won't detect touching player B] to avoid this you would need to make it second airship event page Priority paralel a have it check it's location if it is touching the player location or not Problem = The event may not be moving when it is out of the view area? Not tested.

I can confirm that IE is not working well with this site. Well... that's a loss for IE in my opinion.

Can't you make the NPC event disappear with "Transparent ON" option and also turning it as "Through ON" so you can then move it into wall? Or have it flip a self switch which would make it go to second event page that would have empty sprite for the event and set it below character so it can be walked over/through? The part about meeting the party later, I think you will need to do that with another event anyway, so maybe not use self switch but normal one or variable, which will also function to start the rendezvous event.

They remind me of Ragnarok Online :-) Working on downlaod, it looks sweet.

Why not nest the six conditions inside each other? Or since you are using the script, cant you use the && to join conditions together? like condition1 && condition2 && condition3 ....

You could also do it that the red "event" is indeed a below character touch started event. You can also create those two green ones as well with two pages and no autorun. FIrst page empty picture and empty event. and second pages with Picture of character and with a switch to make it enabled. The animation can be ran from the red event, since animations on map can be targeted to spot where another event is, in this case those two green ones. Then flip a switch to which the green ones are depending on to make them appear. The red event also could také care of the talking, then starting the fight and then playing animations again and again making that conditional switch turn off, making those green ones disappear. It depends on the details of how you want to play it out. Do the green ones wait for player input to start the talk or do they talk immediately? Images in order of Red starting event page 1 and 2m and then double page for the green event page 1 and 2 (where both green events are the same)

Well as I wrote, I had msot of it done in my other project, and using "none" category skills made it a lot simpler. If there are troubles with it, or something like that, let me know.

Aaaalright... I tried to make it with the "none" category of skills. You should note that it will override some native methods, namely the add_original_commands from Window_MenuCommand, then the create_command_window and on_personal_ok from Scene_Menu, so if you made any adjustments there, you will need to make them in this script too. Next I went the way of least resistance and shamelesly copied the sklil window, just gutted the commands from there, so when you go from menu to Traits, there is nothing to select, the list with commands is active right away. On cancel it takes you back to menu. On confirm of useable trait, it will try to use that sklil. Skills that appear in the Traits window are the skills of "none" category. You can switch between actors with the pageup and pagedown mapped buttons (default Q and W ?) On Traits option selection from menu you are to select the actor to see his or her traits (or passive skills), so you can have anyone with passives, though it is shared, like normal skills. I guess it can be altered so only main hero is selected, but this leaves a good option, I guess. Oh right, since I removed the sklil category selection (the command list in skill window) the status window (between help and skill list) is stretched and it will probably leave a bit of blank space... as I said, least resistance. Now since the description goes to the help window, and help window behaves like message window, you can use \v[number_of_variable] in the skill description to call upon a variable. Thus you can display variables in skill levels and hence their level, if stored in said variable. Now if you decide for other actors having traits as well, you could add "eval" functionality, so the game recognizes not only things like \v[number_of_variable], but also something like \eval<your_equation_here> and in that manner use more variables in sense of using the actor ID as a offset to the variable you want. For example, lets say you have 2 actors with ID 1 and 2. You said you have 10 skills now? Well in that case the skill description would read something like \v[\eval<offset>] which would in the end result in 11 for skill 1, 12 for skill 2 etc for first actor and 21 for skill 1 and 22 for skill 2 for the second actor. Detail in the end of post I already tampered with the eval function, it would be this: class Window_Base < Window def convert_escape_characters(text) result = text.to_s.clone result.gsub!(/\\/) { "\e" } result.gsub!(/\e\e/) { "\\" } result.gsub!(/\eV\[(\d+)\]/i) { $game_variables[$1.to_i] } result.gsub!(/\eV\[(\d+)\]/i) { $game_variables[$1.to_i] } result.gsub!(/\eN\[(\d+)\]/i) { actor_name($1.to_i) } result.gsub!(/\eP\[(\d+)\]/i) { party_member_name($1.to_i) } result.gsub!(/\eG/i) { Vocab::currency_unit } result.gsub!(/\eAID/i) { $game_variables[0].to_s } result.gsub!(/\eEVAL<(.*?)>/i) { eval($1) } result end end Added to the end of the script I posted. Together with adjusting two spots from the previous script def start super create_help_window create_status_window create_item_window $game_variables[0] = @actor.id @item_window.activate @item_window.select_last end def on_actor_change $game_variables[0] = @actor.id @status_window.actor = @actor @item_window.actor = @actor @item_window.activate @item_window.select_last end These make it so that when you display the traits the actor ID is saved into variable 0, so either you call upon it as \v[0] or to make it more convenient as \aid in the text. So the result description of your skill could ho like this \v[\eval<\aid+10>] would result for 11 for actor ID == 1, 12 for actor ID == 2 and so on. Be aware that if you use Yanfly message codes or actor codes or similar script, you might need to add the result.gsub!(/\eAID/i) { $game_variables[0].to_s } result.gsub!(/\eEVAL<(.*?)>/i) { eval($1) } to apropriate spot, especially the EVAL part, that is if you vant it to work with other message codes as well. I hope I was not extra confusing and I hope it will be helpful. EDIT: Now that I think about it... it is not even that close to what you wanted... if you wish I can tamper with it a bit more, so the variable of your chosing will be displayed besides the skill name, where the mana/TP cost usually is? Would that be better? EDIT 2: Oh well, did it anyway... to make it work add this to the first script, inside the Window_Traits def draw_skill_cost(rect, skill) variable = $game_variables[@actor.id * 10 + skill.id] draw_text(rect, "Lvl: "+variable.to_s, 2) end It will make it so that instead of the skill cost in the Traits window there will be written value of variable that is actor ID * 10 + skill ID, so adjust that variable equation to your liking. This eliminates the need for the EVAL part I wrote and the skill level will be written besides the skill name, instead of the skill description, making it more easy to look over the levels. The whole script, without the eval parts (no actor ID stored in variable 0 etc), will look like this then: and the skills on list will have "Lvl: x" added to their name, aligned to right. EDIT : Corrected few things, now the variable the skill will display is equal to actor ID *10 + skill ID so for actor 1 and skill ID 21 it will produce variable 31, for actor 2 it will be variable 41, If you order your skills nicely, it should work, or just adjust the equation

I have it finished, it seems to work. The version with the states anyway (and if they dont have icon, they dont even show up anywhere... or at least not in vanilla or yanfly battle engine). I can try to make one with the "none category" if you want? But it is a bit in a mess, having the code all over the place.... I will need it to put it together, somewhat. I will do it tomorrow and post it here for you to try. As I said... I am off to bed now, sorry.