Gus' Text Input Module

[Gust]

[Really loong post by BlueScope]

Thanks for the comment \o
1- I like the blank line to separate blocks of code. I think it improves reading.
2- The alias... man, I read that once in the SDK conventions and I thought "well, if there is some sort of convention out there, I should follow". And i really think it is a good idea to avoid name clash =P
3- The Scene_Name issue is 99% probably your fault lol Post the code and I can try to help.
4- Well, I really didn't have the ambition to make a complete Input module here. I mean, there are a lot (at least two) very good input modules out there that people are used to. All they lack is this one feature, so I thought "I should do a module to complete them, there's no need to redo everything". About combining, there's really no reason not to. If you read the DLL code you'll see, my approach doesn't use the same method the others do, and it doesn't interfere with the key states or whatever.
5- Yea, I know this script is not that useful. Actually, I made this with online games in mind. And because I was bored and wanted to mess with windows api. A few months ago I released my RWK here (another fun-to-make-not-so-useful script) and I wanted to make a little sample forum for it, and I couldn't find an input script that worked for everything. But even for offline games I think full text input could be a good addition: think about a notepad in a mistery game, or something like that. Or just to make a Scene_Name that doesn't look like made for SNES.
6 and last- I have a few years of experience with Java and some C/C++. I mess with Ruby now and then. It is pretty easy to learn, but I never really studied all the dynamic-language features, so I guess my scripts look like java code translated XD

2- They were needed. Is there any other way to store info relative to the module itself?

An instance variable, as Glitchfinder said.
The difference is, that you can not access those instance variables in an instance of GTI.

p GTI.instance_variable_get(:events) # should print something

p GTI.new.instance_variable_get(:events) # should print nil

Class variables are available in a larger scope, for example instances of a class.

The class variables are actually like the static variables in Java.
GTI is an instance of the class "Class". And as it is an instance of something, it can have its own instance variables.

=O Oh, I get it. They're instance variables of the Class object. What confused me is that they're defined in the class body. How do I tell if a @variable is an instance variable of the Class object or an instance variable of the instances of the class, then? O.o

3- I know that "private" doesn't do anything in RGSS, but since it is a part of actual Ruby, I thought I should put it there to remember "DO NOT USE THIS METHOD" XD

This is not what I meant. I was talking about String s = ' '*8.

LOL I DIDN'T SEE I DID THAT XD
As I said previously about the semi-colons, that's my Java side working XD
Thanks, I'll correct it right now =]

Would you mind providing a demo?

I can't seem to get this to work with my crappy RGSS knowledge. :rock:

You couldn't even get the Scene_Name example to work?
Just paste GTI anywhere above Main, and the Scene_Name script above main and below GTI (and the original Scene_Name). Then download the DLL and put it in the same directory as Game.exe.
Make an event that asks input for hero name to test.

 

[Neo-Bahamut]

How do I tell if a @variable is an instance variable of the Class object or an instance variable of the instances of the class, then? O.o

That's depending on the place you use it.

class Test

 @var = 100 # instance variable of Test

 

 def Test.var

  return @var # instance variable of Test

 end

 

 def initialize

  @var = 500 # instance variable of a Test instance

 end

 

 def var

  return @var # instance variable of a Test instance

 end

end

Or I could also say: The instance variable belongs to the object you get with "self".

 

[BlueScope]

2- The alias... man, I read that once in the SDK conventions and I thought "well, if there is some sort of convention out there, I should follow". And i really think it is a good idea to avoid name clash =P

Like I said, I know where you got it from, and I know you think it's awesome (and everyone else will agree). I'm just stating that it isn't. XD

@NeoBahamut: I know that method, and while it's definately a valid one, using semicolons seems "more correct" to me... it's also more compact, and of course way faster to type... but you're right, it's not a necessity at all ^^

 

[kyonides]

I disagree with BS, that kind of aliasing provides people with an idea of who scripted the code, who might help them if possible... or even suggest if the scripter is a newbie or a well-known scripter, etc.

 

[Gust]

2- The alias... man, I read that once in the SDK conventions and I thought "well, if there is some sort of convention out there, I should follow". And i really think it is a good idea to avoid name clash =P

Like I said, I know where you got it from, and I know you think it's awesome (and everyone else will agree). I'm just stating that it isn't. XD

It is common practice in C to put a prefix in function names in libraries because all the functions share the same namespace. The prefix usually has something to do with the name of the lib itself, but that's as redundant as putting the scripter's name. My point is: it's a practice in a classic language that has worked quite well until now, maybe copying it isn't a bad idea.

 

[Glitchfinder]

It is common practice in C to put a prefix in function names in libraries because all the functions share the same namespace. The prefix usually has something to do with the name of the lib itself, but that's as redundant as putting the scripter's name. My point is: it's a practice in a classic language that has worked quite well until now, maybe copying it isn't a bad idea.

While it's a generally acceptable practice in a language like C++, theres one key difference between C++ and RGSS/RGSS2. That difference is that C++ has hundreds of times more programmers using it than RGSS/RGSS2. At this point, it looks like RGSS will never have enough scripters working it to make it a necessary practice to include your name into a function name or alias, since there are very few scripts that will end up with exactly the same name for an alias, if they just include the script name. Especially since most people prefer naming their script something unique.

 

[Zeriab]

Good work Gus. :cute:
I think you will find The ruby object model interesting as it does not work the way you would expect when coming from Java. (Everything's an object)

Class variables should only be used when really needed. They often show some weird behavior.

Please do elaborate, preferable with examples of weird behavior. I haven't noticed any weird behavior myself so I am quite interested :cute:
If you mean the @running and @events variables in the GTI module then I would use class variables because it would more clearly indicate that you only want one hook.

3- I know that "private" doesn't do anything in RGSS, but since it is a part of actual Ruby, I thought I should put it there to remember "DO NOT USE THIS METHOD" XD

It does set the visibility of future methods in the class scope to private, but there is a caveat. It doesn't affect class methods. I see two immediate solutions to this problem where the first one uses private_class_method
[rgss]  def self.pop
    # ...
  end
  private_class_method :pop
[/rgss]
I don't think there is a no-argument version which sets future method, so it has to be applied retrospectively.

The other version is to mess around with the hidden inner class. (The video I linked to will explain what I mean)
[rgss]  class << self
    private
    def self.pop
      # ...
    end
  end
[/rgss]

There are definitely other methods as well. Know also that the methods can be made public later as well.


I prefer your alias name which follows the convention over what BlueScope suggests because it is a trivial thing to implement which reduces the chance of compatibility problems between script. Its strength lie particular in that it is an established convention which people have come to expect. For scripts just for your own project then I would agree with Blue.

*hugs*
- Zeriab