More hairstyles

[linkanon]

Is it possible to add alternative hairstyle slots for cards?

The way I imagine it you'd have to store the alternative hairstyles(slots, flips, lengths, possibly color) and a copy of the original hairstyle in the AAU data.
In the game you'd have to add some kind of trigger(s) to switch between them(either a keypress, period, day of the week, going on a date, outfit, etc.) When it fires you basically set the card hairstyle to the predetermined alternative(like pony tail for sports periods) and switch it back when you don't need it.
No idea on how to go about the maker UI though. Maybe another number field called hairstyle or a preset number of styles(4?) with multiple tabs. Maybe even set the triggers in the maker?

As I understand it's simple to store the needed data and the whole work would be making it work in game.

[AA2Hackanon]

Sounds like a lot of work, but it should be pretty easy to implement from a technical perspective. I already have the global class roster and the char data structs, so applying the hair at run time would just be a few variable assignments. The Events you mention are mostly easy to find as well; outfit, day of the week and periods are all simple variables whose changing code can be found by simply putting a breakpoint on it, date is a npc->pc interaction which is pretty much already existent as an event, the key stuff might be a little weirder as i would either have to find the games tick function or implement some kind of key listener, but both are certainly possible.

First thought about implementing this:

• add a listbox with hair-styles. Each hairstyle consists of the 4 picked hairs, the additional hairs, maybe color
• there is a static hair style labled "default" thats always there; non AAU cards or cards without additional hairstyles will operate on default
• additional hair styles can be created and given a name
• a second listbox that lists event -> hairstyle pairs that define when the character changes to which hairstyle
• one can click a hair style to "select it"; the maker will load the hair settings, and any changes done in the maker will affect this hair style
• additional chunk in aau card data saves additional hair styles, default is built from the original card data and the current chunk for additional hairs

Potential problems:

• conflict with overrides / mesh texture overrides do not differentiate between hair styles, having two hairstyles with e.g different highlights would be impossible
• special handling for default hair styles as those parameters are not saved in the aau card data
• incomplete event list might cause awkward situations (e.g if change to gym outfit changes hair to pony tail but no other outfit has an event, changing outfit back to school outfit will keep the pony tail, or girl will keep date stuff after the date is over (how does that one work anyway, date is a single line))

sounds good enough? other ideas?

[linkanon]

Having a key listener opens up lots of opportunities for additional user actions later on(masterbation, follow etc.). I had a wild idea of spawning a separate window for AAU-specific actions stylized as a smartphone screen but it's a lot of work designing and wiring it up and is out of the current scope imo.

On implementation:

• Since the maker operates with slots for everything, we can add alt slots counter that starts with 0 and increments whenever we add a hairstyle. This way we can have just 4 additional buttons for the navigation: add(copies current)/remove(goes back to previous) hairstyle, next/previous hairstyle. In the maker switching between them will load the models defined by the hairstyle slots. Similarly, although it might not be worth it due to bloat, instead of limiting ourselves to hairstyles we can store the whole body data in alt slots, might be useful for non-OCs that have multiple forms or in general more dynamic variety(super saiyan, demonic possession, vampires/zombies, girls that get fat after lunch or get slim after exercise, girls covered in semen after H etc).
• for compatibility with non-AAU cards the vanilla data simply stores current hairstyle instead of default. In this case all AAU cards would have at least a copy of their default hairstyle called "default".
• yeah, name is handy to have.
• instead of listing pairs we can simply have a drop-down list with all the available triggers for the current hairstyle(or body if we go that route). Each trigger might have additional parameter(s) in the separate drop-downs so it's stored like [name mode value] e.g. [keypress toggle F5]
• having buttons for navigation like [prev|remove|add|next] would get the same effect. After you switched to another hairstyle all your changes are applied to that style. Can be done by substituting the current hairstyle in the maker and restoring the default hairstyle as current right before saving.
• I think having the default data as the working set is more convenient. This way after we switch to alt it behaves like the regular hair for all intents and purposes. In case we need to switch to something else or restore default we can read the memorized styles and set the vanilla data to whatever we need. The AAU data block would looks something like:
  • int iAltSets (counter)
  • arrAltSets[iAltSets + 1] (arrAltSets[0] always stores a copy of the default set)
    • string name
    • <trigger info>
    • <hairstyle data>

On potential problems:

• is it possible to differentiate them by .xx instead? Right now setting different highlights for different hairpieces also doesn't seem possible without making new hair mod with baked-in highlight. Archive redirects would still work even if complicated due to multiple sets.
• not sure what you mean. If we use the vanilla data as the current set no special handling required aside from switching it out when a trigger fires.
• in some cases it might actually be the intent. It can be solved by having trigger modes such as:
  • toggle - will simply set this set when the trigger fires and set the default when it fires again
  • random - switches between similar triggers randomly, e.g. [keypress random F5] will randomly switch between all sets that are assigned to [keypress random F5]
  • temporary - depends on the trigger but the idea is to revert to default set after the event "expires". Say, [period_type temporary swimming_class] will reset to default after the swimming period ends.
  • permanent - will overwrite the default set once fired and disable the trigger. Can be used for drastic changes like pure girls turning into sluts. Here having body sets shines because you can make a default pure girl set and her gyaru form for when she has sex 100 times/has more than 5 partners(another possible trigger).
  • delayed - acts like toggle but the changes are noticeable after another event fires. Say, [had_sex_100_times delayed next_day] will change the girl to her slutty set the next day.
• for dates in particular the idea was to consider the whole Sunday to be the "date day". Basically all the girls you asked for a date that day would look fancier the whole day. Also, even though it is not this issue's scope, people were asking for a casual wear for the sundays/dates. Could be done by embedding a sunday.cloth file into the card.

I like how it looks overall but it is a lot of work, mostly the triggers part. Imo it can be started after some kind of comprehensive event system is done because it can be used for much more(like adding exploitable to characters who lost a fight). It should support adding new triggers later down the line. Don't think I could help you with it though, since even if I know how to work with events I don't know how to write them. I could help with the fiddly code though.