I’ve been sitting on this for way too long, but I’m finally putting a little time to releasing it.
Support Rework Rework
That’s right. My own Support Rework from about 2 years ago is such a mess of me sneezing asm code around that I felt it necessary to rewrite it in C. While the older version was a little buggy, the new version has been behaving nicely in my own working project. Anyway, I’m proud to finally release it.
Features include all from the original version plus:
- EIGHT unique support levels. That’s right. Eight. Should anyone use eight support levels? I don’t know I’m gonna wizard’s creed my way out of that one. If you don’t want that many you can have fewer. (I only use three lmao)
- Enhanced stat screen drawing. I’ve gotten better at custom drawing routines, and I’ve made the stat screen look nicer. This also includes @HyperGammaSpaces’s chadly support R text system which looks GREAT. Thank you, Gamma, for developing that!
- This is a C hack! Old support rework was all written in thumb, making it pretty error prone. This source should look much cleaner.
- The hack is fairly separate from base conversations now. They work well together, and if you want base conversations, use the version that comes with Support Rework Rework. Otherwise, no sweat!
- The utility macros (for modifying unit support data via events) should be easier to use now.
- There is support for the Skill System talk bubble to appear if there is a viewable support convo in a chapter.
- Probably more stuff? tbh I “finished” this a while ago and just now touched it up for release. Shoutouts to @Alaric for nudging me to release this!
I suppose that the instructions for using this hack will be similar to before, but I'll reiterate them
So you wanna use Support Rework Rework. Great! These instructions are going to be long not because the system should be difficult to use but moreso because I want to provide as much documentation on how to use it as I can.
You’re going to want to download the entire Support Rework Rework folder from my link in the OP and include
SupportRework.event in your buildfile.
The first thing that this file does is include
SupportReworkDefinitions.event, a file that defines various macros and such. Some of these macros are used in events to control support data. If necessary depending on the layout of your buildfile, you can include this file earlier in your buildfile.
This definitions file defines values for your various support levels. The example levels given are
#define CSupport 0
#define CPSupport 1
#define BMSupport 2
#define BSupport 3
#define BPSupport 4
#define AMSupport 5
#define ASupport 6
#define APSupport 7
representing C support, C+ support, B- support, etcetera. Change these as you see fit. These are just silly examples. Just make the IDs between 0 and
MaxSupportLevelVal inclusive and unique. Speaking of
MaxSupportLevelVal, define that to be your highest support level. I’ll get to the rest of the things in this file later. You don’t need to touch them.
SupportLevelNameTable is a table indexed by support level (remember the definitions we just discussed?) with each entry as a pointer to a string that represents that support level. You shouldn’t need to touch anything else in this file.
I’ll talk about externalish hacks next.
Firstly, Support Rework Rework supports easy integration with Base Convos. Refer to my post about that hack for instructions on how to use it.
SupportReworkDefinitions.event defines a single additional base conversation macro,
baseSupport(Character1,Character2,Level), where the first two parameters are the character IDs of the two supporters, and
Level is the support level the conversation should try to raise to. If the current support level is not one less than the current level (or nonexistent if the level to raise to is 0), then the conversation will not be viewable. If you DON’T want to use base convos, that’s perfectly fine. Just comment out the
#include "CBaseConvos/BaseConvos.event" line in
The next external hack that’s relevant is my prep screen hack which makes editing the prep screen main menu a lot less painful. I discuss what needs to be done there in the base conversation hack post. (It’s just incorporating a CSV and making an edit iirc). This is only relevant if you are using base conversations. Otherwise just ignore this.
Finally, a small hack to the CHARASM event handler is included that makes
CharacterBasedEvents-based support conversations work. It just makes it such that a character event usability routine returning 2 makes the conversation usable without making any other checks.
Support Rework Rework supports support-by-support defining of stat bonuses just like the older version but hopefully in a cleaner way. You’ll define the values you want in
This is a (nonindexed) list of support entries. Start an entry with the
entry(char1,char2) macro, then fill in your support level bonuses with the
support(level,... stats) macro. There are a couple examples in the file to start you off.
Uh what else… all that’s left is controlling supports via events I think.
Okay there are three ways to control support data:
- Adding base conversations to prep screens to allow players to increase supports there
- Adding “talk conversation-like” support conversations to allow players to increase support levels mid-chapter
- Manually changing support data via events
For base conversations, you can simply use the aforementioned
baseSupport macro, and a default event will be used. This is the simplest way to do this. If you’d like, you can also use a custom event for extra modularity. Writing custom base conversation events is discussed in that hack’s post. To make it a “support” convo, you can just call one of the event macros that I will discuss shortly. For the usability of the conversation to match generic support convos, use
supportLevel(Level). You’ll also likely want
textGetter(SupportBaseConvoMenuTextGetter|1). If you know what you’re doing, feel free to make your own custom alternatives to these generic functions!
Next, talk conversations. I’ve designed the system to make support conversations function just like mid-chapter talk conversations. Whenever you want the player to be able to increase a support, use one of the
SupportConvo macros defined in
CharacterBasedEvents. If you provide just a text ID for the last parameter, a generic event will be used to play the text then increase the support level. If you choose to pass in an event, it will play that event instead. This should be pretty straightforward.
Finally, you can pretty easily change support data. Macros to do so are also in
SupportReworkDefinitions.event for use in event scripts with descriptions. I think these are pretty straightforward as well. I think these should work pretty well, but let me know if you hit unexpected behavior with these.
SetSupport will make a new support if one doesn’t already exist. If you try to add a support with max supports or if you try to increase a max level support, nothing should happen.
Small note: Any character ID of 0xFF is interpreted by the system as representing whoever is in the first character struct. This was useful to me, and I left it in because why not.
Oh. Last thing is stat screen stuff. I’ve hooked into the vanilla function that draws supports to… well draw the new supports. In your modular stat screen, you should just need to call that vanilla function (it should be in MSS defs) to draw supports. What I use for page 4 RText is included. (Thanks again to gamma for the support RText system!)
That should be about it I think. Let me know if anything weird happens, and have a nice day!