Feature Refining Thread

[Daddy Poi's Oily Gorillas]

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..

[Kide]

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

That 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.

[Daddy Poi's Oily Gorillas]

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 slot on Party 2's class type chart the same as 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 a pure element.) So bad example, haha. The others might work, though. For the example you would probably edit party 2's and/or .

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.

[Rolina]

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.

[Kide]

@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?

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.)

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?

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?

Well, I think that's what Role said in here

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.

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.

[Atrius (He/Him)]

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?

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.

[Daddy Poi's Oily Gorillas]

with 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.

[Rolina]

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.

[Atrius (He/Him)]

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.

[Daddy Poi's Oily Gorillas]

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..)



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.)

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...

[Rolina]

I look forward to it, Atrius. ^-^

[Atrius (He/Him)]

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.