Options YOU want on a CMS's options screen.

[Ryex]

All right as it stands right now school has finally let up enough that i can get back to work on ms script, but before I continue I need to come up with a list of options that are going to be on the menu.

so far the list of options that WILL be included are:

*BGM volume
*SFX volume
*Font
*Window skin

Options that are up for inclusion IF people want this

* dividing the Window skin option in two and making it so you can select the default window skin and the menu window skin individually
* open for suggestions

Now DON'T post here telling me that it is my CMS and to do what i want I'm VERY indecisive and if it is left to me I will likely procratanate to the end of time.
PLEASE post confirming the current options, asking for new ones, OR ask for one NOT to be included.

you input is greatly appreciated

~Ryex

[Starrodkirby86]

Some of the best options can be customizable options that will be painless towards an Option script.

Such examples can be a Letter-by-Letter message speed, Message color, Dash, etc. (Which I'm mostly basing off from Final Fantasy's GBA versions)

This is if you want to make this public.

If you're making it private, you're still able to do that up there. Some of the best options are truly integrated into the game and aren't just universal plug-in and you're done.

I don't know any other suggestions to put at the moment.

[Ryex]

this will be a public script I'm just trying to think of universal options that could be useful in game

[OracleGames]

some games have difficulty settings you can change during the game

[fugibo]

some games have difficulty settings you can change during the game

But in an RPG, that can be used to just tone down the difficulty in the hard parts and set it to hard in the easier parts. That's cheating >_<

[Blizzard]

I think that font and windowskin options shouldn't be included. I only used it in CP because the graphical style is not consistent anyway. With the proper font and skin you can breath in some live and atmosphere into a game so the player shouldn't actually be able to change that.

[fugibo]

Oh, yeah: Plug-In API, so that other people can add options easy. Nothing too complex, maybe just an array of Procs to be launched when a user selects an option from the menu. ie

class RyexCMS
  PLUGINS = []
  class PlugIn < Proc
  def initialize( name )
    super()
    @name = name
  end
end

Then add an option for each and have PLUGINS[<id>].call when that option is selected.

[Ryex]

Um WcW? while it sounds like a great idea I not sure how that would work... like you select an option from the menu and it calls
RyexCMS::PLUGINS[<plugin id>].< method name>
? your going to add a little more about what you mean i'm not a Blizzard yet

[fugibo]

I'm talking about Ruby's built-in Proc class, which is basically an object-oriented method (more like a conventional function, I guess.)

To create a Proc:

myProc = Proc.new do
  # do stuff
end

and then, to call it:

myProc.call

if you want arguments:

Foo = Proc.new do |bar|
  print bar # just an example
end

call it with arguments:

Foo.call 'abc'
Foo.call 'test'
Foo.call 'bar' # all of these just print the string :P

So, my idea was to make a subclass of Proc, called "PlugIn" or something, which also stores data on what type of plug-in it is. However, it turns out that you can't subclass Proc. So, instead, we should make a class that just has procs:

class PlugIn
  # make @name, @reqs, and @action 
  # read/write-able
  attr_accessor :name, :reqs, :action

  def initialize( name = '', reqs = nil )
    # @name is the name which will show up in the menu,
    # @reqs is the Proc that will be called to see if the option should
    # be activated (optional),
    # and @action is the proc that will be called when
    # the option is selected.
    @name, @reqs, @action = name, reqs, Proc.new
  end

  def call(*args)
    @action.call(args)
  end

  def check(*args)
    @reqs.all(args)
  end
end

Make an array of those; then, when someone wants to make a plug-in, they will just make a script like this:

if $RyexCMS
  RyexCMS::PLUGINS.push(RyexCMS::Plugin.new('My New Option') do
    # do stuff
  end
else
  print "You do realize that you have an add-on installed for a CMS you don't, right?"
end

[Blizzard]

Way to waste memory. I hope your window won't have too many options then. I'd hate to see RMXP use actually 10 processes or something like that.

[fugibo]

...what the crap are you talking about? Ten processes? Are you thinking of Threads, Blizz? 0_0

[Ryex]

oh i get it so...

if $RyexCMS
  RyexCMS::PLUGINS.push(RyexCMS::Plugin.new('shop') do
    $Scene = Scene_Shop.new
  end
end

would add a Proc that would call Scene_shop to the Plugins array

and...

for i in 0...RyexCMS::PLUGINS.size
  self.contents.draw_text(<x>, <y> + 32*i, <width>, <height>, RyexCMS::PLUGINS[i].name)
end

would print the name of all the plugins
and...

for i in 0...RyexCMS::PLUGINS.size+2
  case @option_window.index
  when i
    if i == 0
      #change BGM volume
    elsif i == 1
      #change SFX volume
    else
      if RyexCMS::PLUGINS[i-2].check(<args>)
        RyexCMS::PLUGINS[i-2].call(<args>)
      end
    end
  end
end

would call the first plugin in the RyexCMS::PLUGINS array if the third option in the menu was selected and call the second plugin's Proc if the forth option was selected ECT.

right?

the idea is awesome i'll give it some thought.

[fugibo]

Yes, you get it! Just two things, though:

1) NEVER use "for i in x..y". It's SLOW AS CRAP. For arrays, use "array.each do .. end", or to do something a certain amount of times, "<n>.times do ... end". So the code would be:

RyexCMS::PLUGINS.each do |plugin|
  self.contents.draw(...., plugin.name)
end

2) To call the option, I would just check to see if the <index> of your menu is greater than what is in it by default, and if it is, just call

RyexCMS::PLUGINS[<index - HOW MANY OPTIONS ARE THERE BY DEFUALT>].call

Also, you can add in more options to the PlugIn class so that plugins can do other things, too. It's all up to your imagination ;)

[Ryex]

awesome I learned something new! 

oh and shouldn't it be

RyexCMS::PLUGINS.each do |plugin|
  self.contents.draw(...., RyexCMS::PLUGINS[plugin].name)
end

instead of

RyexCMS::PLUGINS.each do |plugin|
  self.contents.draw(...., plugin.name)
end

PS: I've made over 500 posts! 

[fugibo]

No, in that instance, the actual object is passed to the block, not the index -- yet another useful feature

[Ryex]

oh lol i forgot the difference between each and each_index
I could use...

RyexCMS::PLUGINS.each_index { |plugin|
  self.contents.draw(...., RyexCMS::PLUGINS[plugin].name)
}

but what would be the point when

RyexCMS::PLUGINS.each { |plugin|
  self.contents.draw(...., plugin.name)
}

is less code and probably uses less memory

[Blizzard]

...what the crap are you talking about? Ten processes? Are you thinking of Threads, Blizz? 0_0

You are using Proc, not Thread. Yes, processes. Most probably invisible to the user, but still a stupid idea if you don't need it IMO. I also think the Proc use for a battle command in the RTP scripts is retarded. But there's not much I can do about it.

[fugibo]

The use of procs in the default engine does suck, but Procs require around as much memory as a method, so aliasing another script's methods will produce similar results. And heck, I did a quick benchmark (synthetic of course) on Procs yesterday, and an array of 1000 objects similar to what I told Ryex to use only consumer a little over 1mb. Assuming that the average user only uses around 10, that's almost nothing.

However, in a true game design environment, that would be horrible, horrible practice, I concur, but in RMXP it's not that big of a deal.

[Blizzard]

Yes, let's all do horrible practice in RMXP. Oh wait, we already have an SDK.

[Ryex]

Yes, let's all do horrible practice in RMXP. Oh wait, we already have an SDK.

lol