Golden Sun Hacking Community
June 24, 2019, 04:18:50 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
  Home   Forum   DC Wiki Help Search Calendar Downloads Login Register  
Pages: 1 [2] 3 4 ... 10
 11 
 on: June 11, 2019, 01:08:04 AM 
Started by Foreclosure - Last post by Foreclosure
Based on the rear sprites from Alex that I got from a guy in this website, but can't really remember his name... anyways...
I drew the front sprites and I want to share with you guys my work. I hope I'm at least on the right track :/

 12 
 on: June 09, 2019, 03:51:45 PM 
Started by Misery - Last post by Misery
Here are some suggestions for how to build Golden Sun's class system in a way that circumvents some design/functionality limitations imposed by the original methods. They're mainly aimed at those who want to make or are working on GS fangames or other GS-based games, though GSHC still seems like the most suitable place to put it on and refer to. And there's nothing stopping you from hacking this into the original games, although that may not be the most practical...

I'll start with the "how" and touch a bit on the "why" as I go. Occasionally I will refer to the original methods, but I don't think it's necessary to be familiar with them in order to follow this. The concept of elemental levels (may be abbreviated as eLevel) is still central, these can practically be thought of as the amount of djinn a character has equipped (set), e.g. one Mars djinni would add one Mars level. And in case anything is unclear, or if you think these ideas are bullshit or don't work, I'll have a Q/A section at the end.

It should be noted that the algorithm for assigning classes would be functionally identical to what it is in the GS series, only the arguments differ. Perhaps the main distinction is that originally, each entry in a class "line" has their own data set, whereas this will be based around the idea that each class is treated as a single object, with parameters (stats and abilities) that improve with higher eLevel.

Class data table
  • Elemental level requirements
  • Stat modifier table
  • Ability table
  • (Class name list)
  • (Effect vulnerability list)

Each playable character would have 4 accessible class IDs assigned to them, with the one to actually be used being determined by which of their eLevels is the highest. They would also have a list defining elemental prioirity in case of ties. Consequently all of their potential classes can be either entirely unique or shared with other characters on a case by case basis.

Class IDs:
  • Venus level highest
  • Mercury level highest
  • Mars level highest
  • Jupiter level highest

Elemental priority value:
  • Self = 4
  • Opposite = 3
  • Neutral = 2
  • Affinity = 1

Opposite: Venus to Jupiter, Mercury to Mars
Neutral: Venus to Mercury, Mars to Jupiter
Affinity: Venus with Mars, Mercury with Jupiter

To determine which class ID should be used, do [(eLevel * 5) + priority] for each element and use the element which gets the highest resulting value.

The class ID refers to a list of classes, or just a single class as may often be the case with base classes. Once the ID is obtained, check each entry of that list until one meets the eLevel requirements, that class then gets assigned to the character. Entries should be ordered so that classes with higher eLevel requirements are checked before those with lower.

This method removes two quirks from the original system, the first being that classes with lower eLevel requirements could override those with higher, the most prominent example being base classes - add one djinni of any other element, and suddenly you're in a tier 1 class even though you have enough djinn for tier 5. The other one is "spillover" classes which could result from an element with a level of 6 or higher effectively being treated as the character's primary element. Though if one still wanted that functionality, it could be recreated and designed for in this system.

Originally, characters start with 5 base eLevels (no djinn equipped) of their own element. This system assumes they do not, and as such, the djinn requirements for tri-elemental classes would have to be changed a bit if you want them to be "truly" shared between characters, i.e. to avoid defining the class twice with different eLevel requirements. More specifically, they would need to have eLevels (djinn) of their own element in addition to the other two. On the flip side, this does offer the option to do that for some slight class variations while still sharing the same ID (group).

Edit: another workaround to enable shared tri-elemental classes would be to either add the 5 elemental base levels but disregard them when checking highest element, or to add them only to the check for class requirements. Both of those options would require the base element to be defined in the character data.

Stat modifier table
Two values would be defined for each stat, base modifier and eLevel modifier. The actual modifier for a given stat would be obtained by [baseMod + (eLevelMod * total eLevel)]
In other words, each equipped djinni, regardless of element, would contribute to the stat modifiers as defined on a per-class basis. This has the benefit - or drawback - of enforcing a more even stat scaling based on djinn equipped, you do not get the jumps of the original system.

An alternative that would be similar to the original mechanics is to instead refer to a table where each entry is a set of stat modifiers, and where the entry to be used corresponds to total eLevel (+1 if not 0-inclusive). For the record, this is basically how Golden Sun assigns eLevel-based elemental power and resistance bonuses. This would enable the uneven scaling as seen in some classes.

Anyway, I believe that basing stat modifiers on total eLevel may help make class changing a bit less intimidating for players who are not very familiar with the system, as it grants stat boosts for each djinni equipped rather than having to conform to arbitrary element combination thresholds. It would also make changing classes in battle more tactically viable, same for using summons with multi-elemental classes. Which specific method to use is mainly a question of design philosophy.

Ability table
Each entry would have the following fields:
  • Ability ID
  • Level learned
  • (Element)
  • Min. eLevel
  • (Max. eLevel)

Basically, the advanced class abilities would require the user to have sufficient eLevel rather than being in a specific class tier. This also opens up some new opportunities, mainly that it allows classes to conditionally have abilities of elements they would normally be unable to use. That would also make it seem more like individual djinn grant additional abilities when equipped.

Element can optionally be defined to know which eLevel to check, or it could be fetched from the ability data.
Max eLevel can optionally be defined for "upgrading" abilities, e.g. Ragnarok to Odyssey.
One could even have fields for min/max requirements in all four elements, which would allow for compound elemental abilities (plasma could be wind/fire, growth could be earth/water, etc). Just a thought, probably not something I'd do personally.

Class name list
Class names have always been a design headache to me, having to come up with several different names for a role that is fundamentally the same is bound to result in some reaching on occasion. Nevertheless there is the familiarity factor, and one may want to use the names as a means to telegraph the increased mastery of a role. For these reasons, I'll include methods for having named class tiers that are compatible with this system. Even so, having 5 or 6 different names for the same class seems a bit ridiculous, surely it would be enough to have 3 for standard classes and at most 2 for complex, multi-elemental classes.

A simple method would be to just take the "main" elemental level of the class and use that to check a list of [value, name], where if eLevel >= value then assign name.

For stricter and more flexible naming, one could instead use a list of:
[Venus Lv, Mercury Lv, Mars Lv, Jupiter Lv, name], i.e. exactly how Golden Sun already assigns classes but used for names only.

Effect vulnerability list
This is a somewhat peculiar part of class data in Golden Sun that a lot of people probably don't know about. Basically, up to 3 effect values can be listed, which makes the class more susceptible to fail resistance checks against those effects. I figure if you wanted classes to actually have individual effect weaknesses and/or resistances, you could put a simple list here with [effect, argument]. The argument could be a multiplier or it could be used however you want really, it depends entirely on the implementation of effect/ailment resistance checks.

All that said, having this at all is highly optional - but if you do include it, at least display it somewhere on the character status screen so that players have a fair chance to be aware of it.

Q/A

Q: Just four classes per character? You could have much more than that in Golden Sun.
A: I have a feeling this might come up, so I'll address it right away. The class ID value is just part of the sorting method; tri-elemental classes are defined by their eLevel requirements but still have a primary element, such as the Ninja which is a Jupiter-based class that requires both Venus and Mars levels, or the Dragoon which is the same but Mercury-based.

 13 
 on: June 09, 2019, 10:38:34 AM 
Started by Foreclosure - Last post by Foreclosure
.

 14 
 on: June 08, 2019, 05:32:36 PM 
Started by Foreclosure - Last post by Foreclosure
Edit: Thanks to the info Fox posted above plus some empyrical research, I could figure this out.
The first digit in class type corresponds to the adept in question, meaning 2 is Isaac, 3 is Garet and so on.

So the deal is this: Squire Class is type 20 because Isaac is adept 2 and 0 is pure venus class.
So, when I put type 22 to the classes, then it worked like a charm, because Isaac is 2 and Mars is 2.
If u want to put mia base class, say, to Mars, then change it to type 5 (digita correspondent to Mia) and 2 (Mars) and so on.

Idk if you guys could understand it. I will make a little more research and then maybe I will edit this. Thanks Fox!

Now I can finally finish my patch!

 15 
 on: June 08, 2019, 12:34:07 PM 
Started by Foreclosure - Last post by Fox
Quote
Then, I went to Squire class series and put the requirements for Mars instead of Venus (5 Mars for Squire, 7 for Knight, etc)
Did you also update the class type? (Mars isn't the same class type as Venus)

Class type is mostly just elemental priority... (Though, can include item classes that don't check for elemental priority.)
1=Venus
2=Mars
3-5=Venus&Mars but with secondary element
6-10 similar as above but with Jupiter/Mercury & secondary element.



Quote
Without going into too much detail (because I'm not sure how to explain), the game uses these values to determine how characters get classes.
When multiple elements have the same level, yes... but in this case, with three elements being a level 0, and one not... and we're only working with the base class-line (single element)... it's not really relevant right now. (To have a secondary element, its level must be above 0.  (If you have an element at "9" (0.9) (not "90"/(9.0)) in the party editor, but no Djinn of the same element, that is still level 0.)
He didn't say anything about class type, and to me, that makes the most sense right now for what the problem may be (If he deleted/changed the original Mars classline, which I suspect is the case?), but he'd need to show us what he has for it.


I may try this myself soon.   Not right now, though.  I'm feeling pretty confident, but I know it's always best to double check.   (I have studied the entire function for what assigns your class a long time ago... so I'm not expecting any problems.)

 16 
 on: June 07, 2019, 11:53:54 PM 
Started by Salanewt - Last post by Salanewt
Okay, so two quick things.

1. Did you try Venus 1, Mercury 2, Mars 54, Jupiter 3? Other numbers will act funny for Mars adepts (unless you change Mars by multiples of 10).

2. How do you have your classes organized?

 17 
 on: June 06, 2019, 04:20:07 PM 
Started by Foreclosure - Last post by Salanewt
Have you tried swapping the Mercury and Jupiter stats?

Without going into too much detail (because I'm not sure how to explain), the game uses these values to determine how characters get classes.


And it's great that you feel welcome! :)

 18 
 on: June 05, 2019, 03:54:25 PM 
Started by Salanewt - Last post by Foreclosure
Any other combination will get me the same result so I don't think this is because of the statistics but I believe it has something to do with the player character's stats being hardcoded and if I am right I don't think there is a way around this...

Edit: Nevermind guys I figured it out :D

 19 
 on: June 05, 2019, 03:00:02 AM 
Started by Foreclosure - Last post by Foreclosure
Thanks for replying, Salanewt. I feel welcome indeed. :)

I have tried editing the stats like you said, but I still get the NPC glitch class, but maybe I wasn't clear enought about my doubts, so I'm going to explain again my issues:

What I want is to change Isaac into Saturos, and so change elemental level from Venus 5 to Mars 5. Then, I went to Squire class series and put the requirements for Mars instead of Venus (5 Mars for Squire, 7 for Knight, etc)

When I test, and put all Saturos djinn on standby, it switches back to NPC class instead of Squire class. Why is this happening?
I tried editing different stats (Mars 54, Venus 1 or Mars 51, Venus 3, etc) and all combinations get the same result.

 20 
 on: June 05, 2019, 01:18:03 AM 
Started by Foreclosure - Last post by Salanewt
Hey there, welcome!

Going to comment on the text editing thing first: It's very finicky, and it often glitches for basically no reason at all. Getting beyond that stage is often a matter of trial and error.

As for the stats thing, have you tried giving Isaac the same stats that Garet and Jenna have in vanilla? Venus 3 will probably cause issues because of the way these games do classes.


Pages: 1 [2] 3 4 ... 10
Cbox
Today at 08:05:17 AM
Fox: Such a patch would mean you need to be careful with item drops, coins, exp, etc. Because those things would then no longer be an infinite supply.  Whether or not one uses it depends on what they want to do with it.
Today at 07:55:01 AM
Fox: (High enough being based on the area you are in.)
Today at 07:54:02 AM
Fox: I had a thought today. What if I look into making a simple patch just for lulz.  One that works the same way as using Avoid, but it lasts from start to finish, and can't be disabled.  Avoid only works if your levels are high enough, though... so thought is to keep that as is.
Today at 01:55:17 AM
ryancaesar12345: hi guys i have new update in Golden Sun 2 Lost Age Revise Mod.ips try this. :)
Today at 01:54:16 AM
ryancaesar12345: where's that link?
Today at 01:53:56 AM
ryancaesar12345: i have no account in discord.*
Yesterday at 08:44:52 PM
Salanewt: Although in the case of Wish, you could probably just use Breeze instead.
Yesterday at 08:44:36 PM
Salanewt: Yeah, it's a messaging program sort of like Skype. I find that it's much easy to walk people through some of the basics of assembly, since that's what you'll need for most animation hacks.
Yesterday at 09:39:10 AM
ryancaesar12345: discord? im not good in asm or assembly.
June 22, 2019, 09:37:26 AM
MaxiPower: gpnna update my thread on progress of my character art if anyones interested. :P
June 21, 2019, 07:51:44 PM
Salanewt: Hey there! Animation editing can be tricky, but I can share some notes with you if you pop in on our Discord. Are you good with assembly?
June 21, 2019, 02:59:40 PM
ryancaesar12345: and how to change a death curse turn in hex editor?
June 21, 2019, 02:50:00 PM
ryancaesar12345: and how to make animation but changing palette only like wish blue i want to change violet. for AOE healing and earth element.
June 21, 2019, 02:47:44 PM
ryancaesar12345: im done already thanks man i change the icon in that tutorial and all i need is animation most of elemental like healing like wish but wind element. how to import animation in TLA editor in *game crashes* index
June 21, 2019, 12:01:35 PM
Fox: Oh that. You are talking about Caledor's tutorial?
June 21, 2019, 11:49:55 AM
Fox: So in little endian... 08FA0000 (32-bit) is the same as 00 00 FA 08 (8-bits) (Since GBA is little endian) ;;; but if this were big-endian, it would have been 08 FA 00 00 (8-bits)     
June 21, 2019, 11:42:17 AM
Fox: "in the ROM file" = I mean when using any other hex editor to look in the file... ROM section in VBA is 08000000-09FFFFFF, but ROM files are different sizes, so GS1 stops a quarter the way (08800000 / 8MB), and GS2 stops half way. (09000000 / 16MB)
June 21, 2019, 11:39:55 AM
Fox: I am not sure I understand what you are trying to do? ... But all little endian is is just reverse byte. (of the bytes in a data type).... So like... 8-bit is the same regardless of big or little endian. 16-bit is like 0102=big endian 0201=little endian .... 32-bit is like 01020304=big endian ; 04030201=little endian.  (I use 01-04 numbers to represent how the bytes are ordered by address.) ; 00FA0000 in the ROM file is 08FA0000 in VBA's memory viewer/and that's how it works when the game reads
June 21, 2019, 05:20:47 AM
ryancaesar12345: i sa that in icon compressor 00FA0000 -> in 00FA0008 hmm?
June 21, 2019, 05:14:41 AM
ryancaesar12345: how to convert in hex editor a address in little endian like this? 00FA0080?

Affiliates
Temple of Kraden Golden Sunrise
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.124 seconds with 17 queries.