Messages

If you mean what I think you mean, those are IDs for ability effects (such as ailments or debuffs) that those classes are more vulnerable against. Yeah, that's a thing.

I remember something to that effect included in the Golden Sun Reloaded hack. It would be nice to know what addresses corresponded to what weaknesses though!

Every number corresponds to the effect with that number, you can view these with the editor when selecting additional effects for abilities. You might notice there are a lot of similar ones, particularly for stat debuffs (-12.5% and -25% are different effects)

Class requirements are checked from bottom to top / higher numbers to lower, and the first class to meet the requirements is assigned, so the order is very important. Make sure classes with higher elemental level requirements are placed after those with lower ones for all classes that share the same ID, otherwise the higher tiers will never have a chance to get checked.

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! Then the only way is to just painstakingly organize them all... It's too bad that there's no way to just move classes around on the ordering without having to edit every single spot.

You could move the class data around in a hex editor

Hey, welcome! Forum doesn't get much activity nowadays as people mostly talk on discord... would be good if we used it more when talking about hacking stuff though, so the info doesn't get drowned out by all the other conversation and lost to history.

Slightly jealous of having free time... for me it's work as usual >_>

You can change the graphics using this version of the editor. It doesn't work with earlier versions:
http://www.goldensunhacking.net/downloads/GoldenSunTLA_Editor_DevV0_5.zip
In the graphics viewer, look for options to export/import. You will have to use another program for editing. This works for player character graphics, but not for most enemies, since they use a different format.

Hardly any activity on these forums now days, so support is usually best asked for on the Discord we have.... although, I still check these forums from time to time, not super often as I use to, though.

I think forums are better for this though, it's hard to keep up with instant messaging if you're not familiar with the language.

Must be quite a bit of work to put everything together for a GS2 randomizer, but I'm definitely looking forward to it.

I've started rescaling class boost stats to deal with the OP default tri-elemental classes. Yay or nay? It's just a line function of the total elements, at least from what I can tell.

Yay... I think? As long as you keep it optional.
Initially I reacted to getting those classes right at the start - I had Dragoon and Ninja as base classes, and White Mage available with one djinni. But they're not as "OP" as one would expect due to not having access to their abilities. The main benefit comes from them being tankier, especially when you have more djinn available and can use them without stat penalties.

What first comes to mind for psynergy movesets is completely random, random but grouped (e.g. if a class gets Ply, it also gets the other Plys), or swapped (e.g. Squire psynergy becomes Wind Seer psynergy). Any other ideas?

That's basically what I had in mind as well, sounds like you've got everything covered with the options you listed earlier.

For inaccessible classes, maybe I could write a new script for setting the class type and give each class a unique type (kind of like the class items in GS2). I'll look into that

I can't imagine how you'd actually assign the type, but if you can figure out something that works then go for it. However, the system in place is still fairly flexible (aside from types 1, 2, 6 and 7). Rather than making a new system, it seems like less work to make sure that when multiple class lines use the same type, the later entries:

• Don't require the exact same elements
• Don't require fewer different elements (no dual elementals after triple elementals)
• Always require at least 1 level in any element that isn't the type's primary element

Following those conditions, you shouldn't run into the issue of inaccessible classes. Although for everything to have the same chance, you'll have to move the actual class data around, otherwise it will be much less likely for something like tri-elemental Squire to be generated.

This was fun. Beat the game (seed 342146), and I have some notes and suggestions.

-Give Ivan whirlwind as an innate psy if possible, it doesn't impact gameplay much and imposes less on class randomization than forcing one of the classes to be available at a certain point.
-As we noted, Dragon's Eye is not actually needed anywhere, since you can get the other key item from Fuchin Temple without it. So it should probably stay in its normal location and be excluded from the pool of key items.
-Class randomization results in a lot of inaccessible classes due to other classes of the same type appearing later in the list. For example, in my seed Guard and Hermit have the exact same type and requirements, meaning no one can ever be a Guard. Checking so that classes that require three elements appear after ones requiring two if they use the same class type value would go a long way towards variety. As would not generating duplicate requirements, of course.

Additional stuff I'd like to see:
-Option to ensure all gear can be equipped by at least one party member. Assign completely unequippable items to one random party member after the initial randomization to avoid increasing the overall chance of being able to equip items.
-Option to keep higher total elemental level requirements for (originally) tri-elemental classes. As it is they go well with the general randomization quirkiness, but they'll have much higher stats across the board while requiring few to no djinn, so it would be nice to be able to separate them.
-Randomization for non-key items. I guess this is what you meant by all item randomizer.

We also talked about randomizing psynergy learnsets for classes. There are several ways that could be implemented, maybe I'll get back on that later with some ideas.

[Class data table]

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.

This thread has been dead for a while, but I could really use some help regarding classes. I'm just wondering how critical the order of the classes is in the editor. I inserted a lot of new tier 3 classes for both parties 1 and 2, but it's not organized by number. In fact, they're kind of just randomly scattered around wherever I found space. Is there some sort of logic that I need to be following when ordering these classes? Because almost all of them don't work, and most of the already established classes have also broken down (everyone is just turning up as an NPC). The only ones that are working are the ones with Jupiter and Mars as primary elements.

Class requirements are checked from bottom to top / higher numbers to lower, and the first class to meet the requirements is assigned, so the order is very important. Make sure classes with higher elemental level requirements are placed after those with lower ones for all classes that share the same ID, otherwise the higher tiers will never have a chance to get checked.

As for getting NPCs, that happens when the character does not meet the elemental level requirements for any of the classes that uses the class ID they're getting from their current djinn setup. Here is an overview of how those are assigned. Generally, characters can have their primary element overridden by having 6 or more djinn of a different element, resulting in unexpected IDs (this is why the higher tiers of dual elemental classes are forced to use djinn of the character's own element)

Also related... I changed the elemental levels of the characters at some point as an experiment, but then I changed them all back to their original values. Would this mess anything up even though I changed it back?

No, not unless the editor does something funky. Which I'm pretty sure it doesn't in this case.

I also noticed the two values beneath the abilities in the class editor. Do these do anything?
Thanks in advance.

If you mean what I think you mean, those are IDs for ability effects (such as ailments or debuffs) that those classes are more vulnerable against. Yeah, that's a thing.

This is a seemingly random bug with the editor, I don't think anyone knows what causes it. Usually you can get rid of it by simply restarting your computer. With that, welcome and hope you have fun hacking!

Uh hi, who are you?

Lol Sala, hope you're prepared to see this a lot.

Just so I'm understanding the idea in the OP (which I'm not sure I do), is the purpose basically to give more options for how to determine final class type by checking for more things? I get the impression it would be used to modify the class type value, or maybe even override/set it to something specific if certain conditions are met. Am I on the right track?

Anyway, for something else that has been brought up in this thread: getting more class slots to use. What complications would there be in reading the class data from different locations based on character number? For example, if PC number >= 4, use a second class data table, which could potentially double the amount of class slots available without having to rework the code to address numbers over 8 bits. Text string (class name) assignments have already been mentioned, but is that all?

(using this method, item classes should probably have a separate table as well, unless you want characters to get different classes from items)

Another idea to address the available slots issue that would be done on the editor (user) side rather than in code is to simply cut down on the amount of classes for each type. Instead of giving each class 5-6 stages with the same skill list just to have slightly different modifiers, they could have 1 or 2 stages and compensate for the lacking modifiers by making djinn give higher stat boosts.

I also think class data in GS could be stored much more efficiently. However, the work it would take to both change the code to read a different data format and to give it editor support... doesn't seem like it would be worth it, since I'm assuming there's more than enough free space scattered throughout the ROM to use the current format even for a large amount of classes (500+).

Yes, the game looks at all classes with the type value resulting from the highest two elemental levels in order, starting from the highest index and counting down. It then assigns the first class that fulfills the elemental level requirements. So if for example the Ninja class line started at a lower index than the Apprentice class line, nobody would be able to access the Ninja class line since the resulting class in the Apprentice line would be assigned before Ninja is even checked for.

does anyone know why I cant seem to get the RNG to work, or otherwise know of a cheat to enforce drops?

There are many reasons the RNG exploit might fail, but if you just want to test getting the drop you could set the drop rate to 1/1 temporarily

(on that note, does anyone know how i can make it so that even the player character can speak?)

I believe you could do it by editing the script, but if you don't already know specifically what to do it would probably be a disproportionate amount of work just to make this change.

-if i get it to work, natural quatro-elemental classes for 2 characters

This should be pretty simple. If you set djinn of the 3 non-innate elements for a character, you'll see which of the class lines get priority. Use the class type value for that class line for the new classes, put them after all other classes that use that value in the class list, and set the elemental level requirements to 5/1/1/1 and 5/2/2/2 with 5 in the character's innate element, if you want to make sure they're character specific (though other characters will be able to access the first class if you can set 8 djinn or more).

In general I'm not really sure what to comment on, the changes listed don't seem like they would have any major effect on the game. I guess you could release a patch when you feel it's ready, and hopefully people will play it and give some feedback.

Heh, wouldn't that be a nice Christmas gift?
I'm planning to give it a go at some point after your final update to the current version, then hopefully after that I'll be able to provide some real feedback as well.

I think what Squirtle was trying to say there was that you don't need ideas if you already know what you're going to do.

Now, I don't play Minecraft so I can't get too involved with the specifics, but everything so far seems like relatively simple suggestions. You act as if the notion that something could potentially not be the most efficient distribution of work in regards to the end result (according to what measure?) means you have to dismiss any and all ideas with no consideration. You're not on a budget or a deadline, you don't have to manage a staff, allocate resources, or meet a certain result. You can do as much or as little as you feel like.

So, don't ask other people for ideas if you don't intend to consider them. If you don't want to do something because you disagree with the idea or just don't want to put in the effort... that's perfectly fine. But trying to rationalize it any other way just looks silly.

Golden Sun does not originally distinguish between gender for classes, females can be Wizards, Swordsmen, Monks etc. If it seems like it would be an issue, you can use gender neutral class names or make alternate versions based on gender. But having gender restrictions for classes seems like it would be unnecessary. I'm more concerned about the fact that the female option has beast ears...

Bashing stuff with a stick is not quite as charming as it sounds, it's essentially the same as bashing them with a sword but slightly worse. However, I think the issue has less to do with physical damage being based on a stat that scales with level, and more to do with attack spells becoming obsolete by the time you get them once your levels start hitting the 30-40 range.

-It's not merely the successor to the handheld 3DS or stationary console Wii U.
-This will be hardware that's been made with a new way of thinking. (Basically a redundant line?)

Basically PR lines that tell us absolutely nothing. It's going to succeed the 3DS/Wii U regardless of whether it is "merely" a successor, and it can be said to be made with a "new way of thinking" as long as it's not a copy of an earlier system.

I think it's safe to assume that:
-You can play games on it (considering a title has been announced for it...)
-It's either stationary or portable (if it's not one, it's the other)

Hmm, I guess the lighthouses can be explained by saying that to create the stone of sages, it was necessary to focus/seal the power into the elemental stars. I think that's the key here, the power once flowed freely throughout the world, but was sealed by the actions of man. If the lighthouses themselves were the seal, one could simply destroy them.

Oh, umm. You must know about the goal values every 20 levels... the base growth per level is the difference between them, divided by 20, rounded down to the nearest integer. And the chance to gain an additional one stat point is relative to how close the result is to the next integer before rounding, so there's no randomness if the division is even. It's detailed in Terence Fergusson's mechanics guide.

Or if you meant how it works regarding the RNG, I have no idea. Sure wish I knew though.

If you're willing to dig into hacking the level up mechanics, ideally you'd have a function that calculates the stat increases for the current level based on the goal values, meaning it would consistently return the same stat increase for a given level. Having a growing luck stat would not be a problem in that case.

Alright, so this old topic. Before Dark Dawn came out, I was hoping that a potential sequel would head in one of two directions:

-Alchemy was not meant to be sealed forever, but only those who could pass all the trials (as the player does) would be allowed to unseal it, having proven their ability to protect the world from those forces. Following the events of The Lost Age, all hell breaks loose around the world as a result of alchemy returning, and the plot would be centered around creating order in that world.

-A story taking place in a rather distant future, a new "Golden Age" where the names of the former heroes are at best mentioned in stories, if at all. This could be a very different type of game. It might be very similar to a prequel, considering.

I've been toying with the idea of a prequel as well. The main obstacle I've come across is "what was the world like before the lighthouses were built?". What do they do, exactly? They can't have been built to channel the "power" of alchemy into the world, because that's supposedly the power they were built with, not to mention the world wouldn't have functioned properly before they were built. The only answer I can think of, then, is that they were built as a means to seal alchemy... but how would they be able to build them then, considering those who wanted alchemy to remain in the world? I doubt they were built overnight in secret.

Also you mention disregarding Dark Dawn, which actually even in a prequel I would do so. No Ei Jei nonsense, no Light, no Dark. Like I said above, no Luna Tower, perhaps just a nod here and there to it and other DD elements, but nothing that could impact the world. Also Psyenergy Vortexes or a generic evil empyror which diverts from the theme the games have about the villains residing in a gray area.

Personally I think the lore in Dark Dawn was a completely unecessary retcon out of nowhere. It doesn't contradict anything as far as I know, but since it's never mentioned or acknowledged in the earlier games it feels like something they pulled out of their @#$.

But yes, it's less than 1 Luck per level so the only thing i can say is don't exploit it if you want to enjoy it.

Aww, and here I was hoping you had come up with some fix :p (not really, that would be a bit unrealistic)

It's not that it's exploitable, just that random variation has such a big impact on it compared to other stats. I hate to say this when I can't provide any other suggestions, but there's a number of reasons luck does not work well as a growing stat.

TBS has a predictable RNG.  That's why you can get a perfect level up run reliably in TBS, but not really in TLA.  As such, TBS is a bad game to test RNG with.

It's still predictable, just less friendly to perfect levels. If you do a battle against the same encounter and take exactly the actions, it will always give the same result for stat growths. It's just that it changes with every level instead of every 20 levels, and there's no reliable way to hunt down the specific encounter you want.