Kayzee

This site has been semi-dead for a while ya know? Also I think it's hard for a lot of people in the RPG Maker community to get really excited in general. I think I somehow missed that battle system vid, but in general most JRPG-style battle systems don't excite me very much. Don't mean to be a parrty pooper though! The game still looks very pretty and seems like it might be fun!

The nice thing about script calls in move routes is you can just use 'self' to get the current event object like this: $game_variables[0] = self.x $game_variables[0] = self.y $game_variables[0] = self.direction Though in this case it is probobly better to use '@' to look up the current event object's private attributes/variables directly like this: $game_variables[0] = @x $game_variables[0] = @y $game_variables[0] = @direction In either case replace 0 with whatever variable number you want. Also, Just FYI: Let explain the difference between these two things for a bit, it may be handy in the future. You see, RPG Maker VX Ace uses Ruby, and in Ruby all of an objects attributes/variables are basically like secrets that only it knows. However you are able to make it so an object can tell other things the secret when asked. Why is this important? Because objects usually don't give away all their secrets, a lot of things it might need to figure out on the spot and can't just give a secret answer for, and sometimes they can just outright lie. An object can respond to things any way it likes. Basically 'self.' is gonna give you what the object will tell everyone else when asked, and '@' is gonna give you some of the secret information it keeps hidden from everything else.

Though really I expect there will be a lot of characters in my game like that. If I ever finish it. XD

I have a character like that in my game too sorta! Not sure if I am gonna make her explicitly sexual (probobly pretty lewd though), but she definitely could be described as some kind of predator. Shes a fairy who basically tries to steal the player away to fairyland to play with forever. She is very cute, often makes horrible puns, and can be comedically childish. She also can be very creepy, sort of manipulative, and amoral. But I mean, she is a fairy. That's kind of to be expected. Am I worried that a character that is both comedic and more then a bit predatory will undermine the impact of the more unsavory aspects of her personality? Actually no. I expect in fact the more comedic elements to actually reinforce the impact of her creepy otherworldly predatory nature. Basically she is a character that (if I write her right) should seem cute but the more time you spend talking to her the more you notice she is ever so slightly 'off' compared to normal humans, and after a while she starts going form endearing to creepy and back so suddenly and casually as to really send chills down the player's spine. In fact I am sorta worried about going to far and actually creeping people the heck out. I don't really want people to hate the character, after all she is me. ;)

I will try and remember to give it a look at least, but I don't play nearly as many games as I used to. It';s not that I am busy really, it's more that I am a pretty lazy fairy sometimes.

Wish granted! You now have a much better perspective on 2D graphics. You can't actually draw any better or have any new skills or anything, but your attitude sure as changed and that has to count for something right? I wish that annoying voice in my head that always begs and whines to leave it alone (even when I actually am) would, ya know, not do that. Yeah this gonna backfire horribly but at this point a change would be refreshing. >_>

What's really interesting to me is this line: Do the skills in question have any other effects besides calling common events? Do they work if given one? Calling a common event is done differently to how other effects work, so I wonder if something is causing skills without any normal effects/damage to be ignored? More technically, MP/TP costs are paid and common events are set up in the same place, the battler's 'use_item' method. If for some reason this isn't called for some skills, the result will be no MP/TP gets taken away and common events are not run. Edit: Also might have to do with the skill's scope if it's set to 'None'.

Hehe, that trailer looks pretty cute... Nice way to use the quarantine! Even if you can't go outside and play much, you can always make a game world and play there right? :3

I did do something like that in VX Ace with scripts actually. I remember at one point I was trying to get a ghost enemy to work by turning 'through' on and off but I kept running into problems. I mean the idea of keeping through off in walkable areas and turning it on before it moves into a wall sound simple enough, but the catch is through also needs to be on when exiting a wall, and if it's on it will ignore all character (events, player, and so on) collisions too, so it will step into characters when exiting walls. I eventually made a 'pass type' script that fiddled with how characters decide what map tiles are 'passable' so that characters could either swim (move through water), fly (move over water/pits), or act like a ghost (phase through every kind of map tile). Since this ghost movement was only for map tiles, character collisions still worked and a ghost couldn't just step on a square that had another character on it. On an unrelated note, my little 'pass type' script had a lot of kinda silly advanced features. I also allow any feature object (aka states, equipment, classes, or anything else the game checks for features related to a battler) to set pass types too, so you could have a status effect that made the player float, or since all the enemies in my game are events with a battler attached to it it works on enemies too. Also made some little neat visual effects. When swimming it acts like a tile with the bush flag so the character looks half-submerged, flying characters float up and down a bit and have a shadow that changes size/opacity in sync with the float, and ghost characters are always have half their normal opacity if they are inside a wall.

I am happy to help when I can! *sprinkles fairy dust on you*

Yeah note tags can be a pain in the butt to deal with sometimes, especially since every script basically needs it's own way to load/parse them. Personally though when I write scripts I don't even bother making each script load/parse it's own note tags and use this script to load/parse stuff for all my scripts instead. It makes things a million times simpler for me as someone who makes a lot of my own scripts. If you only are using three skills though? Yeah, just use conditionals I say.

Methods maybe? Operators in Ruby are really just fancy methods. For example this would be how you actually define '+': class SomeClass def +(value) # do something here end end Really in Ruby 'x + y' kinda translates to 'x.+(y)' Personally I would have probobly used a note tag of some kind. Though really items and skills are basically the same thing. In most cases you could probably just use reusable items instead of skills, but I don't know if that is practical in this case.

One alternative to 'x += y' for arrays would I think be 'x.push(*y)' where * in this case is the splat operator. Not sure if 'x << *y' would work though, because although .push accepts multiple arguments, I am not sure if << does. Yeah that's weird... as far as I know += should be defined if + is defined... Though it could be that for totaldata's class '+' is not defined, but it is for object's class and Ruby will use object's '+' when it encounters that situation because for numbers x + y and y + x are the same thing. This isn't always true for other types of objects, but I could imagine this being assumed. If so, this is what I might expect to happen if 'totaldata' is nil (or undefined) and 'object' is a string. Saying something like ' nil + "string" ' might actually work fine then because Ruby would reinterpret it as ' "string" + nil ' which would try and convert nil to a string by calling nil.to_s which I believe always returns the empty string (aka ""). Therefore 'totaldata = totaldata + object' would work, even though it really shouldn't. However 'totaldata += object' would not. Because + is not defined for totaldata, += would not be defined either and in this case Ruby would not assume that x += y is the same as y += x because they obviously wouldn't be the same even for numbers. Usually in that case you would want to set totaldata to "" before you start using it. That way you are absolutely sure it's a string. Good luck then! *sprinkles fairy dust on you*

Keep in mind that += and << do very different things. Pretty sure that << works identically to the .push method, adding something as a new member on to the array. On the the other hand += is a way of combining two arrays into one. In this case, '$data_skills.select {|skill| usable?(skill) }' is an array containing all usable skills. Using << here would add one new member to the @data array containing the usable skills array, which is not what we would want is it? Using += here would add each member of the usable skills array to the end of the @data array, which is what we would actually want to do. Side note: By a 'section that does not use math operators in a full capacity' I can only assume you are talking about the traditional difference between 'statements' and 'expressions' in many programing languages. In some languages operations like += might be defined as 'statements' and not allowed to be used where the language expects an 'expression'. Probably mostly in languages that use '=' to both set if used as a statement (such as 'x = 5') and compare things if used as an expression (such as 'if x = 5') rather then use '=' to set and '==' to compare. In Ruby however the difference between 'statements' and 'expressions' is virtually (but I don't think entirely) nonexistent. Otherwise, math operators are defined purely by the object(s) they operate on. The biggest reason something like 'x += y' might give an error is that ether the + operator is not defined for the class of x, or that the + operator for the class of x is unable to handle an object of the class of y. Happens most often in my experience because x and/or y were never actually set and default to nil. Then again... I am kind of confused because I thought you wanted a bunch of skills to show up in the item menu, not just one?