kellessdee

'tis unfortunate. Perhaps enterbrain's anti-competition mindframe is more reason to move on to GDU. Then, while we can still support RPG Maker to an extent, the main focus can finally move away to something that has the potential to grow. I think being a community that is there to help people get into game development in general/platform to show case game development tools/games/etc. is much more appealing than a community centered around RPG Maker. Releasing the website before it is finished sounds risky, but in the same breath I'd REALLY hate to see all the hard work/effort you have put into this project go to waste. What about becoming a completely community-centric website? As in, the main focus being the forums, even perhaps the main site could be the forums? That might be a little more work than worth it, as well as that is risky in its own respects as well (although, as it stands, that's kind of what we are right now). But then, if that was the case, the forums could be based around user-generated content (although, technically, that's how it works now as well...) So I guess the point would be, maybe, it would be better to actually head in that direction, rather than try so hard to get the parallelism between website/community. Just my two cents. I'm not too sure what the usage statistics of this site are for the non-community stuff/etc. but, releasing it prematurely with just forums doesn't sound like it would be too bad. As long as members know what's happening, and can still post/communicate, I don't really see it being a community-breaking issue. Either way, you have my support on the final decision.

Well, I don't really use RPG Maker XP anymore..... BUT, I can say this is actually really nifty. I'm sure it could be VERY useful.

OMFG I disappear for a while and miss all the good ruby discussions Q_Q Hmmm, I always thought classes were supposed to be Constants (first letter uppercase) and methods were instances (first letter lowercase) Also, class SymbolTest != SymbolTest::SymbolTest -> they may share the same symbol; but both have very different scope and thus different object_ids As for class SymbolTest/def SymbolTest -- can anyone really expect declaring a method and class in the same scope with the EXACT same name (as a constant) do to what they want? I really don't think using symbols in these kinds of cases is a bad habit at all. If one is really that paranoid, all you need is a little bit of paranoid programming: class Whatever def initialize end alias_method :new_initialize :initialize end now ruby knows you are specifically referring to a method, and not anything else... but as I said, you shouldn't have 2 (different) objects in the same scope with the same name (I know you know that a class/method definition are simply instances of the class and method object) -- THAT is bad practice, and as long as you don't do that, an alias can only reference what's available in the scope (unless you fully qualify the object) i.e. module RPG class Sprite < ::Sprite # `::` preceding `Sprite` references global scope, outside of RPG end end c:\test>more test.rb class SymbolTest SymbolTest = 4 end def SymbolTest puts "hello, World!" end puts "SymbolTest::SymbolTest -> #{SymbolTest::SymbolTest.object_id}" puts "SymbolTest -> #{SymbolTest.object_id}" puts SymbolTest c:\test>ruby test.rb SymbolTest::SymbolTest -> 9 SymbolTest -> 22251492 SymbolTest declaring a method with the same name as the class (in the same scope) really screws with things...where's my "Hello, World!"? What's interesting though, is just found out now, if you were to declare a method with the same name as a class in the same scope, but have it take parameters, you can reference both uniquely...but, that's still not the best idea IMO. Brackets are optional in ruby, so @move_list.include? [X,Y] would actually work. Not a big deal, but usually the ruby community uses brackets for multiple parameters Something.do_something(1, 2, 3) and no brackets for single parameter method_defined? :do_something But that's all personal preference anyways. Looks good at the moment, if it works -- even better. However, just so you know, you shouldn't have to include the Fade module in Game_Event and Game_Character... Game_Event inherits from Game_Character, and thus would inherit the included methods from the Fade module. In fact, since both Game_Player and Game_Event just inherit from Game_Character, you could just define the methods from the Fade module, RIGHT in the Game_Character event. But, that depends on what plans you may have for that module... either way, you should just chop out this part: class Game_Event < Game_Character include Fade end that's redundant, IMO. Here's an example: irb(main):001:0> module A irb(main):002:1> def test irb(main):003:2> puts "hello, world!" irb(main):004:2> end irb(main):005:1> end => nil irb(main):006:0> class B irb(main):007:1> end => nil irb(main):008:0> class C < B irb(main):009:1> end => nil irb(main):010:0> class B irb(main):011:1> include A irb(main):012:1> end => B irb(main):013:0> C.new.test hello, world! => nil irb(main):014:0> B.new.test hello, world! => nil It doesn't matter what order they are defined in either. Only the one include is necessary. EDIT: I dunno if anyone explained @move_route.list, but: @move_route is an instance of the RPG::MoveRoute class module RPG class MoveRoute def initialize @repeat = true @skippable = false @list = [RPG::MoveCommand.new] end attr_accessor :repeat attr_accessor :skippable attr_accessor :list end end and RPG::MoveRoute#list (@move_route.list) is an instance of an array, which elements are (or at least should always be) instances of RPG::MoveCommand module RPG class MoveCommand(code = 0, parameters = []) def initialize @code = code @parameters = parameters end attr_accessor :code attr_accessor :parameters end end Both of those code snippets were from the RPG Maker XP help manual, if you want some more details you can check them out.

Firstly I'd like to state this: screen_z is not a property. It is a method that calculates and returns the Game_Character object's 'Z' index (draw depth) Next, this may be confusing but, Game_Actor does have a similar screen_z method that acts similar to Game_Character's screen_z . However, THAT screen_z is meant for positioning the actor's battler NOT their walking sprite. All game sprites (on map) are either a Game_Event or Game_Player ($game_player is a Game_Player), both of which are subclasses of Game_Character. hence why you need to look at Game_Character#screen_z I think you are beginning to realize this, I figured I'd point it out. So, in order to mess with the z-index of things, we need to figure out how it works: #-------------------------------------------------------------------------- # * Get Screen Z-Coordinates # height : character height #-------------------------------------------------------------------------- def screen_z(height = 0) # If display flag on closest surface is ON if @always_on_top # 999, unconditional return 999 end # Get screen coordinates from real coordinates and map display position z = (@real_y - $game_map.display_y + 3) / 4 + 32 # If tile if @tile_id > 0 # Add tile priority * 32 return z + $game_map.priorities[@tile_id] * 32 # If character else # If height exceeds 32, then add 31 return z + ((height > 32) ? 31 : 0) end end So, here we go. if the Event has the always on top option set (@always_on_top), Z will always be 999. Since we know, in your case, that is false we can ignore that. z = (@real_y - $game_map.display_y + 3) / 4 + 32 First, the 'Z' is calculated from Character's Y coordinate (@real_y), this creates the effect that as things move down the screen, they get closer or as the move up the appear farther away (this is how you can stand behind an event, as well as stand in front of them). So, first thing: The greater Y (lower down), the greater the Z value will be (closer to the screen) and vice versa. (Also note: if two sprites set the same Z value, the first sprite will be drawn before the second sprite) Next, if the character is a tile (by setting the event graphic to a tile rather than a character set) some more calculations are done, but you are working with character sprites, so we can ignore that. Finally, if the character is taller than 32 pixels (i.e. taller than a tile) they receive a greater z-index. So, how can we fix this? Well, we just need to redefine the calculations that provide the scripts with the z-index. If self is in the caterpillar use a different calculation. else use original calculations or something. Conveniently, Zeriab's caterpillar script already does half the work for this: => event class has been altered to add the @caterpillar_actor instance variable -- we can test to see if the event is in the caterpillar So, let add alias the screen_z method and play with it: NOTE: this can be done directly INSIDE the Game_Event class, but this way of messing with it, will give us more room to experiment without damaging the original script class Game_Event # alias the screen_z method, then redefine the old version unless method_defined?(:old_screen_z) alias :old_screen_z :screen_z end def screen_z # if @caterpillar is not nil if @caterpillar_actor # return new calculations. # this is just an example, but it will order the # caterpillar actors based on their index in the party # 0 - on top, 3-on bottom actor_index = $game_actors[@caterpillar_actor].index if actor_index # actor_index is nil if actor is NOT in the party return old_screen_z - actor_index end end # @caterpillar is nil, self is not in caterpillar # return the original calculations, unaltered: return old_screen_z end end unless method_defined?(:old_screen_z) this will prevent RPG maker re-aliasing a method (which would mean the new method will reference itself, and thus infinitely call itself. This is recursion, which rpg maker doesn't play well with...and even worse it's broken--it is an infinite loop. When you f12 reset an rpg maker xp game, any open aliases will re-execute, and thus when the new definition calls itself, you get a stack level too deep error.) if @actor_caterpillar the @actor_caterpillar in zeriab's script stores the actor_id of the actor the event represents in the caterpillar, which is nil if they are not in the caterpillar. in the context of < if (expression) > expression will be considered "true" if it is anything except nil or false and vice versa. So, when @actor_caterpillar is anything other than nil or false, the if clause will be executed. My little example here simply orders the caterpillar's z-index based on the game_party's index order. Hope this helps.

Ah, yea, I didn't mean to alter through win32api (as you cannot alter code with it), I meant in the terms that it provides a direct interface with libraries and thus, the ability to extract certain functions...which since you still don't know HOW the functions work, would be quite useless in that state..and it would be probably really hard to determine those functions' signatures as well. Huh, as an afterthought, I dunno why I even mentioned that. But yea, in conjunction with what fZer0 said, you should only mess with the core RGSS classes if it's REALLY worth it. i.e. the loss of performance is worth the gain in functionality. OR you are simply extending that class to other stuff (which in that case, you should be inheriting the core class, and adding the functionality in the child. Also, you should look into what you are trying to do (although, you may have already)--you may be able to find that someone already has come up with a solution or something similar to what you are trying to do. Sometimes even, the functionality may already exist, it just requires a bit of tweaking to use it. From personal experience of trying to hack at the core classes/functionality, I can say I've wasted A LOT of time trying to do something, that had a much, much simpler solution or was already built-in.

If you want to change the functionality of any of the classes featured in the RGSS library, you're much better off altering the classes through inheritance or some kind of wrapper class. The most you'll be able to do to truly access the underlying classes in the RGSS dll would be to disassemble the library (which would only be useful if you know whatever assembler language it gives you) or to attempt to interface with the library through Ruby's win32api classes (which I don't really know how well that would work) Do you mind me asking what you are trying to do exactly?

:( Are you giving up that easily? Couldn't you just translate every part except the impossible part? Is the wave effect absolutely necessary?

Ah, well, those functions are in the Sprite class for RGSS2 Those don't have any ruby equivalent source, as they aren't programmed in ruby. Those properties define the parameters for a raster scroll/wave effect. Ruby would be too slow to pull off that kind of graphics processing. EDIT: Basically, you won't get that functionality in RPG Maker XP, unless you plan on using RGSS2 in RMXP and rewriting most of the default classes, unfortunately.

RPG::Sprite does not exist in RPG Maker VX. Instead, RPG::Sprite's functionality was replaced with the Sprite_* classes (primarily Sprite_Base) in the default scripts. Even then, I believe a lot of RPG::Sprite's functionality disappeared in the move from XP -> VX (mind you, it wouldn't be hard to copy RPG::Sprite's code into VX and use it there *hint hint* *nudge nudge* okay, I dunno if that even helps or not xD but I felt like saying it, okay?)

First off, that code shouldn't work. The correct syntax for alias is: alias new_method_name original_method_name all Alias does, is (essentially) make a "copy" of the original method definition, and rename it to the new method name provided. Since ruby provides open classes/methods, you can redefine the old method (AFTER the alias), which that definition will not override the aliased method (as it contains a reference to the definition that was in place at the time of calling alias) :/ I hope that made a little sense. It's kind of hard to explain.... With that snippet you posted: 1. `foo` is defined def foo -> [print "foo"] 2. `foo` is aliased to `bar` (should be `alias bar foo`) def foo -> [print "foo"] def bar -> [print "foo"] 3. `foo` is redefined, `bar` still references original `foo` definition def foo -> [print "bar"] def bar -> [print "foo"] Then, when the class is instantiated, the constructor method is called (which calls foo, then bar) and `foo` prints "bar" and `bar` print "foo" This is how you usually see custom rpg maker xp scripts use alias, the constructor method is aliased (to keep the original method definition), then the constructor (or any other method really, though initialize is most common imo) is redefined with new functionality and a call to the old method: # default script class Foo def initialize #do stuff end end #custom script class Foo alias new_initialize initialize def initialize new_initialize # original constructor is called #do new stuff end end EDIT: Is there a specific reason to why you are using alias? Are you trying to just learn how it works or are you trying to accomplish a specific task that necessitates an alias?

I respect your opinion, but out of curiosity, I am quite intrigued as to WHY you believe it's a "gloated" version. I'm not trying to convince you to buy it; but in my eyes it DOES combine the best of both xp and vx. I'm curious to know what you think they are leaving out, that was better in either of the versions.

no way y u necro for??? hahah, just kidding. ESPECIALLY in this case, that's a huge addition. I'm sure someone might find this useful. :D

No problem at all. I'm glad I could help :) And, I do suggest keeping the help menu open at all times (especially when learning to script). Most people don't know about it, and even a lot of those that DO, don't realize it's FULL of ruby / rgss scripting references. When I was first learning Ruby/rgss I had it open so often, that I just created a shortcut on my taskbar to the actual help file (there should be a .chm for it somewhere in the RMXP install directory) To be honest, I had a feeling this was why you were doing this. But, I think you'd be surprised at how much easier it would be to work with the actual scripts and what not. As you can see, there are a lot of weird things that happen when trying to use too much scripting with events (I tried this same approach when I started as well), and I figure I'd help you prevent a lot of headaches which would probably slow the learning process :( Anyways, once again, glad I could help. If you have any more questions/issues don't hesitate to ask :) P.S. If you want to get started on messing with what happens when you press the menu key-- When the menu key is pressed, essentially the call is: $scene = Scene_Menu.new So, if you head over to the script editor and check out the Scene_Menu script, any modifications to that class will modify the menu called by the menu key press. That should be a good starting point for you :)

Agreed. and I just liked them and posted that I love it on the facebook page, just to be cool. Are you still taking suggestions? My only gripe with the profiles is that...it still seems heavily based on RMXP. Perhaps, for the skills section anyways, you should have something more like: -Graphic Design (instead of spriting) -Composing -Level/World Design (though, Mapping could probably still apply) -Writing (I think then it would better apply to dialogue, story, etc.) -Programming (technically scripting could still work...although programming sounds more professional IMO) Or maybe even just let users create their own "skills" (i.e. add either custom or pick from a list of skills to add)? Although, that might make things really messy xD Though, I do think it would be better to use more generic skills that can apply to any engine or game development team/environment. ps. Just in case you forgot, I am STILL TOTALLY STOKED FOR THIS. (and I think it looks VERY nice.) keep up the good work boss <3

Hmm, interesting I would never have thought of attempting to create a menu with half scripts and half events. Personally, I think this approach is a bad idea...and will probably be a lot more painful than necessary BUT, Before I lecture you about why this *may* be a bad idea impractical (I believe in letting people make their own decisions), I will first tell you what the issue is: So, firstly, Google isn't going to give you much information on RGSS specific errors. Ruby errors you'll find plenty of documentation; but RGSS documentation is not widespread...however, for your benefit I will redirect you to RPG Maker XP's help manual. It can be a little iffy on the wording at times, but if you look, it has a COMPLETE Ruby + RGSS reference manual and will give you MUCH more information on RGSS (that I know of) than any other source... With that said, I'll explain this error: As you probably know, Window#dispose will free all resources being used by the receiver (instance of window). However, what is important to keep in mind, is that when Window#dispose is invoked, the receiver is still considered a instance of a window -- only it is a disposed window -- and more importantly, any method invocations on a disposed window will raise an RGSSError. Which is what happened in this case. So, let's take a look see at why this error was raised: 1. $window = Window_NewMenu.new -> Window is instantiated and stored in `$window` 2. Event loop 3. if $window.is_a?(Window_NewMenu) -> true? 4. $window.update; $window.check_input 5. wait a frame (here is your source of input lag btw) -> false? 6. break event loop 7. end if 8. end loop Well, firstly, we know the game reaches 4 (as you are able to at least try to select an option, which is our next clue). So, we know selecting a menu option crashes the game... so let's see what happens when an option is selected: def check_input if Input.trigger?(Input::C) $window.dispose if self.index == 0 $scene = Scene_Item.new elsif self.index == 1 $scene = Scene_Equip.new elsif self.index == 2 $scene = Scene_Save.new elsif self.index == 3 $scene = Scene_End.new end refresh end end So, when the player presses the `C` key, -$window is disposed -$scene is set to a new scene object -refresh method is called self.contents.clear happens to be the first line of the refresh method... The issue here, is that, in this context (i.e. $window.check_input), self in the refresh method refers to $window. Invoking ANY method on $window after it has been disposed will throw that error. So, don't dispose $window before calling it's refresh method. A couple of tips: -Avoid global variables like the plague. They can be a very useful tool, but should ONLY be used when absolutely necessary--they are much more error prone (as in this case, referring to a global object of class X from within class X). Sometimes, static members within a class/module are a better design pattern...but then again this is just my opinion... -I would rename check_input to update, and make the first statement within that method a call to super. considering that check_input will probably ALWAYS be called immediately after update, you can just take advantage of the inherited update (if you like to save time typing...) - As a general rule of thumb, the update method should be called once per frame... However, the refresh method (in this case) SHOULD not. refresh (in this case) simply draws contents into the window's bitmap (contents). If you need to change the content within the window, then you would need to clear and redraw the entire bitmap...however, since this window ALWAYS displays the same information, you should only call refresh ONCE (when the window is created). (calling it each frame isn't necessarily a HUGE issue...but, it IS technically a waste of resources, and graphics processing is QUITE expensive) Mind you, this is MY opinion, and you are welcome to listen or ignore...and the same is true for the following lecture. LECTURE ALERT And............ that's my 2 cents. Hope it helps.

I think I know the issue. You are correct, Window_Selectable carries all the code required for Input Handling. This is the method from `Window_Selectable` that handles input: Window_Selectable#update (RPG Maker-wise, the update method handles player input where needed) Here's the deal though: This method IS NOT automatically called within the Window_* Classes. I'm sure you've noticed, but RPG Maker uses a "Scene" concept--every "game screen" is managed with a corresponding Scene_* class (Scene_Map, Scene_Title, Scene_Menu, etc)--and the Scene to which the Window_ object belongs to should be responsible for calling the update method. So, in your Scene_Menu (or whatever you may have named it) you must ensure you are making a call to Window_NewMenu#update. Without this call, the Window WILL NOT respond to input. Here is a snippet from the default menu: Scene_Menu def main # Command window setup code... @command_window = Window_Command.new(160, [s1, s2, s3, s4, s5, s6]) # menu window instantiated # More Setup code... # Main loop loop do # Update game screen Graphics.update # Update input information Input.update # Frame update update # Call Scene_Menu#update # Abort loop if screen is changed if $scene != self break end end # Scene break down code... end def update # Update windows @command_window.update # More update code... end Note that Scene_Menu#update makes a call to Window_Command#update (Window_Command is also a child of Window_Selectable, which provides the user input handling) So, just make sure you are making a call to your Window's update method each frame. Also, RPG Maker tends to put the user confirm/cancelling code in the Scene_* class... However it isn't absolutely necessary. If you leave the confirm/cancelling input in your Window_NewMenu class, make sure you are also either: A) Making a call to Window_NewMenu#check_input from the Scene_Menu class or B) Make a method in Window_NewMenu called update, make update's first statement a call to the super method, and put the code from check_input after the call to super. Then, when you call Window_NewMenu#update from Scene_Menu, it will call the key up/down/etc. code from Window_Selectable as well as the confirm/cancel code from Window_NewMenu#update Hope this helps.

Don't be sorry :3 Open the script database, and scroll to the bottom (in the left box). There will be a Script titled "Main" at the very bottom, right click that script and click "Insert" A new, empty script will appear above Main. Then, select that empty script and paste my script into the script window (in the right box). Then, if you want to call script from an item: ->Open the database ->Make a new common event ->Add a "Call Script" event command ->Type $scene = Scene_Crafting.new into the Call Script box ->Make a new item ->Set Scope to "None" ->Set Occasion to "Only from Menu" ->Set Common Event to the common event you just created Then when the player uses the item, the common event will be called; which will execute the call to the crafting scene.

Hmm, would you be able to post the scripts? I might be able to get a better view of what's going on exactly. Which array has sub arrays? I know the *default* $game_party.actors is a 1 dimensional array...though I dunno about the other ones (or if the scripter changed that). In the meantime, perhaps I can give you a bit of advice (I hope you don't mind my long tangents....I REALLY can't help myself lol) *you probably know some of this already, but I'll try to clarify some things, in this context* First off -- Arrays in Ruby: Arrays are very similar in all languages. In ruby arrays are ... 1. 0-based -> this is true for most languages, this means that the index of the first element of an array is 0, and the index of the last element of an array is always (number of elements - 1). In ruby you can call array.size to get the number of elements in the array array = [1, 2, 3] puts "First element: #{array[0]}" puts "Last element: #{array[array.size-1]}" # Output: # First element: 1 # Last element: 3 2. Dynamically Sized -> This is one of the most convenient bits about ruby arrays. They will shrink/grow as elements are added or removed (i.e. array.push(obj) array.pop etc.) The other nice thing about this, is you can refer to an index of an array that is out of bounds without causing errors -- if out of bounds, ruby returns `nil` array = [1] puts array.size array.push(1) puts array.size array.pop puts array.size puts array[50] # Output: # 1 # 2 # 1 # nil 3. Negative indices -> If a negative index is referred to of an array, ruby grabs the element relative to the last element. array = [1, 2, 3] puts array[-1] puts array[-2] puts array[-3] # Output: # 3 # 2 # 1 4. Mixed types -> This can be convenient, and potentially dangerous if one is not careful...but it's a feature that can be REALLY useful. A ruby array can contain any type of object, and various types as well. array = [1, "string", 4.5, [1, "string"], nil, Time.now, 0..4] There are probably more features, but these are the more important ones to keep in mind (well, also being able to enumerate/iterate over an array...but I already mentioned this) Next important thing (I think *this* might be messing with you most) In most programming languages (especially OOP languages), there are 2 main "data types" -- value types and reference types. A value type is usually what most people would call "primitive" data types (i.e. Integer, Float, Char, etc) where as a reference type is usually what people would refer to as an instance of a class. The most important thing to know about these "types" are: Value Types: - passed by value, meaning the actual value is "copied" when passed to a method/variable Reference Types: - passed by reference (memory address), meaning the reference to the object is passed to a method/variable (object IS NOT copied) In ruby, everything is an instance of an object (I do literally mean EVERYTHING), HOWEVER, it is EXTREMELY important to note: ALL OBJECTS ARE PASSED BY REFERENCE, EXCEPT FOR NUMERIC OBJECTS (i.e Fixnum/Integer or Floats) This is especially important for arrays, as arrays are reference types. Hmm...That seems confusing a bit. Perhaps an example could help: a = [1, 2, 3] # Array is loaded into memory, then Array.new is called # Memory address of newly created array is stored in variable `a` b = a # a's value (memory address of [1, 2, 3]) is copied to b b.push(4) # push 4 into array stored at address referred to by b puts "Array A: #{a.to_s}" puts "Array B: #{b.to_s}" # Output: # Array A: [1, 2, 3, 4] # Array B: [1, 2, 3, 4] # Notice array a.push(4) was not called, but a/b refer to the same array in memory puts a.object_id puts b.object_id # Output: # 22209828 # 22209828 Therefore, you should be careful when calling "Destructive" methods upon arrays. Destructive methods are methods that modify the object in place, rather than returning a modified copy: # Array.delete is destructive a = [1, 2, 3] a.delete(1) puts a # output # 2 # 3 # Array.reverse is not destructive puts "a#reverse" puts a.reverse puts "a" puts a # output # a#reverse # 3 # 2 # a # 2 # 3 # Array.reverse! is destructive puts "a#reverse!" puts a.reverse! puts "a" puts a # output # a#reverse! # 3 # 2 # a # 3 # 2 If you ever need to pass a copy of an object rather than the reference to the object, use object#clone or object#dup puts a.object_id puts a.dup.object_id puts a.clone.object_id # output # 23857056 # 23060688 # 22197900 Now, as you know (and mentioned yourself) objects have properties/methods. The really important thing here is to understand how referencing these things work. Most (as far as I know) Object-Oriented languages use dot notation or the dot operator `.` What you need to know about this, is that anything to the LEFT of the dot is an object, and anything to the RIGHT is a method/property of that object. Also, the dot operator works from left to right So, in this context, `actors` is a property of $game_party (which is an instance of the Game_Party class) $game_party . actors object < > property in Game_Party, actors is an array object containing all the current actors in the hero's party. (note: each element of $game_party.actors is an instance of the Game_Actor class, which has it's own properties and methods) After $game_party.actors is invoked, the actors array is returned (as an object) to the calling statement...i.e, if you wrote this: a = $game_party.actors a will be a reference to the $game_party.actors object Or a more detailed example: a = $game_party.actors.dup $game_party -> object actors -> property of Game_Party dup -> method of Object (in this case the object is the actors array) finally, dup returns to this statement, putting a reference to a copy of $game_party.actors into `a` So, a property of any object can be called from an instance of that object. Note: print $game_party.actors.name works because $game_party has a property called actors, that is an array, which has an element which has a property called name print @count_battlers.battler.name does not work, because (as far as I understand), @count_battlers is an array. Array objects do NOT have a property called battler. If you wanted to print the contents of @count_battlers, you would be better off doing: print @count_battlers[i].inspect # If @count_battlers is an array of battlers, print @count_battlers[i].name # will work # My favourite however, for printing array contents: print @count_battlers.inspect # no loop required, and displays ALL elements at once In regards to array comparisons, you seem to be a *bit* mixed up: <, <=, ==, >=, >, != are comparison operators, where as &, |, - are special array operators (with other objects, these operators have other meanings) array & other_ary -> array intersection, returns a new array containing only elements common to array and other_ary, with duplicates omitted: irb(main):044:0> [1, 2, 3] & [1, 2, 3, 4] => [1, 2, 3] array | other_ary -> array join, returns a new array containing all elements of array and other_ary, with duplicates omitted: irb(main):046:0> [1, 2, 3] | [1, 2, 3, 4] => [1, 2, 3, 4] array - other_ary -> array difference, returns a copy of array with any items that appear in other_ary removed: irb(main):047:0> [1, 2, 3, 4] - [1, 2, 3] => [4] As for the last bit, I'd have to look at the script in question to help you there. Although, perhaps I may be able to shed some light on "if added_actor == @count_battlers.battler" Unless the == method has been defined for an object, object == other_object will compare references, rather than the object itself. So, even if added_actor is "the same" as @count_battlers.battler, if either one of those objects are a COPY of the original, that statement will ALWAYS return false. *Ahem* ANYWAYS, you don't need to read through all that, just thought I'd ramble again. Hopefully it makes sense, if you need further clarification, just ask. Though, if you'd like to post the script, I could look over it for you. It would be easier to explain if I knew EXACTLY what each variable was. Right now, I'm just kinda taking stabs in the dark at finding you a solution.

Sorry, for some reason my post was getting cut off :( IN THE MEANTIME.... SCRIPT WITH BUG FIX + BREWMEISTER's MODIFICATION ADDED:

To add to fZer0's response: Yes, it is not the script causing the sound effect, it's the animation that is played through the script: event.animation_id = 98 #98 happens to be the exclamation animation 98 is the ID no. in the database of the animation that is played. You can: A) Change this number to another animation number B) Edit animation no. 98 in the database to play no sound, a different sound or even change the entire animation all together.

Sorry for the late response... School's been hectic... FIRSTLY, as an FYI to everyone(if anyone cares xD), I *am* really really close to finishing version 2.0 (which will be much better...IMO) (and Kare, I *AM* almost finished your request as well, sorry it's been so long) *ahem* anyways, @souldustwolf: You are in luck, these are some easy fixes! 1. You actually got the configuration perfectly...however, Since this is a recipe based system, recipes will only show up in the window IF the party is currently holding that recipe. Have you put the recipe in the party's inventory? 2. Good bug catch, *ahem* lemme fix that... (this is a really old script xD, there might be more bugs hiding in there) 3. ahhh, ok, I'll add that in for you 4. Oh yay, another reader :D I hope the tutorials help...Ask me if you need any help. (Which reminds me....I'm REALLY behind on those tutorials :( Hopefully over my break I'll be able to get some done)

Hmm, I think I worded that funny. array - array will return an array, then other_array.delete(array) will try to delete the array from the other_array, which would not exist within that other_array Hmm... maybe that was more confusing xD, Let me demonstrate the issue with that solution: (pretend the number values represent battler objects) count_battlers = [1, 2, 3, 4] game_party = [1, 2, 3, 4] watched_party = [1, 2, 3, 4] # Remove last actor from party: game_party.delete_at(3) # last index == 3 # Get removed actors new_ary = watched_party - game_party # new_ary == [4] count_battler.delete(new_ary) # count_battler == [1, 2, 3, 4] as no element within count_battler == [4] So, technically, there are no sub arrays. And since you are trying to remove an array from another array (which would/should never have a sub array) However, perhaps I could re-explain my original solution: If you have used ruby enumerators before, this should be easy..if not, hopefully I can clear it up. The 2 most common enumerators/iterator on an array are array#each and array#each_index. For example, array#each { |item| block } will loop through each element of array, and on each iteration passes that element to the local variable `item`. `block` is any block of code, which will be executed on each iteration/loop. Really, you can think of an enumerator as a fancier (and technically much more efficient) version of a `for` loop. array = [1, 2, 3] # For loop: for i in array puts i end # array#each # NOTE: { |i| block } is the same as # do |i| # block # end # Generally, ruby programmers use do...end for multi-line blocks and { ... } for single line blocks array.each do |i| puts i end # OUTPUT (will be the same for either method): # 1 # 2 # 3 Now, array#delete_if { |item| block } is also an enumerator. On each iteration, the element of the array is passed into `item`, and then, if `block` evaluates to `true`, that element will be removed from array.... So: array = [1, 2, 3] array.delete_if { |i| i == 2 } # array is now: # [1, 3] # when 2 (element index 1) is passed into i on the second iteration, # i == 2 evaluates to `true` and thus 2 is removed from array. Therefore, in my solution, on each iteration the current element (an actor/battler) will be passed to `battler`. Then, when removed_actors.include?(battler) is `true`, meaning the current battler from @count_battler is contained within removed_actors. Therefore, if a removed actor exists within @count_battler, it will be deleted. And here's another solution I just thought of...which is ultimately simpler/less confusing.... (I left the explanations in case you wanted to know anyways) # Get the removed actors: removed_actors = watched_party - $game_party.actors # removed_actors is now an array containing ALL `missing` actors @count_battler = @count_battler - removed_actors # @count_battler is now an array, WITHOUT the actors contained within `removed_actors` xD I told you I needed some sleep. note: of course, if you like simplifying things...you can do this all in one line: @count_battler -= watched_party - $game_party.actors And, to come full circle, here's a demonstration: irb(main):035:0> game_party = [1, 2, 3, 4] => [1, 2, 3, 4] irb(main):036:0> wacthed_party = game_party.dup => [1, 2, 3, 4] irb(main):037:0> count_battlers = game_party.dup => [1, 2, 3, 4] irb(main):038:0> game_party.delete_at(3) => 4 irb(main):039:0> count_battlers -= watched_party - game_party => [1, 2, 3] *ahem* now, with that all said and done, is there a reason why you can't just manage all this in 1 or 2 arrays? I mean, maybe it would be pretty hard to manage with just ONE array, but IMO, I think it would me much easier to use $game_party.actors (for player's party) and another array for ALL battlers in battler (ie. @count_battlers) then, just manage both at same time? EDIT: LOL, you JUST beat me to it. *props*

I'm not 100% sure I fully understand what you need to do... I think (correct me if I am wrong) that in this battle system, you add or remove actors from $game_party.actors; then, you need to figure out which actors were removed and remove the same actors from @count_battlers? If yes, then I think what you are trying to do is more like this: # $game_party has actors removed # find removed elements (actors) removed_actors = watched_party - $game_party.actors # delete removed actors from @count_battlers @count_battlers.delete_if do |battler| removed_actors.include?(battler) end First, you need the "removed" elements, assuming $game_party.actors has elements removed, and watched_party is the same except still contains the "removed" elements, then you need to capture a new array containing those elements: removed_actors = watched_party - $game_party.actors array - other_ary returns a copy of array, with any common elements from other_ary removed...thus leaving you with the removed elements. Then, array#delete_if { |item| block } will iterate over each element in array, and removes each element that block returns true for... i.e. removed_actors.include?(battler) will return true, if removed_actors contains the current battler in the array. The only problem with your code, is that array#delete(obj) will delete obj from array if it is contained within that array. If you try to delete(array) from an array, it will ONLY remove an element that is an array, equal to that array. Hope that made sense, hope that helps. I need some sleep xD