This is a thread to post things to help refine CURRENT features in the editor, to help them to be easier to use or more aesthetically pleasing in the next version. If you've got an idea to make something a bit more understandable or to help improve a feature in the editor, feel free to explain.
A few important things here:
1 - Be as descriptive as possible. Explain things the best you can so that Atrius can understand what you're trying to get across.
2 - Don't bother posting here if you've not got anything useful to say. You can complement things, sure, but try to at least be more helpful in your helpful than just "That's a good idea, lulz!"
3 - Don't keep pushing stuff over and over again, give Atrius a chance to get the next version of the editor out. Something we GS fans are known for is patience, after all, so do kindly show your patience here.
4 - THIS IS NOT A PLACE TO SUGGEST NEW FEATURES, ONLY TO HELP REFINE ONES WE ALREADY HAVE.
Shall I kick things off? I think I shall.
Though this is relatively minor, it's VERY helpful. In the item editor, there's multiple options for stats like Agility and Luck. One is for stat addition, the other for a stat multiplier. The problem is, you don't know which is which right now until you fiddle with it. To make it more user friendly, might I suggest marking which ones are additive and which are multipliers? This could be simply be done by marking it with a (+) or (x) next to the respective stat.
Also, the ability to change the default names of the characters, and to rename skills/abilities/items/etc... would be VERY helpful. Actually, that's done by the text editor, which we'll eventually get.
This post has been edited by Role on Jun 10 2009, 02:22 AM
Well, to reiterate what i posted in another thread that i made, please be weary when editing an enemy's defense stat, as it will revert back to it's original defense after it's edited.
I did notice that in the editor, in the character editor, I gave Jenna the Shaman's Rod, but she also had her wooden stick. I tried several times to try to make it so she does not have the Shaman's Rod equipped, but nothing seemed to work. So, I was wondering if the editor could be changed slightly to allow you to choose which items are equipped, and which ones are not.
Have a nice day.
:MercurySet:
When you change starting equipment, you ALWAYS HAVE TO START A NEW GAME TO TEST IT.
Let me say that again. YOU ALWAYS HAVE TO START A NEW GAME TO TEST IT.
Why? When you start a new game, it gives them what the editor said they start with. When you save the game, THEIR INVENTORY IS SAVED. You cannot change it with the editor anymore.
I know Role, I did erase a spare file to test it. However, even though I gave Jenna the Shaman's Rod, I did not want it equipped right away. I wanted it so the player would have to look at their inventory, then change her weapon. Anyway, I also tried rearranging her inventory, but nothing really changed. She still had the Shaman's Rod equipped.
Have a nice day.
:MercurySet:
I believe the game automatically equips whichever weapon has a higher attack rating.
Well, then why does it equip Salanewt's Shaman's Rod? It subtracts several hundred attack and a hundred or so defence. So why does it auto-equip?
Well, what Atrius says makes sense... Remember what unleash it has? Also, I made it so it bestows Thunderhead (which might be too strong for almost half of the game).
Besides, it is not a few hundred, but by the highest number that it can subtract (it seems like I can not use multiplication when editing weapon traits).
Have a nice day.
:MercurySet:
While I don't really have any credentials or e-fame in this forum, I thought I'd post anyway. I've been using this editor for the past week for literally hours a day, and I love it, but there are a few things I'd like to see refined, and I'm sure others would love them as well.
1) The search box is very helpful, although it would be awesome if it could also do more specific look-ups. For example, while editing stuff in the items tab, typing "attack:>50" would bring up any item that gives more than 50 attack.
2) While this may tie into the first point, it would also be nifty if you could sort items/abilities by their function or availability. For example, only showing unleashes in the ability list, or only showing headgear in the item list.
3) The text boxes you can type in? You can't highlight the text. If that was possible, copy and paste would be easier, as well as running automated macros separate from the editor.
4) While editing character stats, there is a bar you can drag up and down to change the maximum value of the graph. Perhaps it would be more useful if the bar changed the actual stats, while the text box above it changed the maximum graph value.
5) It would be REALLY cool if you could edit the enemy's elemental power and resistance. I'm not even sure if it's possible as it wasn't available in the editor in the first place :S
Anyway, I love the editor so far, thanks a lot Atrius :D
Any input is appreciated.
Those are nice suggestions, but complex refinements like most of those would be secondary to expanding the primary features of the editor.
I've been meaning to make it so text fields can be highlighted in, though it didn't seem too important to do that before the text editor was ready, and now it very nearly is.
Yeah, editing elemental power & resistances is coming, it's just a little odd how the game sorts it so I've been trying to think up a decent way to handle it.
Yeah, I understand where you're coming from.
Most of the suggestions I made are to make it easier for the person doing the editing, although they're not required.
I'm reeeeally looking forward to highlight-able text though :D
Edit: Forgot to suggest the ability to change the names of items and abilities as well. All of those ? spots could be put to good use~
Aaand size modifier for enemies. I've noticed the sprites can get a little stretched so I assume there's a value for size tied to each monster (or sprite?) Not entirely sure on this one though.
This post has been edited by Lv11 on Sep 11 2009, 07:41 PM
Of course Item, ability & enemy names will be editable. It had to wait for a few other things to be done (Cracking compression codes, writing an auto-repointer, e.t.c.) but it's all ready for the next version of the editor.
Great, I can't wait for the release :)
Quote from: Atrius on 27, June, 2009, 08:47:00 PMI believe the game automatically equips whichever weapon has a higher attack rating.
I'm just guessing, but isn't it because the Shaman's Rod is lower in the item variable than the Wooden Rod?
Could be, it's probably something worth checking just so we know for sure at any rate.
Oh yeah, I forgot about this topic...
Anyway, that does seem like a good theory, but I think it might also have something to do with importance/rarity of item (well, maybe not rarity). For example, the Shaman's Rod is an important item, can not be sold, and it can not be re-obtained. The Wooden Stick can. More items will probably have to be tested.
Or maybe it is a combination of the two...
Have a nice day.
:MercurySet: :MercuryDjinni:
While editing items, you can select item effects in the four separate boxes.
Just to clarify, options 0-6 add a static value to the selection, whereas options 7-14 are multipliers. Currently options are listed on the list twice, you could change the name of 7-14 to make sure people know the value is a multiple as opposed to a static value.
I overlooked the fact that they were actually different >_<
Actually, that's one of the first things that I mentioned, marking which are multipliers and which are just added.
In this thread (http://z9.invisionfree.com/Golden_Sun_Hacking/index.php?showtopic=1) Atrius asked what the four odd boxes to the right of the enemy group editor are for. I'm not sure if this has been pointed out yet but they have to do with how the enemies are sorted. The only combination I've messed around with so far has been 2/0/0/0, which puts the strongest enemy in the center, with weaker ones surrounding it. I've tried a few others but I forget what the number combinations were, one of the combinations ordered them from weakest to strongest, left to right.
Any chance in a full screen mode? or is it out of the question
Although it's hardly ideal, F4 puts it into fullscreen.
Well i,ll be dammed, that suits me down to the ground, my eyes get sore trying to read whilst small text (i prob need glasses)
purge
Garet can NEVER have as low of a speed as he's supposed to have, the game always gives him at least three at level up, meaning that with 100% Anti-perfect levels, he's STILL way higher than the target. It's the opposite with his defense - even with 100% Perfect level ups, it is impossible to actually reach his target defense - the target at level 99 is what, five higher than the max possible?
This has nothing to do with refining features, however. This is something that needs a patch to correct it. As for your issues with the HP cap, I'm sure that in a future version of the editor, Atrius will have a stat cap modifier, so we can alter the stat caps up to the max possible level for the type of data value they have.
purge
This one is serious there is also a problem in the enemy group editor:
Actually this one will really ruin a day. If you change the leader in a group (that's the first enemy in a group)
the previous enemy group leader will also change. Examle enemy group 1 has a leader of wild wolf if you change
the leader in grou 2 into ruffian the leader also of grou 1 will be change into ruffian.
Maybe its nice to fix this because editing enemy groups will be difficult with this.
Also some abilities have the same name like gale(djinn) and gale(psynergy)
Maybe its nice to put (psy) in some abilities or other marks to make editing easy and can reduce error in hacking.
Quote from: i_am_isaac on 23, May, 2010, 11:34:23 PMIf you change the leader in a group (that's the first enemy in a group) the previous enemy group leader will also change. Examle enemy group 1 has a leader of wild wolf if you change the leader in grou 2 into ruffian the leader also of grou 1 will be change into ruffian.
Maybe its nice to fix this because editing enemy groups will be difficult with this.
Weird, I never noticed that before. I'll look into it.
purge
Either way, isn't this the wrong thread? This is for making existing features easier to use, such as suggesting a sort feature, to sort existing enemies by various stats.
Basically, for enemies, you'd have:
Sort by: Index Number, Level, HP, PP, Attack, Defense, Agility, Luck, etc..
and then: Ascending, Descending
This makes things easier to look up. Same for Items:
Sort by: Index Number, Item Type, Attack, Defense
THIS is feature refining. It has nothing to do with reporting possible errors, there's a thread for that. As for issues with the game itself, that what you make threads for...
Aw sorry then how about the ability names?
Some of them have the same name like gale (there are two of them, the psynergy and the djinn effect) maybe we can put something besides the ability name to make it easy to distinguish those with the same ability name while editing.
One of them is surrounded by other Djinni abilties isn't it? Hmm... I can probably come up with something, but it wouldn't do to have them always labeled as such if someone did a complete hack of the game, and they weren't used that way anymore.
Sorting lists will require quite a bit of work, someone had mentioned it before, but it's fairly low on my list of priorities.
Really? I'd assume that it'd just change the order that they're displayed, and if for some reason they got out of order (via editing), you'd just need to resort them again. The index number of them stays with the item, so if you were to sort descending by attack, it'd go:
275 Darksword
10 Sol Blade
276 Excalubur
293 Tisiphone Edge
etc..
For ties, it goes by index number.
As if the computer natively knows how to do all that. I have to step it through the entire process as though it doesn't understand anything.
Me: "Just sort them in descending order"
Computer: "How do I do that?"
Me: "Check one value is lower than another, then move it below it"
Computer: "How do I do that?"
Me: "take byte 1 from location A, and byte 2 from location B and compare them"
Computer: "Oh, then if byte 1 is less how do I move them?"
Me: "Write byte 1 at location B, and byte 2 at location A"
Computer: "Oh, but wait, if I write byte 1 at location B where byte 2 is then I'll overwrite it, how can I write it to location A if I don't have it anymore?"
Me: *facepalm*
And that's the easy part really, there's a lot of other behind the scenes infrastructure that goes into sorting lists as well. The main concerning is getting the data necessary to the list system in way that's compatible with all of the features of the editor since everything is stored in different formats.
Odd... I'd assumed that since this kinda thing is something that I was taught in Comp. Sci II back in high school that it would be on the easier end of things... Guess it's a bit more complicated than I remember...
Of course, if I could actually remember how to do it, that'd be QUITE helpful as well, but sadly I'm so out of practice I'd be surprised if I can remember the beginner's "hello world" prompt... T-T
Sorting lists in and of itself is fairly easy. It's when you have to pump mixed data formats into those sorting algorithms from various places where things get a bit tricky. I mean, it's not on the same level of tricky as the automatic data repointer or anything like that, but it's mostly a nicety, and I'd rather focus on more important things at the moment.
Well, niceties are the whole POINT of this thread, atrius! XD
To make streamline things and make them easier to use - but they're not necessities. That'd be Error Fixes (see: Error Reporting thread) and Main Updates (see the Feature Preview thread)
It seems that the flag that marks an item as "rare" isn't the one that makes it an "artifact", meaning that it's currently impossible to make an actual "artifact" item.
One problem - first, the mouseclick response. I click on nothing and move down to OK, and it says I clicked on Clay Spire. Totally annoying - I have to stay over the option for a bit for it to realize that's the one I clicked. Some faster response time would be nice.
Second, better keyboard support. It'd almost be easier if I were to type in which ability I wanted, and it had a suggestion box similar to google showing up as I typed.
Third, the class multipliers. The interface needs to be changed alot. Since they behave like multipliers, typing in 7 would be recognized as 70, and 30 as 300. Once the 10x Multiplier Removal patch is in, we'd actually type in 75 for 75% multiplier, etc...
Quote from: Role on 15, January, 2011, 08:37:08 PM
One problem - first, the mouseclick response. I click on nothing and move down to OK, and it says I clicked on Clay Spire. Totally annoying - I have to stay over the option for a bit for it to realize that's the one I clicked. Some faster response time would be nice.
What's the number at the top right beside the red cross-hairish circle thingy say? Do items in lists highlight as you move the mouse over them, or is there a delay? What are your computer's specs?
Quote from: Role on 15, January, 2011, 08:37:08 PMSecond, better keyboard support. It'd almost be easier if I were to type in which ability I wanted, and it had a suggestion box similar to google showing up as I typed.
Like what the search box already does?
Quote from: Role on 15, January, 2011, 08:37:08 PMThird, the class multipliers. The interface needs to be changed alot. Since they behave like multipliers, typing in 7 would be recognized as 70, and 30 as 300. Once the 10x Multiplier Removal patch is in, we'd actually type in 75 for 75% multiplier, etc...
"Once the 10X Multiplier Removal patch is in" being the key phrase there.
The mouse over works, but it has a delay from the time I click to the time it works. Though... for some reason when I went to check the time, it was working fine... huh... odd... I'll get back to you on this when I get it to happen again.
Yes, but I'd rather just type it out in the field instead of scrolling. It'd save a LOT of time.
Aye, that's what I figured for that.
I thought, it would be nice, if it could be possible to use Psynergy-icons for Items and otherwise... because I want to make psynergy, with an ichon of an item, and items with psynergy-icons...
I do have an idea for refining the Code Patches section, though I may be suggesting this kind of late. You know how we have either textboxes or checkboxes that we can alter in this section? What if the Name Length patch were made into a changeable value in the Party Members section, and then the rest of the patches are read from a folder? Something like this would allow us to add and remove patches with ease; we wouldn't have to go into the game's code to disable unwanted patches. I am not fully sure how patches are coded yet, though, so I am not sure what would be done for reverting data to the previous values outside of using a configuration file.
Just a random idea for refining the editor, but I do not consider it to be really important or major. One of those little shiny whistles for your consideration, but not as shiny as sprite editing of course. :happy:
You mean regular IPS patch files? They're not at all designed to removable after they've been applied.
So Atrius, do you plan to add suport to special characters like "ç", "á"... in the text editor?
Thanks.
Ah, that's a good idea, but I don't know if the game can support it without modification. If it has support in the text already, it should be fine, but if we have to install the special characters, then I'd say no dice until much later.
Thanks for the answer, Role!
Well, the Italian version of the game, at least, has those special characters, so it could get implemented.
I used to use the Gstoolkit, that worked with umcompressed text. And it let me use accents! I even made a Portuguese translation of the game with that tool. I'm just waiting Atrius to work on the compressed table so that I can start a translation of GSTLA.
Sorry about my bad english :sad:
Bad English my @#$. You type better than many people I know whom have English as a native language (which includes 90% of my family. T-T).
That's not saying a lot role, given most of the people that apply for a job with my dad can't even spell their own name... its happened more then once... I question the English education system some times...
Ok, I don't know if this is the best place to say this, but I think it is. The reason being this is going to be something that will DEFINITELY need to be reworked (and I'm sure Atrius already know it by now), and I'm talking about the Auto checkbox in the Class editor.
The way it works right now makes it a lot more of a burden than anything, because it is very inaccurate, to say the least. When I was messing around with the classes I had to untick it almost every time, as it was usually giving the wrong class types. I've got an idea about what to do regarding this, but I don't know if the editor can handle it (probably can).
Sadly, just one Auto checkbox wouldn't work. For example, if I tick the box and type in a requirement of :VenusStar: 7 :MercuryStar: 7 :MarsStar: 0 :JupiterStar: 0 I'll be getting class type 8. But what if I wanted this class for a Venus Adept? The correct type should be 3 instead. So what I have in mind is having four different Auto boxes, one for each innate element. So if I wanna make a class specifically for a Mars Adept, I tick the Mars Auto box and not worry about it anymore.
Of course, if someone were to change the Elemental Levels in the Party Members editor, this could screw things up. Maybe it would be possible to make the editor read whichever is the higher level and somehow connect it with the right checkbox, although I'm unsure it would work alright.
I think Atrius already may have his own idea concernig this, but I guess it was worth mentioning my idea here. Don't know if I explained it well, but... oh well
Oh, good idea.
I think it's just a temp solution. In many cases it will do what it's supposed to, and it's checked by default, so someone who doesn't know what they're doing runs a lower risk of screwing up. But someone who doesn't know what they're doing shouldn't be messing with the class system in the first place >_>
Having four checkboxes is a pretty good idea though. In any case, I think a list of the element relation values should be included for completeness.
QuoteBut someone who doesn't know what they're doing shouldn't be messing with the class system in the first place >_>
Yeah, I thought as much. But, you know, there are people and there are people.
QuoteIn any case, I think a list of the element relation values should be included for completeness.
I'm sorry, could you explain a bit better what you mean by that?
I think what he means is "What values mean what". So value 3, for example, would be "Characters 0 and 1, Venus and Mars" or something like that. Or was it mercury first? I don't remember. Anywho, I think that's the gist.
Quote from: Kide on 14, December, 2011, 03:34:40 PM
QuoteBut someone who doesn't know what they're doing shouldn't be messing with the class system in the first place >_>
Yeah, I thought as much. But, you know, there are people and there are people.
And most of them actually expect the editor to handle things by itself.
Quote from: Kide on 14, December, 2011, 03:34:40 PM
QuoteIn any case, I think a list of the element relation values should be included for completeness.
I'm sorry, could you explain a bit better what you mean by that?
The value representing the combination of the elements highest and second highest in level. Like, if highest and second highest levels are both Venus (all other levels 0) you get a 1, while if the highest is either Venus or Mars and the second highest is Mercury you get a 3 (I think) and so on for all highest/second highest elemental level combinations. Atrius posted a table for it somewhere, I expected you had found it already given how in-depth you've been going with class sorting.
Umm... am I seeing a contradiction here? So you say people "expect the editor to handle things by itself", yet you suggest The Freakin Table to be included within the editor? What for? That would defeat the purpose of implementing Auto boxes, from what I see. For those poor unfortunate souls that would be expecting the editor to do everything for themselves, they wouldn't even bother to look at the table.
I'm sorry if I failed to get your point here. Of course, smarter people would appreciate what you suggested I guess...
QuoteI expected you had found it already
I found the table Atrius posted
in the forums only. I wanted to find it in the actual code, so I could change it a bit if possible. Something like this (http://forum.goldensunhacking.net/index.php?topic=1338.msg31994#msg31994), you know. (Hopefully I'll be understood this third time ._. )
It would be interesting to have an area in the editor to look at basic formulas. the secton wouldn't have to do anything to the code... but be more like an index you can open to reference whole working... just a random idea i just had from reading these posts... of course this is just more work that Atrius would have to do and its just kinda... like the extra stuff to make the editor look better... meh
I realize I'm late at replying here, but I've been pretty busy recently.
I've been thinking, it would probably make more sense to be able to set the primary/secondary element for a class rather than messing with the type value directly in many cases anyway. I could make it so the editor automatically sets them based on how you set the element requirements, then you can fine tune them yourself. Rather than having any "auto" check boxes, there would instead be an "Item class" check box that lets you manually set the class type value, otherwise the value is completely invisible.
The potential pitfall I see with this are places on the class type table where the value is the same for two different element combinations. It could end up producing results the user wouldn't expect in those cases. Sure, it would happen a lot less than with the current class editor, but I'd still like to minimize it as much as possible.
It would also be great if the editor had a way to make sure your classes are sorted properly to work the way they're intended... That may require a bit more thought though... Hmm... It'd actually be pretty cool to have a tool in the party member editor that let you see what all classes a character could get, and how.
Anyone want to see the table written in a way of how it could look if the Class type value was a combo-box?
It goes like this: Primary Secondary
1 - :VenusStar: :VenusStar:
2 - :MarsStar: :MarsStar:
3 - :VenusStar: :MercuryStar: , :MarsStar: :MercuryStar:
4 - :VenusStar: :MarsStar: , :MarsStar: :VenusStar:
5 - :VenusStar: :JupiterStar: , :MarsStar: :JupiterStar:
6 - :MercuryStar: :MercuryStar:
7 - :JupiterStar: :JupiterStar:
8 - :JupiterStar: :VenusStar: , :MercuryStar: :VenusStar:
9 - :JupiterStar: :MarsStar: , :MercuryStar: :MarsStar:
10 - :JupiterStar: :MercuryStar: , :MercuryStar: :JupiterStar:
11 - (And below = Item Classes, etc.)
This list should make it easier to tell that Venus and Mars share similar classes just like Jupiter and Mercury.
So what does everyone think? Combo-box or numeric? (I can't see how it could hurt... A number by itself doesn't tell you much.)
EDIT: I think we should make up names for them. (And have a column with the element information.) That way, referring to them will be even easier.
1 - Venus
2 - Mars
3 - [A word that is associated with both Venus and Mars] [A word for Mercury. Ex: Healer]
4 -
5 -
6 - Mercury
7 - Jupiter
8 -
9 -
10 -
11 -
I am not sure about using terms like Fighter/Mage/Spellsword/etc. in their names.
Edit yet again: To me, having something like this would still be beneficial. (As long as the elemental information is displayed.)
Basically copying the first one of each list. (Which could be updated when their names are updated.)
1 - Squire
2 - Guard
3 - Swordsman
4 - Brute
5 - Aprentice
6 - Water Seer
7 - Wind Seer
8 - Seer
9 - Pilgrim
10 - Hermit
11 -
12 - NPC
13 - Flame User
14 - Mariner
15 - Pierrot
16 - Tamer
17 - Dark Mage
That would be the lowest class in each class type.
Note to self: 080C6604 = Class Type chart.
Ha, I knew Atrius would come up with something better. Especially that "Item class" checkbox, if I understood it correctly.
QuoteNote to self: 080C6604 = Class Type chart.
I think I'm gonna request to change my name to 'self'.Alright, this is exactly what I wanted. Thank you very very much, sir!
You are welcome,
I've also had this idea for a code hack to duplicate that chart for the second team: Instead of taking up more space, one could probably make them 16-bits, and if it is party 2, get the second 16-bit.. That way, when we go to edit, we can make anyone have the same class without duplicating classes, One problem, if I did this, the editor may become slightly incompatible. (?) I am not sure if it grabs these values in any way? (Hint the Auto box.)
Edit: This is what I mean (Attachment) It takes up the same ammount of space.. so..
Yeah, after I saw that thing I was surprised it used so much space.
About your idea, wouldn't it work kinda similar to what we already have? Maybe if you explain this part
QuoteThat way, when we go to edit, we can make anyone have the same class without duplicating classes
a little more, as I didn't understand what you're trying to say there.
Also, I don't know it for sure, but I believe the Auto box only uses info concerning elemental level needs for classes, and not the types themselves. At least at the current time. Since this is going to be changed... that could change as well. I think it won't cause any incompatibility issues, though.
I meant if we didn't want party 2's class type chart based off party 1's chart. Right now, without Atrius's patch you are forced with 2 pairs of PCs having access to the same classes (Isaac and Felix; Ivan and Sheba), with Atrius's patch, none of party 2 shares any classes with party 1, so you'd have to duplicate them in order to achieve that. But with my class patch idea, what you should be able to do is choose which pair of elements should refer to class types listed in party 1's and which should not.
Here's an example that wouldn't exactly work, but..., maybe I want to make Jenna use some of Isaac's classes... (For example, if it was mono-type classes, One could make the :MarsStar::MarsStar: slot on Party 2's class type chart the same as :VenusStar::VenusStar: in party 1's class type chart.
Technically, that wouldn't work if Jenna has any other elements besides Venus with a higher level than 0 (since :Mars::Mars: a pure element.) So bad example, haha. The others might work, though. For the example you would probably edit party 2's :MarsStar::VenusStar: and/or :VenusStar::MarsStar:.
Edit again: Though, nothing says that you can't make another class with just Mars requirements for the same class type. I imagine we could combine all the mono-classes into one class type, this way? That would total up to two different class types, one for Party 1's and the second for Party 2's.)
I wonder what it would be like if each character had their own chart...would it perhaps clear up some of the confusion a bit more for those who don't understand it? - since in the continuation of my example, I think Felix would have Isaac's classes if he had Mars djinn. - Edit: I imagine this to also come in handy for those who want all their highest elemental level to start at maybe 1.
Honestly, I'd like to see a patch that separates it into four groups, and another that separates it into eight. It'd allow for many more approaches for hacks, and would allow for branching classes.
@Teawater: Ok, I think I understand it now. The main purpose of your idea would be to save some space if you're planning to share some classes between characters, right? This could be useful for some people, although its use is somewhat... restricted, maybe?
QuoteI imagine we could combine all the mono-classes into one class type, this way? That would total up to two different class types, one for Party 1's and the second for Party 2's.)
While this could be done, I don't think it would be much needed. All it would do is use a less quantity of class types, right?
QuoteI wonder what it would be like if each character had their own chart...would it perhaps clear up some of the confusion a bit more for those who don't understand it?
Well, I think that's what Role said in here
QuoteHonestly, I'd like to see a patch that separates it into four groups, and another that separates it into eight. It'd allow for many more approaches for hacks, and would allow for branching classes.
Would you know how to do something like this, or how much trouble it would be to do it?
Also, I have a suggestion. Since the class type chart can be indeed changed, and quite easily, I wonder if the editor could do that for us. And maybe it could work with Teawater's patch idea as well. I don't know if this would fall into "stuff the editor isn't suposed to do" area, but it could be useful for some people.
QuoteI wonder what it would be like if each character had their own chart...would it perhaps clear up some of the confusion a bit more for those who don't understand it?
More variables typically means more confusing.
If I did make the table editable, and/or splittable. I would HAVE to make it so that the editor only uses the class type value with no way to automatically detect it, or set it more easily than just manually setting the number. You'd be creating a situation where it's possible to make a class that's aligned as primary Mars, secondary Mercury for one character to be pure Jupiter/Venus for a different character.
Quotewith no way to automatically detect it
That means you'd have to add something where the user can select the table used in the detection. Probably still confusing. But even if it didn't work, it still doesn't mean you can't implant the feature in. Maybe in a section for Advanced Users under Code Patches. Though, in my opinion, I think it would be best to illustrate what the Class Type value means than making it automatic, anyway. I remember in 11th grade learning something about knowledge being freedom, so the more knowledge you have on something, the more you can freely use it.
Aye, just because some things get complicated doesn't mean we can't have advanced users who understand it. Christ, Atrius, some of the people are delving head first into ASM, I think many of us can handle some advanced features.
It's not like I wouldn't do it, there are already features in the editor catered specifically to advanced users (Hex editing for map code, anyone?) I just prefer to try to keep things that can be presented in an easy manner accessable to everyone in a way that will make sense even if they're not intimately familiar with th underlying system.
Hmm... Selecting a table used for detection? No, the tables could be written in a way that automatic detection just doesn't make sense if too many odd combinations share the same value.. But I just came up with a good idea on how to present it that should work great for both beginners, and advanced users, thanks Teawater. Yes, this will work out fantastically, I'll do it.
You are welcome, Atrius!
Hmm, this is still feature refining.. so I guess I can say this here. I have been doing a bit more research on the asm scripts npcs use... and I was wondering how easy it would be to get the editor to display these known values? I noticed the bl instructions in between, but they don't seem to make you lose that r5 value, so... (Most functions in Golden Sun seem to keep r5+ safe, so..)
(http://i900.photobucket.com/albums/ac208/charleysdrpepper/npcconstantsnotdetected.png)
Perhaps maybe it has something to do with the conditional (bne)? No idea... (In that case, I'd save the pointer and current variables that hold your register data.), keep reading the code checking to see of the address being read matches the address in the conditional, if it does... I don't know...? Do some data comparisons between the old register bank and the current one?? That would determine which ones are made "variable/non-constant".), get rid of pointer... and so on... Hmm.. It does take a bit of thought.... - Scratch that, I think the one with the lower address should be the one being read and dealt with... - Except, it is hard to imagine what to do when the conditional points to a lower address (going backwards.) You probably just read it, anyway, using the address of the branch as the "stop" location. If you meet up with a bl instruction you already scanned for, you can compare values for constants. As for stopping at the stop location... eh, dunno, I'm thinking of For events, and Do events, but they probably don't matter for this anyway.)
:Kraden: :um: Teawater! I'm the one who lectures everyone!
P.S. As for the npc base functions... I think the argument matches the NPC number? Maybe, I would like to confirm this, though. I been looking around Daila keeping an eye on two values...
02030160 and the ones that are located in say... 16-bit 0200959C for the Item Shop Keeper in flooded Daila. I have not yet found out how those values are moved to 02030160, though. (When talking to the NPCs.)
I wonder if that helps any.
5920 = Hm? You want a boat?[30]
5921 (Yes) = What kind of insensitive[3]
5022 (No) = Of course not![3]
Perhaps I will look up what these unknown functions do, as well. Hmm...
I look forward to it, Atrius. ^-^
You seem to be working under the impression that the argument detector reads the code in the correct order. It in fact reads it in reverse from the function call it's working on, if it encounters anything that would put the register in an unknown state it quits. To begin with that bne call turns r5 into a variable, it's like an if statement (If r0==0 { r5++ } else {r5+=2 }) Trying to interpret an if statement with zero context would be difficult enough reading the code in proper order, but backwards? At best the dialogue() call from 8270 is still screwed, as soon as it hits the command b $00008274 at 8266 it can't really make a guess how r5 made it past there.
I suppose though, that bl commands could be scanned to see if they push the register that's being watched.
You should also be aware that to begin with the argument scanning function is watching r0 here.