20 replies to this topic

[bigace]

Scene_Biography

Author: Bigace360

Type: Scene Menu

Version: 2.4

---

Introduction

This is a script that calls a window that displays different aspects about a character... like their age, height, gender etc. These can be changed though. This script is free to use and edit as long as credit is given to me.

---

Feature

Shows actors characteristic stats and battler image or imported image. Can also add a background to it now.

---

Instructions

Insert this script above main, and call it Scene_Biography. Everything is in the module so there's no need to go any further down unless you know what your doing. Also as default, the script uses the battlers set in the database unless you place a image in the picture folder and place _P at the end of the files name.

---

Screenshot

---

Demo
Not need

Script
Scene_Biography v2.4

Older versions:
Scene_Biography v2.3
Scene_Biography v1.1

---

Compatibility
No known issues.

---

Credits and Thanks

• Bigace360, for the script

---

Author's Notes
Enjoy!

Edited by bigace, 26 April 2012 - 12:16 PM.

[bigace]

Update v1.1
~ Just improved coding

I also fixed screenshot (appearently it disappeared). Another update will come later as I have to fix paragraphs with something bliz made.

Edited by bigace, 23 January 2012 - 01:20 AM.

[Calvinchun]

VERY SWEET SCRIPT!! I'll credit you...

[Moonpearl]

Interesting. Too bad that your script lacks flexibility (what if I wish to display additional info like star sign or whatever?). All the same, using constants does not seem like a very wise choice to me (what if I want to modify bio info in-game, for example to unveil things progressively?), even though Ruby allows modifying constants, you should consider using hashes instead. Besides, what's that ACE module? And what does it bring at all?

[bigace]

Moonpearl, on 08 January 2012 - 11:21 AM, said:

Interesting. Too bad that your script lacks flexibility (what if I wish to display additional info like star sign or whatever?). All the same, using constants does not seem like a very wise choice to me (what if I want to modify bio info in-game, for example to unveil things progressively?), even though Ruby allows modifying constants, you should consider using hashes instead.

As I said in my previous post I'm working on the paragraph script (Bio and History), so there not complete. You make it sound like this is the final script and theres no room for updates. If you want something added I'll add it, but don't try to ack like I don't know what I'm doing, like I'm just sitting here scratching my ass. I'm doing other stuff and upgrading this whenever I update my personal CMS. Don't worry about it to hard.

Moonpearl, on 08 January 2012 - 11:21 AM, said:

Besides, what's that ACE module? And what does it bring at all?

I'm not going to explain what a module does to a scripter, that just kind of sad don't u agree.

Edited by bigace, 08 January 2012 - 03:19 PM.

[Moonpearl]

Ow, sorry for trying and help you improve your scripting at all. I came here to give a hand, not to fight over who writes the better scripts. Anyways...

Quote

You make it sound like this is the final script and theres no room for updates.

That's the whole point. I'm actually making it sound like your script, the way it's written, can hardly be updated at all, unless you rewrite it in depth, that is. I'm not saying this is the final script, i'm saying you could gain much time in the future by working with a more flexible structure. Then again, if you want to spend hours rewriting code while it could just be a matter of minutes to add a new feature, suit yourself.

Quote

I'm not going to explain what a module does to a scripter, that just kind of sad don't u agree.

Of course you're not going to explain to me what a module does, because 1 - I know what a module does, 2 - I use modules myself and 3 - that's not what I'm asking at all. Nevermind though, I'm not going to explain to a scripter what a question about scripts means, either.

Edited by Moonpearl, 08 January 2012 - 05:09 PM.

[kellessdee]

I don't like the hostility I am seeing here.
Moonpearl and Bigace, please smarten up.

@moonpearl: Bigace didn't ask for suggestions on the source code itself. There is nothing wrong with making such suggestions, but you should actually give suggestions/ask questions. Cryptic/vague rhetoric makes you sound arrogant.

@bigace: Regardless of whatever you felt moonpearl's intentions were, there is no reason to make personal attacks.

I think this is all just a big misunderstanding, and I wanted to douse the fires before it got too large.
If either of you feel I am being unfair/wrong, please PM me or another staff member, and keep this topic for discussing the script.

Back to discussion:

@bigace: Nifty little script. Looks nice. Personally, I would change the way the name, gender, age, etc. are aligned, to make it look a little neater. Probably, the best would be to align the caption (ie. name:, gender:, age:) to the right, then put the data left-aligned next to it, to make all the data aligned at the colon `:`

@moonpearl: If the flexibility issue lies within using constants, shouldn't your suggestion be to not use constants (and use instance/class variables), rather than hashes? Hashes can be constants as well -- but arrays have better performance rates and, IMO, conceptually less-confusing to non-scripters.
Just my two cents--in the end, for something like this, I think it's kind of a non-issue (especially if it works). Although, that is an interesting suggestion for dynamic biographies, I have never seen that before.

[Moonpearl]

kellessdee, on 08 January 2012 - 07:45 PM, said:

There is nothing wrong with making such suggestions, but you should actually give suggestions/ask questions.

Is it not what I did? Need i quote the suggestions I gave and questions I asked?

Quote

@moonpearl: If the flexibility issue lies within using constants, shouldn't your suggestion be to not use constants (and use instance/class variables), rather than hashes? Hashes can be constants as well -- but arrays have better performance rates and, IMO, conceptually less-confusing to non-scripters.

Guess I mixed two suggestions in one. The flexibility issue mainly lies in using fixed names, regardless of them being constants or not. If you ever wish to add new features, this means adding new names, then adding new portions of code to process those new names, then adding portions of code to call those new portions of code, and so on. If you use either arrays or hashes instead, you may expand them at will with no need to tweak the rest. Personally I would prefer using hashes because this way you can easily add new features to the bio with no need for a reference table to know which index refers to which feature. Arrays do have better performance rates but as far as a bio menu is concerned, this would just need a single call here and there, so you wouldn't gain much. As for the conceptually confusing aspect, I don't know, but I bet it would be clearer for me if I saw a table matching a feature name with its value directly, rather than a table of values plus a table of references.

[kellessdee]

kellessdee, on 08 January 2012 - 07:45 PM, said:

If either of you feel I am being unfair/wrong, please PM me or another staff member, and keep this topic for discussing the script.

@moonpearl: I see what you are saying, but is adding a new constant array or adding a new key => array and then processing it actually saving any work (note that the current model uses an array, each index points to the actor ID in the database)? You would still need to add the new feature (with unique name and all), and then adjust the processing. Setting up a flexible hash and loop may make it easier for non-scripters to add functionality...but for the scripter it's not THAT much of a time saver. But really, in this scenario; I think neither an array nor a hash is really a good model. A good object oriented structure would probably define a biography as its own specific data structure, one instance for each actor. That would be much more flexible.

Also, hashes are easy for you to set up, because you already know how and understand. Explaining the syntax of a ruby hash to someone who isn't even familiar with any programming language syntax can be mind-boggling. Especially if you did something like this:

# Set up actor biographies here:
# Make sure that the feature points => to a list
# that corresponds to the correct actor id in the database
@@biographies = {
  :gender    => [ 'Male',
                  'Female',
                  'Male' ],
  :specialty => [ 'Swords',
                  'Guns',
                  'Spears']
}
# Or
@@biographies = {}
@@biographies[:gender][0] = 'Male'
@@biographies[:gender][1] = 'Female'
# etc.

If you expanded this to fit say 10 actors in the database, I think it would be enough to hurt even a professional programmer's head. With an object-oriented language to the extent of ruby, IMO, one should be careful not to lump everything into a list or table data structure (of course unless, that is the best way to describe the structure)

[Moonpearl]

Quote

A good object oriented structure would probably define a biography as its own specific data structure, one instance for each actor. That would be much more flexible.

I totally agree with that and that's exactly what I have in mind. I'm considering hashes because it seems to me like the best solution unless you go for an actual class. Your example is indeed difficult to read, but actually I would transpose it and rather do something like that:

$bio = [
  # Actor 0
  {
	:name => "Aluxes",
	:gender => "male",
	:age => 18,
  },

  # Actor 1
  {
	:name => "Basil",
	:gender => "male",
	:age => 20,
  },
]

Then, calling for a particular actor's feature would be like

$bio[actor_id][feature]

Properly commented, it seems very clear to me. As for the syntax, if you're not a scripter, you just have to replicate lines and edit the text, like I used to do when i was new to Ruby.

Besides, I do not agree that you still have to call features explicitly by their name, because using arrays and hashes, you can enumerate them. Thus, drawing a list of all the features would merely be like:

$bio[actor_id].each { |feature, value|
  # Write feature name
  # Write value
}

And here you have a tiny portion of code able to process the hashes, whatever they may contain, which allows the script's user to add/remove features from them at will, with no need to tweak the code. You can also manipulate the display order by merely changing the declaration order of the features in the hashes. And you're not even forced to fill all features for each character.

So, maybe because I'm a lazy guy, I do think it's THAT simpler for the scripter to do this way.

[kellessdee]

Ah yes, your example would be more readable than my example. However, for a non-scripter, I still think that structure still would be confusing. I know, there's not much you can do about that in the first place (there will always be a certain level of confusion), which is why I believe these kinds of things were not suited for arrays/hashes at all, and creating either a struct or class based around the model would be more efficient...as well as it could be added to the existing actor data structures:

$data_actors[1].gender = 'Male'
$data_actors[2].age = 13

With the enumeration, that's what I was referring to, by being easier for non-scripters to add features (then, features are simply added, rather than added, then manually drawn).
The issue with enumeration (in this case), is that you still need some way to handle A) Multi-line features (such as biography/history). B) Features in different columns.
(Otherwise, you are absolutely correct about the enumeration, although the current design *may* need to change in order to fit enumeration better...unless you want to write some algorithms to correctly determine/split up multiple lines, as well as add a way to customize which column the feature is placed in, and auto-sizing/positioning, etc.)

But really, in the end, it's difficult to design scripts for non-scripters to work with. There isn't really a "best" model, in those terms. Which is why *I personally believe* that a structured, object model is the best...after all, ruby is object oriented.

My personal preference, for customizable, list-based data structures would be:

# Pretend we have the user modify a text file that defines an actor's
# Biography:
def biography(id)
  case id
  when 1 then "aluxes_bio.txt"
  when 2 then "basil_bio.txt"
  end
end

I believe, that "when x then y" is easier to comprehend, than "= [ { key => value } ]" for non-scripters. But, that's what I believe...and that would depend on the user as well.
This also means, performance-wise, that no array/hash/string/objects are even instantiated/stored in memory, until used and they definitely, do not persist in memory for the entire running-time of the game.

EDIT: Oh yea, forgot to mention, being a lazy programmer, to an extent (especially in the context you are referring to it) is a good thing. The number one philosophy in the Ruby community (and with most languages as well) is DRY (Don't Repeat Yourself), which I am sure you have heard a lot. It's easier to do this with duck-typing...which is why Ruby is really focussed around these concepts.

[Moonpearl]

I get your point. If your concern is about non-scripters, though, I believe that no matter what structure you may choose, there will always be people who find it obscure. So, if a script is meant to be modified by potentially non-scripter users, I think the scripter should rely on comments rather than any kind of seemingly clear syntax (which is what I personally do). Thus, why not write an efficient script with proper commenting, rather than sacrifice a good structure to transparent syntax? After all, since non-scripters cannot script by definition, they should be able to use scripts without requiring to read them in the first place.

[kellessdee]

Yea that's the problem ... you can't satisfy everyone . Which is my issue for creating public scripts - when I create for non-scripters I always want to remove as much programming specific things from the customization as possible, which performance-wise is usually not efficient.

Any way, I think we both are getting a bit off topic now (thanks to my innate ability to derail threads)

[bigace]

Pointless Rant

Spoiler

Moonpearl, on 08 January 2012 - 04:41 PM, said:

Ow, sorry for trying and help you improve your scripting at all. I came here to give a hand, not to fight over who writes the better scripts. Anyways...
That's the whole point. I'm actually making it sound like your script, the way it's written, can hardly be updated at all, unless you rewrite it in depth, that is. I'm not saying this is the final script, i'm saying you could gain much time in the future by working with a more flexible structure. Then again, if you want to spend hours rewriting code while it could just be a matter of minutes to add a new feature, suit yourself.
Of course you're not going to explain to me what a module does, because 1 - I know what a module does, 2 - I use modules myself and 3 - that's not what I'm asking at all. Nevermind though, I'm not going to explain to a scripter what a question about scripts means, either.

Why your arguing with me when I told you that this script isn't really that complex to begin with is a mystery. I can except a suggestions, but as I said before I'm working on a whole bunch of stuff right now that updating to what you said won't happen soon. So as I said, what are you so pissed about? Hopefully this stupid argument as ceased as I never said I wouldn't take your things into consideration. Just told you'll fix the stuff on the next update. Just want to let you know that theres no hard feelings from my side that is. Sitll learning to script myself so, I'll think about it on the next update.

kellessdee, on 08 January 2012 - 07:45 PM, said:

I don't like the hostility I am seeing here.
Moonpearl and Bigace, please smarten up.

@moonpearl: Bigace didn't ask for suggestions on the source code itself. There is nothing wrong with making such suggestions, but you should actually give suggestions/ask questions. Cryptic/vague rhetoric makes you sound arrogant.

Thank you, the thing is I don't like it when people try to tell me things like I'm doing nothing but scratching ass all day (like Atoa thinks I do back on RRR and HBgames). As I said before I'll get to it when I get to it. Not trying to create hosility.

kellessdee, on 08 January 2012 - 07:45 PM, said:

@bigace: Regardless of whatever you felt moonpearl's intentions were, there is no reason to make personal attacks.

I think this is all just a big misunderstanding, and I wanted to douse the fires before it got too large.
If either of you feel I am being unfair/wrong, please PM me or another staff member, and keep this topic for discussing the script.

Other then the last thing I said in that post, I wasn't trying to make hostility just answering his question. And to be honest, I think my silence and ignoring that second post ended that conversation as I didn't have time for that ignorance. from a mods stand point it's fine what your doing compare to some mods I know on a Bleach forums. They'll just ban or give you a warning without figuring out the problem and then they were hacked. Reason for jumping back in this converstion was because I'm not home.

kellessdee, on 08 January 2012 - 07:45 PM, said:

@bigace: Nifty little script. Looks nice. Personally, I would change the way the name, gender, age, etc. are aligned, to make it look a little neater. Probably, the best would be to align the caption (ie. name:, gender:, age:) to the right, then put the data left-aligned next to it, to make all the data aligned at the colon `:`

Calvinchun, on 08 January 2012 - 07:41 AM, said:

VERY SWEET SCRIPT!! I'll credit you...

I appricient it. , I'll take what happened here into my next update.

Edited by bigace, 22 January 2012 - 09:28 PM.

[bigace]

Update: v2.0
- The code has been rewriten so it's easier to read and takes up less lines.
- Added "slice_text" method by Blizzard, which automatically break to next line when needed
- Can now easily change/remove/add what type of stats are shown

Edited by bigace, 22 January 2012 - 09:43 PM.

[ForeverZer0]

Nice script.

Looks familiar.

[bigace]

@F0: Ya, I should probably credit you as well. since I based it off your Journal script with this new update. The old verison had more lines and I had meaning to use Blizzard's slice method for the paragraphs earlier and then I saw how both you guys did it and rewrote this script again.

Edited by bigace, 22 January 2012 - 11:03 PM.

[ForeverZer0]

Its not a problem. I noticed you based much of the configuration from it, but you didn't copy-paste the whole script or anything, just used the base as a starting point for your own version of it.

[bigace]

Update v2.3
~ You can align your paragraph's in the module [Right, Center, Left]
~ You can now add a custom layount to your Biography screen.
~ Improved coding

[bigace]

Update: v2.4 (Apr. 26, 2012)
● Added an option in the module that adds the Biography into the Menu for you

[Jesse66126]

Thanks for fixing it =)